XPath 2.0: The Donald Sutherland of XML
It's not glamorous. It's not charismatic. But the promise of XPath 2.0 could make it a consistent, reliable XML performer
by Kurt Cagle
Posted August 25, 2003
The hardest working actors in Hollywood are not the ones whose names are splashed on theater marquees and headlines in People week after week. These folks may make the big bucks, but their popularity can be short-lived. One day they're the toast of the town, the next they're doing Hollywood Squares. No, the real workhorses in Tinseltown are the supporting actors. Take Donald Sutherland: over the course of a fifty-year career, Sutherland has appeared in more than 130 movies, playing heroes, villains, and everything in between. The quantity and versatility of his roles are extraordinary compared to what most leading players get to do in their careers.
XPath is the Donald Sutherland of the XML world. XPath often tends to get dismissed as being unimportant in the grand scheme of things. As I write this, Amazon.com offers only two books featuring XPath as their primary focus: John Simpson's (O'Reilly & Associates, 2002) and Andrew Watt's (John Wiley & Sons, 2002). Compare this quantity to the more than 30 books on extensible stylesheet language transformation (XSLT), and the nearly 300 on XML.
A big part of the reason for its underdog status is that XPath never appears by itself; instead, it always supports some other language. Microsoft included Document Object Model (DOM) support for XPath with its .selectNodes() and .selectSingleNode() methods on the MSXML4 component, and it also plays a part in the .Net XML classes. The World Wide Web Consortium (W3C) incorporates an XPath mechanism into the formal XML DOM version 3.0, although it uses a different set of interfaces, and JAX pack APIs in the future likely will end up implementing these interfaces once the specification reaches Recommendation status.
XPath is of course inextricably intertwined with XSLT, to such an extent that XSLT by itself would be impossible without it. XPath is also an integral part of the XML Query Language, although in that case it is somewhat secondary to the native FOR-LET-WHERE-RETURN (FLWR, pronounced "flower") form preferred in most of the XML Query use cases. It even plays a bit part in the XPointer specification, a specification for referencing document fragments through a URL. For some time, XPointer had been a fairly moribund project, but just within the last several months revisions to this standard have been proposed that would take into account XML Schema and the revised XPath 2.0 functionality, and the recognition that XML-based invocation through Web services introduce its own requirements.
In other words, XPath is pervasive in XML technology; it finds its way into nearly every other specification, quietly doing the heavy lifting of retrieving nodal structures for processing while the marquee names get all the press. With XPath 2.0, that role will only increase.
An XPath 1.0 Limitation
XPath is a selection language. To understand the importance of that role, consider the nature of XML compared to that of a relational database. Relational databases work by creating sets of linear tables, and then within each table (usually) creating one or more keys to other tables that potentially join them together. When you make a query in SQL, what you are doing in essence is creating a virtual table consisting of parts of other tables that have been joined together through these keys. This model, while powerful, has several limitations, the biggest being that when you have a one-to-many (or many-to-many) relationship, the potential number of virtual records can increase in a combinatorial fashion. A good database designer spends a lot of time trying to figure out how to "lock" tables together through constraints to keep this record quantity manageable.
Consequently, hierarchical data provides real challenges to most SQL databases, because even though SQL is a set-selection language, the set first has to be linearized to do anything useful with it. XPath, on the other hand, takes a different approach to selecting information, one specifically predicated on the tree-like structures that make up XML. When you make a query in XPath 1.0, what you are doing is creating a set of pointers to the nodes in an existing XML tree, rather than creating new nodes themselves. Because the set is made up of pointers and even though the set of nodes is linear (a node set is just a list of such pointers), they can come from anywhere in the tree, and they keep all of the information about their relationships—children, parents, attributes, and so on—that can in turn be accessed by other XPath expressions.
This model is incredibly powerful. For instance, from the top node in the tree, you can linearize the tree into a list of nodes that retain their processing order with the simple XPath expression "//*." You can retrieve a node on the basis of an attribute value ("//*[@id='foobar']," to retrieve a node with the ID foobar); select one or more nodes based on relational information ("//manager[.//employee[location/state='WA']]," to retrieve all managers with employees located in Washington state); or even perform sophisticated cross-node comparisons for matching.
However, the data-set model has some problems. One of the more serious limitations is that the model makes sense only in situations where all of the nodes are part of the same XML document. In the case of XSLT transformations, this limitation is overcome by the use of the document() function and persistent variables; you can create a node set from multiple documents and assign it to a variable (which acts as the root node in a virtual tree of nodes). However, this solution is not elegant. XPath has to break its own data model, use an addressing structure that is foreign to what was originally designed, and consequently the XPath within XSLT differs from the XPath used anywhere else.
In the next installment, we'll look at another XPath 1.0 limitation and how XPath 2.0 has addressed these limitations, as well as how XPath 2.0 represents nodes.
About the Author
Kurt Cagle is an author and consultant who has just completed (APress Books, 2002). He has just relocated to Portland, Oregon, where he is working toward his Ph.D. in systems science at Portland State University. Contact Kurt at .
Back to top
|