XDR Schemas | XML and SQL Server 2000

The XDR language is a subset of ideas described in the XML-Data specification. Microsoft's XML Parser (MSXML) implementation utilizes the XML-Data Reduced language specification, which is based on the XML-Data Note posted by the W3C in January 1998. It is still available at http://www.w3.org/TR/1998/NOTE-XML-data-0105/. The parser implementation is also based on the Document Content Description (DCD) for XML, available at http://www.w3.org/TR/NOTE-dcd. XML schemas in Microsoft Internet Explorer 5.0 and later provide support for the subset of XML-Data that coincides directly with the functionality expressed in this DCD, although in a slightly different XML grammar.

Elements and Attributes

Just as in the W3C schema specification, specifying <ElementType ...> and <AttributeType ...> defines the elements and attributes contained in an XDR schema, respectively. These provide the definition and type of the elements and attrib-utes. Then an instance of an element or an attribute is declared using <element ...> or <attribute ...> tags.

Consider the XDR schema shown in Listing 5.1.

Listing 5.1 Sample XDR Schema

 <?xml version="1.0"?>  <Schema xmlns="schemas-microsoft-com:xml-data">    <ElementType name="title" />    <ElementType name="author" />    <ElementType name="pages" />    <ElementType name="book" model="closed">      <element type="title" />      <element type="author" />      <element type="pages" />      <AttributeType name="copyright" />      <attribute type="copyright" />    </ElementType>  </Schema>

The schema defines four elements <title> , <author> , <pages> , and <book> using the <ElementType> element. The <book> element specifies the individual elements and attributes that make it up. In other words, it describes the content model for the ele-ment. There is much more to the content model than this simple example shows, and we will discuss the additional components in the next section.

This example shows that each book element contains title , author , and pages child elements. This content model is specified using the element element, along with the type attribute that references the element type defined earlier.

There is also support for global attributes that enable multiple elements to share the definition of a common attribute. Take a look at Listing 5.2. This schema declares an attribute, copyright , for the book element. This is done using the <AttributeType> element, which defines an attribute type, and then declaring it using attribute ele-ment. You specify the <AttributeType> element globally by placing it outside the context of any <ElementType> .

Listing 5.2 Sample of Global Attribute Declaration

 <Schema xmlns:s="urn:schemas-microsoft-com:xml-data">    <ElementType name="title" content="textOnly"/>    <ElementType name="authors" content="textOnly"/>    <AttributeType name="pages" content="textOnly"/>    <ElementType name="book" order="seq" content="eltOnly">      <attribute type="pages" />      <element type='title" />      <element type="authors" />    </ElementType>  </Schema>

The Content Model

The content model describes the structure of elements and attributes in the XML document.To do this, you use various attributes such as model , minOccurs , maxOccurs , order , content , and so on. We'll look at the content model of an element first and then at the content model of an attribute.

For the rest of this content model discussion, I would like you to keep in mind that choices made concerning these elements and attributes and the attributes' values are strictly and completely governed by a company's business rules. These are not arbitrary decisions.

Look back at Listing 5.2. As we saw in the preceding section, the content model for the title , author , and pages elements is pretty straightforward. Because the content attribute specifies the elements as textOnly , these elements contain text and nothing else (no child elements).

The content model for the book element is a little more complex. The content attribute for the book element is eltOnly . This means that the book element can contain only the elements specified ( title , author , and pages ). Furthermore, for each book element instance, the child elements must be in the order specified in the schema. See Listing 5.3 for a sample instance document that conforms to the schema in Listing 5.2.

Listing 5.3 A Valid Instance Document of the Schema in Listing 5.2

 <msx:book xmlns:msx="x-schema:BookSchema.xml">    <msx:pages>522</msx:pages>    <msx:title>Java and XML: A Marriage That Works</msx:title>    <msx:authors>John Griffin</msx:authors>  <msx:/book>

Let's now take a look at the different attributes used by the content model.

The model Attribute ( Open and Closed Content Models)

