Developer

An overview of the new XPointer specification

What is the new XPointer XML proposal all about, and how does it compare to XPath? Find out more about this new standard and check out some examples of how to put it to use.


The W3C’s new XML Pointer (XPointer) standard provides a method for identifying pieces or fragments of an XML document. XPointer extends the XPath standard and reuses many of the same concepts, evaluation rules, and syntax. But there’s more to it than just that.

Let's take a look at the various aspects of the new XPointer standard and the W3C recommendations you can peruse to obtain more information. As I discuss the standards, I'll also provide some examples that will refer to the XML document found in Listing A.

An XPath backgrounder
Since XPointer and XPath are related standards, it’s important to understand the latter before discussing the former. For an overview of the capabilities of XPath, I’d recommend taking a look at the Builder.com article “Locate and format XML data with XPath functions.”

In its simplest form, an XPointer statement looks a lot like a standard URI that’s had a pound-sign (#) pre-pended and a fragment identifier stuck on the end. The fragment identifier is itself formally known as the XPointer, and it will invoke a real feeling of déjà vu in anyone who has ever hand-coded XHTML. However, comparing XPointers to XHTML anchors is a great simplification; XPointers are more than hard-coded links within a document.

Overview of the XPointer recommendation
The WC3 maintains four recommendation documents, each covering a different aspect of the XPointer language, its features, and its capabilities. I’d recommend that anyone interested in XPointer become familiar with the contents of these documents. You should understand though, that because these documents are only proposed recommendations, the final versions may in fact be quite different from the current versions, in much the same way that alpha and beta versions of software are different from the final shrink-wrapped product.

The XPointer Framework
The XPointer Framework document describes the Internet media types that the XPointer proposed recommendations apply to, as well as describing the syntax of the XPointer language. XPointer is currently intended for use with the any of the following Internet media types:
  • ·        Text/xml
  • ·        Application/xml
  • ·        Text/xml-external-parsed-entity
  • ·        Application/xml-external-parsed-entity
  • ·        XPointer element() Scheme Document

The XPointer xpointer() Scheme
The redundantly named XPointer xpointer() Scheme document describes the syntax for the XPointer language in detail. This document includes the definitions for the terms point, range, location, and location sets. Briefly, a point is a single location in an XML document that has no content; a range point is the content between two points; a location is roughly the equivalent to a node in XPath; and a location-set is the equivalent of an XPath node-set.

In addition to these somewhat circular definitions of terms and concepts, the document includes descriptions, syntax, and examples of the various XPointer functions, which are briefly described in Table A.
Table A
Function Description
covering-range(x) Returns the range for each location in 'x'.
end-point(x)
Returns a location set consisting of the ending points for all locations in 'x'.
here
Returns a reference to the node containing the current point.
origin
Provides the ability to address the target of a link.
range-inside(x)
Returns the contents of the ranges in 'x'.
range-to(x)
Returns a location set consisting of the context starting point to the 'x' for all locations in 'x'.
start-point(x)
Returns a location set consisting of the starting points for all locations in 'x'.
string-range(x,s,n1,n2)
Returns a range for each x, using s as a search string. n1 is the offset from the first matching character, n2 is the length of the range returned.
XPointer functions

The XPointer element() Scheme
The purpose of the XPointer element() Scheme document is to describe how, in conjunction with the XPointer Framework, you’d use XPointer to address XML elements in an application. For example, the following code identifies the first child element of the root node, which in the case of Listing A would be the first item node.
 
element(/1/1)
 

The XPointer element() Scheme is a bit like a Swiss Army knife—there is usually more than one tool for any particular job. For example, you could achieve the same results by coding any of the following possibilities:
 
element(root/1)
element(root/item)
element(item)


The XPointer xmlns() Scheme
Finally, we have the XPointer xmlns() Scheme document, which describes the XML namespace used for XML Pointers, including namespace prefixes and namespace qualified names.

XPointer versus XPath
As I indicated, XPointer is described in the framework document to be an extension of XPath, but in reality, this is an oversimplification. Like XPath, XPointer can identify both nodes and node sets within a document, but XPointer has the additional capability of addressing both ranges of nodes and points within an XML document. To demonstrate this, consider the following statements:
 
xpointer(string-range(//*,'electronics'))
 

If run on the document in Listing A, the above code creates a location set consisting of two string locations, denoting the two occurrences of the string "electronics" in the document.
 
xpointer(start-point(//root))
 

This command results in a point, or a location in an information set with no content or children, that represents the location immediately following the <root> in the XML document shown in Listing A.

Neither of these tasks would have been possible using XPath, which is a major reason why the XPointer standard is being developed.

XPointer implementations
Personally, I’m one of those people who like to learn by doing. The problem with this, though, is that often I jump on a new technology when it's too new for me to really do anything with it. But learning about something theoretically, before there are any implementations, is frankly no fun.

I'm thankful that this isn’t the case with Xpointer, since it has a few implementations already available. The University of Bologna has both an ASP implementation of XPointer written in JavaScript and a Java implementation you can play with. From Mozdev.org comes a partial XPointer implementation written in JavaScript that's available for the Mozilla and Netscape browsers. While not complete, these implementations of the XPointer language offer a starting point and a way to learn by doing.

Even though the XPointer specification is (as of this writing) only a recommendation, because of its flexibility and power it warrants a closer look. Either by itself or in combination with XPath, it provides the capability to access and manipulate XML documents in ways that were unimaginable before.

 

 

Editor's Picks