Xsd.exe errors?

Hi,
I’m new to Collada so I decided to start it easy and try to generate classes from the COLLADASchema_141.xsd. When I run it on the commandline I get following error.

xsd /classes /language:CS COLLADASchema_141.xsd
Microsoft (R) Xml Schemas/DataTypes support utility
[Microsoft (R) .NET Framework, Version 2.0.50727.42]
Copyright (C) Microsoft Corporation. All rights reserved.
Error: Error generating classes for schema 'COLLADASchema_141'.
  - Group 'glsl_param_type' from targetNamespace='http://www.collada.org/2005/11
/COLLADASchema' has invalid definition: Circular group reference.

If you would like more help, please type "xsd /?".

Is this bug in the schema or in the xsd.exe tool?

I also tried to generate dataset from it using the same commandline tool but I get following error:

xsd /d /language:CS COLLADASchema_141.xsd
Microsoft (R) Xml Schemas/DataTypes support utility
[Microsoft (R) .NET Framework, Version 2.0.50727.42]
Copyright (C) Microsoft Corporation. All rights reserved.
Writing file 'COLLADASchema_141.cs'.
Error: There was an error processing 'COLLADASchema_141.xsd'.
  - Error generating code for DataSet ''.
  - Unable to convert input xml file content to a DataSet. The 'http://www.w3.or
g/XML/1998/namespace:base' attribute is not declared.
  - The 'http://www.w3.org/XML/1998/namespace:base' attribute is not declared.

If you would like more help, please type "xsd /?".

So no luck with it either. If anyone could point me to the right directions with this?

which version of Visual Studio you are using ?
The 2003 version has several bugs, it should have need fixed in 2005.

I’am using Visual Studio 2005 Professional version.

The Xsd.exe which I tried to use is located at C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin\xsd.exe. I could not locate a duplicate of the utility in my system so it should be the newest one.

I did manage to create a data classes by using XMLSpy but it adds it’s own framework to the mix which I don’t want. Anyone has a code tempelate avaible for it which uses generic .NET xml nodes or other less intrusive classes?

Can you report this bug to Microsoft please ?

Can you make sure that the <xs:import> that supplies the xml:base declaration is not commented out? Since the error message includes the whole namespace for “base” it seems like it is being parsed but then it looks like the import directive may not be supported in VS8 completely?

marcus, you are using the xsd.exe from the vs2003. The error we are talking is in vs2005. I’ve managed to convert to C# classes after I commented out the GLSL part, the CG part and the GLES part(this one because of the GLSL). There are only 2 errors, which are similar, one is in GLSL and one in CG, they are related to groups glsl_param_type and cg_param_type and the error is the same : circular group reference.

Actually I have access to both versions. The error message quoted is not from me.

This bug needs to be posted to www.khronos.org/bugzilla I think.

The bug isn’t in the schema. The XML Schema language allows for circular references and we use them in the effects parameters. The problem is that MSXML doesn’t allow for that.

When I was working on 1.4 support for the DOM the circular references were a problem but I created a way to handle them properly. It’s not impossible and not incorrect. Just MS must think it’s not something that should be done.

I’m not sure that we can fix this in the schema either. Some of it might be pretty essential and logical to be circular. The circular reference is as follows:
The glsl_param_type and cg_param_type can have a <surface>. This <surface> can have a program to procedurally generate itself described by <generator>. <generator>, since it is a program, can have parameters that need to be set. These parameters are set using <setparam> which contains a glsl_param_type.

That makes plenty of sense to me. You may think that we can limit the type of parameters <generator> can take, thus removing <surface> and the circular dependency but I think that generating a surface based on a different surface as a parameter could be useful. Sure nobody is doing it now with COLLADA but thats not our fault :wink:

-Andy

We may be able to “hack” a solution together using substitution instead of groups. It might allow backwards compatibility with regards to validating instance documents, but any application based on classes generated from the schema, ie COLLADA DOM, would not be backwards compatible. And personaly I really wouldn’t want to work on trying to make the DOM backwards compatible with a change like that.

