XML Schemas

An XML schema is a document which describes a language derived from the internet ur-sprache XML. Any missive which conforms to a given XML schema is called an instance document for that XML schema. For example, we could create a XML schema which describes a pigeon English and then write instance documents which conform to this XML schema. This whole manual might be considered as such. We also could, in a much more mundane mood, write an XML schema which describes instance documents which are purchase orders. First let us consider an example instance document for two purchases.

<?xml version="1.0"?>
<purchaseOrder orderDate="1999-10-20">
    <shipTo country="US">
        <name>Alice Smith</name>
        <street>123 Maple Street</street>
        <city>Mill Valley</city>
        <state>CA</state>
        <zip>90952</zip>
    </shipTo>
    <billTo country="US">
        <name>Robert Smith</name>
        <street>8 Oak Avenue</street>
        <city>Old Town</city>
        <state>PA</state>
        <zip>95819</zip>
    </billTo>
    <comment>Hurry, my lawn is going wild!</comment>
    <items>
        <item partNum="872-AA">
            <productName>Lawnmower</productName>
            <quantity>1</quantity>
            <USPrice>148.95</USPrice>
            <comment>Confirm this is electric</comment>
        </item>
        <item partNum="926-AA">
            <productName>Baby Monitor</productName>
            <quantity>1</quantity>
            <USPrice>39.98</USPrice>
            <shipDate>1999-05-21</shipDate>
        </item>
    </items>
</purchaseOrder>

From staring at this chunk of text long enough one can gather that this instance document is a purchanse order filed on with the shipping address

Alice Smith
123 Maple Street
Mill Valley, CA
90952
USA

and the billing address

Robert Smith
8 Oak Avenue
Old Town, PA
95819
USA

for one lawnmower at a cost of dollars and one baby monitor at a cost of dollars. The ship date for the baby monitor is . Thrilling stuff!

Staring a bit more at this pile of text one can glean from the ink pressed onto the page that a purchase order consists of a main element purchaseOrder and the subelements shipTo, billTo, comment, and items. All of these subelements, mod comment, in turn contain further sub-elements and on, and on. However, some elements, for example the element USPrice, do not contain any subelements. Elements that have subelements are said to have complex type; elements that contain numbers, strings, or dates...are said to have simple type. One of the main functions of the XML schema which defines the grammar for this document instance is to declare which elements are of simple type and which elements are of complex type along with a slew of other information associated with this document type.

This example gives a feel for what a instace document looks like. However, you may be wondering, what's the XML schema which defines this purchase order language look like? Glad you asked. Here it is, hot off the presses

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">

 <xsd:annotation>
  <xsd:documentation xml:lang="en">
   Purchase order schema for Example.com.
   Copyright 2000 Example.com. All rights reserved.
  </xsd:documentation>
 </xsd:annotation>

 <xsd:element name="purchaseOrder" type="PurchaseOrderType"/>

 <xsd:element name="comment" type="xsd:string"/>

 <xsd:complexType name="PurchaseOrderType">
  <xsd:sequence>
   <xsd:element name="shipTo" type="USAddress"/>
   <xsd:element name="billTo" type="USAddress"/>
   <xsd:element ref="comment" minOccurs="0"/>
   <xsd:element name="items"  type="Items"/>
  </xsd:sequence>
  <xsd:attribute name="orderDate" type="xsd:date"/>
 </xsd:complexType>

 <xsd:complexType name="USAddress">
  <xsd:sequence>
   <xsd:element name="name"   type="xsd:string"/>
   <xsd:element name="street" type="xsd:string"/>
   <xsd:element name="city"   type="xsd:string"/>
   <xsd:element name="state"  type="xsd:string"/>
   <xsd:element name="zip"    type="xsd:decimal"/>
  </xsd:sequence>
  <xsd:attribute name="country" type="xsd:NMTOKEN"
     fixed="US"/>
 </xsd:complexType>

 <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>

 <!-- Stock Keeping Unit, a code for identifying products -->
 <xsd:simpleType name="SKU">
  <xsd:restriction base="xsd:string">
   <xsd:pattern value="\d{3}-[A-Z]{2}"/>
  </xsd:restriction>
 </xsd:simpleType>