An element's content model can have the property of being either open or closed. In an open content model, an element can have additional child elements and attributes that are not declared in the schema that the document references. With the opposite , a closed model, the document cannot include any data that does not follow the rules of the referenced schema.

The default value for an XDR schema content model is open. This provides extensibility for an XDR schema that is not present in a Document Type Definition (DTD), which is a closed model. A DTD disallows including any information that does not follow its rules.

Listing 5.4 is a fragment of our earlier XML document in Listing 5.2.

Listing 5.4 BookSchema Fragment

 <msx:book xmlns:msx="x-schema:BookSchema.xml"          xmlns:msy="urn:some-new-namespace">    <msx:title msy:id="123"> Java and XML: A Marriage That Works  </msx:title>    <msx:authors> John Griffin </msx:authors>    <msx:pages>474</msx:pages>    <msy:publisher>New Rider's Publishing</msy:publisher>  </msx:book>

By default, this schema specifies an open content model. This fragment is valid even though it has additional elements and attributes not specified in the schema (such as the id attribute in the title element and the publisher child element, both of which are defined in the "urn:some-new-namespace" namespace).

Even though the open content model allows some freedom and enables us to do some things that we can't do in a DTD, there are constraints that must be met:

Content cannot be inserted or deleted, thereby breaking the existing content model. For example, our schema defines the book element as a sequence of three elements. Therefore, you must provide that exact element sequence before adding any open content. So the pages element cannot be removed, nor can there be two title elements next to each other.
Undeclared elements can be added as long as they are defined in a different namespace.
After the schema content model is satisfied, other elements can be added. For example, an XML document will validate even if you add a second title element after the pages element.

The following example specifies a closed content model:

 <x:ElementType name="book" model="closed">

This indicates that a book element can only contain the title , author , and pages elements, as the schema dictates. In this case, utilizing the extended elements in the preceding XML fragment would invalidate the document.

The content Attribute

The content attribute describes exactly what an element can contain. Its possible values are listed in Table 5.1.

Table 5.1. The content Attribute

Value	Description
`textOnly`	The element can contain only text.
`eltOnly`	The element can contain only other elements.
`mixed`	The element can contain a mixture of text and elements.
`empty`	The element must be empty.

Going back to our book example in Listing 5.4, as we've said, this XDR schema defines a book element that contains three child elements: title , author , and pages . These child elements can contain only text because the content attribute for each of these elements is textOnly . The book element, however, can contain only elements and no text because its content attribute is eltOnly . Listing 5.5 shows our entire schema again.

Listing 5.5 The Book XDR Schema

 <?xml version="1.0"?>  <Schema xmlns:s="schemas-microsoft-com:xml-data">    <s:ElementType name="title" content="textOnly" />    <s:ElementType name="author" content="textOnly" />    <s:AttributeType name="pages" content="textOnly" />    <s:ElementType name="book" content="eltOnly" model="closed">      <s:element type="title" />      <s:element type="author" />      <s:attribute type="pages" />      <s:AttributeType name="copyright" />      <s:attribute type="copyright" />    </s:ElementType>  </Schema>

