XDT versus XML Schema

Content

1. Abstract
2. Type comparison
 2.1. myInteger
 2.2. Simple Type "SKU"
 2.3. Enumeration Facet
 2.4. List Type
 2.5. Union
 2.6. Anonymous
 2.7. Complex Type
 2.8. Mixed Content
 2.9. Empty Complex
 2.10. Nested Choice and Sequence Groups
 2.11. Attribute Group
 2.12. Nil Value
 2.13. Allow HTML
 2.14. anyType
3. For those who used to use XML Schema Datatypes
4. Conclusion

1. Abstract

This web page is dedicated to comparison between two methods of defining data types - XDT v1.0 and XML Schema (2001/05/02).

The best way to see difference between two protocols is to make a comparison step by step, instance by instance of data definitions supported by protocols. So let's start with the examples, taken from XML Schema specification. All examples below are chosen sequentially as they appear in XML Schema with some omitted exceptions (they do not contain important and a new distinctive information), and this choice is not based on the flavor of one or another approach. Reader of this document may form his/her own opinion based on this comparison or other materials from different sources. In case if such conclusion is difficult - we will help with our inference later.

Just to make it simpler the document uses different color coding schema for two compared approaches. Below you'll find set of pairs of blocks. In each pair -

the first block contains a sample given by XML Schema specification, and

the second  - the way how it may be done in XDT.

Examples of data instances are in green blocks.

Ultimately, at the end of the page you may find some conclusion.

2. Type comparison

2.1. myInteger

Defining myInteger, Range 10000-99999 in XML Schema:

<xsd:simpleType name="myInteger">
  <xsd:restriction base="xsd:integer">
    <xsd:minInclusive value="10000"/>
    <xsd:maxInclusive value="99999"/>
  </xsd:restriction>
</xsd:simpleType>

Defining myInteger, Range 10000-99999 in XDT:

<xdt:define new-type="myInteger" type="xdt:integer" limits="10000-99999"/>

2.2. Simple Type "SKU"

Defining the Simple Type "SKU". This is derived (by restriction) from the simple type string. Additionally, XML Schema constrains the values of "SKU" using a facet called pattern in conjunction with the regular expression "\d{3}-[A-Z]{2}". It restrains string to the pattern - "three digits followed by a hyphen followed by two upper-case ASCII letters":

<xsd:simpleType name="SKU">
  <xsd:restriction base="xsd:string">
    <xsd:pattern value="\d{3}-[A-Z]{2}"/>
  </xsd:restriction>
</xsd:simpleType>

Defining similar type in XDT:

<xdt:define new-type="SKU" type="xdt:string" pattern="\d[3]-\a[2]"/>

2.3. Enumeration Facet

Using the Enumeration Facet in XML Schema:

<xsd:simpleType name="USState">
  <xsd:restriction base="xsd:string">
    <xsd:enumeration value="AK"/>
    <xsd:enumeration value="AL"/>
    <xsd:enumeration value="AR"/>
    <!-- and so on ... -->
  </xsd:restriction>
</xsd:simpleType>

Defining string-based enumeration in XDT:

<xdt:define new-type="USState" type="xdt:string" limits="AK|AL|AR"/>
<!-- The list AK|AL|AR in example above may be extended to comprise
all US states -->

2.4. List Type

List Type for Six US States in XML Schema:

<xsd:simpleType name="USStateList">
 <xsd:list itemType="USState"/>
</xsd:simpleType>

<xsd:simpleType name="SixUSStates">
 <xsd:restriction base="USStateList">
  <xsd:length value="6"/>
 </xsd:restriction>
</xsd:simpleType>

Defining similar type in XDT:

<xdt:define new-type="SixUSStates" type="USState" occur="co=6"/>

2.5. Union

Union Type for Zipcodes in XML Schema:

<xsd:simpleType name="zipUnion">
  <xsd:union memberTypes="USState listOfMyIntType"/>
</xsd:simpleType>

Defining similar type in XDT:

<xdt:define new-type="zipUnion">
  <xdt:element name="USState" type="USState" occur="ch"/>
  <xdt:element name="listOfMyIntType" type="xdt:string" pattern="\d[5]" occur="co=3,ch"/>
</xdt:define>

It should be clarified here that data instances complying with type specified by XML Schema and XDT examples shown above slightly differ from each other.

<zips>CA</zips>
  <!-- And the second instance: -->
<zips>95630 95977 95945</zips>

Data instances in XDT:

<Zips1 type="zipUnion">
  <USState> CA </USState>
</Zips1>
  <!-- And the second instance: -->
<Zips2 type="zipUnion">
  <listOfMyIntType> 95630 95977 95945 </listOfMyIntType>
</Zips2>