-Andy

Can someone report this bug to Microsoft ?
Please!

I reported this bug to MS via “MS Connect” site.
Anybody can send bug report via the site ealsily.
I was suprised about nobody sent bug report until now.

Oh one man sent the report, but he did not include schema file, so MS couldn’t reproduce the bug, and it has been ignored.

My report is listed in:
https://connect.microsoft.com/VisualStu … kID=289668
(You need MS passport account)

I have no support request right, so I cannot request support for this problem. If you have support right, you may make MS to make a hotfix for this bug. Via MS support site.

Hi,

the topic was closed unresolved by MS. :frowning:

http://connect.microsoft.com/VisualStud … kID=289668

They say they can workaround it, but I don’t have any clue how to do this myself.

Maybe someone can upload a *.xds file without these OpenGL things,
so we have a starting point after all.
I’ll try, but expect too much :wink:

Greetings

Edit: All commercial databinder/xml2code/class designer failed to create proper code, since they all use the MS XML tool and code provider.
Maybe some more names instead of references work better?

The generated code isn’t worth all that much IMO. If I were redesigning the Collada DOM from scratch I wouldn’t even include the generated classes. You would just work with the raw string data, and there’d be helper functions to do things like convert an array of float strings to an array of floats, etc. I’m pretty sure that when Remi did Collada for XNA he just used .Net’s native XML support, without any generated classes. It didn’t prevent him from getting stuff done.

Anyway that’s just my take on it. Sorry to hear that Microsoft won’t fix the bug. At least they acknowledged it I guess.

The generated classes save you all the trouble of writing code to parse XML in order to get something in memory and the trouble of writing code to emit the XML to get something out of memory. I’ve looked at doing this by hand and its a ton of work compared to using the automatically generated classes.

The bug report on connect says that the problem can be worked around by eliminating the use the the <group> directives in the schema. I will look at doing this by XSLT. The advantage of generating classes for XML I/O directly from the schema is that it removes one more opportunity for getting things wrong.

I’m pretty sure that when Remi did Collada for XNA he just used .Net’s native XML support, without any generated classes. It didn’t prevent him from getting stuff done.

Yes, I’ve looked at that code as well. It doesn’t leverage any of the builtin support for serializing structures in and out of XML in the .NET framework, so it too does many things manually that you can do automatically by getting xsd.exe to consume the Collada schema.

That’s not correct. It’s the xml parser that saves you from having to deal with xml streaming and formatting directly, not the code generator. Suppose I have this content:

<element>
    <child>
        1 2 3 4
    </child>
</element>

An xml parser will provide me with an API so I can analyze the structure of this content without having to do any xml parsing myself. This is extremely valuable and there are many C/C++ libraries that provide this functionality (libxml, xerces, tinyxml), but it has nothing to do with code generation.

With a normal xml parser the content of the <child> element would be reported as the string “1 2 3 4”, and then it’s the client’s responsibility to deserialize that into data types native to the language. This is what code generation can help you with. Although it sounds good in theory, in my experience the benefits are outweighed by the sheer enormity of the generated code, which aside from making the API larger also drastically increases the size of your binaries and makes compilation take much longer.

I’ve looked at doing this by hand and its a ton of work compared to using the automatically generated classes.
It’s important to keep in mind that we’re only talking about deserializing strings into native types, not parsing xml. IMO deserialization is trivial to implement, and with the right set of helper functions it isn’t too much of a burden on client code either (though I’ll certainly admit that it’s a burden).

I spent a lot of time working with the DOM, client code, and the DOM’s code generator. I also spent some time using the more conventional xml parser interface provided by C libraries like libxml, and built-in to languages like Python with its minidom API. I vastly prefer the latter.

Steve

That’s not correct. It’s the xml parser that saves you from having to deal with xml streaming and formatting directly, not the code generator.[/quote]

Are you familiar with how Xml serialization works in .NET? Because based on the above, it seems that you aren’t.

