XPointer Abbreviations

Because it's so common to refer to elements by location or ID, XPointer adds a few abbreviated forms of reference. Here's an example; suppose that you wanted to locate Venus's <DAY> element:

 <?xml version="1.0"?>  <?xml-stylesheet type="text/xml" href="planets.xsl"?> <PLANETS>     <PLANET>         <NAME>Mercury</NAME>         <MASS UNITS="(Earth = 1)">.0553</MASS>         <DAY UNITS="days">58.65</DAY>         <RADIUS UNITS="miles">1516</RADIUS>         <DENSITY UNITS="(Earth = 1)">.983</DENSITY>         <DISTANCE UNITS="million miles">43.4</DISTANCE><!--At perihelion-->     </PLANET>     <PLANET>         <NAME>Venus</NAME>         <MASS UNITS="(Earth = 1)">.815</MASS>  <DAY UNITS="days">116.75</DAY>  <RADIUS UNITS="miles">3716</RADIUS>         <DENSITY UNITS="(Earth = 1)">.943</DENSITY>         <DISTANCE UNITS="million miles">66.8</DISTANCE><!--At perihelion-->     </PLANET>     .     .     . 

You could do so with this rather formidable expression:

 http://www.starpowdermovies.com/ch15_06.xml#xpointer(/child[position()=1]/child::  *[position()=2]/child::*[position()=3] 

As you know from Chapter 13, the child:: part is optional in XPath expressions, and the predicate [position() = x ] can be abbreviated as [ x ] . In XPointer, you can abbreviate this still more, omitting the [ and ] . Here's the result, which, as you can see, is fairly compact:

 http://www.starpowdermovies.com/ch15_06.xml#1/2/3 

When you see location steps made up of single numbers in this way, those locations steps correspond to the location of elements.

In a similar way, you can use words as location steps, not just numbers, if those words correspond to ID values of elements in the document. For example, say I give Venus's <PLANET> element the ID "Planet_Of_Love" (here I'm assuming that this element's ID attribute is declared with the type ID in a DTD):

 <?xml version="1.0"?>  <?xml-stylesheet type="text/xml" href="planets.xsl"?> <PLANETS>     <PLANET>         <NAME>Mercury</NAME>         <MASS UNITS="(Earth = 1)">.0553</MASS>         <DAY UNITS="days">58.65</DAY>         <RADIUS UNITS="miles">1516</RADIUS>         <DENSITY UNITS="(Earth = 1)">.983</DENSITY>         <DISTANCE UNITS="million miles">43.4</DISTANCE><!--At perihelion-->     </PLANET>  <PLANET ID = "Planet_Of_Love">  <NAME>Venus</NAME>         <MASS UNITS="(Earth = 1)">.815</MASS>         <DAY UNITS="days">116.75</DAY>         <RADIUS UNITS="miles">3716</RADIUS>         <DENSITY UNITS="(Earth = 1)">.943</DENSITY>         <DISTANCE UNITS="million miles">66.8</DISTANCE><!--At perihelion-->     </PLANET>     .     .     . 

Now you could reach the <DAY> element in Venus's <PLANET> element like this:

 http://www.starpowdermovies.com/ch15_06.xml#xpointer(//child::*[id("Planet_Of_Love")]/  child::*[position()=3] 

However, there's also an abbreviated version that's much shorter. In this case, I take advantage of the fact that you can use an element's ID value as a location step, and the result looks like this:

 http://www.starpowdermovies.com/ch15_06.xml#Planet_Of_Love/3 

As you can see, this form is considerably shorter.

In this example, I used the id() function; to use that function, you should declare ID attributes to have the type ID . However, not all documents have a DTD or schema, so XPointer allows you to specify alternative patterns using multiple XPointers. Here's how that might look in this case, where I specify two XPointers in one location step:

 http://www.starpowdermovies.com/ch15_06.xml#xpointer(id("Planet_Of_Love"))xpointer(//  *[@id="Planet_Of_Love"])/3 

If the first XPointer, which relies on the id() function, fails, the second XPointer is supposed to be used instead; that one locates any element that has an attribute named ID with the required value. It remains to be seen how much of this syntax applications will actually implement.

That's it for XLinks and XPointers. As you can see, there's a lot of power herefar more than with simple HTML hyperlinks . However, the XLink and XPointer standards have been proposed for quite a few years now, and there have been practically no implementations of them. Hopefully the future will bring more concrete results.

In the next chapter, I'm going to take a look at some popular XML applications in depth, starting with the most popular one of all: XHTML.