XSD Schemas

The first feature of the XSD tool we are going to explore is deriving an XSD schema from an XML document. This is probably the least interesting of the XSD tool’s three use-cases, but we will continue that chapter with the schema in this section. First, we need an XML document so we can derive an XSD schema. Let’s create an XML document like the one shown in listing C.1 and call it garage.xml. The document has one top-level element garage with an element desc for a description and two car elements representing the cars parked in the garage.

1           C.1 An XML document  describing a garage

<?xml version="1.0" encoding="utf-8"?>

<garage>

  <desc>Two-car garage with attached workshop.</desc>

  <car make="Toyota" model="Camry" year="1996" />

  <car make="Honda" model="Accord" year="1999" />

</garage>

Now we can derive a schema for the structure of the XML tags in the in the above document. Deriving an XSD schema from an XML document is as simple as a calling a single program from the command line. Open a command window, navigate to the directory with the garage.xml document, make sure the Framework SDK’s “bin” directory is in your search path and execute the following command:

xsd.exe garage.xml

The xsd.exe program will run and create an XSD schema file named garage.xsd shown in listing C.2. It is important that you specify a filename with a “.xml” extension. Without the “.xml” extension the tool will not recognize the file type and abort without generating a schema. If you are using Microsoft Visual Studio.NET you can also create the schema from the context menu of the XML edit or.

2           C.2 A schema automatically created by the XSD tool from the document in listing C.1

<?xml version="1.0" encoding="utf-8"?>

<xs:schema id="NewDataSet" xmlns=""

  xmlns:xs="http://www.w3.org/2001/XMLSchema"

  xmlns:msdata="urn:schemas-microsoft-com:xml-msdata"> 

  <xs:element name="garage">  | #1

    <xs:complexType>          |

      <xs:sequence>

        <xs:element name="desc" type="xs:string" minOccurs="0" />   |#2

        <xs:element name="car" minOccurs="0" maxOccurs="unbounded"> |

          <xs:complexType>                                          |

            <xs:attribute name="make" type="xs:string" />           |

            <xs:attribute name="model" type="xs:string"/>           |

            <xs:attribute name="year" type="xs:string" />           |

          </xs:complexType>

        </xs:element>

      </xs:sequence>

    </xs:complexType>

  </xs:element>

  <xs:element name="NewDataSet" msdata:IsDataSet="true">

    <xs:complexType>

      <xs:choice maxOccurs="unbounded">

        <xs:element ref="garage" />

      </xs:choice>

    </xs:complexType>

  </xs:element>

</xs:schema>

(annotation) <#1 The root element in the source document results in a top level element with an anonymous type declaration.>
(annotation) <#2 The types of the child elements are also declared inline.>

When we examine the generated schema we find an element definition for the garage element. The type of the element is described directly within the element’s declaration as an anonymous complexType definition. A complexType is the XSD equivalent of a class, it describes a well-defined set of attributes and/or child elements and their form. The type definition for the garage node states that a <garage> element can contain elements named <desc> and <car> through the <xs:element> tags. A <car> element is itself defined as a complexType with the attributes make, model and year, each of type xs:string. The  xs:string type is the equivalent of the .NET string type for character sequences. Note that despite the year attribute’s value was a number in all instances in the source document, the <xs:attribute> tag in the schema declares the attribute to be of type xs:string, not a numeric type like xs:decimal or xs:integer. The tool does not assume that the source document is representative of all possible values and chooses the less restrictive type xs:string. In the same vein, the tool declares the type’s two elements to be optional. It has no information whether or not both child nodes are required, hence it chooses the more conservative option and adds the minOccurs attribue set to zero, meaning neither node is required. However, since the car element occurs more than once in the source document, the schema declares that a garage node can contain multiple car elements by adding the maxOccurs="unbounded" attribute.  As a rule of thumb, the tool creates a very “conservative” schema from the source document.

BUG WARNING: In a few cases the tool produces a schema that is not valid for the source document. When the source document contains an element that occurs multiple times or contains an element with attributes, the tool places these elements out of order within the corresponding xs:sequence. Since the xs:sequence model group requires its content to occur in the order defined in the schema validation of the XML source document against the generated XSD schema fails.

The generated schema also contains another element declaration NewDataSet which enables validation of XML documents that contain more than one garage element.