[xsd-users] Parsing the Collada 1.3.1 XSD

[mark_barnes at playstation.sony.com]

On Wed, 2006-01-04 at 11:24 +0200, Boris Kolpackov wrote:
> 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'.

Yeah. It's gone in COLLADA 1.4.0. We've tightened up the sequencing alot
and eleminated most unordered choice groups.

> > > 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.

Right, I see. I think we have named a lot more of the types in COLLADA
1.4 and created many abstract base types and substitution groups as
well.

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.

> 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.

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!

> The second approach translates anonymous types to nested C++ classes.

This is what we having be favoring ourselves.

> 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.

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

Well we can named all our types and still used nested classes in the
design. So perhaps there is a middle ground on this? To limit bloat you
really have to limit the unique types of elements in the schema. In
COLLADA 1.4 we have gone towards more strongly-typed elements and more
of them because we want to leverage schema validation a great deal.

> 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

Thanks I'll take a look at it. I think I read parts of it before as we
were desiging COLLADA 1.4. Perhaps we have applied some of the
lessons :)

Regards,
Marcus



-- 
Mark Barnes
COLLADA Project Lead, tel:+1.650.655.7342
Sony Computer Entertainment America
http://research.scea.com