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 understand this point very well, but I don’t view it as important. Having validation handled separately by an xml schema validation tool (e.g. xmllint) has always worked well for us and isn’t much of an additional burden.
It’s also important to keep in mind that the schema itself can only validate a fairly small percentage of the information contained in a Collada document. For example, suppose I’m writing a conditioner to convert polygon primitives to triangles in a Collada document. Maybe I accidentally call the <triangles> element <triangle>. With a code generator like you’re using, this should show up as a compilation error. In my case, I would detect the error when I attempt to validate the output file against the schema using xmllint.
But what if my polygon triangulation algorithm is wrong? This isn’t going to be caught by the additional checking provided by your code generator, and won’t be caught by an external schema validation tool. In my experience the great majority of bugs in Collada programs are of this sort. This is why the Collada Coherency Test program was created, and why a huge amount of time and manpower has been invested in developing the Collada Conformance Test Suite. Checking against the schema isn’t nearly enough to ensure program correctness.
Good luck with your project. Let us know if you come up with a workaround for the <group> bug in Microsoft’s code generator… I’m sure other people would benefit.
Huh? Again, it seems like you just don’t understand anything about .NET, Xml serialization support in the .NET framework or xsd.exe. What you describe above would not result in a compilation error. There is no compiling going on when you marshall an Xml document into memory using the classes generated by xsd.
Again, it seems like you just don’t understand anything about .NET, Xml serialization support in the .NET framework or xsd.exe.
This isn’t .net specific in any way at all. It has to do with generating classes to act as an xml data binding given an xml schema. You can do this in .net (via xsd.exe) or you can do it in any other language that has a schema-to-classes code generator. In my case I use a code generator that generates C++ classes, but the concepts are exactly the same. Stop trying to make this about .net.
What you describe above would not result in a compilation error. There is no compiling going on when you marshall an Xml document into memory using the classes generated by xsd.
After running the schema through xsd.exe you’ll end up with a bunch of generated classes. Now I want to use those classes to perform some task. Say I want to load up a document, then add some <triangles> elements to it. With the generated classes, you would write some code like this:
TrianglesElement tris = parent.AddTrianglesChild();
In my case, with just a bare xml parser, I would write this:
Element tris = parent.AddChild(“triangles”);
The example error I was giving was if you mistyped “triangles”. With the generated classes you get a compilation error thanks to the additional static type checking, without the generated classes (i.e. using a raw xml parser) your program compiles and runs, but you get a schema validation error when you validate the output file against the schema.
My point was that although the generated classes help you catch these types of errors, these errors are trivial to catch with a schema validation tool, so it doesn’t save you that much. The core logic errors, which are infinitely harder to detect and more common, won’t be caught by any type of schema validation or generated classes. For example, if the polygon triangulation code was buggy, you’d have just as much trouble detecting and fixing that error with your generated classes as I would with my raw xml parser.