Design Goals for XML in the .NET Framework

Article
10/17/2014

The goals of XML in .NET Framework are:

Compliance with the W3C standards.
Extensibility.
Pluggable architecture.
Performance.
Tight integration with ADO.NET.

Standards Compliance

Standards compliance means that the classes fully conform to the current W3C recommended standards of XML, Namespaces, XSLT, XPath, Schema, and the Document Object Model (DOM). Compliance ensures interoperability and eases application development across platforms.

Most notably, the XML classes in .NET Framework supports the W3C XML Schema Definition language (XSD) 1.0 recommendation. There are XML classes in the .NET Framework that provide validation, and an object model is available to build the XSD Schemas in memory. The fast, forward-only parser that can validate against schemas, DTDs, XDRs, and XSDs is called the XmlValidatingReader. The XmlValidatingReader is a compliant XML parser. The XmlSchemaCollection class can be use to cache frequently used XSD or XDR schemas when using the XmlValidatingReader.

There are a set of XML classes in the .NET Framework that provide a Schema Object Model (SOM) that allows you to programmatically build and compile XSD schemas. The XmlSchema class represents an XSD schema. These schemas can be loaded and persisted using the XmlReader and XmlWriter classes.

The XmlDocument class implements the Document Object Model level 1 and level 2 recommendations and is tailored to the common design guidelines of the .NET Framework. For example, the method names are capitalized.

The XslTransform class conforms to the XSL Transformations (XSLT) Version 1.0 recommendation and the XML Path Language (XPath) 1.0 recommendation for transforming documents using XSLT.

Extensibility

XML in the .NET Framework is extensible through the use of the abstract base classes and virtual methods. This extensibility, or subclassing, is illustrated by the XmlReader, XmlWriter, and XPathNavigator abstract classes, which are classes that enable new implementations to be developed over different stores or data sources, and expose XML. For example, XPathNavigator is an API that incorporates an XPath query engine that can be implemented over existing stores, such as file systems, registries, and relational databases. This not only displays the data as XML, but it provides XPath query support over disparate sources of data, using the default implementation of the XPath API query methods, such as Select.

Another example of extensibility is the XmlReader, which provides an API for fast, forward-only, parsing of a store, exposing the XML Infoset that it finds as it moves through the stream. XML in the .NET Framework has implementations of XmlReader called the XmlTextReader class for reading streams, the XmlNodeReader class for reading node trees, and the XmlValidatingReader for layering validation support on an XmlTextReader.

XmlWriter generates a stream of XML using a push-based API. XML in the .NET Framework has an implementation of the XmlWriter called the XmlTextWriter.

The implementations of these classes can be further derived from to create other readers that can implement specific processing. For example, deriving from the XmlTextReader to create a custom reader called MyXmlTextReader enables you to create a version of the reader with logic specific to your application processing needs.

The XmlResolver abstract class provides a hook to external resources referenced in an XML document. This allows you to cache resources in a manner specific to the application, such as a database, or to resolve resources having different protocols by deriving from this class. The XmlResolver implementations, XmlUrlResolver and XmlSecureResolver, resolve resources with the http://, https://, and file:// protocols.

Pluggable Architecture

XML in the .NET Framework has a pluggable architecture. Pluggable, in this stream-based architecture, means that components that are based on these abstract classes within the .NET Framework can be easily substituted. Pluggable architecture also means that data can be streamed between the components, and new components inserted into this stream can alter the processing. For example, a stream of XML from an XML Web service can be parsed with the XmlTextReader. The XmlTextReader can be used to create an XmlDocument, which in turn can be used to create an XmlNodeReader.

Another example is loading the DOM (XmlDocument class) from an XmlReader and saving the output using an XmlWriter. By creating your own implementations of these classes by extending the existing ones, you have the ability to affect the behavior of the XmlDocument class. For example, if you created an implementation of XmlReader, called MyXmlFileReader that can expose a file system as XML, then you can load an XmlDocument from this reader. Or you could inherit from an XmlTextReader to create a new, custom reader that converts an attribute-centric document to an element-centric document and this could be used to load the XmlDocument. This provides a pluggable architecture for new classes based on existing ones.

Another example of plugging components together is the use of different data stores, such as an XPathDocument and XmlDocument, in the transformation process. These data stores can be transformed with the XslTransform class, and the output can then be streamed either into another store or returned as a stream from an XML Web service. The illustration below shows this.

Streaming Data with the XslTransform class

5w1xh124.architecture_overview(en-us,VS.71).gif

Any store that implements an XPathNavigator, by using the IXPathNavigable interface, can be plugged into the XslTransform class to allow XSLT transformations over that store. The XmlDocument, XPathDocument, and XmlDataDocument classes are capable of this. The streamed output from XslTransform can then be sent to XmlReader or XmlWriter for a pluggable architecture style.

Performance

The XML classes in the .NET Framework represent low-level XML processing components that are used, not only as part of the .NET Framework, but to integrate XML into applications. The classes are required to be extremely performant.

The XML classes in the .NET Framework are designed to support a streaming-based model by having the following characteristics:

Minimal caching for forward-only, pull model parsing with the XmlReader.
Forward-only validation with the XmlValidatingReader.
Innovative cursor style navigation of the XPathNavigator, which minimizes node creation to a single virtual node, yet provides random access to the document. This does not require a complete node tree to be built in memory like the DOM.
Incremental streaming output from the XslTransform class.

The XPathDocument is an optimized, read-only store for XPath queries and is recommended whenever XSLT processing is required. By using this store and the XslTransform class, performant XSLT transformations are achieved.

Integration with ADO.NET

Relational data and XML are brought together in the .NET Framework by a tight integration between the XML classes and ADO.NET.

The DataSet component, which represents a disconnected database, has the ability to read and write XML using XmlReader and XmlWriter classes, the ability to persist its internal relational schema structure as XML Schemas (XSD), and the ability to surmise the schema structure from an XML document.

The XmlDataDocument truly crosses the boundaries of XML and relational data worlds by synchronizing a DataSet with an XmlDocument so that data maintained by one is updated in the other, where applicable. Since the XmlDocument has the ability to store semi-structured data, you gain all the features of an XML store while the DataSet provides a relational view onto the XML based on its schema.

For more information how the .NET Framework enables real-time, synchronous access to both the relational and hierarchical representations of data through the DataSet object and the XmlDataDocument object, see XML Integration with Relational Data and ADO.NET