Using XDR Schemas

As mentioned, XML-Data Reduced (XDR) schema validation is the result of a Microsoft implementation of an early draft of what today is XSDs. XDR was implemented for the first time in the version of MSXML that shipped with Microsoft Internet Explorer 5.0, back in the spring of 1999.

In the XDR schema specification, you’ll find almost all of the ideas that characterize XSDs today. The main reason for XDR support in the .NET Framework is backward compatibility with existing MSXML-based applications. To enable these applications to upgrade properly to the .NET Framework, XDR support has been retained intact. You will not find XDR support anywhere else outside the Microsoft Windows platform, however.

If you have used Microsoft ActiveX Data Objects (ADO), and in particular the library’s ability to persist the contents of a Recordset object to XML, you are probably a veteran of XDR. In fact, the XML schema used to persist ADO 2.x Recordset objects to XML is simply XDR.

Overview of XDR Schemas

The example XML document data_dtd.xml used to demonstrate DTDs contains information about the modules in which a given class is articulated. The following listing shows the XDR schema that provides a full description of the class:

<?xml version="1.0"?>

<Schema name="MyClass" 
        xmlns="urn:schemas-microsoft-com:xml-data"
        xmlns:dt="urn:schemas-microsoft-com:datatypes">

<!-- Attribute Types -->
<AttributeType name="title" dt:type="string" />
<AttributeType name="company" dt:type="string" />
<AttributeType name="author" dt:type="string" />
<AttributeType name="total" dt:type="int" />
<AttributeType name="expandable" dt:type="enumeration" 
               dt:values="true false" />
<AttributeType name="optional" dt:type="enumeration" 
               dt:values="true false" />
<AttributeType name="id" dt:type="int" />

<!-- Element Types -->

<!-- CLASS -->
<ElementType name="class" content="eltOnly" model="closed" order="seq">
   <element type="days" minOccurs="1" maxOccurs="1" />   
   <attribute type="title" required="yes" />   
   <attribute type="author" required="no" />   
   <attribute type="company" required="no" />
</ElementType>

<!-- DAYS -->
<ElementType name="days" content="eltOnly">
   <element type="day" minOccurs="1" maxOccurs="*" />   
   <attribute type="total" required="yes" />   
   <attribute type="expandable" required="no" />
</ElementType>

<!-- DAY -->
<ElementType name="day" content="textOnly">
   <attribute type="id" required="yes" />   
   <attribute type="optional" required="no" />
</ElementType>
</Schema>

Compared to the DTD schema, this XDR schema is certainly more verbose, but it also provides more detailed information. The idea behind an XDR schema is that you define attribute and element types and then use those entities to construct the hierarchy that makes the target document. For example, let’s analyze more closely the block that refers to the <class> root node, shown here:

<ElementType name="class" content="eltOnly" model="closed" order="seq">
   <element type="days" minOccurs="1" maxOccurs="1" />   
   <attribute type="title" required="yes" />   
   <attribute type="author" required="no" />   
   <attribute type="company" required="no" />
</ElementType>

The <class> element is declared as an element type, with the subtree formed by all the nodes located one level down from it—in this case, only <days> and a few attributes.

Both attributes and child nodes have a type property that refers to other ElementType or AttributeType schema nodes. From this structure, it’s easy to see how validating parsers work to verify the correctness of a node against a schema—be it XDR or XSD. They simply validate the node attributes and the child nodes one level down. By applying this simple algorithm recursively, they traverse and validate the entire tree.

From our sample XDR file, you can also appreciate the schema enhancements over the DTD model. In particular, you can set the type for each attribute and strictly control the cardinality of each node by using the minOccurs and maxOccurs properties. With DTDs, on the other hand, you can barely define a fixed range of occurrences for a given node.

Looking ahead to XSD, you’ll notice that the key improvement concerns typing. XSD defines a type system that extends the XDR type system and that, more importantly, has a direct counterpart in the .NET Framework type system. (I’ll have more to say about this in the section “.NET Type Mapping,” on page 109.)

Validating Against an XDR

An XML document can include its XDR schema as in-line code or simply link it as an external resource. The XmlValidatingReader class determines that a given document requires XDR validation if an x-schema namespace declaration is found. The following sample document, named data_xdr.xml, points to an XDR schema stored in an external resource—the schema.xml file:

<?xml version="1.0" ?>
<!-- Sample XML document (data_xdr.xml) using XDR -->

<class xmlns="x-schema:Schema.xml"
       title="Applied XML Programming for .NET" 
       company="Wintellect" 
       author="DinoE">
   <days total="5" expandable="true">
      <day id="1">XML Core Classes</day>
      <day id="2">Related Technologies</day>
      <day id="3">XML and ADO.NET</day>
      <day id="4" optional="true">XML and Applications</day>
      <day id="5" optional="true">XML Interoperability</day>
   </days>
</class>

The following code snippet demonstrates how to set up an instance of the XmlValidatingReader class to make it validate a file using XDR:

XmlTextReader _coreReader = new XmlTextReader("data_xdr.xml");
XmlValidatingReader reader = new XmlValidatingReader(_coreReader);
reader.ValidationType = ValidationType.XDR;
reader.ValidationEventHandler += new ValidationEventHandler(MyHandler); 
while(reader.Read());

This is in no way different from what you’ve seen for DTD and what you will see for XSD in the section “Validating Against an XSD Document,” on page 130. When you require XDR validation and no XDR schema information exists in the XML document, the parser always returns a warning similar to the one shown in Figure 3-5.

The XML format for an ADO recordset provides the perfect, real-world example of an XML document that contains in-line XDR schema information, as shown here:

<!-- Northwind.xml, XML representation of an ADO recordset -->
<xml xmlns:s=‘uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882’ 
     xmlns:dt=‘uuid:C2F41010-65B3-11d1-A29F-00AA00C14882’ 
     xmlns:rs=‘urn:schemas-microsoft-com:rowset’ 
     xmlns:z=‘#RowsetSchema’>
<s:Schema id=‘RowsetSchema’>
   <s:ElementType name=‘row’ content=‘eltOnly’>
      <s:AttributeType name=‘employeeid’ rs:number=‘1’ />
      <s:AttributeType name=‘firstname’ rs:number=‘2’ />
      <s:AttributeType name=‘lastname’ rs:number=‘3’ />
      <s:extends type=‘rs:rowbase’/>
   </s:ElementType>
</s:Schema>
<rs:data>
   <z:row employeeid=‘1’ firstname=‘Nancy’ lastname=‘Davolio’ />
   <z:row employeeid=‘2’ firstname=‘Andrew’ lastname=‘Fuller’ />
   <z:row employeeid=‘3’ firstname=‘Janet’ lastname=‘Leverling’ />
</rs:data>
</xml>

This simple recordset contains just three columns taken from the Employees table in the Microsoft SQL Server 2000 Northwind database. The XDR schema is placed in-line under the <s:Schema> tag. The structure of the document is expressed using a single element node (named row) and one attribute node per each column in the result set. Figure 3-6 demonstrates that this file (northwind.xml) is perfectly validated by the .NET XDR parser.