In the rush to capitalize on the promise of the XML format, Microsoft and other technology vendors have introduced a variety of different options for converting relational data into XML. Unfortunately, no single approach so far has combined ease-of-use with the flexibility developers require. For example, later versions of ADO introduced XML as a format for persisting a stream to disk. However, the developer had little control over the structure of the XML document. Around the same time, SQL Server 2000 introduced the new FOR XML query syntax. This technique was more flexible, but proved difficult to manage, could complicate queries horribly, and limited solutions to a single database product.
ADO.NET improves upon this picture. With ADO.NET, you can easily convert data into XML. It's also easy to generate a matching XSD schema, perform an XPath search on a result set, or even interact with an ordinary XML document through the ADO.NET data objects. All these features of ADO.NET's support for XML far exceed previous Microsoft data-access technologies.
Things aren't as straightforward if you need to use XML for cross-platform use (for example, sharing data between a .NET web service and a Java client). If you can write a Java client to accommodate the default ADO.NET XML structure, your task is easy. However, if you have an existing client that expects information in a different format, you may need to perform some tedious processing with the .NET XML classes. You'll also need to master the DiffGram schema if you want a non-.NET client to use the DataSet to submit batch changes.
This chapter introduces all these concepts, focusing on three topics:
We'll conclude with a quick look at the XML extensions available in SQL Server 2000.