Xsd generates classes with appropriate Xml serialization attributes on them. You then can deserialize an Xml document into the generated classes with a few lines of code. Similarly, you can serialize the data in the classes in memory into an Xml document with a few lines of code. I don’t even need to call a parser directly, much less write one. The serialization classes in the .NET framework handle all of this for me.

Suppose I have this content:

<element>
    <child>
        1 2 3 4
    </child>
</element>

An xml parser will provide me with an API so I can analyze the structure of this content without having to do any xml parsing myself. This is extremely valuable and there are many C/C++ libraries that provide this functionality (libxml, xerces, tinyxml), but it has nothing to do with code generation.

I never said that Xml parsers weren’t valuable. They are and .NET provides classes that do the Xml parsing if you want to do it yourself, but that is doing things the hard way in .NET since Xml serialization/deserialization is available by simply putting the right attributes on your data structures. Xsd.exe generates classes with the appropriate attributes to be able to serialize and deserialize documents matching the supplied schema directly from and into memory.

I spent a lot of time working with the DOM, client code, and the DOM’s code generator. I also spent some time using the more conventional xml parser interface provided by C libraries like libxml, and built-in to languages like Python with its minidom API. I vastly prefer the latter.

…however, all of that is from C/C++ and not .NET, so its not really relevant to this discussion because we are talking about .NET, xsd.exe’s ability to generate Xml serializable classes from a schema and the Xml serialization framework built into .NET. Xml serialization goes way beyond just getting the string “1 2 3 4” from your example; if your schema said that the <child> element contains a list of integers, then Xml serialization would turn this into an array of ints and not just give you a string.

Lol, ok.

xsd.exe does the same thing that the Collada DOM’s code generator does: creates a set of classes that act as an xml data binding. You were saying this generated code saves you from having to deal with xml parsing yourself. My point was that even if you aren’t using a code generator (e.g. if you don’t have a schema), you don’t have to do any xml parsing yourself. Instead you use an xml parser for that, whether you’re in C or C#. In that case what you have to do manually is string serialization, not xml parsing. I have to convert “1 2 3 4” into an array of integers, but I don’t have to parse the xml markup manually at all.

Ok, hopefully we agree about that. Now the question is if the extra convenience provided by the code generator (it’ll automatically convert “1 2 3 4” into an array of ints) is worth the hassle of dealing with the code generator (and it’s bugs, like the one you’re trying to work around in xsd.exe) and the hundreds of files of generated code that result from processing the Collada schema. In my opinion it isn’t worth it, but that’s certainly debatable and I accept that a reasonable person could have a different view.

…however, all of that is from C/C++ and not .NET, so its not really relevant to this discussion because we are talking about .NET
I don’t see how this discussion is language specific at all.

But you have to do much more than that. You have to encode all the knowledge of which nodes are allowed as children, which attributes apply to which node types, which values are enums, which are strings, which are ints, which are floats, which are lists of ints, which are lists of floats, etc. Collada is not exactly a trivial schema to handle, even if the low-level “I read the start of a tag, its called instance_geometry, it has these attributes and these child nodes” business is handled for you by a generic Xml parser.

Xsd’s processing of the schema handles all of that stuff for you. You don’t need to code all of that yourself.

Now the question is if the extra convenience provided by the code generator (it’ll automatically convert “1 2 3 4” into an array of ints) is worth the hassle of dealing with the code generator (and it’s bugs, like the one you’re trying to work around in xsd.exe)

First, as I’ve already said above, its doing a lot more than just parsing “1 2 3 4” into an array of ints. Second, it strictly speaking isn’t a bug in xsd.exe because its limited support for <group ref=“”> schema tags is documented, even if it is annoying. Finally, the hundreds of files generated (assuming one per schema item) is exactly my point. If I can get something to generate the appropriate classes from the schema directly, then that’s hundreds of files that I don’t have to write. If you want to handle Collada in its full glory, then you need those hundreds of classes. If you just want to do a quick hack to extract some piece of information for your application, then you can scrape it out with any old Xml library, but your application will not be robust in terms of the variety of collada files that are legitimate vs. the variety of files your application can eat with its limited hand-crafted Xml scraper. By the time you go through all the work of hand-crafting all the support in the Collada schema, then you have just duplicated the hundreds of classes generated by Xsd.

