Playing Nice. XML Schemas and Data Binding

Over the years, I've been introduced to a variety of XML Schema design patterns. We've gone the route of defining everything in complex types as in STAR 4

STAR 4:

    <xsd:complexType name="PartyBase">
        <xsd:sequence>
            <xsd:element name="PartyId" type="PartyId" minOccurs="0">
                <xsd:annotation>
                    <xsd:documentation source="http://www.starstandard.org">Party Identification Number</xsd:documentation>
                </xsd:annotation>
            </xsd:element>
        </xsd:sequence>
    </xsd:complexType>

To going to all Global Elements in STAR 5:

   <xsd:complexType name="MessageType">
        <xsd:sequence>
            <xsd:element ref="ID" minOccurs="0" maxOccurs="1"/>
            <xsd:element ref="ReasonCode" minOccurs="0" maxOccurs="1"/>
        </xsd:sequence>
    </xsd:complexType>

Both of these patterns can be a problem though for various tooling to handle. The reason is that the tools tend to generate extra content models to handle the schemas. In particular data binding frameworks will tend to generate thousands of classes. Which in turn can be problematic to deploy and maintain.

STAR is currently looking at implementing a Hybrid approach for STAR 5. The hybrid approach will maintain backwards compatibility with the existing XML Schemas from an XML Validation standpoint, but will hopefully help reduce the number of classes that are generated.

The XML NDR by UNCEFACT that STAR follows describes the hybrid approach as follows:

    <xsd:complextype name="ApplicantType">
        <xsd:sequence>
            <xsd:element name="PrimaryDriverIndicator" type="udt:IndicatorType" minoccurs="0" maxoccurs="1">
            <xsd:element ref="ResidencePeriod" minoccurs="0" maxoccurs="1">
            <xsd:element ref="ApplicantParty" minoccurs="1" maxoccurs="1">
            <xsd:element ref="ApplicantDemographics" minoccurs="0" maxoccurs="1">
....
            <xsd:element ref="ReferencePerson" minoccurs="0" maxoccurs="unbounded">
            <xsd:element name="GSTRegistrantIndicator" type="udt:IndicatorType" minoccurs="0" maxoccurs="1"/>
       </xsd:sequence>
   </xsd:complextype>

Basically anything that is a Component is still treated as a global reference. Anything that is a Field is locally defined within the component that it appears. This should help reduce the number of classes that are generated by various tooling as the local elements will be mapped more directly to fields or attributes in the appropriate language.

The benefits of the design change will vary depending on tooling support. It is the hope though that the design change will help ease some of the integration burden. This is planned to be available to STAR members during the upcoming Draft and Milestone releases for STAR 5.3.2. Other community members will see the proposed design changes in STAR 5.3.4 in March 2010.