Notice also that the book element uses a closed content model ( model="closed ). This means the book element can contain only these three child elements and no text or additional child elements and attributes.

An empty content attribute specifies that the element cannot contain any text or child elements; conversely, it can contain attributes. A mixed element, on the other hand, can contain text and child elements.

The minOccurs and maxOccurs Attributes

The minOccurs and maxOccurs attributes are constraint rules that specify how many times a child element can appear within its parent element. A complete description of these attributes is given in Table 5.2. You specify it like this:

 <element type="Item" maxOccurs="*" />

Table 5.2. The Constraint Rules

Attribute	Description	Valid Value	Interpretation	Default
`maxOccurs`	Specifies the maximum number of times that a child element may appear within a parent element.	"1"	One and only one instance of this child element may appear.	"1" unless the content="mixed"; if this is the case, then the default value is " `*` ".
	" `*` "		Any number of this child element may appear.	n/a
`minOccurs`	Specifies the minimum number of times that a child element may appear within a parent element.	"0"	In effect, specifying "0" for `minOccurs` makes an occurrence of the child element optional.	`minOccurs` ' default value is "1".
		"1"		n/a

In the schema in Listing 5.6, the author element sets maxOccurs to "*" , while the pages element sets the minOccurs attribute to "0" .

Listing 5.6 A Schema with Both maxOccurs and minOccurs

 <?xml version="1.0"?>  <Schema xmlns:s="schemas-microsoft-com:xml-data">    <s:ElementType name="title" content="textOnly" />    <s:ElementType name="author" content="textOnly" />    <s:ElementType name="pages" content="textOnly" />    <s:ElementType name="book" content="eltOnly" model="closed">      <s:element type="title" />      <s:element type="author"  maxOccurs="*"  />      <s:element type="pages"  minOccurs="0"  />    </s:ElementType>    <s:ElementType name="root" >      <s:element type="book" />    </s:ElementType>  </Schema>

The schema in Listing 5.6 makes the document in Listing 5.7 a valid XML document.

Listing 5.7 A Valid Document Based on the Listing 5.6 Schema

 <root>    <book>      <title>C Programming</title>      <author>Author A</author>      <author>Author B</author>      <pages>300</pages>    </book>    <book>      <title>Java Programming</title>      <author>Author C</author>    </book>  </root>

The minLength and maxLength Attributes

The "urn:schemas-microsoft-com:datatypes" namespace specifies an element or attribute's data type. The minLength and maxLength attributes defined in this namespace are used to constrain the length of a string , number , bin.hex , or bin.base64 data type. These attributes are enforced at parse-time and run-time, and they have valid parent elements of <ElementType/> , <AttributeType/> , and <dataType/> .

For string and number data types, maxLength specifies the maximum number of characters allowed, and minLength specifies the minimum number of characters.

For bin.hex and bin.base64 , maxLength sets the maximum number of bytes of the binary object, and minLength sets the minimum number of bytes.

Here's an example of how to use these length attributes. The following schema (see Listing 5.8) specifies the content model for the userID , password , and LoginInfo elements. The password element specifies a minimum length of six characters and a maximum length of eight characters. dt:type and its uses will be explained later in this chapter in the "Data Type Coercions" section. For now, we'll just say that it specifies an element's data type.

Listing 5.8 Sample Schema Using minLength and maxLength

 <?xml version="1.0"?>  <Schema xmlns:s="schemas-microsoft-com:xml-data"          xmlns:dt="urn:schemas-microsoft-com:datatypes" >    <s:AttributeType name="userID"          xmlns:dt="urn:schemas-microsoft-com:datatypes"          dt:type="string" />    <s:AttributeType name="password"               dt:type="string"  dt:minLength="6"   dt:maxLength="8"  />    <s:ElementType name="LoginInfo" >      <s:attribute type="userID" />      <s:attribute type="password" />    </s:ElementType>  </Schema>

Here are two examples of valid instance documents of the preceding schema.

 <LoginInfo userID="1" password="xyz123" />  <LoginInfo userID="2" password="" />

Although the password attribute value in the second instance is less than the minLength , the instance is still valid because a password value specified as "" is treated the same as if the password attribute is not specified.

The order Attribute

The order attribute specifies how sequences of elements appear in a document instance. The order attribute can have any one of these values: "seq" , "one" , or "many" .

An order attribute value of "seq" indicates that the enclosed elements must appear in the same order in the instance document as they appear in the schema. See the schema fragment in Listing 5.9.

Listing 5.9 An Example of order="seq"

 <ElementType name="PurchaseOrder" order="seq">    <element type="PONumber" />    <element type="PODate" />    <element type="ShipAddress" />  </ElementType>

An order attribute value of "one" specifies the "either/or" combination. Put another way, only one of the child elements defined in an <ElementType> can appear in an instance document. So to specify that an Item element can contain either a product element or a backOrderedProduct element but not both, the schema can be specified as in the following schema fragment:

 <ElementType name="Item"  order="one"  >    <element type="product" />    <element type="backOrderedProduct" />  </ElementType>

An order attribute value of "many" specifies that the child elements can appear in any order and in any quantity.

The default value for the order attribute depends on the content model in use. With a content attribute of "eltOnly" , the default value for order is "seq" . With a content attribute of "mixed" , the default value for order is "many" .

The order attribute is valid for either an <ElementType> or group element.

The group Element

The group element enables us to specify constraints on a subset of child elements. This capability can be quite useful.

The group element can have the order , minOccurs , and maxOccurs attributes.

Let's look at another example in Listing 5.10. The following schema defines the Item element as containing a group element with two child elements, product and backOrderedProduct . Because the group element has an order attribute of "one" , only one of these children elements can appear in the Item element. This way, you won't have an Item element with both a product and a backOrderedProduct element (that wouldn't work so well). Only one of these child elements can be present.

Listing 5.10 An Example of the <group> Element

 <ElementType name="Item">      <group order="one">          <element type="product" />          <element type="backOrderedProduct" />      </group>      <element type="quantity"/>      <element type="price"/>  </ElementType>

This schema validates the document in Listing 5.11.

Listing 5.11 Document Conforming to Schema in Listing 5.10

 <Item>    <product>CD</product>    <quantity>100</quantity>    <price>10</price>  </Item>  <Item>    < backOrderedProduct >FloppyDisk</ backOrderedProduct >    <quantity>100</quantity>    <price>1</price>  </Item>

An Attribute's Content Model

The <AttributeType> element specifies the type of attribute used within elements. Required attributes are specified with the required keyword, as in the following:

 <AttributeType name="shipTo" dt::type="idref" required="yes"/>

The <attribute> element specifies instances of an attribute defined within the <AttributeType> element. It is used within an <ElementType> element.

In some ways, attributes are more limited than elements:

Attributes cannot contain child elements.
Attributes have no "either/or" alternative.
Attribute order cannot be specified.
Attributes can appear only once per element (although you can specify required ).

At the same time, attributes can do some things that elements cannot:

Attributes can limit their legal values to a small set of strings, like this:

 <AttributeType name="priority" dt:type="enumeration" dt:values="high medium low" />

Attributes have a default value, as in the following example:

 <AttributeType name="quantity" dt:type="int">  <attribute type="quantity" default="1"/>

Although different element types can have attributes with the same name, these attributes are independent and unrelated.

Specifying an Attribute's Default Value

The default attribute specifies an attribute's default value. It is specified in the <AttributeType> and <attribute> elements in the schema.

For example, the schema in Listing 5.12 assigns the default value of "Seattle" to the City attribute.

Listing 5.12 Specifying a Default Value for an Attribute

 <?xml version="1.0" ?>  <Schema xmlns="urn:schemas-microsoft-com:xml-data" >  <ElementType name="Customer" >      <AttributeType name="CustomerID" />      <AttributeType name="ContactName" />      <AttributeType name="City" default="Seattle" />      <attribute type="CustomerID" />      <attribute type="ContactName" />      <attribute type="City" />  </ElementType>  </Schema>

Taking an example from the Northwind database in Appendix A, in a document instance with a <Customer> element with a missing City attribute, the default value ( "Seattle" ) will be assumed and the document made valid. For example:

 <Customer CustomerID="ALFKI" ContactName="Maria Anders" City="London" />  <Customer CustomerID="ANATR" ContactName="Ana Trujillo" />

The customer "ALFKI" has an explicitly stated City attribute ( "London" ), so the default value is ignored. On the other hand, the customer "ANATR" has no City attribute specified, so the default value ( "Seattle" ) is supplied.

If the schema specifies both a default attribute and a required attribute, as in the following example, there is a slightly different behavior. Look at the following fragment, in which the <AttributeType> specifies the City attribute as required with a default value of "Seattle" .

 <AttributeType name="City" default="Seattle" required="yes" />

The Customer element is now required to have a City attribute, and it must have "Seattle" as its value.

Data Types

Data type specification is a necessary part of schemas. In fact, it was one of the major driving forces behind their creation. The W3C XML 1.0 Recommendation defines enumerated types and a set of tokenized types. These types are referred to as primitive types in Microsoft's XML documentation.

The primitive types listed in Table 5.3 include the following, defined in Section 3.3.1 of the W3C XML 1.0 Recommendation.

Table 5.3. Microsoft's Primitive Data Types

Primitive Data Type	Description
`entity`	Represents the XML `ENTITY` type.
`entities`	Represents the XML `ENTITIES` type.
`enumeration`	Represents an enumerated type (supported on attributes only).
`id`	Represents the XML `ID` type.
`idref`	Represents the XML `IDREF` type.
`idrefs`	Represents the XML `IDREFS` type.
`nmtoken`	Represents the XML `NMTOKEN` type.
`nmtokens`	Represents the XML `NMTOKENS` type.
`notation`	Represents a `NOTATION` type.
`string`	Represents a `string` type.

In addition to the primitive types, Microsoft's schema specification enumerates many other different types. These data types are listed in Table 5.4. Later in this chapter, in the "Data Type Coercions" section, we'll see how these entities map to SQL Server data types and what SQL Server conversion functions are used to translate XML data types.

Table 5.4. Microsoft Supported XML Nonprimitive Data Types

Data Type	Description
`bin.base64`	MIME-style, Base64-encoded binary large object (BLOB).
`bin.hex`	Hexadecimal digits representing octets.
`boolean`	0 or 1, where 0 = "false" and 1 = "true".
`char`	String, one character long.
`date`	Date in a subset ISO 8601 format, without the time data (for example, "1994-11-05"). The date itself is not validated . (For example, 2-31-99 will pass validation.)
`dateTime`	Date in a subset of ISO 8601 format, with optional time and no optional zone. Fractional seconds can be as precise as nanoseconds (for example, "1988-04-07T18:39:09").
`dateTime.tz`	Date in a subset ISO 8601 format, with optional time and optional zone. Fractional seconds can be as precise as nanoseconds (for example, "1988-04-07T18:39:09-08:00").
`fixed.14.4`	Same as `number` , but no more than 14 digits to the left of the decimal point and no more than 4 to the right.
`float`	Real number with no limits on digits; can potentially have a leading sign, fractional digits, and optionally , an exponent. Punctuation as in U.S. English.Values range from 1.7976931348623157E+308 to 2.2250738585072014E-308.
`int`	Number with optional sign, no fractions, and no exponent.
`number`	Number with no limit on digits; can potentially have a leading sign, fractional digits, and optionally, an exponent. Punctuation as in U.S. English. (Values have the same range as the most significant number, R8: 1.7976931348623157E+308 to 2.2250738585072014E-308.)
`time`	Time in a subset ISO 8601 format, with no date and no time zone (for example, "08:15:27").
`time.tz`	Time in a subset ISO 8601 format, with no date but optional time zone (for example, "08:1527-05:00").
`i1`	Integer represented in one byte. A number with optional sign, no fractions, and no exponent (for example, "1, 127, -128").
`i2`	Integer represented in one word. A number with optional sign, no fractions, and no exponent (for example, "1, 703, -32768").
`i4`	Integer represented in four bytes. A number with optional sign, no fractions, and no exponent (for example, "1, 703, -32768, 148343, -1000000000").
`i8`	Integer represented in eight bytes. A number with optional sign, no fractions, no exponent, and 19-digit precision. Range is from 9,223,372,036,854,775,808 to 9,223,372,036,854,775,807.
`r4`	Real number with seven-digit precision; can potentially have a leading sign, fractional digits, and optionally, an exponent. Punctuation as in U.S. English.Values range from 3.40282347E+38F to 1.17549435E-38F.
`r8`	Same as `float` . Real number with 15-digit precision; can potentially have a leading sign, fractional digits, and optionally, an exponent. Punctuation as in U.S. English.Values range from 1.7976931348623157E+308 to 2.2250738585072014E-308.
`ui1`	Unsigned integer.A number, unsigned, no fractions, no exponent (for example,"1, 255").
`ui2`	Unsigned integer, two bytes. A number, unsigned, no fractions, no exponent (for example, "1, 255, 65535").
`ui4`	Unsigned integer, four bytes. A number, unsigned, no fractions, no exponent (for example, "1, 703, 3000000000").
`ui8`	Unsigned integer, eight bytes. A number, unsigned, no fractions, no exponent. Range is 0 to 18,446,744,073,709,551,615.
`uri`	Uniform resource identifier (for example, `"urn:schemas-microsoft-com:Office9"` ).
`uuid`	Hexadecimal digits representing octets, optional embedded hyphens that are ignored (for example, "333C7BC4-460F-11D0-BC04-0080C7055A83").

Now that we've looked at Microsoft's version of XML schema documents, let's start establishing the connection between them and SQL Server 2000 and discuss whatever else is needed to make them work together.

Mapping Schema

So how do we get relational data from a database into an XML document format? Well, we first start with an XML schema document. This alone isn't enough, though. The schema describes the structure of the document, but there is still no relation between the document and the data yet. What we need to tie these two objects together are referred to as annotations to the XDR schema. An annotated XDR schema is referred to as a mapping schema because it maps the schema to the relational database. This enables data to be retrieved in the form of an XML document (see Figure 5.1).

Figure 5.1. Schemas, annotations, and XPath.

graphics/05fig01.gif

Several schema annotations defined by Microsoft map the elements and attributes of XML data to database tables and columns . We will be examining each of these annotations in the remainder of this chapter.

Think of a mapping schema as a database view, which is created with the CREATE VIEW command. Queries against the mapping schema are carried out via XPath queries, much in the same way that SQL queries are used to extract data from a database view.

Namespaces

We'll be using two different namespaces in our mapping schema discussions, one for annotations and the other for data types.

Annotation namespace is declared with "urn:schemas-microsoft-com:xml-sql" inside the <schema> declaration. We will again be using sql as our namespace prefix, although the choice is completely arbitrary, as we've said previously. Listing 5.13 shows a sample declaration.

Listing 5.13 A Sample Declaration of the Annotation Namespace

 <?xml version="1.0" ?>  <Schema xmlns="urn:schemas-microsoft-com:xml-data"          xmlns:sql="urn:schemas-microsoft-com:xml-sql"  >  ...  </Schema>

Data type namespace is declared with "urn:schemas-microsoft-com:datatypes" , again inside the <schema> declaration. We will use dt as our namespace prefix, as shown in Listing 5.14.

Listing 5.14 A Sample Declaration of the Data Type Namespace

 <?xml version="1.0" ?>  <Schema xmlns="urn:schemas-microsoft-com:xml-data"          xmlns:sql="urn:schemas-microsoft-com:xml-sql"          xmlns:dt="urn:schemas-microsoft-com:datatypes"  >  ...  </Schema>

Annotated Schema Example

Let's take what we've learned up to this point and tie it together with an example. First we'll look at an XDR schema of the Northwind database's Orders table, shown in Listing 5.15.

Listing 5.15 XDR Schema for the Orders Table

 <?xml version="1.0" ?>  <Schema xmlns="urn:schemas-microsoft-com:xml-data"          xmlns:dt="urn:schemas-microsoft-com:datatypes"          xmlns:sql="urn:schemas-microsoft-com:xml-sql">  <ElementType name="Orders" >      <AttributeType name="OrderID" />      <AttributeType name="CustomerID" />      <AttributeType name="ShipName" />      <attribute type="OrderID"/>      <attribute type="CustomerID" />      <attribute type="ShipName" />  </ElementType>  </Schema>

Nothing is new here. Now let's map the schema to the Orders table by adding the appropriate annotations, as shown in Listing 5.16. Don't worry yet about exactly what the annotations themselves mean; I give a short explanation about what the annotations are doing. We'll be covering them in detail in the next several pages of this chapter.

Listing 5.16 Mapping the Schema to the Orders Table

 <?xml version="1.0" ?>  <Schema xmlns="urn:schemas-microsoft-com:xml-data"          xmlns:dt="urn:schemas-microsoft-com:datatypes"          xmlns:sql="urn:schemas-microsoft-com:xml-sql">  <ElementType name="Order"  sql:relation="Orders"  >      <AttributeType name="OrdID" />      <AttributeType name="CustID" />      <AttributeType name="SName" />      <attribute type="OrdID"  sql:field="OrderID"  />      <attribute type="CustID"  sql:field="CustomerID"  />      <attribute type="SName"  sql:field="ShipName"  />  </ElementType>  </Schema>

In this example, we used two annotations, sql:relation and sql:field . The sql:relation annotation maps the Order element to the Orders table, and the sql:field annotation maps the OrdID , CustID , and SName attributes to the OrderID , CustomerID , and ShipName fields, respectively.

The relations specified by the annotations are case sensitive.

Default Mapping of XDR Elements and Attributes

The default behavior for an annotated XDR schema maps an element to the table or view with the same name. In the same manner, an attribute maps to the same-name column of the table or view.

It is possible to change this behavior if we want to. That is, we can map an element to a column. However, just like the supposed great deals on major airlines' fares, some restrictions apply.

The elements to be mapped to columns cannot be of a complex type. (They cannot have child elements.)
The elements must have the content attribute set to textOnly .
If the content attribute is not specified, the sql:field annotation must explicitly specify the element to column mapping. (See the discussion of the sql:field annotation in this chapter.)

Now, to demonstrate the points we've made, let's execute these schema files on SQL Server and observe the results. First, save the schema file from Listing 5.16 to the template directory you specified during the virtual directory setup as OrderSchema.xml . Next, create the template file shown in Listing 5.17 and save it in the same template virtual directory as OrderTemplate.xml . Refer to Chapter 3, "Internet Information Server and Virtual Directories," if necessary to perform virtual names and directories setup. Refer to Chapter 4 for information on template files and their execution method.

Listing 5.17 The Template File to Call the Order Schema File

 <ROOT xmlns:sql="urn:schemas-microsoft-com:xml-sql">    <sql:Xpath-query mapping-schema="../OrderSchema.xml">      /Orders    </sql:xpath-query>  </ROOT>

Then execute OrderTemplate.xml with the following URL:

 http://iisserver/Nwind/templates/OrderTemplate.xml

The first five returned records are displayed in Listing 5.18.

Listing 5.18 Partial Results of Executing the Template File

 <ROOT xmlns:sql="urn:schemas-microsoft-com:xml-sql">    <Orders OrderID="10248" CustomerID="VINET" ShipName="Vins et alcools     Chevalier" />    <Orders OrderID="10249" CustomerID="TOMSP" ShipName="Toms     Spezialitten" />    <Orders OrderID="10250" CustomerID="HANAR" ShipName="Hanari Carnes" />    <Orders OrderID="10251" CustomerID="VICTE" ShipName="Victuailles en     stock" />    <Orders OrderID="10252" CustomerID="SUPRD" ShipName="Suprmes dlices"  />  ...  </ROOT>

A couple of points here: First and foremost, the reason you saved the schema file into the template directory is because the template file specified the location of the schema file as being in the same directory. If you wanted to place the schema file in the schema directory, you would have had to specify the relative address of the schema file from the template directory. This means changing

 <sql:xpath-query mapping-schema="OrderSchema.xml">

 <sql:xpath-query mapping-schema="../schemas/OrderSchema.xml">

If your system administrators have allowed direct path access on servers (and I doubt they have), we could have specified an absolute path also, such as:

 c:\inetpub\wwwroot\Nwind\schemas\OrderSchema.xml

This entire discussion assumes that the two directories are parallel to each other in the directory tree, just as we set up the structure in Chapter 3.

Second, the /Orders in the third line of Listing 5.15 is an XPath query that returns results for all orders found.

Before we dive into each of the individual annotations in detail, I'd like to take a small side trip and discuss Microsoft's proposed solution to several prominent distributed computing problems facing developers today. This solution utilizes XML and schemas as its language. This solution is what Microsoft calls BizTalk.