OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ciq message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: CIQ XML Schema Issue & Resolution


Title: FW: CIQ XML Schema Issue & Resolution
Hi Stephen,
 
Thank you for your detailed email.
 
Yes, this is a problem with V2.0 and it is already in our
list of things to do. The future versions of CIQ will be strongly data typed.
 
Regards,
 
Ram


From: Viens, Stephen [mailto:Stephen.Viens@LibertyMutual.com]
Sent: Tue 1/18/2005 9:33 AM
To: Ram Kumar
Subject: FW: CIQ XML Schema Issue & Resolution

[Please forgive the length of this message.  I do believe you'll find the subject of interest]

Ram, CIQ TC,

We're leveraging the current CIQ standard schema's to implement a web service for managing client data.  We've included the CIQ schemas in the WSDL for our service to describe the data managed by the service.  We're using the "WSDL First" method of web service development which recommends developing the service's WSDL first and generating service and client code (Java, C#, C++, etc) from that using common WSDL2Java code generation tools.

Unfortunately we've encountered a problem when trying to generate Java code from the CIQ schemas.  We're using two industry standard WSDL2Java generation tools - Apache Axis 1.1 and IBM WSAD 5.1 - and we've been presented with the same problem with both.  The purpose of this note is to inform you of the problem and describe how we've worked around it.

When type information for an elements character data is not specified the code generation tools will produce a Java class without a class variable to contain character data.  In other words, the Java generation tools assume that if type information isn't supplied for an element's character data then it must be an "attributes only" element.  Here's an example:

    <xs:element name="CustomerID" minOccurs="0" maxOccurs="unbounded">
      <xs:complexType mixed="true">
        <xs:attribute name="Type"/>
        <xs:attributeGroup ref="grPostal"/>
        <xs:anyAttribute namespace="##other"/>
      </xs:complexType>
    </xs:element>

Here's the Java code generated from the schema snippet above . You'll note that there is no class variable to hold a CustomerID value - only the "Type" attribute is represented.

    public class CustomerID
    {
      private java.lang.Object type;

      public CustomerID() {
      }

      public java.lang.Object getType() {
        return type;
      }

      public void setType(java.lang.Object type) {
        this.type = type;
      }
    }

Only when a simpleContent element is specified with type information for the element's character data (xs:string) will the generation tools produce Java that includes a class variable and getter/setter methods for a CustomerID value.  Below is an example.  This is the same schema snippet shown above with the addition of the "xs:simpleContent" and "xs:extension" elements:

    <xs:element name="CustomerID" minOccurs="0" maxOccurs="unbounded">
      <xs:complexType mixed="true">
        <xs:simpleContent>
          <xs:extension base="xs:string">
            <xs:attribute name="Type"/>
            <xs:attributeGroup ref="grPostal"/>
            <xs:anyAttribute namespace="##other"/>
          </xs:extension>
        </xs:simpleContent>
      </xs:complexType>
    </xs:element>

Here is the Java code that is generated from the modified schema. You'll notice that a class variable for the CustomerID value is now present as well as getValue and setValue methods:

    public class CustomerID
    {
      private java.lang.String value;
      private java.lang.Object type;

      public CustomerID() {
      }

      public java.lang.String getValue() {
        return value;
      }

      public void setValue(java.lang.String value) {
        this.value = value;
      }

      public java.lang.Object getType() {
        return type;
      }

      public void setType(java.lang.Object type) {
        this.type = type;
      }
    }

The way the WSDL2Java tools work makes sense in a way.  How else would they be able to know if an element includes (or does not include) character data without it being explicitly stated in the schema? 

Would the CIQ team consider updating the schemas to include these changes or at least incorporating these changes into future versions?

We have been forced to make many alterations to the CIQ schemas for our web service to leverage them.  We're concerned that we will have to make all of the same alterations when (if) we decide to upgrade to a new version of CIQ in the future. 

Steve

Stephen Viens
Enterprise Architect
Liberty Mutual Insurance Company
Enterprise IT Services (EITS)
stephen.viens@libertymutual.com
603-245-3467 (phone)
603-245-5338 (fax)



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]