Sekhar Vajjhala wrote:
>Ralph Kar wrote:
>
>
>
>>Hi all,
>>
>>I have a question concerning the new JAXB version 1.0 FCS.
>>I want to migrate from the early access version (which was using DTDs)
>>to the new schema driven version of JAXB. With the old version it was
>>possible to define interfaces (and so inheritance) in a very flexible
>>way via interface elements. I have used this technique excessively and
>>defined several interfaces.
>>With the new version I discovered a problem with the inheritance
>>mechanism.
>>To my knowledge there is no possibility to define any multiple inheritance
>>relationships which was possible with the early access version.
>>
>>
>
>Since XML schema (unlike DTD), provides a way to define inheritance type
>hierarchies, the assumption was that the schema would be designed with the
>desired inheritance hierarchy. JAXB, then provides a way to map the
>inheritance
>hierarchy specified in the schema to a Java inheritance hierarchy; support for
>this
>feature was therefore dropped.
>
>For your particular use case, a <class> customization on an <attributeGroup>
>is
>be one possibility. But a <class> customization on an <attributeGroup>
>is currently not allowed by the specification.
>
>We are investigating this further. Stay tuned.
>
I would just like to add that XML Schema's model group definition
construct provides
a means for multiple complex type definitions to reference a model group
definition, thus formalizing that they are all sharing common content.
Both attribute
and model group definitions are the closest that XML Schema comes to
formally modeling the java concept that a class implements multiple
interfaces.
Regrettfully, it does not formally show up in the XML type derivation
hierarchy,
but it has the same net effect otherwise.
Thus a possible binding of model group definitions and attribute group
definitions
is to just generate Java interfaces when these constructs are
encountered. All complex type
definitions that reference these group definitions would implement these
interfaces
and obviously implement these methods.
I believe it is best first to identify the automated schema bindings to
java that result in
the behavior you are seeking.
While the early access version of JAXB forced the JAXB user to discover the
commonality in the DTD and express this in customization, the hope is that
schema designers in the future will use schema features that capture
that commonality.
The benefit is that the names of the model and attribute group
definitions can be mapped
to interfaces automatically by the databinding, with no customizations
needed.
The more commonality in semantically meaningful names between the schema
and the schema-derived code, the easier to relate the two.
-Joe Fialli, Sun Microsystems
>
>Thanks for the feedback.
>
>Sekhar Vajjhala - Sun Microsystems.
>
>
>
>
>>An example:
>>
>>We have the following elements:
>>
>>baseA baseB
>> ^ ^
>> | |
>> | |
>>elementA --> InterfaceAandB <-- elementB
>>
>>Furthermore elementA and elementB have some attributes in common.
>>This relationship is documented by the fact that both elements
>>implement the interface InterfaceAandB.
>>
>>With JAXB early access this could be expressed:
>>
>>DTD:
>>
>><!ELEMENT baseA EMPTY>
>><!ATTLIST baseA attrC CDATA #IMPLIED
>> attrD CDATA #IMPLIED>
>>
>><!ELEMENT elementA EMPTY>
>><!ATTLIST elementA attrA CDATA #IMPLIED
>> attrB CDATA #IMPLIED
>> attrC CDATA #IMPLIED
>> attrD CDATA #IMPLIED>
>>
>><!ELEMENT baseB EMPTY>
>><!ATTLIST baseB attrE CDATA #IMPLIED
>> attrF CDATA #IMPLIED>
>>
>><!ELEMENT elementB EMPTY>
>><!ATTLIST elementB attrA CDATA #IMPLIED
>> attrB CDATA #IMPLIED
>> attrE CDATA #IMPLIED
>> attrF CDATA #IMPLIED>
>>
>>XJS:
>>
>><interface name = "BaseAElementA"
>> members = "BaseA
>> ElementA"
>> properties = "attrC
>> attrD"/>
>>
>><interface name = "BaseBElementB"
>> members = "BaseB
>> ElementB"
>> properties = "attrE
>> attrF"/>
>>
>><interface name = "ElementAElementB"
>> members = "ElementA
>> ElementB"
>> properties = "attrA
>> attrB"/>
>>
>>With the new version of JAXB you can express the inheritance relationship
>>very easily:
>>
>><xsd:complexType name="baseA">
>> <xsd:attribute name="attrC" type="xsd:string"/>
>> <xsd:attribute name="attrD" type="xsd:string"/>
>></xsd:complexType>
>>
>><xsd:complexType name="elementA">
>> <xsd:complexContent>
>> <xsd:extension base="baseA">
>> <xsd:attribute name="attrA" type="xsd:string"/>
>> <xsd:attribute name="attrB" type="xsd:string"/>
>> </xsd:extension>
>> </xsd:complexContent>
>></xsd:complexType>
>>
>><xsd:complexType name="baseB">
>> <xsd:attribute name="attrE" type="xsd:string"/>
>> <xsd:attribute name="attrF" type="xsd:string"/>
>></xsd:complexType>
>>
>><xsd:complexType name="elementB">
>> <xsd:complexContent>
>> <xsd:extension base="baseB">
>> <xsd:attribute name="attrA" type="xsd:string"/>
>> <xsd:attribute name="attrB" type="xsd:string"/>
>> </xsd:extension>
>> </xsd:complexContent>
>></xsd:complexType>
>>
>>The Interface between elementA and elementB is a bit harder:
>>
>><xsd:attributeGroup name="ElementAElementB">
>> <xsd:annotation>
>> <xsd:appinfo>
>> <jxb:class name="ElementAElementB"/>
>> </xsd:appinfo>
>> </xsd:annotation>
>> <xsd:attribute name="attrA"/>
>> <xsd:attribute name="attrB"/>
>></xsd:attributeGroup>
>>
>><xsd:complexType name="elementA">
>> <xsd:complexContent>
>> <xsd:extension base="baseA">
>> <xsd:attributeGroup ref="ElementAElementB"/>
>> </xsd:extension>
>> </xsd:complexContent>
>></xsd:complexType>
>>
>>With the jxb:class tag you can ask JAXB to generate the interface.
>>This is where the problem occurs. There seems to be no way to
>>convince JAXB to make ElementA implement the interface ElementAElementB.
>>Since every element will be represented as an interface there should be no
>>reason to deny inheritance from more than one interface.
>>Another possible solution would be to allow more than one extension
>>element within a complexContent element. Since JAXB only creates code
>>which inherits interfaces that should not be a problem either.
>>As long as JAXB does not provide possibilities to inherit from more than
>>one interface it is not as powerful as the early access version has been.
>>Any comments or advice to my problem will be greatly appreciated. If I
>>have missed something helpful in the JAXB spec or user guide please let me
>>know.
>>
>>Greetings,
>>Ralph
>>
>>-----------------------------------------------------
>> Ralph Kar |
>> Software Developer | mailto:r.kar_at_rtsgroup.net
>> RTS Realtime Systems AG | http://www.rtsgroup.net
>>-----------------------------------------------------
>>
>>