[xsd-users] tools generating classes from schema

[Boris Kolpackov]

Good day,

There was a post on the xmlschema-dev at w3.org mailing list where its
author provided a list of features and asked for feedback on how well
various data binding tools support those features. I provided the
information for xsd which some people on this list may find interesting.

The archive of the thread is available at

http://lists.w3.org/Archives/Public/xmlschema-dev/2005Sep/0002.html

My reply is quoted below.

-boris

----- Forwarded message from Boris Kolpackov <boris at codesynthesis.com> -----

From: Boris Kolpackov <boris at codesynthesis.com>
Subject: Re: tools generating classes from schema
Date: Wed, 7 Sep 2005 11:09:10 +0200
To: Paul Kiel <paul at hr-xml.org>
Cc: xmlschema-dev at w3.org, wsinterop at lists.hr-xml.org

[Apologies if this is the second copy you received.]

Paul,

Here is the information about xsd, an XML Schema to C++ translator.
You can find out more about this tool at

http://codesynthesis.com/products/xsd/


Paul Kiel <paul at hr-xml.org> writes:

> The key constructs that cause problems when creating classes are:
>
> 1) xsd:union.  - This is the least supported feature of our schemas. We
>    had already been considering removing these as bad design anyway, so
>    this may add some force to that effort.

This is not supported.


> 2) xsd:pattern  - This is supported by some tools and not others.

This is supported.


> 3) having an element and a type with the same name.

There are two cases to consider. The first is when a global element
and a global type have the same name, e.g.,

<xsd:complexType name="hello"/>
<xsd:element name="hello" type="hello"/>

This case is supported.

The other case is when a type and an element inside this type have
the same name:

<xsd:complexType name="hello">
  <xsd:sequence>
    <xsd:element name="hello" type="xsd:string"/>
  </xsd:sequence>
</xsd:complexType>

This case is not supported.


> (also a problem even if casing is different, as in a "MyType" element and
> a "mytype" attribute)

There is no such problem in xsd.


> 4) recursive content models

This is supported.


> Other oddities that only cause problems in some tools:
>
> 5) extension of complexTypes - XSDObjectGen in particular has a problem
> with this, which seems odd as this is a major design feature of xml schema.

Works as expected.


> 6) simpleContent extension using a xsd base type

Works as expected.


> 7) reserved keyword element names (such as "Value")

All identifiers are properly escaped. Note that besides keywords, you may
also want to check for characters that are illegal in identifiers in most
programming languages but legal in XML Schema (e.g., '-').


> 8) too many anonymous types can lead to some class name collisions when
>    classes are generated

There is no such problem in xsd since all anonymous types are mapped to
nested types (i.e., we don't "flatten" the object model). For example,
this XML Schema definition

<xsd:complexType name="hello">
  <xsd:sequence>
    <xsd:element name="name">
      <xsd:complexType>
        ...
      </xsd:complexType>
    </xsd:element>
  </xsd:sequence>
</xsd:complexType>

will result in the following C++ class definitions:

class hello
{
  class name
  {
    ...
  };

  ...
};


> 9) enumerations in elements (enumerations in attributes worked fine.
>    wierd but true for a tool to remain nameless)

Works as expected. Also note that we map XML Schema enumerations to
C++ enums.


> Here are features we don't even use, so we can't comment on (but suspect
> there may be possible problems):
>
> A) substitutionGroups

Not yet supported. We however plan to support this along with other instance
polymorphism mechanisms (e.g., xsi:type).


> B) redefine

Not supported. Note that this is one of the "questionable" features of XML
Schema (along with unions, as you pointed out) that don't map cleanly to the
target programming language.


> C) abstract types

Somewhat supported. Right now we simply ignore this attribute since it is
more of a validation feature. I guess we could make the generated d-tor
pure virtual to make the type non-instantiable.


> D) nillable

Can be supported should there be any interest.


> E) complexType restriction

Not supported. There is no natural mapping of this feature to the object
model of the target programming language. In particular, if we map
restriction to inheritance then we break the substitutability principle
(the derived-by-restriction type is-not-a base type). Probably the best
approach would be to generate a completely unrelated type.


> F) list types

Can be supported should there be any interest.


You may also want to check the "planned feature list":

http://codesynthesis.com/projects/xsd/documentation/future.xhtml

hth,
-boris

----- End forwarded message -----
-------------- 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/20050907/7e29d86f/attachment.pgp