Re: tools generating classes from schema

Paul,

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 .

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