W3C home > Mailing lists > Public > xmlschema-dev@w3.org > September 2005

Re: tools generating classes from schema

From: Sekhar Vajjhala <Sekhar.Vajjhala@Sun.COM>
Date: Wed, 07 Sep 2005 07:16:24 -0400
To: Paul Kiel <paul@hr-xml.org>
Cc: xmlschema-dev@w3.org, wsinterop@lists.hr-xml.org
Message-id: <431ECC08.2000102@sun.com>

JAXB 2.0 (being developed in JCP as JSR 222) provides support for
all of XML Schema features.

JAXB 2.0 consists of both a specification, a RI (Reference 
Implementation) that
implements the spec, and TCK (for compatiblity testing by JAXB Providers).
Both the spec and RI can be downloaded from https://jaxb.dev.java.net .

Sekhar Vajjhala

Paul Kiel wrote:

> Folks,
> I am interested in people's experiences with code generation tools.  
> We have found several key constructs that cause problems with these 
> tools.  Don't know if people have work arounds or recommendations on 
> better tools.  We would love to recommend tools for our member 
> companies who are asking us for advice.
> So far, we have reports on Castor, XSDObjectGen, XSD.exe (ships with 
> vs.net), and CodeXS (built on xsd.exe).  I hope to get reports on Axis 
> and I believe XMLBeans sometime soon.
> 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.
> 2) xsd:pattern  - This is supported by some tools and not others. 
> 3) having an element and a type with the same name. (also a problem 
> even if casing is different, as in a "MyType" element and a "mytype" 
> attribute)
> 4) recursive content models
> 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.  
> 6) simpleContent extension using a xsd base type
> 7) reserved keyword element names (such as "Value")
> 8) too many anonymous types can lead to some class name collisions 
> when classes are generated
> 9) enumerations in elements (enumerations in attributes worked fine.  
> wierd but true for a tool to remain nameless)
> Here are features we don't even use, so we can't comment on (but 
> suspect there may be possible problems):
> A) substitutionGroups
> B) redefine
> C) abstract types
> D) nillable
> E) complexType restriction
> F) list types
> I would very much be interested in a code generation tool that 
> supports # 1-9 above if you know of one.  (Of course I also want a 
> million dollars to appear in my bank accout.)
> Paul Kiel
> HR-XML Consortium
Received on Wednesday, 7 September 2005 11:19:20 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:56:08 UTC