XDR is an acronym for XML-Data Reduced and is a language used to create schemas. Normally a Data Type Definition (DTD) is used to describe the structure of the data in an XML document. This is generally fine, except that in the DTD and XML document all data is character data. XDR schemas provide you with a way to map the elements to their respective fields in a SQL Server table.
Annotations to the XDR schema allow you to map different elements to the fields in the database and assign your own element name attributes. Using annotations to the XDR schema is an alternative to using the XML FOR EXPLICIT mode, which is quite complex.
A schema file is built to perform the mapping of columns in your database table to the elements in an XML document. This file has a .xml extension and is in fact an XML document itself. The browser will parse a schema file as an XML document and execute any queries contained in your document.
Let's take a look at the basics for an XML schema file. As with all XML and XSL documents the first line in a schema file is the XML declaration:
Annotations for an XDR schema are specified in the namespace. There are actually three different namespaces that we need to include in a schema document and these namespaces are defined in the <Schema> element of the schema document.
The first of these namespaces is the Microsoft schema namespace. This defines this document as a Microsoft XDR schema document:
The next line of code defines the namespace for data types. Using this namespace allows us to specify the data type of an element or attribute:
The final namespace allows us to map SQL fields to attribute types in our schema document. This namespace is defined as shown in the code below:
After all of the namespaces have been specified we define the <ElementType> element. This element provides the mapping to a table in your database. An example of this mapping is shown in the next code fragment. We specify the name attribute for this element and specify the table that this element is mapped to using the sql:relation annotation:
Within the <ElementType> element we specify the <AttributeType> element. This element defines an attribute type for use within the schema. We can optionally specify the data type and a default value for this attribute. In the example below the <AttributeType> element has been assigned a name of FirstName and an XML data type of bin.base64, which maps to a VarChar data type in SQL Server. The Data Type Coercions topic in the SQL Books Online provides a complete cross-reference between SQL Server data types and XML data types.
We use the <attribute> element to define the actual attribute and specify how it should be mapped to the database. Using the sql:field annotation, we specify the physical mapping between this element and a column in the table specified in the <ElementType> element above. The code below demonstrates how this is done:
These are the basic elements required to create an annotated XDR schema. Let's move on and see how this actually works.
The schema that we want to create here will display the Software_ID and Software_Name_VC columns from the Software_T table. We will be using the sql:field annotation to map the Software_ID and Software_Name_VC columns to attributes that we define.
1. The code for the schema is listed below. Using your favorite text editor, enter the following code and save it as SoftwareSchema.xml. This XML document should be saved in the htData\Schema directory.
2. To test this schema, enter the following URL in the browser. After the schema name we specify the table name that will supply the data to this schema. Since we have not defined a root element in the schema we must specify the root element here; in this case we have chosen a root element name of Software:
Note the forward slash after the schema name – the syntax for calling a schema is slightly different from that for calling a template. When we execute a schema template we must specify the schema directory instead of a template directory, followed by a forward slash and then the schema name, which is just another XML document. We follow this with another forward slash followed by the table name that the schema is applied to. Finally, a question mark is inserted, followed by the parameter name Root, then an equals sign, then the name of the root element that we want to use.
The results that are displayed should be similar to those shown in the following figure. Notice that the Software_T element contains the ID attribute instead of Software_ID and the Software attribute is specified instead of Software_Name_VC:
The first line of code in this schema is the XML declaration and is standard in all XML and XSL documents that we create.
The <Schema> element defines the namespaces for this schema and includes the three namespaces that we have just discussed.
We have defined the <ElementType> element next and it provides a mapping between this element and a table in the database. Here we have specified that the <attributes> defined for this element will be mapped to the Software_T table:
Next, we specify the <AttributeType> element. We have no special data types that we want these fields to represent so we take the default XML data type of bin.base64:
We specify the <attribute> elements next and use the sql:field annotation to map these attributes. Notice that the first attribute is the ID attribute and this has been mapped to the Software_ID column in the Software_T table. The second attribute has been mapped to the Software_Name_VC column:
We specify the closing tags for the <ElementType> and <Schema> elements:
Having coded and executed our XDR schema we see that we are getting back to entering a lot of data in the URL. However, we can eliminate this by creating a template to execute the schema for us. This will reduce the amount of text that must be entered into the URL of the browser.
1. The template that we must code is very similar to our previous templates. The complete code for this template is listed below. Enter this code and save it as Software.xml in the Template directory:
2. To execute this template enter the following URL in your browser:
The results that you see are the same as for the last exercise, except that now we have executed a template that has executed a query to execute the schema. The results are shown in the following figure:
The first line of code in the template is the standard XML declaration. The second line of code is the root element to which we have assigned a name of Software. Within this element is the standard namespace for templates, which we have seen before:
Using the <sql:xpath-query> element we specify the mapping to the schema file. Notice that since the Schema directory is at the same level as the Template directory we have specified two periods to get back to the root level of the htData virtual directory. Then we specify a forward slash and the Schema directory followed by another forward slash and the schema file.
Within the <sql:xpath-query> element we have specified the query to be executed, and the table name of Software_T. This will cause the data from the entire table to be returned.
Lastly we close the root element by specifying the closing tag for the <Software> element:
By now you should realize that working with XML is not all that hard. Hopefully this chapter has dispelled some of the mystique surrounding XML, and you have a better feel for what XML can do and what you can do with XML.
We have introduced some of the more common XML features of SQL Server 2000 and have shown how easy it is to access data in SQL Server using the URL of your web browser. We have displayed data in the browser as unformatted well-formed XML data and, through the use of XSL stylesheets, we have also formatted XML data.
By now you should feel comfortable using XSL stylesheets to format XML data and to display it in a web page. While we have only touched on the basics of XSL stylesheets, be aware that XSL provides many different elements that will aid you in formatting the XML data to suit your needs. Appendix F provides some links and places to go for more information on XSL and XML.
We have seen how we were able to reduce the amount of data that needs to be entered into the URL through the use of templates. We also know that templates provide better security, as we have hidden the details of the queries and the details of our database from the end user. The maintenance aspects of templates are self-evident, as we need only make the necessary changes in one place and they are immediately effective for everyone who uses the templates.