As you can see from the examples XDT is more demanding comparing with XML Schema to type definition for each element.
By offering 'union' XML Schema relays on the guesses on the type of data element that are based on the actual data presented here as a content. Here, if data element has content - "CA" XML Schema assumes that the element may have type "USState". If content is "12345" - it may have type "listOfMyIntType". But what if specified types are close to each other (for example, both are using "string" as a base type)? In some cases there is no way to find out to which particular type the data instance comply to.
In a contrast to this, XDT method does not rely on guesses of the type for the element - it takes it for checking/processing by looking at the element name. If name is among specified - its type can be easily obtained from initial type definition. In the present example, if name of child element is "USState" - data should comply with "USState" type. If it has name "listOfMyIntType", it is clear that element contains data with the "listOfMyIntType" type.

2.6. Anonymous

Two Anonymous Type Definitions in XML Schema:

<xsd:complexType name="Items">
 <xsd:sequence>
  <xsd:element name="item" minOccurs="0" maxOccurs="unbounded">
   <xsd:complexType>
    <xsd:sequence>
     <xsd:element name="productName" type="xsd:string"/>
     <xsd:element name="quantity">
      <xsd:simpleType>
       <xsd:restriction base="xsd:positiveInteger">
        <xsd:maxExclusive value="100"/>
       </xsd:restriction>
      </xsd:simpleType>
     </xsd:element>
     <xsd:element name="USPrice"  type="xsd:decimal"/>
     <xsd:element ref="comment"   minOccurs="0"/>
     <xsd:element name="shipDate" type="xsd:date" minOccurs="0"/>
    </xsd:sequence>
    <xsd:attribute name="partNum" type="SKU" use="required"/>
   </xsd:complexType>
  </xsd:element>
 </xsd:sequence>
</xsd:complexType>

Defining similar type in XDT:

<xdt:define new-type="Items">
  <xdt:element name="item" occur="0-oo">
    <xdt:attribute name="partNum" type="SKU"/>
    <xdt:element name="productName" type="xdt:string"/>
    <xdt:element name="quantity" type="xdt:integer" limits="0-{100}"/>
    <xdt:element name="USPrice" type="xdt:currency"/>
    <xdt:element name="shipDate" type="xdt:date" occur="0-oo"/>
  </xdt:element>
</xdt:define>

2.7. Complex Type

Deriving a Complex Type from a Simple Type in XML Schema:

<xsd:element name="internationalPrice">
 <xsd:complexType>
  <xsd:simpleContent>
   <xsd:extension base="xsd:decimal">
    <xsd:attribute name="currency" type="xsd:string"/>
   </xsd:extension>
  </xsd:simpleContent>
 </xsd:complexType>
</xsd:element>

Defining similar type in XDT:

<xdt:define new-type="tInternationalPrice" type="xdt:integer">
  <xdt:attribute name="currency" type="xdt:string">
</xdt:define>

Here is an example of data instance with specified above type:

<PurchasePrice currency="ForeignCountry"> 123.45 </PurchasePrice>

2.8. Mixed Content

Snippet of XML Schema for Customer Letter in XML Schema:

<xsd:element name="letterBody">
 <xsd:complexType mixed="true">
  <xsd:sequence>
   <xsd:element name="salutation">
    <xsd:complexType mixed="true">
     <xsd:sequence>
      <xsd:element name="name" type="xsd:string"/>
     </xsd:sequence>
    </xsd:complexType>
   </xsd:element>
   <xsd:element name="quantity"    type="xsd:positiveInteger"/>
   <xsd:element name="productName" type="xsd:string"/>
   <xsd:element name="shipDate"    type="xsd:date" minOccurs="0"/>
   <!-- etc. -->
  </xsd:sequence>
 </xsd:complexType>
</xsd:element>

Defining similar type in XDT:

<xdt:element name="letterBody">
  <xdt:element name="salutation"  type="xdt:string">
    <xdt:element name="name"      type="xdt:string"/>
  </xdt:element>
  <xdt:element name="quantity"    type="xdt:integer" limits="0-oo"/>
  <xdt:element name="productName" type="xdt:string"/>
  <xdt:element name="shipDate"    type="xdt:date" occurance="0-oo"/>
  <!-- etc. -->
</xdt:element>

2.9. Empty Complex

An Empty Complex Type in XML Schema:

<xsd:element name="internationalPrice">
 <xsd:complexType>
  <xsd:complexContent>
   <xsd:restriction base="xsd:anyType">
    <xsd:attribute name="currency" type="xsd:string"/>
    <xsd:attribute name="value"    type="xsd:decimal"/>
   </xsd:restriction>
  </xsd:complexContent>
 </xsd:complexType>
</xsd:element>

Defining similar type in XDT:

<xdt:element name="internationalPrice">
  <xdt:attribute name="currency" type="xdt:string"/>
  <xdt:attribute name="value"    type="xdt:currency"/>
</xdt:element>

2.10. Nested Choice and Sequence Groups

