DataStream

LANGUAGES: C#

ASP.NET VERSIONS: 1.0 | 1.1

What's New for XML Developers in .NET 2.0

The next version of the .NET Framework adds a lot of new capability for working with XML.

By Brian Noyes

In a recent issue of this column, I gave you a quick overview of the new features in ADO.NET 2.0 for data access. Now I want to cover what is new on the XML side of the data access equation in .NET 2.0. XML usage for a variety of data scenarios continues to grow by leaps and bounds. There is just no better approach to bringing together heterogeneous data than working with it in the form of XML. As such, Microsoft continues to try to make the XML management capabilities of .NET more and more powerful to make your life easier.

The information I'll be covering in this article comes from a combination of the documentation from the Alpha of .NET Whidbey (2.0) released at the Professional Developers Conference (PDC) in October, PDC talks I attended, and info from the book A First Look at ADO.NET and System.Xml v2.0, by Alex Homer, Dave Sussman, and Mark Fussell from Addison-Wesley. I'll be covering two key areas that include a range of new classes and capabilities: enhancements to the XML document model and integration of XQuery and native XML types in SQL Server Yukon (the next version of SQL Server due out at the same time as .NET 2.0). This is not a comprehensive list of the changes that touch XML development in .NET 2.0, but should give you a good idea of the new capabilities to come.

XPathDocument on Steroids

If you are a .NET XML developer, hopefully you are already familiar with and using the XPathNavigator and XPathDocument whenever you can. This model for dealing with XML was introduced in .NET 1.0 as a powerful new alternative to working with the DOM. In .NET 1.X, the XPathDocument is a lightweight, read-only storage approach that exposes an XPathNavigator for traversing and querying the underlying data. You can also obtain an XPathNavigator from an XmlDocument or XmlDataDocument, allowing you to approach writable stores with the same traversal and query model.

In .NET 2.0, XPathDocument has a new and more attractive sibling, XPathDocument2. This new class, in coordination with several other new classes, gives you the ability to make modifications to the data stored in the document, allowing you to make updates and track changes for each node in the tree. The XPathEditor class works as a writable cursor into the data stored in an XPathDocument2 instance, and you can have multiple XPathEditors working against the same document at the same time. The XPathChangeNavigator class gives you a quick and easy way to iterate through only the nodes that have changed in a document that is being modified. The combination of these classes gives a lighter weight, higher performance approach to navigating, accessing, and updating data stored as an XML InfoSet.

In a lot of situations, it is more convenient for an application or business layer to retrieve and manipulate data in the form of XML rather than relational tables, even if that data is originating from a relational data source. In ADO.NET, we have this great model of being able to work with a DataSet that is independent of the data source that populated it and that can keep track of changes so those changes can be used to perform updates to the original or other data sources. To tie the source-independent DataSet with a specific data source for retrievals or updates, we have the SqlDataAdapter to act as the mediator between the two worlds.

If you are currently getting XML data out of SQL Server, you have two main options: get it back as an XmlReader from the managed SQL provider, or get it back as a raw string of XML. In the former case, you then have to iterate through the reader to push the results into one of the XML document models available in .NET before you can do any meaningful manipulation of the data. In the latter case, you have to load the string into an XML document, resulting in significant parsing expense.

What is really needed, and is part of the new feature set of .NET 2.0, is an XmlAdapter class that functions in a similar fashion to the SqlDataAdapter class. The XmlAdapter in .NET 2.0 will bridge the gap between an XPathDocument2 instance and the SQL Server queries that are used to retrieve and update the underlying data. The XmlAdapter uses a set of XML mapping files to specify which fields in the SQL Query map to which elements in the XML schema being retrieved. The mechanisms used for this are very similar to the mapping files used for ObjectSpaces, which I mentioned in the ADO.NET 2.0 overview, so the skills for working with XmlAdapter mapping files will be mostly transferable to working with the object mapping files in ObjectSpaces.

The combination of XPathDocument2 and its associated classes and the XmlAdapter really gives you a whole new approach to consider for working with XML data that I have only scratched the surface of here. If you want to read more, I recommend the book mentioned in the intro, plus get your hands on the bits as soon as possible and start to play around.

Expanding Choices for Server or Middle Tier XML Storage and Query

A significant portion of data that is retrieved and manipulated as XML today actually comes from relational data sources. Databases are made for storing and retrieving data, and they still provide the best performance and options for doing that on the server side, even if the application intends to manipulate the data as XML. SQL Server Yukon will support XML as a native data type for columns, which opens a whole new realm of possibilities for offloading some of the XML manipulation and querying from the application to the database server. Through the XmlAdapter and XPathDocument2 you have a bunch of new options for how that data gets into your application and is stored. But what is also needed are some more powerful options for querying that data as XML.

When you work with XML today, the closest equivalent to performing a SQL query on relational data is performing a node selection on XML data using XPath and one of the available document objects or XSLT in your application code. A dedicated language and query processor is really needed for more powerful querying of complex documents, and is in the works. The W3C has been working on the XQuery language specification for a while, and it should become an approved Recommendation by the time .NET 2.0 and SQL Server Yukon release. XQuery provides a more SQL-like language for querying a document or set of documents to retrieve nodes or produce new documents based on the selection. XQuery uses XPath syntax for node selection, so many of your existing skills will be transferable. But there is a lot to XQuery beyond just specifying XPath selection criteria, so standby for yet another XML language that you will need to learn to take advantage of the new capabilities.

.NET 2.0 and SQL Server Yukon both include new capabilities to support the XQuery language. On the .NET side, there is an XQueryProcessor class that will allow you to perform XQuery queries against XML documents of the various forms that .NET supports. On the SQL Server side, you will be able to issue a query against native xml typed fields and XML views using XQuery. Surrounding these capabilities are a number of new classes that let you capitalize on the choice to store and query XML data on the client or server side.

.NET 2.0 and SQL Server Yukon will usher in significant new capabilities for data access on both the relational and XML side of the house. The existing capabilities of .NET will still work, your apps are not going to break, and you don't have to learn all this new stuff right away. But if you have felt the pain of developing XML applications that really need a more integrated approach to XML, you will see the benefits of these new capabilities and probably can't wait to get your hands on them.

Brian Noyes is a consultant, trainer, speaker, and writer with IDesign, Inc. (http://www.idesign.net), a .NET focused architecture and design consulting firm. Brian specializes in designing and building data-driven distributed applications. He has over 12 years' experience in programming, engineering, and project management, and is a contributing editor and writer for C#PRO, asp.netPRO, and other publications. Contact him at mailto:brian.noyes@idesign.net.