Ryan,
Thank you for the response, I believe I understand the issue better
now. We are still unsure as to which route to take however. While the
proposed work around I have suggested, swapping the <extension>
<restriction> elements in our Schemas works for the immediate case, it
does not allow for people to be able to extend our Schemas and use java
binding in the future. We are really trying to provide a set of
Schemas which can act as a base or foundation for customization that
literally hundreds of other organizations may need to make.
Also, by swapping the <extension> <restriction> elements, the
conceptual approach used in designing the Schemas is completely thrown
out of the window. It moves the trimming down of the base elements to
the outer most layer of abstraction, while placing the customized types
in the middle layer of abstraction...
However, as you stated, the type extensions are not well supported in
JAX-B, or indeed implementable as traditional java types.
Any other advice, comments, etc is very appreciated.
Jim
On Wednesday, February 18, 2004, at 09:52 AM, Ryan Shoemaker - JavaSoft
East wrote:
> Jim Beard wrote:
>
>> Howdy all,
>> I work with a company that is trying to use JAX-B generated code
>> in a number of projects. The most recent one involves a rather
>> complex set of Schemas. In these Schemas there are complexTypes
>> defined using extension from other complexTypes. Some of these
>> complexTypes are based off of other complexTypes using restriction.
>> XmlSpy validates everything, as does a recent SAX parser. However
>> xjc spits out errors when I try to use JAX-B to generate code from
>> the Schemas, and no code is generated. The errors look like this:
>> [ERROR] Base complex type is derived by restriction, while this
>> complex type is derived by extension
>> This problem occurs 5 or so times throughout the Schema. We have
>> a little bit of control over the Schema we are using ( though another
>> company is mainly responsible for it ). However we have no control
>> over the base Schemas that this Schema uses in its namespace.
>> I tried running with '-extension' and adding in the
>> complexTypeSubstitution attributes, but still no luck. Does anyone
>> have any experience with this problem or any advice to offer?
>> NOTE: I found a work around now by swapping the extension and
>> restriction elements of the complexTypes, so the that our base type
>> uses extensions and the final type is a restriction. This seems to
>> work. However, it is not an optimal solution due to the fact that it
>> changes the approach of what types of data elements are being defined
>> in which Schemas.
>> I have been reviewing section 3.4.6 of the w3c Schema
>> specifications to see if this is a problem with our Schemas, or with
>> JAXB. Anyone have an opinion on this matter?
>
> Hi Jim,
>
> From what you've described, it does not sound like there is anything
> illegal
> in your schemas. The problem is that this type of schema derivation
> hierarchy
> is very difficult to map to a Java object inheritance hierarchy. Java
> has
> no concept of "derivation by restriction" - roughly speaking, there is
> no way
> for a sub-class to only inherit a portion of it's baseclass. The JAXB
> spec
> (sec 5.3.2) sort of glosses over this issue because there really isn't
> a good
> solution. It covers simple derivation by restriction, but handling a
> type
> that derives by extension from a type that derives by restriction is a
> whole
> other beast. As a result, the RI punts on the issue and flags it as
> an error.
>
> It sounds like you might have enough wiggle-room in your schemas to
> work
> around the issue though.
>
> Thanks,
>
> --Ryan
>
>
>> Jim Beard
>> counterclaim.com, Inc
>> http://www.counterclaim.com
>> http://openefm.sourceforge.net
>> (800) 264-8145
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jaxb.dev.java.net
>> For additional commands, e-mail: users-help_at_jaxb.dev.java.net
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jaxb.dev.java.net
> For additional commands, e-mail: users-help_at_jaxb.dev.java.net
>
>
Jim Beard
counterclaim.com, Inc
http://www.counterclaim.com
http://openefm.sourceforge.net
(800) 264-8145
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_jaxb.dev.java.net
For additional commands, e-mail: users-help_at_jaxb.dev.java.net