Search code examples
javaweb-servicesxsddesign-by-contractcontract

XML inside an string element vs independent elements

What are the conceptual and technical disadvantages of this request/response structure:

A)

<xs:element name="OrderRequest">
        <xs:complexType>
            <xs:sequence>
                <xs:element name="OrderID" type="xs:integer"/>
                <xs:element name="OrderType" type="xs:integer"/>
                <xsd:element name='OrderAttributes' type='xsd:string'/>
            </xs:sequence>
        </xs:complexType>
</xs:element>

where OrderAttributes element will contain string in the following XML structure:

<OrderName> xy </OrderName>
<OrderDate> xy </OrderDate>
<OrderDetails> xy </OrderDetails>
....lots of other attributes

compared to this request/response structure

B)

<xs:element name="OrderRequest">
        <xs:complexType>
            <xs:sequence>
                <xs:element name="OrderID" type="xs:integer"/>
                <xs:element name="OrderType" type="xs:integer"/>
                <xsd:element name="OrderAttributes">
                  <xs:complexType>
                    <xs:sequence>
                      <xs:element name="OrderName" type="xs:string"/>
                      <xs:element name="OrderDate" type="xs:date"/>
                      <xs:element name="OrderDetails" type="xs:string"/>
                       ....lots of other attributes
                    </xs:sequence>
                  </xs:complexType>
                </xs:element>
            </xs:sequence>
        </xs:complexType>
</xs:element>

I need to design web service interface for orders processing, and I am thinking about the two alternatives mentioned above.

Version A, is more generic, so interface doesn't need to change, when OrderAttributes structure changes in any way.

But schema validation is not possible.

And my question is, what are other disadvantages compared to version B. I am analyst, not programmer, so I cannot say, if there is some impact on parsing requests, generating code from contract etc...

Solution

  • First note that your generic use of the word attribute to refer to a property can be confusing in XML, where attribute refers to a specific construct that stands apart from element:

    <element attribute="attribute value">
    <childElement>child element value</childElement>
</element>

    Then, while doing design, you might consider which properties you wish to represent as XML attribute and which you wish to represent as XML elements. See XML attribute vs XML element for help deciding.

    Regarding your A vs B proposed designs, note that A simply is not viable -- you cannot have unescaped markup within an element declared to have xs:string content as you've shown. Furthermore, A would then require further parsing of the OrderAttributes contents anyway whereas B would leverage the XML parser to process OrderAttributes contents. (And, like you said, B would not leverage XSD validation either.)

    For future expansion, consider instead the use of xs:any, which supports various interpretations of wildcard contents via its processContents attribute values of strict, lax, or skip.