Ben Langhinrichs wrote about his frustrations with anchor links in Notes the other day. I commented there, but wanted to say more about it. Most of his frustrations are right on: the feature could have been made easier to use. But one is a direct analog to a problem on the web: you can’t link to something if the author didn’t anticipate the link.

This is the way the web works today: if you want to link to a point within a document, you need either an <a name=’foo’/> tag or an id=’foo’ attribute in a tag to identify the point to link to. If the author placed one in just the right spot, anyone can link to it, by adding #foo to the end of the URL. If the author didn’t, then you have to either:

• somehow modify the document (which you generally can’t do), or
• ask the author to change the document (which they generally won’t do), or
• link to someplace less precise and include goofy text like “scroll down to where it says foo” along with your link.

XPath and XPointer are trying to change that. The XPointer xpointer() scheme is a way to replace the simple named id mechanism with a more sophisticated addressing model within documents. Basically the idea is that XPath is a powerful syntax for expressing sets of nodes in an XML document, so why not use it in URLs to identify locations in a document? With it, I can link to the second paragraph of the third h1 section with a URL like:

.../doc.html#xpointer(h1[3]/p[2])

(I think: Would it kill these standards authors to include a long list of examples to help people trying to grok the semantics? See my blog entry Impossible CSS gripe #1 for more on this.)

This syntax is extremely expressive if not exactly intuitive, and includes fancy stuff like expressing not just points in the document but ranges. All of XPath is available for creating expressions to identify parts of the document, so you can select stuff based on its content, its neighbors, and so on. I’d show you more examples, but frankly, I couldn’t be sure I got it right, and I couldn’t find a tutorial or a sample implementation to work with.

None of this fancy technology completely solves the problem of linking to places the author didn’t expect. After all, no matter what addressing scheme I use into someone else’s document, if they edit the document, the address could change.

(By the way: these sorts of issues were at the heart of Project Xanadu, Ted Nelson’s long-simmering but never completed hypertext project.)

Ben complained about this aspect of anchor links, and I thought about it and looked into XPointer, and saw that there was nothing to be done about it, since web browsers don’t do anything fancy like XPointer. The best I could do was to use lots of id=’foo’ attributes. So I updated my XSLT code that produces this site, and now every <h1> and <h2> tag on the site includes an id attribute generated from the text of the tag.

So, for example, the section entitled “Use a real log” in my Log message style guide article is tagged like this:

<h1 id="h_Use_a_real_log">Use a real log</h1>

and therefore can be targeted thusly: text/log-style-guide.html#h_Use_a_real_log. Link away!