</xsd:schema>

Instead of testing the metal of the musculature proping your eyelids in the open position by going through each and every detail of the above XML schema, we'll instead whet the appetite by concentrating on a few key morsels.

We'll first focus on the element purchaseOrder. This element is defined by the following XML schema snippet

 <xsd:element name="purchaseOrder" type="PurchaseOrderType"/>

This snippet defines a new element with the name purchaseOrder which is of type PurchaseOrderType. The type of this element indicates which attributes the element may have and which elements may be contained within the new element. To shed a little sunshine on what this exactly means we can look at the definition of the type PurchaseOrderType. The type PurchaseOrderType is defined by the following XML schema snippet

 <xsd:complexType name="PurchaseOrderType">
  <xsd:sequence>
   <xsd:element name="shipTo" type="USAddress"/>
   <xsd:element name="billTo" type="USAddress"/>
   <xsd:element ref="comment" minOccurs="0"/>
   <xsd:element name="items"  type="Items"/>
  </xsd:sequence>
  <xsd:attribute name="orderDate" type="xsd:date"/>
 </xsd:complexType>

The snippet of the snippet,

 <xsd:complexType name="PurchaseOrderType">
   ...
 </xsd:complexType>

indicates that the type PurchaseOrderType is a complex type and thus elements that are of this type can contain other elements. Peeling the onion one layer back, the snippet of the snippet,

 <xsd:complexType name="PurchaseOrderType">
  <xsd:sequence>
   ...
  </xsd:sequence>
  ...
 </xsd:complexType>

indicates that an element that is of type PurchaseOrderType contains a sequence of other elements. The grammar for XML schemas also has various other grouping elements beyond the sequence element. For example the XML schema grammar contains the list element the choice element and various other grouping elements which we will not touch upon. Peeling back one more layer we have the snippet-snippet

 <xsd:complexType name="PurchaseOrderType">
  <xsd:sequence>
   ...
  </xsd:sequence>
  <xsd:attribute name="orderDate" type="xsd:date"/>
 </xsd:complexType>

which indicates that an element of type PurchaseOrderType has an attribute with the name orderDate which can take values which are of type xsd:date. In our original example we saw the use of this attribute to indicate when the order was placed. We had in that instance document

<?xml version="1.0"?>
<purchaseOrder orderDate="1999-10-20">
  ...
</purchaseOrder>

The type xsd:date is but one of a profusion of primitive types which are part of the XML schema standard. Just as the programming language C contains int, long, double, ... So the XML schema standard defines an hierarchy of primitive types, see figure . The vast majority of these types we will not touch upon in this short tract, but you should at least be aware of their existence.

Now lets peel the onioin one more layer back. The full snippit

 <xsd:complexType name="PurchaseOrderType">
  <xsd:sequence>
   <xsd:element name="shipTo" type="USAddress"/>
   <xsd:element name="billTo" type="USAddress"/>
   <xsd:element ref="comment" minOccurs="0"/>
   <xsd:element name="items"  type="Items"/>
  </xsd:sequence>
  <xsd:attribute name="orderDate" type="xsd:date"/>
 </xsd:complexType>

can now be seen to indicate that elements that are of type PurchaseOrderType have one attribute named orderDate which takes values of type xsd:date. It also indicates that elements of this type contain a sequence of other elements. This sequence of other elements consists of the following elements: shipTo, billTo, comment, and items. Furthermore, the snippit also provides the definition for the majority of these elements. We see that

<xsd:element name="shipTo" type="USAddress"/>

indicates that the element shipTo is of type USAddress,

<xsd:element name="billTo" type="USAddress"/>

indicates that the element billTo is of type USAddress, and

<xsd:element name="items"  type="Items"/>

indicates that the element items is of type Items. Finally, the term

<xsd:element ref="comment" minOccurs="0"/>

indicates that the element comment, defined elsewhere, can also occur in the sequence of elements zero or more times. I can see heads nodding at the back of the room; so, with this I'll close this section on XML schemas. This lightning introduction should give enough of the flavor of XML schemas so as to allow you to deal with any problems that occur when working with GAT and the various adaptors which GAT may employ.