Nested Choice and Sequence Groups Type in XML Schema:

<xsd:complexType name="PurchaseOrderType">
 <xsd:sequence>
  <xsd:choice>
   <xsd:group   ref="shipAndBill"/>
   <xsd:element name="singleUSAddress" type="USAddress"/>
  </xsd:choice>
  <xsd:element ref="comment" minOccurs="0"/>
  <xsd:element name="items"  type="Items"/>
 </xsd:sequence>
 <xsd:attribute name="orderDate" type="xsd:date"/>
</xsd:complexType>

<xsd:group name="shipAndBill">
  <xsd:sequence>
    <xsd:element name="shipTo" type="USAddress"/>
    <xsd:element name="billTo" type="USAddress"/>
  </xsd:sequence>
</xsd:group>

Defining similar type in XDT:

<xdt:define new-type="PurchaseOrderType">
  <xdt:attribute name="orderDate" type="xdt:date">
  <xdt:element type="shipAndBill" occur="ch">
  <xdt:element name="singleUSAddress" type="USAddress" occur="ch">
  <xdt:element name="items" type="Items">
</xdt:define>

<xdt:define new-type="shipAndBill">
  <xdt:element name="shipTo" type="USAddress"/>
  <xdt:element name="billTo" type="USAddress"/>
</xdt:define>

Of cause in XDT you may include second definition into the first one. In this case type definition for PurchaseOrderType will look even shorter. The example above has the same structure for the purpose of closer comparison only.

2.11. Attribute Group

Adding Attributes Using an Attribute Group in XML Schema:

<xsd:element name="item" minOccurs="0" maxOccurs="unbounded">
 <xsd:complexType>
  <xsd:sequence>
   <xsd:element name="productName" type="xsd:string"/>
   <xsd:element name="quantity">
    <xsd:simpleType>
     <xsd:restriction base="xsd:positiveInteger">
      <xsd:maxExclusive value="100"/>
     </xsd:restriction>
    </xsd:simpleType>
   </xsd:element>
   <xsd:element name="USPrice"  type="xsd:decimal"/>
   <xsd:element ref="comment"   minOccurs="0"/>
   <xsd:element name="shipDate" type="xsd:date" minOccurs="0"/>
  </xsd:sequence>

  <!-- attributeGroup replaces individual declarations -->
  <xsd:attributeGroup ref="ItemDelivery"/>
 </xsd:complexType>
</xsd:element>

<xsd:attributeGroup name="ItemDelivery">
  <xsd:attribute name="partNum"  type="SKU" use="required"/>
  <xsd:attribute name="weightKg" type="xsd:decimal"/>
  <xsd:attribute name="shipBy">
    <xsd:simpleType>
     <xsd:restriction base="xsd:string">
      <xsd:enumeration value="air"/>
      <xsd:enumeration value="land"/>
      <xsd:enumeration value="any"/>
     </xsd:restriction>
    </xsd:simpleType>
  </xsd:attribute>
</xsd:attributeGroup>

Defining similar type in XDT:

<xdt:element name="item" occur="0-oo">
  <xdt:merge  name="./xdt:element#2"/>
  <xdt:element name="productName" type="xdt:string"/>
  <xdt:element name="quantity" type="xdt:integer" limits="0-{100}"/>
  <xdt:element name="USPrice" type="xdt:currency"/>
  <xdt:comment occur="0-1"/>
  <xdt:element name="shipDate" type="xdt:date" occur="0-1"/>
</xdt:element>

<xdt:element name="ItemDelivery">
  <xdt:attribute name="partNum" type="SKU"/>
  <xdt:attribute name="weightKg" type="xdt:integer" limits="0-oo"/>
  <xdt:attribute name="shipBy" type="xdt:string" limits="air|land|any"/>
</xdt:element>

2.12. Nil Value

Defining type of element with nil value in XML Schema:

<xsd:element name="shipDate" type="xsd:date" nillable="true"/>

Defining similar type in XDT:

<xdt:element name="shipDate" type="xdt:date" occur="co=0-1"/>

2.13 Allow HTML

Modification to purchaseReport Declaration to Allow HTML in Instance in XML Schema:

<element name="purchaseReport">
 <complexType>
  <sequence>
   <element name="regions" type="r:RegionsType"/>
   <element name="parts"   type="r:PartsType"/>
   <element name="htmlExample">
    <complexType>
     <sequence>
      <any namespace="http://www.w3.org/1999/xhtml"
           minOccurs="1" maxOccurs="unbounded"
           processContents="skip"/>
     </sequence> 
    </complexType>
   </element>
  </sequence>
  <attribute name="period"       type="duration"/>
  <attribute name="periodEnding" type="date"/>
 </complexType>
</element>

Defining similar type in XDT:

