Hi,
I am in the process of finishing up a new XML parser generator. I wrote it because none of the tools in existence (that I am aware of) allow me to customize the generated model. Sure there is COLLADA_DOM, but since the actual tool to generate it is not available it leaves you resorting to dynamically parsing the Extra/Technique data; its a real pain. So I wrote one. For those interested it will be open source and I will release details soon.
The main point I was solving in writing my own parser was related to easing the use of generated XML grammar objects by allowing customization. COLLADA proved a shining example with its ID/SID addressing scheme which works well when its handled by the generated tree, and sucks when you have to do it by hand.
So the real meat of the post. In my travels I came upon the extra/technique scheme for allowing extended data. The problem I had with it was trying to generate a parser from an extension grammar that would build strongly typed elements from inside the technique element.
My first attempt at solving the problem was to check every known element; that takes forever and was off the table immediately. So I turned to fooling around with my parser generator. I added annotations that hint to the parser generator what might be inside a technique element. With the problem set reduced it could now efficiently determine and build elements of the proper type. Well it was about that time that I realized XMLSchema already had this functionality as substitution groups. The only problem was technique was a global element with a local type, and the type was therefore not addressable. If it was a global type it could be used as a substitution group in an extension grammar and problem solved.
Is this thinking correct? Would using it as a substitution group allow me to properly (inside the XMLSchema system) strongly type techniques for my own use? It seems to me yes, but I always seem to be getting stuck on the nuances of XMLSchema. I would love to see the ability to extend my own type from a Technique type and restrict its “profile” attribute to something I choose, while adding my own new elements as children.
Secondly, the intended use of the extra nodes seems to be to contain a single type of information that can be switched out with techniques. I gleaned this from the examples given in the LOD discussion. What, if any, mechanism is in place to determine what the extra’s “type” attribute should be. It seems to be just whatever the creator feels like putting in there. Is that also correct? It seems okay if that is the designed usage (especially with strongly typed techniques) since I can always investigate to find some known elements and determine if its really the “extra” instance i am looking for.
Well with the XML Schema language you don’t need to define any base type to allow substitution. Any xml element declaration can have the substitionGroup attribute. The value of the attribute is the name of the element that this element can substitute for. ie. <xs:element name=“mySpecialTechnique” substitionGroup=“technique”> and in a instance document you could see <extra type=“blah”><mySpecialTechnique>…
Also there is a difference between xml schema substitutionGroups and type extension (inheritance). The substitution is much easier to deal with. I wouldn’t even bother dealing with schema extension for polymorphic behavior.
Yes there is no rhymn or reason to extra type names. As a proprietary extension mechanism the names are left to the person creating them. I would highly suggest people use something that makes sense but thats just a suggestion.
On a side note, I wish we had discussed this (maybe we did and I forgot… in that case sorry) before you went and wrote your own API and generator. I hate for people to have to rewrite existing functionality. We could have worked something out to make the COLLADA DOM work for you. The DOM does have a mechanism for allowing strongly typed proprietary extensions. At the moment it’s a bit of a hack but I had plans to make a really nice system for it. But nobody was requesting this functionality so we couldn’t devote resources to it. In a nutshell the system would let you write your own xml schema, have the code generator available online to generate your DOM classes, and then let you register them with the DOM. There are a lot of hurdles though, dealing with xml namespaces, etc. But without a whole infrastructure in place it is still possible to generate your own DOM classes. And I would have been happy to help you in doing that. Currently the DOM’s <extra><technique> allows for any elements. They take the form of domAny objects, but before creating a domAny the DOM searches through it’s existing classes looking for a match. Only global schema elements can match, but then the DOM would create one of those. So if you registered your own dom elements the mechanism would find and create your own strongly typed classes for you. And you get all the other functionality the DOM provides. Someone else had similar concerns here
Well with the XML Schema language you don’t need to define any base type to allow substitution. Any xml element declaration can have the substitionGroup attribute. The value of the attribute is the name of the element that this element can substitute for. ie. <xs:element name=“mySpecialTechnique” substitionGroup=“technique”> and in a instance document you could see <extra type=“blah”><mySpecialTechnique>…
Also there is a difference between xml schema substitutionGroups and type extension (inheritance). The substitution is much easier to deal with. I wouldn’t even bother dealing with schema extension for polymorphic behavior.
I might be missing something but all element types in a substitutionGroup must extend the substitutionGroup head element correct? That seems to be the way the spec. reads to me, and it is what my validator is telling me. COLLADA’s fx_profile_abstract sidesteps this by making the element abstract and having no type declared. The technique element is defined as having a local complexType. To satisfy the extension requirement for substituionGroups the technique needs a named global type to allow other group members to derive from it.
Yeah you are right. Wow I can’t believe I missed that on my many look throughs of the XML schema spec.
Please submit this as a feature request to the Khronos bugzilla. Such an easy fix to make (which doesn’t invalidate any existing data) can be added to the next version of the COLLADA schema.
Unfortunately, until then you are stuck working with the way it is. Heres another way around it. It’s only slightly more confusing than substitionGroups. Use XML Namespaces. The xmlns attribute can be added to any element in a document. if you have a special schema defining your elements you want strongly typed, in COLLADA add the xmlns to the technique element.
This is how I imagined an API that would take advantage of this. Maybe you can make it happen with your API. Have the base set of elements (COLLADA) generated for your API. They can be hardcoded to always register themselves. Then generate the elements for whatever extra schema. Have a registerSchema( function* ) function in your API so you can include whatever extra generated classes you want (ideally your generator would generate a top level register function which can be passed to this function). Then when your parser comes accros the element <mine:StronglyTypedElement> it will know how to create it and what attributes and element children are allowed.