The XmlReader class is an abstract class, which means you can't create an XmlReader object. Instead you need to create an object from a class that implements the XmlReader class. In the .NET Framework there are currently two classes that implement the XmlReader class: XmlTextReader and XMLNodeReader. To write XML in the cursor-based model the only available implementation is the XmlTextWriter class. For the record: there is no XMLNodeWriter. Basically it isn't needed, because if you supply the XmlTextWriter with an XML structure, it will write that structure to file perfectly. However, when you are reading from file, you may want to use different models. All these classes are based on abstract classes that you could use to base more different readers and writers upon. The class structure is shown in Figure 1.

Figure 1. Cursor-based classes in the .NET Framework

Using the readers seems easy enough, but you'll find that it actually doesn't do what you expect at first. Once you start to think about it, it actually makes sense. First of all the beginning and end tags of are treated as separate entities within the stream, which also holds for text values and white-space. So if you just write out the XML document to a text stream, you will find all sorts of duplicate data and empty spaces. You need to dive further into the class and use methods beyond the simple Read method to get more control over the input. Fortunately this is fairly easy and the names of all the methods and properties are quite intuitive, as you can see in the code below.

Do While myXmlReader.Read()
	If myXmlReader.IsEmptyElement Then
		Console.Write("Empty element: " & myXmlReader.Name)
	ElseIf myXmlReader.IsStartElement() Then
		Console.Write("Non-empty element: " & myXmlReader.Name)
	ElseIf Not myXmlReader.NodeType = XmlNodeType.EndElement Then
		Console.Write("Value: " & myXmlReader.Value)
	End If
Loop

The XmlDocument class is just a DOM implementation. Anybody familiar with DOM should be able to use it fairly easily. This goes even more for people familiar with MSXML, which also implements some additional methods not part of the DOM specification. XmlDocument implements similar (in most cases the same) methods. Besides the regular XmlDocument class, there are also several derived classes optimized for certain operations. The XmlDataDocument class is geared towards interaction with a DataSet, enabling ADO.NET and System.XML to interact easily. The XPathDocument class and the related XPathNavigator class are optimized for XPath queries and transforming XML with Extensible Stylesheet Language Tranformations (???). If you want to use XSLT, you'll also need the XslTranform class. Unlike MSXML, where you can execute a transformation based on two DOM objects, System.XML contains specific classes for specific purposes, each optimized for its unique purpose. This makes the XML support in the .NET Framework extremely performant.

The more complex objects in the Framework are built on the simple ones. The simple objects are highly optimized for performance. The more complex the derived class, the less the performance becomes. This is why it is important to get to know the XML object model in the.NET Framework very well, so you can get to what you want in the least number of steps. Figure 2 shows that the XmlDocument object uses the XmlReader and XmlWriter objects to load/save the document. Everytime you load an XmlDocument, it will employ an XmlReader class. This goes for both situations where you explicitly code it as such, as well as in cases where you leave loading a file up to the XmlDocument class itself. Under the covers it will call the XmlReader anyway.

Figure 2. XmlDocument in the .NET XML object model

The DataSet class represents an in memory relational data store. Under the covers the data is stored as XML. This means it can be loaded from and saved to an XML document as well. The way this works is described when we look at databinding ASP.NET server controls in Section 4.1.

A neat feature of ASP.NET are databound controls. They enable you to show a datasource in a control, without having to loop through the data. This enables you to show rows of data in a spreadsheet-like grid, or repeated in some template. Because a DataSet stores data as XML, independent of the data soure, XML documents can also be databound to controls. To do this, you open an XML file, read it into a DataSet and bind it to a control. As long as the data is (more or less) tabular, you will get data in the form of a database table which can be shown using a data bound control. The listing below is a simple sample of the code used to bind an XML file to a DataGrid control.

Sub Page_Load(Src As Object, E As EventArgs)
    Dim sFile As String = Server.MapPath("data.xml"),
    Dim oFs As FileStream = New FileStream(sFile, FileMode.Open, FileAccess.Read)
    Dim oFile As StreamReader = New StreamReader(oFs)
    Dim oDs As New DataSet

    oDs.ReadXml(oFile)
    oFs.Close()

    grid1.DataSource = New DataView(oDs.Tables(0))
    grid1.DataBind()
End Sub

As you see the steps required are straightforward. The XML file is opened as a standard file stream, which is read into the data set using the ReadXml method. After that it just works as if you are working with a database.

The structure of the XML file is very important. When loading the file, the DataSet analyzes the input and creates tables for data items that are on the same level and have the same structure.

<Products>
  <ProductID>1001</ProductID>
  <CategoryID>1</CategoryID>
  <ProductName>Chocolate City Milk</ProductName>
  <ProductDescription>Chocolate City Milk Description</ProductDescription>
  <UnitPrice>2</UnitPrice>
  <ImagePath>/quickstart/aspplus/images/milk5.gif</ImagePath>
  <Manufacturer>Chocolate City</Manufacturer>
</Products>

If an XML file would contain (under the root node) only elements as shown above, there would be one table created for all the products nodes. Now look at the listing below.

<Products>
  <ProductID>1001</ProductID>
  <CategoryID>1</CategoryID>
  <ProductName>Chocolate City Milk</ProductName>
  <UnitPrice>2</UnitPrice>
  <MoreProdInfo>
    <ProductDescription>Chocolate City Milk Description</ProductDescription>
    <ImagePath>/quickstart/aspplus/images/milk5.gif</ImagePath>
    <Manufacturer>Chocolate City</Manufacturer>
  </MoreProdInfo>
</Products>

This listing has another hierarchical level in it. The result will be that the data set contains two tables, one with the Products built up out of the immediate children (containing data) of the Products element, the other with all the child elements of MoreProdInfo. The former can be accessed with the same code as shown earlier, the latter just by changing the index from 0 to 1:

Grid2.DataSource = New DataView(oDs.Tables(1))

The DataSet also contains a relation between these to 'tables', so you can refer back and forth. The relations between tables is stored in the DataRelations collection, which contains DataRelation items. This object contains objects like ChildTable and ParentTable, so getting the name of the parent table in the relation can be done like this:

oDs.Relations.Item(0).ParentTable.TableName