[quote:i01p8k8z]…however, all of that is from C/C++ and not .NET, so its not really relevant to this discussion because we are talking about .NET
I don’t see how this discussion is language specific at all.[/quote:i01p8k8z]

.NET isn’t a language, its a platform. Xsd can output the generated source in C# or in VB.NET or in a number of other languages. My comments are not related to a specific language, but to the fact that .NET provides an infrastructure for Xml marshalling and unmarshalling already. The easiest way to utilize that infrastructure from a schema document is to use Xsd to generate the classes instead of writing them by hand.

However, even if you were to decide to write your own data binding by hand, it would be lots more work to use XmlDocument, etc., classes instead of using Xml serialization. All the existing bindings for .NET that I can find out there do things the hard way by manually scraping stuff out of the XmlDocument, but they don’t add any value over what the Xml serialization classes would have gotten you in the first place. Furthermore, because those classes were not automatically generated from the schema, which is assumed to be correct, each one of those hand-written classes has to be unit tested and validated to give the correct results for the wide variety of valid collada inputs.

Finally, if there is a bug in the schema and an updated schema is made available, if I can use xsd.exe then I can pick up those corrections automatically, otherwise I have to sift through the differences between the original and updated schemas and manually update my binding classes to incorporate those changes. Then I’ll have to update my application functionality built on top fo the data binding, but I’d have to do this no matter what if the schema is updated and I want to support the updated schema. With Xsd, I have less work because I’ve automated part of the process.

Second, it strictly speaking isn’t a bug in xsd.exe because its limited support for <group ref=“”> schema tags is documented, even if it is annoying.
By your logic, any bug that has a bug report filed against it is no longer a bug since it’s documented. Call it whatever you want, but it’s a defect of their product that you now have to work around.

Finally, the hundreds of files generated (assuming one per schema item) is exactly my point. If I can get something to generate the appropriate classes from the schema directly, then that’s hundreds of files that I don’t have to write.
Ah, this is the heart of our disagreement then. You view these files as necessary whereas I don’t.

Let’s say I wanted to write a lib to import Collada into my rendering engine. I would break this down as involving three tasks:

(1) Load and parse the xml (15%)
(2) Serialize the string data to native language types (5%)
(3) Convert Collada’s data structures to my rendering engine’s data structures (80%)

I’ve also written my estimation of how much of the whole project each task would take. For loading and parsing the xml I’m going to use a library, so that’s not an issue. From my perspective, the only thing schema generated code would save me is the serializing to/from native language types, but that represents a tiny part of the overall work, so it doesn’t seem like a big win at all.

I imagine your perspective of the workload is different:

(1) Write a class data binding for every type in the schema. This data binding handles both parsing the xml and converting to native language types. (90%)
(2) Convert Collada’s data structures to my rendering engine’s data structures (10%)

Since you’ve already accepted that you need an xml data binding, your perspective on the workload is nothing like mine. Here there’s much more work to be done overall than in my workload, but the code generator is taking on the vast majority of the work, so it seems extremely valuable. But just like in my workload, you still have to write the conversion from Collada to your engine. In either case this is where the bulk of your time will be spent. I’ll need to spend a little extra time writing a few serialization routines, but I think that’ll be outweighed by the extra time you have to spend working around bugs in the code generator and managing all the generated code files.

Let’s say I wanted to write a lib to import Collada into my rendering engine.

That is not what I’m doing, so its irrelevant to my needs.

You imply once again that the only role played by the generated classes from xsd is to serialize the string data to native language types. However, I’ve already explained that there is much more going on than that, unless you really don’t care about the Collada schema. A library that only parses XML doesn’t know which nodes are allowed as child nodes, it doesn’t know which attributes are allowed on which nodes and it doesn’t know about the data types defined by the Collada schema.

I imagine your perspective of the workload is different:

Sorry, but your imagining is also incorrect.