Elliotte Rusty Harold
XML Developers SIG August 24, 1999
elharo@metalab.unc.edu
http://metalab.unc.edu/xml/
XLL, the eXtensible Linking Language, is divided into three parts, XLinks, XPointer, and XPath.
XLink, the XML Linking Language, defines how one document links to another document. XPointer, the XML Pointer Language, defines how individual parts of a document are addressed. XPath is a syntax used in XPointers for identifying particular nodes in an XML document's tree.
An XLink points to a URI (in practice, a URL) that specifies a particular resource. This URL may include an XPointer part that more specifically identifies the desired part or section of the targeted resource or document. XPointers use the XPath syntax shared with XSL to identify particular elements in the document tree.
This talk covers:
These should be pretty close to the final versions. Last call on XPath is September 2.
I'm going to focus on XSL and XPointers, and XPath only tangentially. XPath is a big subject, that could easily be a lecture of its own. Some of you are already familiar with it from XSL. Those of you who aren't would probably be better off learning the details of it in the context of XSL where you can actually try it out. I'll explain what we need of it as we discuss XPointers.
The Web conquered the more established gopher protocol for one main reason: HTML made it possible to embed hypertext links in documents. These links could insert images or let the user to jump from inside one document to another document or another part of the same document. To the extent that XML is rendered into other formats such as HTML for viewing, the same syntax HTML uses for linking can be used in XML documents. Alternate syntaxes can be converted into HTML syntax using XSL, as you saw in several examples in Chapter 14.
However, HTML linking has limits. For one thing, URLs are limited to pointing at a single document. More granularity than that, such as linking to the third sentence of the 17th paragraph in a document, requires you to manually insert named anchors in the targeted file. It can't be done without write access to the document to which you're linking.
Furthermore, HTML links don't maintain any sense of history or relations between documents. Although browsers may track the path you've followed through a series of documents, such tracking isn't very reliable. From inside the HTML, there's no way to know from where a reader came. Links are purely one way. The linking document knows to whom it's linking, but not vice versa.
XLL proposes more powerful links between documents called XLinks. It's designed especially for use with XML documents, but some parts can be used with HTML files as well. XLinks can do everything HTML's URL-based hyperlinks and anchors can do.
<A>
Beyond this, however, XLinks provide multidirectional links where the links run in more than one direction. Any element can become a link, not just the A element. Links do not even have to be stored in the same file as the documents they link. Furthermore, the XPointer part (described in the next chapter) allows links to arbitrary positions in an XML document. These features make XLL more suitable not only for new uses, but for things that can be done only with considerable effort in HTML, such as cross-references, footnotes, end notes, interlinked data, and more.
Currently, there are no general-purpose applications that support arbitrary XLinks. That's because XLinks have a much broader base of applicability than HTML links. XLinks are not just used for hypertext connections and embedding images in documents. They can be used by any custom application that needs to establish connections between documents and parts of documents, for any reason. Thus, even when XLinks are fully implemented in browsers they may not always be blue underlined text that you click to jump to another page. They can be that, but they can also be both more and less, depending on your needs.
In HTML, a link is defined with the <A> tag. However, just as XML is more flexible with tags that describe elements, it is more flexible with tags that refer to external resources. In XML, almost any tag can be a link. Elements that include links are called linking elements.
xlink:type attribute with one of these four values:simpleextendedlocatorarcxlink:href attribute whose value is the URI of the resource being linked to. xmlns:xlink attribute specifies the version of XLink this linking element supports. <FOOTNOTE xmlns:xlink="http://www.w3.org/XML/XLink/0.9"
xlink:type="simple"
xlink:href="footnote7.xml">7</FOOTNOTE>
<COMPOSER xmlns:xlink="http://www.w3.org/XML/XLink/0.9"
xlink:type="simple"
xlink:href="http://www.interport.net/~beand/">
Beth Anderson
</COMPOSER>
<IMAGE xmlns:xlink="http://www.w3.org/XML/XLink/0.9"
xlink:type="simple" xlink:href="logo.gif"/>
Notice that the elements have semantic names that describe the content they contain rather than how the elements behave. The information that these elements are links is included in the attributes of the tags.
These three examples are simple XLinks. Simple XLinks are similar to standard HTML links and are likely to be supported by application software before the more complex (and more powerful) extended links, so I'll begin with them.
In the FOOTNOTE example above, the link target attribute's name is xlink:href. Its value is the relative URL footnote7.xml. The protocol, host, and directory of this document are taken from the protocol, host, and directory of the document in which this link appears.
In the COMPOSER example above, the link target attribute's name is xlink:href. The value of the xlink:href attribute is the absolute URL http://www.interport.net/~beand/. In the third example above, which is IMAGE, the link target attribute's name is also xlink:href. The value of the xlink:href attribute is the relative URL logo.gif. Again, the protocol, host, and directory of this document are taken from the protocol, host, and directory of the document in which this link appears.
The xlink: that starts both xlink:type and xlink:href is a namespace prefix. It indicates that these attributes are part of the XLink namespace associated with the URI http://www.w3.org/XML/XLink/0.9 as indicated by the xmlns:xlink attribute. This namespace can be declared either on the root element of the document or on the individual elements that use the xlink prefix. Attributes of elements that themselves use the xlink prefix drop the prefix. For instance, the xlink:href attribute of a COMPOSER element becomes merely the href attribute of an xlink:simple element.
Caution
The 0.9 in http://www.w3.org/XML/XLink/0.9 suggests that this URI is likely to change in the future. However, by assigning different URIs to different versions of the XLink specification, a browser can recognize and support more than one version of the syntax. This is one of the prime advantages of namespaces.
If the document has a DTD, these attributes must be declared like any other. For example, DTD declarations of the FOOTNOTE, COMPOSER, and IMAGE elements might look like this:
<!ELEMENT FOOTNOTE (#PCDATA)>
<!ATTLIST FOOTNOTE
xmlns:xlink CDATA #FIXED "http://www.w3.org/XML/XLink/0.9"
xlink:type CDATA #FIXED "simple"
xlink:href CDATA #REQUIRED
>
<!ELEMENT COMPOSER (#PCDATA)>
<!ATTLIST COMPOSER
xmlns:xlink CDATA #FIXED "http://www.w3.org/XML/XLink/0.9"
xlink:type CDATA #FIXED "simple"
xlink:href CDATA #REQUIRED
>
<!ELEMENT IMAGE EMPTY>
<!ATTLIST IMAGE
xmlns:xlink CDATA #FIXED "http://www.w3.org/XML/XLink/0.9"
xlink:type CDATA #FIXED "simple"
xlink:href CDATA #REQUIRED
>
With these declarations, the xlink:type and xmlns:xlink attributes have fixed values. Therefore they do not need to be included in the instances of the elements, which you may now write more compactly like this:
<FOOTNOTE xlink:href="footnote7.xml">7</FOOTNOTE>
<COMPOSER xlink:href="http://www.interport.net/~beand/">
Beth Anderson
</COMPOSER>
<IMAGE xlink:href="logo.gif"/>
Making an element a link doesn't impose any restriction on other attributes or contents of an element. A linking element may contain arbitrary children or other attributes, always subject to the restrictions of the DTD, of course. For example, here's a more realistic declaration of the IMAGE element. Note that most of the attributes don't have anything to do with linking.
<!ELEMENT IMAGE EMPTY>
<!ATTLIST IMAGE
xmlns:xlink CDATA #FIXED "http://www.w3.org/XML/XLink/0.9"
xlink:type CDATA #FIXED "simple"
xlink:href CDATA #REQUIRED
ALT CDATA #REQUIRED
HEIGHT CDATA #REQUIRED
WIDTH CDATA #REQUIRED
>
You may not wish to entangle your tag set and DTD with link attributes. If so, rather than adding the attributes like xlink:href and xlink:type to elements in your own tag set, you can use an xlink:simple element to wrap links around your own elements. This is similar to how you can wrap an HTML A element around P, STRONG, BLOCKQUOTE. or other HTML elements. The xlink:simple element uses the same attributes as any linking element, with the small difference that you do need to attach the xlink: prefix to the individual attributes. For instance, the three earlier examples could be rewritten using xlink:simple like this:
<xlink:simple
xmlns:xlink="http://www.w3.org/XML/XLink/0.9"
href="footnote7.xml">
<FOOTNOTE>7</FOOTNOTE>
</xlink:simple>
<xlink:simple
xmlns:xlink="http://www.w3.org/XML/XLink/0.9"
href="http://www.interport.net/~beand/">
<COMPOSER>Beth Anderson</COMPOSER>
</xlink:simple>
<IMAGE>
<xlink:simple
xmlns:xlink="http://www.w3.org/XML/XLink/0.9"
href="logo.gif"/>
</IMAGE>
Some people find this approach cleaner and easier to understand. Others don't. Feel free to use elements or attributes for links as you prefer. Of course if you do use the xlink:simple element in a valid document, you have to declare it just like any other element. You have to declare its child elements, though often this is simply defaulted to ANY. You have to declare its attributes. You also have to declare it as a child of any element that will contain it. For example,
If used in a valid document, xlink:simple must be declared
<!ELEMENT xlink:simple ANY>
<!ATTLIST xlink:simple
xmlns:xlink CDATA #FIXED "http://www.w3.org/XML/XLink/0.9"
href CDATA #REQUIRED
>
A link element may contain optional xlink:role and xlink:title attributes that describe the remote resource, that is, the document or other resource to which the link points. For example:
<AUTHOR
xmlns:xlink="http://www.w3.org/XML/XLink/0.9"
xlink:href="http://www.macfaq.com/personal.html"
xlink:title="Elliotte Rusty Harold's personal home page"
xlink:role="information about the author of this book">
Elliotte Rusty Harold
</AUTHOR>
The role and title attributes describe the remote resource, not the local element. The remote resource in the above example is the document at http://www.macfaq.com/personal.html. Thus, the above example says that the page at http://www.macfaq.com/personal.html has the title "Elliotte Rusty Harold's personal home page" and the role "information about the author of this book".
It is not uncommon, though it's not required, for the xlink:title to be the same as the contents of the TITLE element of the page to which you are linking.
The application reading the XML might use these two attributes to show extra information to the user. However, the application is not required to show this information to the user or do anything with it.
The xlink:role attribute indicates the purpose of the remote resource (the one to which it's linked) in the linking document (the one from which it's linked). For example, it might distinguish between footnotes, endnotes, and citations.
As with all other attributes, the xlink:title and xlink:role attributes should be declared in the DTD for all the elements to which they belong. For example, this is a reasonable declaration for the above AUTHOR element:
<!ELEMENT AUTHOR (#PCDATA)>
<!ATTLIST AUTHOR
xmlns:xlink CDATA #FIXED "http://www.w3.org/XML/XLink/0.9"
xlink:type CDATA #FIXED "simple"
xlink:href CDATA #REQUIRED
xlink:title CDATA #IMPLIED
xlink:role CDATA #IMPLIED
>
If you're using xlink:simple, then the xlink:role
and xlink:title attributes are simply role and
title. For example:
<xlink:simple
xmlns:xlink="http://www.w3.org/XML/XLink/0.9"
href="http://www.macfaq.com/personal.html"
title="Elliotte Rusty Harold's personal home page"
role="information about the author of this book">
<AUTHOR>Elliotte Rusty Harold</AUTHOR>
</xlink:simple>
Linking elements can contain two more optional attributes that suggest to applications how the remote resource is associated with the current page. These are:
xlink:show suggests how the content should be displayed when the link is activatedxlink:actuate suggests whether the link should be traversed automatically or whether a specific user request is requiredxlink:simple element the prefix is dropped so these are just show and actuate respectively.
The xlink:show attribute has three legal values:
replace newparsedIf the value of xlink:show is replace, then when the link is activated (generally by clicking on it, at least in GUI browsers), the target of the link replaces the current document in the same window. This is the default behavior of HTML links.
If the value of xlink:show is new, activating the link opens a new window in which the targeted resource is displayed. This is similar to the behavior of HTML links when the target attribute is set to _blank.
Readers do not expect a new window to open after clicking a link. They expect that when they click a link, the new page will load into the current window, unless they specifically ask for the link to open in a new window.
Some companies are so self-important that they find it impossible to believe that any user would ever want to leave their sites. Thus they "help" the readers by opening new windows. Most of the time this only serves to confuse and annoy. Don't change the behavior users expect without a very good reason. The thin hope that a reader might spend an additional two seconds on your site or view one more page and see one more ad is not a good enough reason.
If the value of xlink:show is parsed, activating the link inserts the targeted resource into the existing document. Exactly what this means is application dependent. However, you can imagine it being used to provide client-side includes for Web pages.
Like all attributes in valid documents, the xlink:show attribute must be declared in a <!ATTLIST> declaration for the DTD's link element. For example:
<!ELEMENT WEBSITE (#PCDATA)>
<!ATTLIST WEBSITE
xmlns:xlink CDATA #FIXED "http://www.w3.org/XML/XLink/0.9"
xlink:type CDATA #FIXED "simple"
xlink:href CDATA #REQUIRED
xlink:show (new | replace | parsed) #IMPLIED "replace"
>
A linking element's xlink:actuate attribute has two possible values:
userauto
The value user, the default, specifies that the link is to be
traversed only when and if the user requests it. On the other hand, if the link element's xlink:actuate attribute is set to auto, the link is traversed once the link is loaded. For example, you might set the actuate attribute to auto for an image or other piece of external content that's to be embedded in the linking document. This way the user doesn't have to click the link to follow it. For example,
<IMAGE
xmlns:xlink="http://www.w3.org/XML/XLink/0.9"
xlink:type="simple" xlink:href="logo.gif"
xlink:actuate="auto"/>
Like all attributes in valid documents, the actuate attribute must be declared in the DTD in a <!ATTLIST> declaration for the link elements in which it appears. For example:
<!ELEMENT IMAGE EMPTY>
<!ATTLIST IMAGE
xmlns:xlink CDATA #FIXED "http://www.w3.org/XML/XLink/0.9"
xlink:type CDATA #FIXED "simple"
xlink:href CDATA #REQUIRED
xlink:show (new | replace | parsed) #IMPLIED "parsed"
xlink:actuate (user | auto) #IMPLIED "auto"
>
Because the attribute names and types are standardized, if you have more than one link element in a document, often it's convenient to make the attribute declarations a parameter entity reference and simply repeat that in the declaration of each linking element. For example:
<!ENTITY % link-attributes
"xlink:type CDATA #FIXED 'simple'
xlink:role CDATA #IMPLIED
xlink:title CDATA #IMPLIED
xmlns:xlink CDATA #FIXED 'http://www.w3.org/XML/XLink/0.9'
xlink:href CDATA #REQUIRED
xlink:show (new | replace | parsed) #IMPLIED 'replace'
xlink:actuate (user | auto) #IMPLIED 'user'"
>
<!ELEMENT COMPOSER (#PCDATA)>
<!ATTLIST COMPOSER
%link-attributes;
>
<!ELEMENT AUTHOR (#PCDATA)>
<!ATTLIST AUTHOR
%link-attributes;
>
<!ELEMENT WEBSITE (#PCDATA)>
<!ATTLIST WEBSITE
%link-attributes;
>
Simple links behave more or less like the standard links you're accustomed to from HTML. A simple link connects one element in the linking document to one target document. Furthermore, the link is one way, from the source to the target.
Extended links, however, go substantially beyond what you can do with an HTML link to include multidirectional links between many documents and out-of-line links. An extended link consists of a set of locations and a set of the connections between them. Each location may be either a target or a source of a link or both.
In computer science terms, an extended link is a directed labeled graph in which the locations are vertices and the links between nodes are the edges. Thought of abstractly like this, an extended link is really just an XML format for a directed labeled graph data structure in which each vertex is labeled with a particular URI. The tricky part comes in deciding exactly what any particular application is supposed to do with such a data structure. For now, we can only guess what applications might do with extended links and what sort of user interfaces they might provide.
xlink:extended element
<?xml version="1.0"?>
<WEBSITE>
<xlink:extended
xmlns:xlink="http://www.w3.org/XML/XLink/0.9">
<!-- Locators go here -->
</xlink:extended>
</WEBSITE>
An element of arbitrary type like COMPOSER or
TEAM that has xlink:type attribute with
the value extended
<?xml version="1.0"?>
<WEBSITE
xmlns:xlink="http://www.w3.org/XML/XLink/0.9"
xlink:type="extended">
<!-- Locators go here -->
</WEBSITE>
An extended link is included in an XML document in one of two ways. It is either an xlink:extended element or it is an element of some other type like COMPOSER or TEAM that has xlink:type attribute with the value extended.
Extended links generally point to more than one target. To allow this, extended links store the targets (and sources) in child locator elements of the linking element rather than in a single xlink:href attribute of the linking element as simple links do. These locator children can either be xlink:locator elements or they can be elements of arbitrary type whose xlink:type attribute has the value locator. Each locator element has an href or xlink:href that contains a URI for the location.
A locator element is either
xlink:locator elementxlink:type attribute has the value locatorFor example, here's an extended link for four copies of one site:
<?xml version="1.0"?>
<WEBSITE xmlns:xlink="http://www.w3.org/XML/XLink/0.9"
xlink:type="extended">
<HOMESITE xlink:type="locator"
xlink:href="http://metalab.unc.edu/javafaq/">
North Carolina
</HOMESITE>
<MIRROR xlink:type="locator"
xlink:href="http://sunsite.kth.se/javafaq">
Sweden
</MIRROR>
<MIRROR xlink:type="locator"
xlink:href="http://sunsite.uakom.sk/javafaq/">
Slovakia
</MIRROR>
<MIRROR xlink:type="locator"
xlink:href="http://sunsite.cnlab-switch.ch/javafaq/">
Switzerland
</MIRROR>
</WEBSITE>
Here's
an alternative version that uses
xlink:extended and xlink:locator elements.
<?xml version="1.0"?>
<WEBSITE>
<xlink:extended
xmlns:xlink="http://www.w3.org/XML/XLink/0.9">
<xlink:locator
href="http://metalab.unc.edu/javafaq/">
<HOMESITE>North Carolina</HOMESITE>
</xlink:locator>
<xlink:locator
href="http://sunsite.kth.se/javafaq">
<MIRROR>Sweden</MIRROR>
</xlink:locator>
<xlink:locator
href="http://sunsite.uakom.sk/javafaq/">
<MIRROR>Slovakia</MIRROR>
</xlink:locator>
<xlink:locator
href="http://sunsite.cnlab-switch.ch/javafaq/">
<MIRROR>Switzerland</MIRROR>
</xlink:locator>
</xlink:extended>
</WEBSITE>
Both the extended link element itself and the individual locator children may have descriptive attributes such as role and title. The xlink:role and xlink:title attributes of the extended link element provide default roles and titles for each of the individual locator child elements. Individual locator elements may override these defaults with role and title (or xlink:role and xlink:title) attributes of their own.
As always, in valid documents, the link elements and all their possible
attributes must be declared in the DTD. For example, here's a DTD fragment that
declares the WEBSITE, HOMESITE, and
MIRROR elements as used in the example above, as well as their
attributes:
<!ELEMENT WEBSITE (HOMESITE, MIRROR*) >
<!ATTLIST WEBSITE
xmlns:xlink CDATA #FIXED "http://www.w3.org/XML/XLink/0.9"
xlink:type (simple|extended|locator|arc) #FIXED "extended"
xlink:title CDATA #IMPLIED
xlink:role CDATA #IMPLIED
>
<!ELEMENT HOMESITE (#PCDATA)>
<!ATTLIST HOMESITE
xlink:type (simple|extended|locator|arc) #FIXED "locator"
xlink:href CDATA #REQUIRED
xlink:role CDATA #IMPLIED
xlink:title CDATA #IMPLIED
>
<!ELEMENT MIRROR (#PCDATA)>
<!ATTLIST MIRROR
xlink:type (simple|extended|locator|arc) #FIXED "locator"
xlink:href CDATA #REQUIRED
xlink:role CDATA #IMPLIED
xlink:title CDATA #IMPLIED
>
If you have many extended link and locator elements, it may be advantageous to define the common attributes in parameter entities in the DTD, which you can reuse in different elements. For example:
<!ENTITY % extended.att
"xlink:type CDATA #FIXED 'extended'
xmlns:xlink CDATA #FIXED 'http://www.w3.org/XML/XLink/0.9'
xlink:role CDATA #IMPLIED
xlink:title CDATA #IMPLIED"
>
<!ENTITY % locator.att
"xlink:type (simple|extended|locator|arc) #FIXED 'locator'
xlink:href CDATA #REQUIRED
xlink:role CDATA #IMPLIED
xlink:title CDATA #IMPLIED"
>
<!ELEMENT WEBSITE (HOMESITE, MIRROR*) >
<!ATTLIST WEBSITE
%extended.att;
>
<!ELEMENT HOMESITE (#PCDATA)>
<!ATTLIST HOMESITE
%locator.att;
>
<!ELEMENT MIRROR (#PCDATA)>
<!ATTLIST MIRROR
%locator.att;
>
The show and actuate attributes of a simple link
define how and when a link is traversed. Extended links are a little more
complicated however because they provide many possible different directions of
traversal. For example in an extended link with three locators, A, B, and C;
there are nine different possible traversals. These are:
These are called arcs, and they're represented in XML by
xlink:arc elements or elements that have an
xlink:type attribute with the value arc. Some applications may use
arc elements to determine which traversals are and are not allowed.
xlink:arc elementxlink:type attribute with the value arcfrom attribute tells you the origin of the arcto attribute tells you the destination of the arcEach explicit xlink:arc element has a from attribute and a to attribute. The values of these attributes are the IDs of the locator element in the extended link from which traversal is initiated and to which the traversal goes.
<?xml version="1.0"?>
<WEBSITE>
<xlink:extended
xmlns:xlink="http://www.w3.org/XML/XLink/0.9">
<xlink:locator href="http://metalab.unc.edu/javafaq/"
ID="us">
<HOMESITE>North Carolina</HOMESITE>
</xlink:locator>
<xlink:locator href="http://sunsite.kth.se/javafaq"
ID="se">
<MIRROR>Sweden</MIRROR>
</xlink:locator>
<xlink:locator
href="http://sunsite.uakom.sk/javafaq/" ID="sk">
<MIRROR>Slovakia</MIRROR>
</xlink:locator>
<xlink:locator
href="http://sunsite.cnlab-switch.ch/javafaq/"
ID="ch">
<MIRROR>Switzerland</MIRROR>
</xlink:locator>
<xlink:arc from="us" to="ch"/>
<xlink:arc from="us" to="us"/>
<xlink:arc from="us" to="se"/>
<xlink:arc from="us" to="sk"/>
</xlink:extended>
</WEBSITE>
Each of these possible traversals between locations can have different rules for when the link is traversed and what happens when it's traversed. These rules are specified by attaching actuate and show attributes to arc xlink:arc elements or xlink:actuate and xlink:show attributes to arc elements of arbitrary type. These attributes have the same values and meanings as they do for simple links.
actuate or xlink:actuateshow or xlink:showshowdefaultactuatedefault As the number of locator nodes increases, the number of possible traversals grows more than exponentially fast. Consequently, you don't want to have to attach these attributes to all possible traversals. Therefore, the extended link element can have showdefault and actuatedefault or (xlink:showdefault and xlink:actuatedefault) attributes. These provide default values for the show and actuate attributes of any locator child element that doesn't provide its own values.
<?xml version="1.0"?>
<WEBSITE>
<xlink:extended
xmlns:xlink="http://www.w3.org/XML/XLink/0.9"
showdefault="replace" actuatedefault="user">
<xlink:locator href="http://metalab.unc.edu/javafaq/"
ID="us">
<HOMESITE>North Carolina</HOMESITE>
</xlink:locator>
<xlink:locator href="http://sunsite.kth.se/javafaq"
ID="se">
<MIRROR>Sweden</MIRROR>
</xlink:locator>
<xlink:locator
href="http://sunsite.uakom.sk/javafaq/" ID="sk">
<MIRROR>Slovakia</MIRROR>
</xlink:locator>
<xlink:locator
href="http://sunsite.cnlab-switch.ch/javafaq/"
ID="ch">
<MIRROR>Switzerland</MIRROR>
</xlink:locator>
<xlink:arc from="us" to="us" show="new"/>
</xlink:extended>
</WEBSITE>
To use the WEBSITE, HOMESITE, and MIRROR elements themselves as linking elements, we just need to add the necessary ID attributes and the xlink: prefix and define one new tag for the arc element whose xlink:type is arc.
<?xml version="1.0"?>
<WEBSITE xmlns:xlink="http://www.w3.org/XML/XLink/0.9"
xlink:type="extended" xlink:actuatedefault="user"
xlink:showdefault="replace">
<HOMESITE xlink:type="locator" ID="us"
xlink:href="http://metalab.unc.edu/javafaq/">
North Carolina
</HOMESITE>
<MIRROR xlink:type="locator" ID="se"
xlink:href="http://sunsite.kth.se/javafaq">
Sweden
</MIRROR>
<MIRROR xlink:type="locator" ID="sk"
xlink:title="Cafe au Lait Slovakian Mirror"
xlink:href="http://sunsite.uakom.sk/javafaq/">
Slovakia
</MIRROR>
<MIRROR xlink:type="locator" ID="ch"
xlink:title="Cafe au Lait Swiss Mirror"
xlink:href="http://sunsite.cnlab-switch.ch/javafaq/">
Switzerland
</MIRROR>
<CONNECTION xlink:type="arc"
xlink:from="us" xlink:to="us" xlink:show="new"/>
</WEBSITE>
As usual, if the document has a DTD, then to be valid all the attributes and elements must be fully declared. For example, here's a DTD fragment that describes the above WEBSITE element:
<!ELEMENT WEBSITE (HOMESITE, MIRROR*, CONNECTION*) >
<!ATTLIST WEBSITE
xmlns:xlink CDATA #FIXED "http://www.w3.org/XML/XLink/0.9"
xlink:type (simple|extended|locator|arc) #FIXED "extended"
xlink:title CDATA #IMPLIED
xlink:role CDATA #IMPLIED
xlink:showdefault (new | replace | parsed) #IMPLIED
"replace"
xlink:actuatedefault (user | auto) #IMPLIED "user"
>
<!ELEMENT HOMESITE (#PCDATA)>
<!ATTLIST HOMESITE
ID ID #REQUIRED
xlink:type (simple|extended|locator|arc) #FIXED "locator"
xlink:href CDATA #REQUIRED
xlink:role CDATA #IMPLIED
xlink:title CDATA #IMPLIED
>
<!ELEMENT MIRROR (#PCDATA)>
<!ATTLIST MIRROR
ID ID #REQUIRED
xlink:type (simple|extended|locator|arc) #FIXED "locator"
xlink:href CDATA #REQUIRED
xlink:role CDATA #IMPLIED
xlink:title CDATA #IMPLIED
>
<!ELEMENT CONNECTION EMPTY>
<!ATTLIST CONNECTION
xlink:type (simple|extended|locator|arc) #FIXED "arc"
xlink:from IDREF #REQUIRED
xlink:to IDREF #REQUIRED
xlink:show (new | replace | parsed) #IMPLIED "replace"
xlink:actuate (user | auto) #IMPLIED "user"
>
Inline links, such as the familiar A element from HTML, are themselves part of the source or target of the link. Generally they link from the document they're part of to some other document. However, they can also link to a different part of the same document. Most simple links are inline.
XLinks, particularly extended links, can also be out-of-line. An out-of-line link is not part of any of the documents it connects. Instead, the links are stored in a separate linking document. For example, this might be useful to maintain a slide show where each slide requires next and previous links. By changing the order of the slides in the linking document, you can change the targets of the previous and next links on each page without having to edit the slides themselves.
Out of line links also allow you to add links to and from documents that can't be modified. For instance, out-of-line links might allow a third party to add links to a page it doesn't control. For instance, Fairness and Accuracy in Reporting (FAIR) or Accuracy in Media (AIM) could put out-of-line links from the New York Times editorial page to analyses of those editorials. The links would be visible only to users who loaded the extended link group document from FAIR or AIM's own site, however; and which links you saw would depend on which document you loaded.
And out of line links allow you to add links to different parts of non-XML content. For instance, you could link to the third minute of a QuickTime movie, even though the movie doesn't contain any attributes or elements that would normally be used to identify the linked position.
This expands the abstraction of style sheets into the linking domain. A style sheet is completely separate from the document it describes and yet provides rules that modify how the document is presented to the reader. A linking document containing out-of-line links is separated from the documents it connects, yet it provides the necessary links to the reader. This has several advantages, including keeping more presentation-oriented markup separate from the document and allowing the linking of read-only documents.
Style sheets are much farther along than out-of-line links. There currently is no general proposal for how you attach "link sheets" to XML documents, much less how you decide which individual elements in a document are associated with which links.
One obvious choice is to add an <?xml-linksheet?> processing instruction to a document's prolog to specify where the links are found. The link sheet itself could use something akin to XSL select patterns to map links to individual XML elements. The selectors could even become the value of the locator element's role attribute.
An extended link group element contains a list of links that connect a particular group of documents. Each document in the group is targeted by means of an extended link document element. It is the application's responsibility to understand how to activate and understand the connections between the group members.
I feel compelled to note that application support for link groups is at best hypothetical at the time of this writing. Although I can show you how to write such links, their actual implementation and support likely is some time away. Some of the details remain to be defined and likely will be implemented in vendor-specific fashions, at least initially. Still, they hold the promise of enabling more sophisticated linking than can be achieved with HTML.
An extended link group element contains a list of links that connect a particular group of documents.
xlink:group elementxlink:type attribute with the value groupEach document in the group is represented by an extended link document element.
xlink:documentxlink:type attribute with the value documenthref or xlink:href attribute whose value is a URL.An extended link group element is either an explicit xlink:group element or an element with an xlink:type attribute with the value group. An extended link document element is either an explicit xlink:document element or an element with an xlink:type attribute with the value document. The document element has an href or xlink:href attribute whose value is a URI identifying a member of the group.
For example, I've put the notes for a Java course I teach on my Web site. This particular course consists of 13 classes, each of which contains between 30 and 60 individual pages of notes. A table of contents is then provided for each class. Each of the several hundred pages making up the entire site has links to the previous document (Previous link), the next document (Next link), and the table of contents (Top link) for the week. Putting it all together, this amounts to more than a thousand interconnections among this set of documents.
The possible interconnections grow exponentially with the number of documents. Every time a single document is moved, renamed, or divided into smaller pieces, the links need to be adjusted on that page, on the page before it and after it in the set, and on the table of contents for the week. Quite frankly, this is a lot more work than it should be, and it tends to discourage necessary modifications and updates to the course notes.
The sensible thing to do, if HTML supported it, would be to store the connections in a separate document. Reorganization of the pages then could be performed by editing that one document. HTML links don't support this, but XLinks do. Instead of storing the links inline in HTML files, they can be stored out-of-line in group elements.
<?xml version="1.0"?>
<xlink:group xmlns:xlink="http://www.w3.org/XML/XLink/0.9">
<xlink:document href="week1/index.xml"/>
<xlink:document href="week2/index.xml"/>
<xlink:document href="week3/index.xml"/>
<xlink:document href="week4/index.xml"/>
<xlink:document href="week5/index.xml"/>
<xlink:document href="week6/index.xml"/>
<xlink:document href="week7/index.xml"/>
<xlink:document href="week8/index.xml"/>
<xlink:document href="week9/index.xml"/>
<xlink:document href="week10/index.xml"/>
<xlink:document href="week11/index.xml"/>
<xlink:document href="week12/index.xml"/>
<xlink:document href="week13/index.xml"/>
</xlink:group>
This defines an extended link group, which consists of 13 extended link document elements, each of which refers to the index page for one of the classes.
<?xml version="1.0"?>
<COURSE xmlns:xlink="http://www.w3.org/XML/XLink/0.9"
xlink:type="group">
<CLASS xlink:type="document" xlink:href="week1/index.xml"/>
<CLASS xlink:type="document" xlink:href="week2/index.xml"/>
<CLASS xlink:type="document" xlink:href="week3/index.xml"/>
<CLASS xlink:type="document" xlink:href="week4/index.xml"/>
<CLASS xlink:type="document" xlink:href="week5/index.xml"/>
<CLASS xlink:type="document" xlink:href="week6/index.xml"/>
<CLASS xlink:type="document" xlink:href="week7/index.xml"/>
<CLASS xlink:type="document" xlink:href="week8/index.xml"/>
<CLASS xlink:type="document" xlink:href="week9/index.xml"/>
<CLASS xlink:type="document" xlink:href="week10/index.xml"/>
<CLASS xlink:type="document" xlink:href="week11/index.xml"/>
<CLASS xlink:type="document" xlink:href="week12/index.xml"/>
<CLASS xlink:type="document" xlink:href="week13/index.xml"/>
</COURSE>
As always, if these documents are to be valid all these elements and attributes must be declared correctly in the DTD.
xlink prefix. However, the URI is likely to change in future revisions to XLink. <A> tag.xlink:type attributes.xlink:type attributes with the value simple. The xlink:simple element is also a simple link.title and role attributes.show attribute to tell the application how the content should be displayed when the link is activated, for example, by opening a new window.actuate attribute to tell the application whether the link should be traversed without a specific user request.xlink:type attributes with the value extended. The xlink:extended element is also an extended link.xlink:type attributes with the value locator. The xlink:locator element is also a locator element.href or xlink:href attribute whose value is the URI of the resource it locates.xlink:type attributes with the value arc. The xlink:arc element is also an arc element.from and to attributes of IDREF type that identify to the locator elements they connect.show and actuate attributes to determine when and how traversal of the link occurs.xlink:type attribute with the value group. An xlink:group element is also an extended link group element.xlink:type attribute with the value document. An xlink:document element is also an extended link document element.href or xlink:href attribute whose value is the URI of the document.XPointer, the XML Pointer Language, defines an addressing scheme for individual parts of an XML document. XLinks point to a URI (in practice, a URL) that specifies a particular resource. The URI may include an XPointer part that more specifically identifies the desired part or element of the targeted resource or document. XPointers use the same XPath syntax you're familiar with from XSL transformations to identify the parts of the document they point to, along with a few additional pieces.
URLs are simple and easy to use, but they're also quite limited. For one thing, a URL only points at a single, complete document. More granularity than that, such as linking to the third sentence of the 17th paragraph in a document, requires the author of the targeted document to manually insert named anchors at the targeted location. The author of the document doing the linking can't do this unless he or she also has write access to the document being linked to. Even if the author doing the linking can insert named anchors into the targeted document, it's almost always inconvenient.
class attribute has the value pending.It would be more useful to be able to link to a particular element or group of elements on a page without having to change the document you're linking to. For example, given a large page such as the complete baseball statistics of Chapters 4 and 5, you might want to link to only one team or one player. There are several parts to this problem. The first part is addressing the individual elements. This is the part that XPointers solve. XPointers allow you to target a given element by number, name, type, or relation to other elements in the document.
The second part of the problem is the protocol by which a browser asks a Web server to send only part of a document rather than the whole thing. This is an area of active research. More work is needed. XPointers do little to solve this problem, except for providing a foundation on which such systems can build. For instance, the best effort to date are the so-called "byte range extensions to HTTP" available in HTTP 1.1. So far these have not achieved widespread adoption, mostly because Web authors aren't comfortable specifying a byte range in a document. Furthermore, byte ranges are extremely fragile. Trivial edits to a document, even simple reformatting, can destroy byte range links. HTTP 1.1 does allow other range units besides raw bytes (for example, XML elements), but does not require Web servers or browsers to support such units. Much work remains to be done.
The third part of the problem is making sure that the retrieved document makes sense without the rest of the document to go along with it. In the context of XML, this effectively means the linked part is well-formed or perhaps valid. This is a tricky proposition, because most XML documents, especially ones with nontrivial prologs, don't decompose well. Again, XPointers don't address this. The W3C XML Fragment Working Group is addressing this issue, but the work is only just beginning.
For the moment, therefore, an XPointer can be used as an index into a complete document, the whole of which is loaded and then positioned at the location identified by the XPointer. In the long-term, extensions to both XML, XLink, HTTP, and other protocols may allow more sophisticated uses of XPointers. For instance, you might be able to quote a remote document by including only an XLink with an XPointer to the paragraph you want to quote, rather than retyping the text of the quote. You could include cross references inside a document that automatically update themselves as the document is revised. These uses, however, will have to wait for the development of several next-generation technologies. For now, we must be content with precisely identifying the part of a document we want to jump to when following an XLink.
HTML links generally point to a particular document. Additional granularity, that is, pointing to a particular section, chapter, or paragraph of a particular document, isn't well-supported. Provided you control both the linking and the linked document, you can insert a named anchor into an HTML file at the position to which you want to link. For example:
<H2><A NAME="xpointers">XPointers</A></H2>
You can then link to this particular position in the file by adding a # and the name of the anchor into the link. For example, in a table of contents you might see:
<A HREF="#xpointers">XPointers</A>
In practice, this solution is kludgy. It's not always possible to modify the target document so the source can link to it. The target document may be on a different server controlled by someone other than the author of the source document. And the author of the target document may change or move it without notifying the author of the source.
Furthermore, named anchors violate the principle of separating markup from content. Placing a named anchor in a document says nothing about the document or its content. It's just a marker for other documents to refer to. It adds nothing to the document's own content.
XLinks allow much more sophisticated connections between documents through the use of XPointers. An XPointer can refer to a particular element of a document; to the first, second, or 17th such element; to the first element that's a child of a given element; and so on. XPointers provide extremely powerful connections between documents. They do not require the targeted document to contain additional markup just so its individual pieces can be linked to.
Furthermore, unlike HTML anchors, XPointers don't point to just a single point in a document. They can point to ranges or spans. Thus, you can use an XPointer to select a particular part of a document, perhaps so it can be copied or loaded into a program.
Here are a few examples of XPointers:
xptr(id("ebnf"))
xptr(descendant::language[position()=2])
ebnf
xptr(/child::spec/child::body/child::*/child::language[ position()=2])
/1/14/2
xptr(id("ebnf"))xptr(id("EBNF"))
Each of these selects a particular element in a document. The first finds the element with the ID "ebnf". The second finds the first language element in the document that's the second child of its parent. The third is a shorthand form of finding the element with the ID "ebnf". The fourth finds the second language child element of any
child element of the first body element of the spec child of the root node. The fifth finds the second child element of the fourteenth child element of the first child element of the root element. The final URI also points to the element with the ID "ebnf"; However, if no
such element is present then it finds the element with the ID "EBNF".
The document is not specified in the XPointer; rather, the XLink specifies the document. The XLinks you saw in the previous chapter did not contain XPointers, but it isn't hard to add XPointers to them. Most of the time you simply append the XPointer to the URI separated by a #, just as you do with named anchors in HTML. For example, the above list of XPointers could be suffixed to URLs and come out looking like the following:
http://www.w3.org/TR/1998/REC-xml-19980210.xml#xptr(id("ebnf"))
http://www.w3.org/TR/1998/REC-xml-
19980210.xml#xptr(descendant::language[position()=2])
http://www.w3.org/TR/1998/REC-xml-19980210.xml#ebnf
http://www.w3.org/TR/1998/REC-xml-19980210.xml
#xptr(/child::spec/child::body/child::*/child::language[ position() = 2])
http://www.w3.org/TR/1998/REC-xml-
19980210.xml#/1/14/2
http://www.w3.org/TR/1998/REC-xml-
19980210.xml#xptr(id("ebnf"))xptr(id("EBNF"))
In fact, these URIs are just six different ways of pointing to the same element of the document at http://www.w3.org/TR/1998/REC-xml-19980210.xml.
Normally the URI with an XPointer part is the value
of the href attribute of a locator element. For example:
<locator href =
"http://www.w3.org/TR/1998/REC-xml-19980210.xml
#xptr(id('ebnf'))" >
Extensible Markup Language (XML) 1.0
</locator>
You can use a vertical bar (|) instead of a # to indicate that you do not want the entire document. Instead, you want only the part of the document referenced by the XPointer. For example:
http://www.w3.org/TR/1998/REC-xml-
19980210.xml|xptr(id("ebnf"))
http://www.w3.org/TR/1998/REC-xml-
19980210.xml|xptr(descendant::language[position()=2])
http://www.w3.org/TR/1998/REC-xml-19980210.xml|ebnf
http://www.w3.org/TR/1998/REC-xml-
19980210.xml|
xptr(/child::spec/child::body/child::*/child::language[ position() = 2])
http://www.w3.org/TR/1998/REC-xml-
19980210.xml|/1/14/2
http://www.w3.org/TR/1998/REC-xml-
19980210.xml|xptr(id("ebnf"))xptr(id("EBNF"))
Whether the client is able to retrieve only a piece of the document is protocol dependent. Most current Web browsers and servers aren't able to handle the sophisticated requests that these XPointers imply. However, this can be useful for custom protocols that use XML as an underlying transport mechanism.
FAMILYTREE. A FAMILYTREE can contain PERSON and FAMILY elements. Each PERSON and FAMILY element has a required ID attribute. Persons contain a name, birth date, and death date. Families contain a husband, a wife, and zero or more children. The individual persons are referred to from the family by reference to their IDs. Any child element may be omitted from any element.<?xml version="1.0"?>
<!DOCTYPE FAMILYTREE [
<!ELEMENT FAMILYTREE (PERSON | FAMILY)*>
<!-- PERSON elements -->
<!ELEMENT PERSON (NAME*, BORN*, DIED*, SPOUSE*)>
<!ATTLIST PERSON
ID ID #REQUIRED
FATHER CDATA #IMPLIED
MOTHER CDATA #IMPLIED
>
<!ELEMENT NAME (#PCDATA)>
<!ELEMENT BORN (#PCDATA)>
<!ELEMENT DIED (#PCDATA)>
<!ELEMENT SPOUSE EMPTY>
<!ATTLIST SPOUSE IDREF IDREF #REQUIRED>
<!--FAMILY-->
<!ELEMENT FAMILY (HUSBAND?, WIFE?, CHILD*) >
<!ATTLIST FAMILY ID ID #REQUIRED>
<!ELEMENT HUSBAND EMPTY>
<!ATTLIST HUSBAND IDREF IDREF #REQUIRED>
<!ELEMENT WIFE EMPTY>
<!ATTLIST WIFE IDREF IDREF #REQUIRED>
<!ELEMENT CHILD EMPTY>
<!ATTLIST CHILD IDREF IDREF #REQUIRED>
]>
<FAMILYTREE>
<PERSON ID="p1">
<NAME>Domeniquette Celeste Baudean</NAME>
<BORN>11 Feb 1858</BORN>
<DIED>12 Apr 1898</DIED>
<SPOUSE IDREF="p2"/>
</PERSON>
<PERSON ID="p2">
<NAME>Jean Francois Bellau</NAME>
<SPOUSE IDREF="p1"/>
</PERSON>
<PERSON ID="p3" FATHER="p2" MOTHER="p1">
<NAME>Elodie Bellau</NAME>
<BORN>11 Feb 1858</BORN>
<DIED>12 Apr 1898</DIED>
<SPOUSE IDREF="p4"/>
</PERSON>
<PERSON ID="p4" FATHER="p2" MOTHER="p1">
<NAME>John P. Muller</NAME>
<SPOUSE IDREF="p3"/>
</PERSON>
<PERSON ID="p7">
<NAME>Adolf Eno</NAME>
<SPOUSE IDREF="p6"/>
</PERSON>
<PERSON ID="p6" FATHER="p2" MOTHER="p1">
<NAME>Maria Bellau</NAME>
<SPOUSE IDREF="p7"/>
</PERSON>
<PERSON ID="p5" FATHER="p2" MOTHER="p1">
<NAME>Eugene Bellau</NAME>
</PERSON>
<PERSON ID="p8" FATHER="p2" MOTHER="p1">
<NAME>Louise Pauline Bellau</NAME>
<BORN>29 Oct 1868</BORN>
<DIED>3 May 1938</DIED>
<SPOUSE IDREF="p9"/>
</PERSON>
<PERSON ID="p9">
<NAME>Charles Walter Harold</NAME>
<BORN>about 1861</BORN>
<DIED>about 1938</DIED>
<SPOUSE IDREF="p8"/>
</PERSON>
<PERSON ID="p10" FATHER="p2" MOTHER="p1">
<NAME>Victor Joseph Bellau</NAME>
<SPOUSE IDREF="p11"/>
</PERSON>
<PERSON ID="p11">
<NAME>Ellen Gilmore</NAME>
<SPOUSE IDREF="p10"/>
</PERSON>
<PERSON ID="p12" FATHER="p2" MOTHER="p1">
<NAME>Honore Bellau</NAME>
</PERSON>
<FAMILY ID="f1">
<HUSBAND IDREF="p2"/>
<WIFE IDREF="p1"/>
<CHILD IDREF="p3"/>
<CHILD IDREF="p5"/>
<CHILD IDREF="p6"/>
<CHILD IDREF="p8"/>
<CHILD IDREF="p10"/>
<CHILD IDREF="p12"/>
</FAMILY>
<FAMILY ID="f2">
<HUSBAND IDREF="p7"/>
<WIFE IDREF="p6"/>
</FAMILY>
</FAMILYTREE>
http://www.harolds.net/genealogy.xml. This isn't a real URL, but the emphasis here is on selecting individual parts of a document rather than a document as a whole.id, ancestor, or child.There are two absolute location steps:
id()/id() function is one of the simplest and most useful location steps. It selects the element in the document that has an ID type attribute with a specified value.
URI:
http://www.harolds.net/genealogy.xml#xptr(id("p2"))
Element:
<PERSON ID="p2">
<NAME>Jean Francois Bellau</NAME>
<SPOUSE IDREF="p1"/>
</PERSON>
Because ID type attributes are unique, you know there aren't other elements that match this XPointer. Therefore, http://www.harolds.net/genealogy.xml#xptr(id("p2")) must refer to Jean Francois Bellau's PERSON element. The XPointer selects the entire element to which it refers, including all its children, not just the start tag.
The disadvantage of the id() location term is that it requires assistance from the targeted document. If the element you want to point to does not have an ID type attribute, you're out of luck. If other elements in the document have ID type attributes, you may be able to point to one of them and use a relative location step (discussed in the next section) to point to the one you really want. Nonetheless, ID type attributes are best when you control both the targeted document and the linking document, so you can ensure that the IDs match the links even as the documents evolve and change over time.
In some cases, such as a document without a DTD, a targeted document may not have any ID type attributes, although it may have attributes named ID. In this case, the application may (or may not) try to guess which element you were pointing at. Generally it selects the first element in the document with an attribute of any type and a name whose value matches the requested ID. On the other hand, the application is free not to select any element.
Since ID pointers are so common and so useful, there's also a shortcut for this. If all you want to do is point to a particular element with a particular ID, you can skip all the xptr(id("...")) fru-fru and just use the bare ID after the # like this:
http://www.harolds.net/genealogy.xml#p2
You can only do this is all you want is the particular element with the particular ID. You cannot add additional relative location steps to a URI that uses this shortcut to select children of the element with ID p2 or the third attribute of the element with ID p12. If you want to do that you have to use the full xptr(id("p2")) syntax.
The / location term points to the root node of the document. This is not the same as the root element. Rather it is an abstract node that contains the entire document including the XML declaration, the document type declaration, any comments or processing instructions that come before or after the root element such as xml-stylesheet, and the root element itself.
To select the root node of the XML 1.0 specification at http://www.w3.org/TR/REC-xml you can use this URI:
http://www.w3.org/TR/REC-xml#xptr(/)
/ is primarily useful in compound XPointers as a basis
from which to start. In fact, if no absolute location term is included in a
compound location term, / is assumed. However, root()
can also be used to select the entire document in a URI that uses |
to indicate that only a part is normally loaded. For example:
http://www.w3.org/TR/1999/REC-xml|xptr(/)
id and / are absolute location paths. Absolute location paths can find a particular element in a document regardless of what else is in the document and where the particular element occurs. However, more commonly you want to find the first element of a given type, the last element of a given type, the first child of a particular type, the next element of a given type, all elements of a given type, or something similar. These tasks are accomplished by attaching relative location steps to an initial absolute location step to form a compound locator. The different location steps are separated by forward slashes (/). The most general XPointer is a single absolute location step followed by any number of relative location steps. Each term in the list is relative to the one that precedes it, except for the first. Terms in the list are separated by slashes.
/). The most general XPointer is a single absolute location step followed by any number of relative location steps. Each term in the list is relative to the one that precedes it, except for the first. Terms in the list are separated by slashes.
id("p6")/child::NAME[position()=1]
A relative location step has an implicit context node (possibly more than one) which defines where the step starts from. In a compound locator, this will be the node or nodes selected by the previous location step. For instance, consider this compound locator:
It begins with the absolute location step id("p6"). This identifies the context node for the following relative location step child::NAME[position()=1]. In
our example, the context node is thus Maria Bellau's PERSON element.
The first explicit part of the relative location step is the axis which defines the nodes that are selected based on their position relative to the context node. The axis here is child, so all the children of the context node, that is the children of Maria Bellau's PERSON element are selected, specifically her NAME element <NAME>Maria Bellau</NAME> and her SPOUSE element <SPOUSE IDREF="p7"/>. Other possible axes include ancestor, descendant, self, ancestor-or-self, descendant-or-self, attribute, and more.
The axis is followed by a double colon and a node test. Generally the node test is an element name, but it may also be the asterisk (*) wild card to indicate that any node is to be matched, or one of several functions for selecting comments, text, attributes, and processing instructions. Here the node test is NAME so only NAME elements are selected. Together the axis, the double colon, and the node test are referred to as the basis.
A relative location step must have an axis and a node test. It may or may not have one or more predicates. The predicate is a pair of square brackets containing an expression (exactly like the expressions you learned about in XSL) that further winnows down the nodes selected by the basis. Here the predicate is [position()=1] which says that only the first node in the context node set selected by the basis is pointed at. In this example, that's redundant since the context node set has a single element, Maria Bellau's NAME element.
There are other powerful selection techniques, which are discussed below. In fact, including child, there are twelve relative location axes, all from the same XPath syntax used for XSL transformation. These are listed in Table 17-1. Each serves to select a particular subset of the elements in the document. For instance, the following relative location term selects from elements that come after the source element. The preceding relative location term selects from elements that come before the source element.
| Axis | Selects From |
ancestor |
the parent of the current node, the parent of the parent of the current node, the parent of the parent of the parent of the current node, and so forth back to the root node |
ancestor-or-self |
the ancestors of the current node and the current node itself |
attribute |
the attributes of the current node |
child |
the immediate children of the current node |
descendant |
the children of the current node, the children of the children of the current node, and so forth |
descendant-or-self |
the current node itself and its descendants |
following |
all nodes that start after the end of the current node, excluding attribute and namespace nodes |
following-sibling |
all nodes that start after the end of the current node and have the same parent as the current node |
parent |
the single parent node of the current node |
preceding |
all nodes that start before the start of the current node, excluding attribute and namespace nodes |
preceding-sibling |
all nodes that start before the start of the current node and have the same parent as the current node |
self |
the current node |
The child axis selects from only the immediate children of the source element. For example, consider this URI:
http://www.harolds.net/genealogy.xml#xptr(id("p1")/child::NAME)
The descendant axis searches through all the descendants of the source, not just the immediate children.
/descendant::BORN[position()=3]
selects the third BORN element encountered in a depth-first search of the document tree. (Depth first is the order you get if you simply read through the XML document from top to bottom.) In Listing 17-1, that selects Louise Pauline Bellau's birthday, <BORN>29 Oct 1868</BORN>.
The descendant-or-self axis searches through all the descendants of the source, starting with the source itself, until it finds the requested element.
id("p3")/descendant-or-self::PERSON
refers to all PERSON children of the element with ID p3 as well as that element itself, since it is of type PERSON.
The parent axis refers to the node that's the immediate parent of the source.
/descendant::HUSBAND[position()=1]/parent::*
refers to the parent element of the first HUSBAND element in the document.
The self axis refers to the context node. It's sometimes useful when making relative links.
/self::node()
selects the root node of the document (which is not the same as the root element of the document; that would be selected by /child::* or, in this example, /child::FAMILYTREE.)
The ancestor axis selects all nodes that contain the context node, starting with its parent.
/descendant::BORN[position()=2]/ancestor::*[position()=1]
selects the element which contains the second BORN element. In this example, it selects Elodie Bellau's PERSON element.
The ancestor-or-self axis selects the context node and all nodes that contain it.
id("p1")/ancestor-or-self::*
selects a node set including Domeniquette Celeste Baudean's PERSON element that has ID p1, its parent the FAMILYTREE element, and its parent, the root node.
The preceding axis selects all elements that occur before the context node. The preceding axis has no respect for hierarchy. The first time it encounters an element's start tag, end tag, or empty tag, it counts that element.
/descendant::BORN[position()=3]/preceding::*[position()=5]
This says go to the third BORN element from the root, Louise Pauline Bellau's birthday, <BORN>29 Oct 1868</BORN>, and then move back five elements. This lands on Maria Bellau's PERSON element.
The following axis selects all elements that occur after the context node's closing tag. Like preceding, following has no respect for hierarchy. The first time it encounters an element's start tag or empty tag, it counts that element.
/descendant::BORN[position()=2]/following::*[position()=5]
This says go to Elodie Bellau's birthday, <BORN>11 Feb 1858</BORN>, and then move forward five elements. This lands on John P. Muller's NAME element, <NAME>John P. Muller</NAME>, after passing through Elodie Bellau's DIED element, Elodie Bellau's SPOUSE element, Elodie Bellau's PERSON element, and John P. Muller's PERSON element, in this order.
The preceding-sibling axis selects elements that precede the context node in the same parent element.
/descendant::BORN[position()=2]/preceding-sibling::*[position() = 1]
selects Elodie Bellau's NAME element, <NAME>Elodie Bellau</NAME>. /descendant::BORN[position()=2]/preceding-sibling::*[position()=2] doesn't point to anything because there's only one sibling of Elodie Bellau's BORN element before it.
The following-sibling axis selects elements that follow the context node in the same parent element.
/descendant::BORN[position()=2]/following-sibling::*[position() = 1]
selects Elodie Bellau's DIED element, <DIED>12
Apr 1898</DIED>. /descendant::BORN[position()=2]/following-
sibling::*[position()=3] doesn't point to anything because there are only
two sibling elements following Elodie Bellau's BORN element.
The attribute axis selects an attribute node of the source node.
/descendant::SPOUSE/attribute::IDREF
selects all IDREF attributes of all SPOUSE
elements in the document. For another example, to find all PERSON
elements in the document http://www.harolds.net/genealogy.xml
whose FATHER attribute is Jean Francois Bellau (ID p2), you could
write:
/descendant::PERSON[attribute::FATHER="p2"]
Most of the time the node test part of the basis is simply an element name like PERSON or BORN. However, there are five other possibilities:
*
node()text()
comment()
processing-instruction()
id("p1")/child::*
selects all the child elements of the element with the ID p1 regardless
of their type. This does, however, select only element nodes. It omits comment
nodes, text nodes, processing instruction nodes, and attribute nodes. If you
want to select absolutely any kind of node use the node() wild card
instead.
The text() node test specifically refers to the parsed character
data content of an element. It's most commonly used with mixed content. For
instance /descendant::text() will refer to all of the text but none
of the markup of a document.
Because character data does not contain child elements, further relative location terms may not be attached to an XPointer that selects a text node.
The comment() node test specifically refers to comments.
For example, this XPointer points to the third comment in the document:
/descendant::comment()[position()=3]
Because comments do not contain attributes or elements, you cannot add an
additional child, descendant, or
attribute relative location step after the first term that selects
a comment.You can use a string relative location axis
to select part of the text of the comment, though.
processing-instruction() node test selects any
processing instructions that occur along the chosen axis. /descendant::processing-instruction()
/descendant::processing-instruction(xml-stylesheet)
/descendant::processing-instruction(php)
/descendant::processing-instruction() selects all
processing instructions in the document. However, /descendant::processing-
instruction(xml-stylesheet) only finds processing instructions that begin
<?xml-stylesheet. /descendant::processing-instruction(php) only finds processing instructions intended for PHP. As
with comments, because processing instructions do not contain attributes or
elements, you cannot add an additional child,
descendant, or attribute relative location term after
the first term that selects a processing instruction. However, you can use a
string location step to select part of the text of the processing
instruction.
Each location step can contain zero or more predicates that further restrict
which nodes an XPointer points to. In most non-trivial cases a predicate is
necessary to pick the one node from a node set that you want.
Each predicate contains an
expression in square brackets ([]) that further winnows the node
set. This allows an XPointer to select nodes according to many different
criteria. For example, you can select:
These are just a small sampling of the selections that predicates make possible.
Non-boolean results are converted as follows:
The predicate expression is evaluated for each node in the context node list. Each node for which the expression ultimately evaluates to false is removed from the list. Thus only those nodes that satisfy the predicate remain.
Probably the function most frequently used in XPointer predicates is position(). This returns the index of the node in the context node list. This allows you to find the first, second, third, or other indexed node. You can compare positions using the various relational operators like <, >, =, !=, >=, and <=.
For instance, in the family tree document, the root element is
FAMILYTREE element is the root. It has 14 immediate children, 12
PERSON elements, and two FAMILY elements. In order,
they are:
/child::FAMILYTREE/child::*[position()=1]
/child::FAMILYTREE/child::*[position()=2]
/child::FAMILYTREE/child::*[position()=3]
/child::FAMILYTREE/child::*[position()=4]
/child::FAMILYTREE/child::*[position()=5]
/child::FAMILYTREE/child::*[position()=6]
/child::FAMILYTREE/child::*[position()=7]
/child::FAMILYTREE/child::*[position()=8]
/child::FAMILYTREE/child::*[position()=9]
/child::FAMILYTREE/child::*[position()=10]
/child::FAMILYTREE/child::*[position()=11]
/child::FAMILYTREE/child::*[position()=12]
/child::FAMILYTREE/child::*[position()=13]
/child::FAMILYTREE/child::*[position()=14]
Greater numbers, such as /child::FAMILYTREE/child::*[position()=15],
don't point at anything. They're just dangling. To count all elements in the document,
not just the immediate children of the root, you can use descendant instead
of child.
Selecting a particular element is almost always good enough for pointing into
well-formed XML documents. However, on occasion you need to point into XML data
in which large chunks of non-XML text is embedded via CDATA
sections, comments, processing instructions, or some other means. In these cases
you may need to refer to particular ranges of text in the document that don't
map onto any particular markup element. Or you may need to point into non-XML
substructure in the text content of particular elements; for example the month
in a BORN element that looks like this:
Suppose you may need to point into non-XML
substructure in the text content of particular elements; for example the month
in a BORN element that looks like this:
<BORN>11 Feb 1858</BORN>
string axis selects one or more occurrences of a specified stringYou can use the string axis to do this. At the time of this
writing (July, 1999), the string axis is only a part of XPointer,
not of XPath, so you can't use it with select expressions in XSL. However
something like it may well be added to XPath in the future, in which case this
material will likely become at least partially obsolete.
A string location term points to an occurrence of a specified string, or a substring of a given string in the text (not markup) of the document. For example, this XPointer finds all occurrences of the string "Harold":
xptr(/string::"Harold")
String location terms may have node tests. Thus this XPointer finds only the first occurrence of the string "Harold":
xptr(/string::"Harold"[position()=1])
This targets the position immediately preceding the H in Harold in Charles Walter Harold's NAME element. This is not the same as pointing at the entire NAME element as an element-based selector would do.
xptr(/string::"Harold",6[position()=1])
xptr(/string::"Harold",1,6[position()=1])
xptr(/string::"",1,6[position()=1])
BORN element:
/descendant::BORN[position()=1]/string::" ",2,3[position() = 1]
In some applications it may be important to specify a range of a document rather than a particular point in a document. This can be accomplished with the range axis. A range begins at one XPointer and continues until another XPointer. A range is indicated by the keyword range used as a location term. However, it is followed by two location terms separated by a comma. The first identifies the start of the range and the second identifies the end of the range.
For example, suppose you want to select everything between the first PERSON element and the last PERSON element in genealogy.xml. This XPointer accomplishes that:
range::/child::PERSON[position() = 1],/child::PERSON[position() = last()]
One common way to identify an
element in an XML document is by location. Identifying an
element by location is generally accomplished by counting children down from the
root. For example, the following XPointer points to John P. Muller's
PERSON element:
/child::*[position()=1]/child::*[position()=4]
A tumbler is a shortcut for XPointers exemplified by the second example above; that is, an XPointer that consists of nothing but a series of child relative location steps counting down from the root node, each of which selects a particular child by position only. The shortcut is to use only the position number and the slashes that separate individual elements from each other, like this:
http://www.harolds.net/genealogy.xml#/1/4
/1/4 is a tumbler that says to select the fourth child element of the first child element of the root. This syntax can be extended for any depth of child elements. For example these two URIs point to John P. Muller's NAME and SPOUSE elements respectively:
http://www.harolds.net/genealogy.xml#/1/4/1
http://www.harolds.net/genealogy.xml#/1/4/2
Each tumbler always points to a single element. You cannot use tumblers with any other relative location steps. You cannot use them to select elements of a particular type. You cannot use them to select attribute or strings. You can only use them to select a single element by its relative location in the tree.
id absolute location step points to an element with a specified value for an ID type attribute.root absolute location step points to the root element of an XML document and is generally abbreviated as simply /.self axis points to the context node.parent axis points to the node that contains the context node.child axis points to immediate children of the context node.descendant axis points to all elements contained in the context node.descendant-or-self axis points to all elements contained in the context node as well as the context node itself.ancestor axis points to an element that contains the context node.ancestor-or-self axis points to all elements that contain the context node as well as the context node itself.preceding axis points to any element that comes before the context node.following axis points to any element following the context node.preceding-sibling axis selects from sibling elements that precede the context node.following-sibling axis selects from sibling elements that follow the context node.attribute axis points to an attribute of the context node.* wild card to select all elements or one of the keywords comment(), text(), processing-instruction(), or node().string location term points to a specified block of text in the location source.range axis selects the XML fragment between two XPointers.