Beginning Visual Basic .NET Databases / Edition 1

Chapter 12: ADO.NET and XML

In this chapter, we're going to be introducing the concept of Extensible Markup Language, or XML. For a while now, XML has been touted as an important technology for the storage and exchange of data and, with the advent of .NET, powerful XML functionality can be available to our application with minimal work.

In this chapter, we'll be looking at the essential nature of XML and see a few of the basic tools that are provided by .NET and ADO.NET for the creation and manipulation of XML data.

What is XML?

XML was invented as a technology for overcoming the problems involved in the relatively common activity of exchanging data between applications. However, XML is increasingly being used as a data storage and transport mechanism.

XML is one of those curious technologies that, while it seems scary to a newcomer, the principles are actually very easy to grasp. (Building an end-to-end solution using XML throughout can get a little tricky, however!) The classes available to us in the .NET Framework provide ways to read, write, and explore XML-formatted data very easily.

Despite its name, XML is probably best thought of not as a "language", but rather as a set of rules for defining markup languages. In order for applications to exchange data, the data has to be "marked up" in some way. This marking up allows an application receiving the data to make sense of it and use it in a useful manner. For example, if I give you a bit of data like this:

Disraeli

…how do we know what that data is? However, if I give you a little more information about the data, like this:

My Dog's Name: Disraeli

…then, using common sense, we can all understand what that bit of data represents. In the latter case, I've "marked up" the data. By using the English language, English-speaking readers at least can use the set of common sense rules that we all carry around in our heads to determine what I'm trying to say. XML is a "meta language" or, in other words, is self-describing – it gives the data and the rules to follow to determine what the data is.

As we said, XML is not a language but rather a set of standards and rules for creating your own markup languages. One of these rules is that XML documents must be well-formed. There are over a hundred rules for creating a well-formed XML document, but here are the three basic ones (luckily, the other ones are things you're unlikely to do anyway and so aren't of much importance):

• Every document must have exactly one top-level element.
• Elements must be closed in the reverse order that they were opened, that is, you can't do this:

  <ElementOne>Data<ElementTwo>MoreData</ElementOne></ElementTwo>
  

  ...because ElementOne is closed before ElementTwo is closed.

• Case sensitivity is important. MyElement is not the same as mYeLEMENT.

A Sample XML Document

XML is a fairly curious language because it seems a little "off planet" in concept until you actually start looking at some. Here is an XML document viewed in IE...

Those of you who have seen HTML code will notice that the XML files look very similar. That's because they both share a common ancestor. Standard Generalized Markup Language, or SGML, was the inspiration for both.

XML files work on the concept of tags and elements. A tag can either be a "start tag" or an "end tag" (or "both" – sometimes start and end tags are combined, but we'll see this later). Here's an example of a start tag:

<ShipCity>

…and here's an example of an end tag:

</ShipCity>

You can see that both kinds of tags start with a less-than sign and end with a greater-than sign. This is how tags are delimited. The name of the tag appears between these two signs, and, in this example, the name of the tag is ShipCity. The difference between a start tag and an end tag is that, on an end tag, the name is prefixed with a forward-slash character.

Together, a start tag and an end tag make an element. The text between the two tags is the data that belongs to the tag. For example:

<ShipCity>Albuquerque</ShipCity>

In this case, we have an element called ShipCity; the value of that element is Albuquerque.

Here are the elements that make up order 11077 as shown in our XML document:

• <OrderID>11077</OrderID>
• <CustomerID>RATTC</CustomerID>
• <EmployeeID>1</EmployeeID>
• <OrderDate>1998-05-06T00:00:00.0000000+01:00</OrderDate>
• <RequiredDate>1998-06-03T00:00:00.0000000+01:00</RequiredDate>
• <ShipVia>2</ShipVia>
• <Freight>8.53</Freight>
• <ShipName>Rattlesnake Canyon Grocery</ShipName>
• <ShipAddress>2817 Milton Dr.</ShipAddress>
• <ShipCity>Albuquerque</ShipCity>
• <ShipRegion>NM</ShipRegion>
• <ShipPostalCode>87110</ShipPostalCode>
• <ShipCountry>USA</ShipCountry>

Now life starts to get interesting. Elements can contain other elements. In this case, we have a start tag called Order and an end tag called Order.

<Order>
<OrderID>11077</OrderID>
<CustomerID>RATTC</CustomerID>
<EmployeeID>1</EmployeeID>
<OrderDate>1998-05-06T00:00:00.0000000+01:00</OrderDate>
<RequiredDate>1998-06-03T00:00:00.0000000+01:00</RequiredDate>
<ShipVia>2</ShipVia>
<Freight>8.53</Freight>
<ShipName>Rattlesnake Canyon Grocery</ShipName>
<ShipAddress>2817 Milton Dr.</ShipAddress>
<ShipCity>Albuquerque</ShipCity>
<ShipRegion>NM</ShipRegion>
<ShipPostalCode>87110</ShipPostalCode>
<ShipCountry>USA</ShipCountry>
</Order>

Notice how the data that's contained within the Order element is a bunch of other elements. XML is hierarchical in nature, which means that the Order element contains a set of thirteen child elements, and each of those thirteen child elements represents one column from one particular row. The upshot of this is that if we have an Order element, we can drill down into its child elements to learn everything about the Order that we could possibly need to know.

If you look further into the document, you'll notice that each of the two Order elements is contained within a master Order element. (I've omitted some elements here for clarity.)

<Orders>
<Order>
…
</Order>
<Order>
…
</Order>
</Orders>

Again, this means that, if we have an Orders element, we can assume that we have a list of orders contained within. We also know that each order is encapsulated in its own element called Order. As we stated earlier, every XML document must have exactly one top-level element, called the root element. In this case, we do indeed have only one top-level element: Orders. If we omitted this element, the file would not be well-formed. For example, here's the same document again but without the single top-level element:

<Order>
…
</Order>
<Order>
…
</Order>

In this case, the document has two top-level elements. Under the rules of XML, this document is not well-formed – therefore it cannot be used.

Attributes

There is another way of introducing data into an XML file, although it's mainly used for "metadata", or data about the data. In this chapter, we're not going to concern ourselves with attributes, but here's a little information so you're aware of them. Take our OrderID element. If we wanted to indicate that this element was an ID column, we might add an IsId attribute that looks like this:

<OrderID IsId="True">11077</OrderID>

Attributes have the form of a parameter="value" pair, and sit within the opening tag of an element. We can have as many attributes as we like, and store any data that we like in them:

<OrderID IsId="True" AnotherAttribute="92384">11077</OrderID>

That's the basis behind XML. At this level, XML is mostly common sense and, I'm confident, pretty easy to understand. Because of this, what we'll do next is build the app that produces this output. This will bring the potentially fuzzy points of our discussion so far into sharp focus.

Creating an XML Document

In this chapter, we're going to be looking at an application that's capable of exporting the orders defined in the system to XML documents.

Try It Out – Creating the Project

1. Using Visual Studio .NET, create a new Visual Basic | Windows Application project and call it Order Export.

2. When the Designer for Form1 appears, drag on a DataGrid control and a couple of Buttons, like this:

3. Change the properties for the controls in the Properties window, as shown below:

4. Using the toolbox, drag on a new SaveFileDialog control. Change its Name property to dlgSaveFile.

That's the basic design of the form finished. Now we just need to add some business logic functionality.

Saving DataSets as XML

As ADO.NET has built-in support for XML – it uses XML as its internal data format – this gives us great flexibility in using ADO.NET to access various types of data. In this next section, we are going to look at how we can save DataSets as XML documents....