More On XPointer

As an update to yesterday's post I thought I'd elucidate what I've learned about XPointer.

First, some high-level overview: XPointer is "an extensible system for XML addressing", meaning that with it, you can address arbitrary portions of XML documents. XPointer is specified by the XPointer Framework and then realized through various "schemes".

The element XPointer scheme

The element scheme allows to do relatively simple addressing within an XML document. You can address an element that has id="foobar" like: element(foobar). You can also use a step-wise navigation within the element scheme to get at an arbitrary element. For example, element(/1/3/5) would address the fifth child of the third child of the first element (i.e. the root). Another example would be element(baz/2) which addresses the second child of the element with id="baz".

Now, how can you use an XPointer address? Well, the way in which I'm interested in doing this is by using it as a URL fragment. For instance, in yesterday's post I talked about linking to the "NodeList" section of this page. Well to do that with XPointer framework using the Element scheme, my URL would be:

http://www.w3.org/TR/DOM-Level-2-Core/ecma-script-binding.html#element(/1/2/3/5/1/15)

There are some problems with the above, not least of which is that the above document is NOT well-formed XML (see the <link> tags for starters). No, unfortunately the document is HTML tag soup. Could an XPointer implementation support an HTML document?

This brings me to another topic: Implementation Support of XPointer. Anne let me know that Mozilla has some form of XPointer support. I guess this bug was used to introduce it. It could enable some really cool features. But there are some problems with it. And also, someone wants to drop support because no one uses it yet (you have to love the referenced YouTube video in that bug, though).

So I took the HTML page and reformatted it to be proper XML (defined the &nbsp; entity, closed all <link>, <hr>, <br> elements and wrapped the script in <![CDATA[ ]]> tags). Once I did this, the following URL worked in Firefox 2.0:

file://d/ecma-script-binding.xml#element(/1/2/3/5/1/15)

The fact that this works on XML documents but not on XHTML documents (and especially HTML documents) is a crying shame. I would love to use this feature to direct people to static, non-changing web pages like specifications...

The xpointer XPointer scheme

The element scheme is arguably the least complicated XPointer scheme. The other scheme of interest is the confusingly named xpointer XPointer scheme. This scheme uses the XPath language to allow richer addressing into documents. For instance, to address the first instance of text "foobar", I could use: xpointer(string-range(/, foobar)). Now wouldn't that be cool? Then I could change my URL to:

http://.../ecma-script-binding.html#xpointer(string-range(/,square%20bracket))

so that the reader is instantly drawn to the words "square bracket" in that document.

Now I realize that XPointer is inherently brittle and can break on even the simplest document change (hell, regular web links are similarly brittle when you come down to it). I also realize that the preferred mechanism is for authors to use the id attribute wherever possible, since all browsers support the simple #some-id anchor. Furthermore, I realize there are problems with trying to use XPointer (a XML technology) on HTML documents. However, despite all that, I still think this would be a cool feature to be able to use on those web pages that are static and not likely to change over time ("frozen" specs, blog entries). This benefit would be particularly noticed by those people browsing the web on smaller devices with potentially painful-to-access "text search" facilities (hint: iPhone and the like). Of course with any technology, both implementors and authors have to get behind it to make its benefits known.