[xsd-users] Parsing the Collada 1.3.1 XSD

[Boris Kolpackov]

Marcus,

mark_barnes at playstation.sony.com <mark_barnes at playstation.sony.com> writes:


> I'm not sure if inline use of complexType, group, and sequence counts
> towards anonymous types or not though. We still do that in places.

Only <complexType> and <simpleType> definitions without the 'name'
attribute result in anonymous types.


> I'm glad you have a workaround. If you want to propose a particular
> approach to the COLLADA schema elements I'm open to hear it. We use code
> generation too and favor that approach so ideas that make that work
> better are welcome!

I tried to find COLLADA schema 1.4 but all I can get is 1.3.1. I could
run xsd on it see if there are any warnings wrt anonymous types and code
bloat.


> > This, however, may result in several copies of the same class being
> > generated at different levels which, in turn, results in code bloat
> > (xsd issues warnings when this happens). This approach does not work
> > very well for your schema.
>
> We used nested elements alot more in COLLADA 1.4. It seemed a natural
> approach to limit the vocabulary of the schema while specializing the
> elements based on their context. C++ supports this with nested classes
> and yet I do see how this can be code bloat not unlike using templates.
> But I don't view it as bloat exactly since <camera><technique_common> is
> a different class then <light><technique_common> for example.

Right, if technique_common inside camera is of a completely different
type compared to technique_common inside light, there is no code bloat.
Nothing significant will be achieved if those types are explicitly named.
However, if you have a schema like this:


<element name="technique_common">
  <complexType>
    ...
  </complexType>
</element>


<complexType name="Camera">
   <sequence>
     <element ref="technique_common"/>
   </sequence>
</complexType>


<complexType name="Light">
   <sequence>
     <element ref="technique_common"/>
   </sequence>
</complexType>


Then Camera and Light types will each have its own copy of the
technique_common type. Those copies will be identical and can
be replaced with one global type:


<complexType name="TechniqueCommon">
    ...
</complexType>

<element name="technique_common" type="TechniqueCommon"/>

<complexType name="Camera">
   <sequence>
     <element ref="technique_common"/>
   </sequence>
</complexType>


<complexType name="Light">
   <sequence>
     <element ref="technique_common"/>
   </sequence>
</complexType>


Now both Camera and Light will use the same global TechniqueCommon
type.


> Well we can named all our types and still used nested classes in the
> design. So perhaps there is a middle ground on this?

You probably mean nested elements here? You can use nested elements
regardless of whether you name your types or not. In fact, any schema
with anonymous types can be transformed to an equivalent schema (from
the validation point of view) that does not use any anonymous types.

hth,
-boris
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 652 bytes
Desc: Digital signature
Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20060105/1f0cc4d6/attachment.pgp