Ander,

Castor supports polymorphism out of the box without having to resort to (such 
conditional) constructs as shown below. In other words, imagine you’d have XML 
similar to 

<beings>
    <person>
        <name>Ander</name>
    <person>
</contact>
<contact type="pet">
    <animal>
        <type>dog</type>
        <name>Fibi</name>
    <animal>
</beings>

Given there’s complete class mappings for <person> and <animal> classes, Castor 
will be able to deal with this automagically. Have a look at 

http://www.castor.org/xml-mapping.html#5.-xsi:type

in particular for a more detailed explanation.

Werner


________________________________________
Von: Ander Garcia Gangoiti [mailto:[EMAIL PROTECTED] 
Gesendet: Dienstag, 22. Mai 2007 10:06
An: [email protected]
Betreff: [castor-user][xml] conditional unmarshalling

Dear All
 
I have an xml file similar to the following one, where a nested element depends 
on and attribute of its father :
 
<contact type="friend">
    <person>
        <name>Ander</name>
    <person>
</contact>
<contact type="pet">
    <animal>
        <type>dog</type>
        <name>Fibi</name>
    <animal>
</contact>
 
I would like to express:
if (contact_type =friend)
    marshall/unmarshall person
if (contact_type =pet)
    marshall/unmarshall pet
 
Is it possible to express this conditional marshalling on the mapping file? Is 
there any other way to do it?
 
Thank you very much
 
Ander

________________________________________
De: Justin Permar [mailto:[EMAIL PROTECTED] 
Enviado el: martes, 22 de mayo de 2007 5:40
Para: [email protected]
Asunto: [castor-user] code generation: schema type restriction "re-defines" the 
type of an attribute from the base type
All,

I am using Castor to generate classes directly from a rather large and complex 
schema. I use automatic conflict resolution set to true as part of the 
following binding properties:

org.exolab.castor.builder.javaclassmapping=type
org.exolab.castor.builder.javaVersion=5.0
org.exolab.castor.builder.automaticConflictResolution=true

Nearly all the code that is generated works very well, but there is just one 
type of definition in the schema that Castor seems to have a bit of trouble 
with.

I have a type that is defined as follows:

<xs:complexType name="ON" mixed="true">
                        <xs:annotation>
                                    <xs:documentation>
                                    A name for an organization. A sequence of 
name parts.
                                    </xs:documentation>
                        </xs:annotation>
                        <xs:complexContent mixed="true">
                                    <xs:restriction base="EN">
                                                <xs:sequence>
                                                            <xs:choice 
minOccurs="0" maxOccurs="unbounded">
                                                                        
<xs:element name="delimiter">
                                                                                   
 <xs:complexType mixed="true">
                                                                                               
 <xs:complexContent mixed="true">
                                                                                                           
 <xs:restriction base="en.del">
                                                                                                                       
 <xs:attribute name="partType" type="cs_OrganizationNamePartType" 
fixed="DEL"/>                   <!—This partType “overrides” the partType in 
en.del with a new type cs_OrganizationNamePartType →
                                                                                                           
 </xs:restriction>
                                                                                               
 </xs:complexContent>
                                                                                   
 </xs:complexType>
                                                                        
</xs:element>
                        … <!—snip →
</xs:complexType>

Note that the above element named “delimiter” is a restriction of a type named 
“en.del”. This type is defined as follows:

            <xs:complexType name="en.del" mixed="true">
                        <xs:complexContent mixed="true">
                                    <xs:restriction base="ENXP">
                                                <xs:attribute name="partType" 
type="cs_EntityNamePartType" fixed="DEL"/>  <!—cs_EntityNamePartType is the 
type specified for this attribute here →
                                    </xs:restriction>
                        </xs:complexContent>
            </xs:complexType>

Notice that attribute “partType” is defined in the “en.del” complexType and 
also “re-defined” in “delimiter” element in the complex type “ON”. I say 
re-defined because the type of the attribute named “partType” is 
“cs_EntityNamePartType” in the “en.del” complex type, whereas it is of type 
“cs_OrganizationNamePartType” in the “delimiter” attribute in the complex type 
named “ON”.

I’m sure you can already tell that this is quite “suspicious”!

When I try to generate code for the ON complex type, there is something like 
this that is the output:

public class ONDelimiter extends castor.test.En_del 
implements java.io.Serializable
{


      //----------------/
     //- Constructors -/
    //----------------/

    public ONDelimiter() {
        super();
        
setPartType(castor.test.types.Cs_OrganizationNamePartType.valueOf("DEL"));    
///ERROR!!!!
        setContent("");
    }

… <snip>

Now, the En_del class is generated with a method of the following signature:

    /**
     * Field _partType.
     */
    private castor.test.types.Cs_EntityNamePartType _partType = 
castor.test.types.Cs_EntityNamePartType.valueOf("DEL");


      //----------------/
     //- Constructors -/
    //----------------/

    public En_del() {
        super();
        setPartType(castor.test.types.Cs_EntityNamePartType.valueOf("DEL"));
        setContent("");
    }


      //-----------/
     //- Methods -/
    //-----------/

      <snip!>

    /**
     * Returns the value of field 'partType'.
     * 
     * @return the value of field 'PartType'.
     */
    public castor.test.types.Cs_EntityNamePartType getPartType(
    ) {
        return this._partType;
    }

      <snip!>

    /**
     * Sets the value of field 'partType'.
     * 
     * @param partType the value of field 'partType'.
     */
    public void setPartType(
            final castor.test.types.Cs_EntityNamePartType partType) {
        this._partType = partType;
    }

<snip!>

Of course the ONDelimiter class extends from the En_del class. The En_del class 
has a field named _partType that is of type 
castor.test.types.Cs_EntityNamePartType. Because ONDelimiter subclasses En_del, 
it can’t set _partType to a castor.test.types.Cs_OrganizationNamePartType 
instance like it attempts to in the ONDelimiter constructor. And the 
ONDelimiter class has no field of that type either.

If it helps, here are the definition of Cs_EntityNamePartType and 
Cs_OrganizationNamePartType snippets of the schema:

            <xs:simpleType name="cs_EntityNamePartType">
                        <xs:restriction base="cs">
                                    <xs:enumeration value="FAM"/>
                                    <xs:enumeration value="GIV"/>
                                    <xs:enumeration value="PFX"/>
                                    <xs:enumeration value="SFX"/>
                                    <xs:enumeration value="DEL"/>
                        </xs:restriction>
            </xs:simpleType>

            <xs:simpleType name="cs_OrganizationNamePartType">
                        <xs:restriction base="cs_EntityNamePartType">
                                    <xs:enumeration value="PFX"/>
                                    <xs:enumeration value="SFX"/>
                                    <xs:enumeration value="DEL"/>
                        </xs:restriction>
            </xs:simpleType>



I’m hoping that you might be able to help me with either a workaround (changing 
the code directly is ok with me because this is the only type of error in the 
Castor-generated code). I say “type” of error because this schema has this kind 
of definition a number of places and the errors are all similar. Of course, if 
there is a modification to the binding file that I can make for either of these 
types then that is better! One idea might be to not have one type extend from 
another, and just have all the classes separate concrete classes. Is that a 
possibility in Castor?

Thank you in advance for taking some time with this matter. I appreciate any 
feedback and/or help you can give me.

----------------------------------------------
Justin Permar
Research Programmer
Department of Biomedical Informatics
The Ohio State University

Reply via email to