Conclusion

On the long road to standardization, XPath seems like the first significant step toward a universal query language to keep up with the universal protocol (HTTP), the universal data description language (XML), and the universal remote procedure call protocol (SOAP).

With XPath, you gain the ability to identify and process a group of related nodes from an XML-driven data source. This ability can be exploited by a number of different client environments. XML DOM classes, for example, can use XPath for in-memory data retrieval. XPath is also great for querying XML representations of relational data held both in disconnected structures (such as XmlDataDocument) and in more traditional APIs like XML Extensions for SQL Server 2000. (See Chapter 10.)

XSLT is another programming environment that successfully leverages XPath. XSLT is particularly powerful when it comes to applying code templates to XML subtrees. XPath supplies the underlying means to identify those nodes declaratively. XPathNavigator supports XSLT and can be used as an input mechanism to the XslTransform class. We’ll look at XSLT in more detail in Chapter 7.

This chapter presented two high-level APIs to evaluate XPath expressions: the XML DOM–based API and the newest, .NET Framework–specific navigation API. As we’ve seen, under the hood, the two APIs make use of the same core code. What’s new with XPath in the .NET Framework is the concept of the navigator object, especially in conjunction with the iterator object.

The navigator is a self-contained API used to navigate an XML-based, or XML-looking, data source. The iterator is a child object that comes in handy for accessing the results of XPath queries run by the navigator. All the underlying data structures are extremely optimized and compact. So if you’re looking for efficiency, run your XPath queries using the navigation API.