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.