[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:

> On Sat Dec 3 16:41:46 EST 2005, Boris wrote:
> >
> > <xs:element name="mesh">
> >   <xs:complexType>
> >     <xs:sequence>
> >       <xs:element ref="source" minOccurs="1" maxOccurs="unbounded"/>
> >       <xs:element ref="vertices" minOccurs="1" maxOccurs="1"/>
> >       <xs:element ref="source" minOccurs="0" maxOccurs="unbounded"/>
> >
> >       ...
> >
> >     </xs:sequence>
> >
> > As you can see, there are two definitions of the 'source' element.
> > I am not sure if this is intentional or a typo.
>
> It was intentional... in order to tighten the schema a little bit in
> that minor release while remaining compatible with existing documents.

I see. This complicates code generation because the second 'source'
element needs to be renamed. It also makes the generated code uglier:
nobody likes function names like 'source1'.


> > BTW, the schema uses a lot of anonymous types and is
> > heavily recursive so to avoid code bloat I used --morph-anonymous
> > options:
>
> Are you suggesting that there are some improvements to the schema that
> could be made to make it easier for tools to parse it and generate code?

It is not so much about making tool developer's life easier but
rather about the quality of the generated code. There is a number
of XML Schema constructs that do not have straightforward mapping
to most programming languages. Anonymous types are a very common
example. While C++ supports anonymous types, it is too limited to
be used for anything non-trivial (for example, an unnamed class
cannot define any constructors). So in order to map anonymous XML
Schema types to C++ classes the translator needs to come up with
some names for those types.

xsd provides two way of handling anonymous types. The first is to
automatically name all anonymous types as if they were defined
under xsd:schema element. The names for such types are derived
from element/attribute names under which they were originally
defined. While this approach works rather well in most cases, there
are possibilities of "unstable name conflicts" when a schema includes
or imports some other schemas. In this case the user will have to
manually resolve such conflicts using command line options. This
approach works quite well for your schema.

The second approach translates anonymous types to nested C++ classes.
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.

As you can see, neither of the two solutions can compete with explicitly
named XML Schema types.

We have written "XML Schema Authoring Guide" which lists a number
of XML Schema constructs that do not map "cleanly" to C++ (and most
other programming languages). It is available here:

http://codesynthesis.com/projects/xsd/documentation/schema-authoring-guide.xhtml

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/20060104/771935a5/attachment.pgp