<xdt:element name="purchaseReport">
  <xdt:attribute name="period" type="xdt:duration"/>
  <xdt:attribute name="periodEnding" type="xdt:date"/>
  <xdt:element name="regions" type="r:RegionsType"/>
  <xdt:element name="parts" type="r:PartsType"/>
  <xdt:element name="htmlExample" type="xdt:XML" occur="1-oo"
    xmlns="http://www.w3.org/1999/xhtml"/>
</xdt:element>

2.14. anyType

Defining type of element with anyType in XML Schema:

<xsd:element name="anything" type="xsd:anyType"/>

Defining similar type in XDT:

<xdt:define new-type="anyType" name="anything" type="xdt:XML"/>

3. For those who used to use XML Schema Datatypes

The set of type definitions below will help to move easy from the XML Schema datatypes to XDT:

<xdt:define new-type="xsd:string"   type="xdt:string"/>
<xdt:define new-type="xsd:normalizedString" type="xdt:string" 
  limits="{[#x9]}|{[#xD]}|{[#xA]}"/>
<xdt:define new-type="xsd:token"    type="xsd:normalizedString" limits="{#x20#x20}"/>
<xdt:define new-type="xsd:NMTOKENS" type="xsd:normalizedString" limits="{[#x20]}"/>
<xdt:define new-type="xsd:ID"       type="xdt:integer" limits="0-oo"/>
<xdt:define new-type="xsd:IDREFS"   type="xdt:integer" limits="0-oo"/>
<xdt:define new-type="xsd:language" type="xdt:ext"
  ext-rules="http://www.ietf.org/rfc/rfc1766.txt"/>
<xdt:define new-type="xsd:Name"     type="xsd:string"
  limits="[a-z]|[A-Z]|[0-9]|[_]|[:]"/>
<xdt:define new-type="xsd:NCName"   type="xsd:NCName" limits="{[:]}"/>
<xdt:define new-type="xsd:QName"    type="xdt:string" pattern="\a[1-100]:\a[1-oo]"/>
<xdt:define new-type="xsd:anyType"  type="xdt:XML"/>

4. Conclusion

Below is a list of points that may be taking into consideration when reader of this document tries to make its own conclusion.

While both XDT and XML Schema do the same thing - they are providing methods to specify data types using XML protocol of representing datum - XDT makes this process easier and in a more intuitive fashion. XDT files simply have better readability comparing to XML Schema datatypes.
Almost all examples above show that XDT's way of creating type definitions is simpler and 1.5 - 2 times smaller comparing to the same type definitions done by XML Schema method. It means - less mistakes may be happened and less amount of datum will be required to transmit and to store it later.
XDT allows to define arrays (for both element itself and its content), XML Schema does not.
XDT allows several ways to control of checking data types, including separated .XDT file, self-type-defined data, and combined method. XML Schema does not offer this feature.
XDT does not support element <xsd:sequence> comparing to XML Schema. It is because the sequence of elements itself in XML formatted file represents this order. At the same time, XDT comparing with XML Schema does not recommend to specify any uncontrolled position (sequence, order) of child elements inside their parent, while keeping it possible.
XDT does not support dividing all types into two categories - simple types and complex types (as XML Schema requires to do). The reason to support the division in XML Schema datatypes is to separate the datatypes that could be used in attributes type definitions (simple types) from the other types (complex types, by the way XML Schema language defines as many as four complex types) that can not be used to define attributes. XDT, in a turn, simply restricts specifying a child element in <xdt:attribute> tag. The restriction may be easily checked by a common method - applying "XDT.dtd". As a result - XDT datatypes do not have to have a lot of nested elements like <xsd:simpleType> and <xsd:complexType>.
To simplify process of validating and reading actual data - type definitions in XDT closely resemble corresponding structures of actual data instances. XML Schema does not concern about this feature.
There is no easy way to extend list of supported basic types in XML Schema while XDT provides this mechanism with dedicated xdt:ext basic type.
Schema uses 30 tags and 12 attributes (restriction/facets), while XDT has only 6 tags and 8 attributes to do the practically the same job (and sometimes even more - see notes above).
XML Schema uses two namespaces (usually used with prefixes 'xsd' and 'xsi') while XDT uses only one (prefix 'xdt'). XDT uses common namespace approach offered and supported by XML and therefore it does not need additional namespace related attributes (like 'targetNamespace', 'elementFormDefault', 'xsi:schemaLocation'). XML Schema supports only one user defined target namespace, while XDT does not limit the number of supported namespaces.

Finally, if you have not figured out your valuable opinion yet and still seek for a conclusion we may help you with ours one.
XDT provides more natural way of defining data types resembling instances of a data itself. It is more flexible protocol end ready for future extensions (while keeping tight control on the basic way of defining/checking data types). XDT makes data type definitions simpler and more clear (read - more cost effective in implementation).

E-mail:

[This page was updated: July 25, 2002]