Whereas a simple link describes a single unidirectional connection between one XML element and one remote resource, an extended link describes a collection of resources and a collection of paths between those resources. Each path connects exactly two resources. Any individual resource may be connected to one of the other resources, two of the other resources, zero of the other resources, all of the other resources, or any subset of the other resources in the collection. It may even be connected back to itself. In computer science terms, an extended link is a directed, labeled graph in which the paths are arcs, the documents are vertices, and the URIs are labels.
In XML, an extended link is represented by an extended link
element; that is, an element of arbitrary type that has an xlink:type attribute with the value extended. For example, this is an extended
link element that refers to the novel The Wonderful Wizard
of Oz:
<novel xlink:type="extended"> <title>The Wonderful Wizard of Oz</title> <author>L. Frank Baum</author> <year>1900</year> </novel>
Although this extended link is quite spartan, most extended
links contain local resources, remote resources, and arcs between
those resources. A remote resource is represented by a locator element,
which is an element of any type that has an xlink:type attribute with the value locator. A local resource is represented by
a resource element, which is an element of any type that has an
xlink:type attribute with the value resource. And an arc between two resources,
whether local or remote, is represented by an arc element—that is, an
element of any type that has an xlink:type attribute with the value arc.
Each locator element has an xlink:type attribute with the value
locator and an xlink:href attribute containing a URI for the resource it
locates. For example, this novel
element for The Wonderful Wizard of Oz contains
three locator elements that identify particular editions of the
book:
<novel xlink:type = "extended"> <title>The Wonderful Wizard of Oz</title> <author>L. Frank Baum</author> <year>1900</year> <edition xlink:type="locator" xlink:href="urn:isbn:0688069444" /> <edition xlink:type="locator" xlink:href="urn:isbn:0192839306" /> <edition xlink:type="locator" xlink:href="urn:isbn:0700609857" /> </novel>
Most of the time each locator element also has an xlink:label attribute that serves as a name for the element. The
value of this attribute can be any XML name that does not contain a
colon (i.e., that does not have a namespace prefix). For instance,
in the previous example, we could add labels based on the ISBN
number, like this:
<novel xlink:type = "extended">
<title>The Wonderful Wizard of Oz</title>
<author>L. Frank Baum</author>
<year>1900</year>
<edition xlink:type="locator" xlink:href="urn:isbn:0688069444"
xlink:label="ISBN0688069444"/>
<edition xlink:type="locator" xlink:href="urn:isbn:0192839306"
xlink:label="ISBN0192839306"/>
<edition xlink:type="locator" xlink:href="urn:isbn:0700609857"
xlink:label="ISBN0700609857"/>
</novel>The number alone cannot be used because XML names cannot start with digits. In this and most cases, the labels are unique within the extended link, but they don't absolutely have to be.
Locators may also have the optional semantic attributes
xlink:title and xlink:role to
provide more information about the remote resource and the link to
it. These attributes have the same meanings they have for simple
XLinks. The xlink:title attribute
contains a small amount of text describing the remote resource, and
the xlink:role attribute contains
an absolute URI that somehow indicates the nature of the link. For
instance, the edition elements
could provide the publisher's name in the title and use a Dublin
Core URI to indicate that the link is a formal identifier not meant
to be traversed like this:
<novel xlink:type = "extended">
<title>The Wonderful Wizard of Oz</title>
<author>L. Frank Baum</author>
<year>1900</year>
<edition xlink:type="locator" xlink:href="urn:isbn:0688069444"
xlink:title="William Morrow"
xlink:role="http://purl.org/dc/elements/1.1/publisher"
xlink:label="ISBN0688069444"/>
<edition xlink:type="locator" xlink:href="urn:isbn:0192839306"
xlink:title="Oxford University Press"
xlink:role="http://purl.org/dc/elements/1.1/publisher"
xlink:label="ISBN0192839306"/>
<edition xlink:type="locator" xlink:href="urn:isbn:0700609857"
xlink:title="University Press of Kansas"
xlink:role="http://purl.org/dc/elements/1.1/publisher"
xlink:label="ISBN0700609857"/>
</novel>Paths between resources are called
arcs, and they are represented by arc
elements; that is, elements of arbitrary type that
have an xlink:type attribute with the value arc. Each arc element should have an
xlink:from attribute and an xlink:to attribute. The xlink:from attribute identifies the source
of the link. The xlink:to
attribute identifies the target of the link. These attributes do not
contain URIs as you might expect. Rather they contain a name
matching the value of the xlink:label attribute of one of the
locator elements in the extended link.
Example 10-1 shows
an extended link that contains the first three novels in the Wizard
of Oz series: The Wonderful Wizard of Oz,
The Marvelous Land of Oz, and Ozma of
Oz. Arcs connect the first book in the series to the
second and the second to the third, and then back again. In this
example, the root series element
is the extended link element, each novel element is a locator element, and
the next and previous elements are arc elements.
Figure 10-1 diagrams this extended link. Resources are represented by books. Arcs are represented by arrows. However, although we can understand this link in this sort of abstract sense, it doesn't really tell us anything about how a browser might present the link to a user and how users might choose which links to follow. For instance, this extended link might be interpreted as nothing more than a list of the order in which to print these documents. All details of interpretation are left up to the application.
On occasion, a single arc element defines multiple arcs. If multiple
elements share the same label, then an arc element that uses that
label in either its xlink:to or
xlink:from attribute defines
arcs between all resources that share that label. Example 10-2 shows an
extended link containing locator elements for three different
online bookstores and one edition of The Wonderful
Wizard of Oz. Each bookstore element has the label buy, and a single purchase arc element connects all of
these. Figure 10-2
shows the graph structure of this extended link.
However, it is an error for more than one arc element to
define an arc between the same two resources, whether implicitly
or explicitly. For example, if an extended link contains N
resources and an arc element, such as <edition xlink:type="arc"/>, with neither an
xlink:to or xlink:from attribute, then it cannot
contain any other arc elements because this one arc element
defines all N2 possible arcs between the resources in the extended
link.
Each arc element may optionally have an xlink:title attribute, just like all other XLink elements. This
contains a small amount of text describing the arc, intended for
humans to read. For instance, in Example 10-1, we might give
these titles to the arcs:
<next xlink:type="arc" xlink:from="oz1" xlink:to="oz2"
xlink:title="Next" />
<next xlink:type="arc" xlink:from="oz2" xlink:to="oz3"
xlink:title="Next" />
<previous xlink:type="arc" xlink:from="oz2" xlink:to="oz1"
xlink:title="Previous" />
<previous xlink:type="arc" xlink:from="oz3" xlink:to="oz2"
xlink:title="Previous" />When processing an extended link, a browser might show the title to the user as the contents of a link so they could choose which arc they wanted to follow from their current position, or they might appear in a pop-up menu when the user was on one of the referenced pages. XLink does not require or suggest any specific user interface for arcs or arc titles.
Arc elements cannot have xlink:role attributes. However, an arc
element can have an xlink:arcrole attribute that contains an absolute URI identifying
the nature of the arc. More specifically, this URI should point to
a resource that indicates which relationship the arc describes
(e.g., parent-child, employer-employee). However, there's really
no way to validate this at all beyond checking to see that
xlink:arcrole does contain a
legal URI (and even that is not strictly required). For instance,
in Example 10-2 we
might add an xlink:arcrole
attribute to the purchase arc that pointed to http://www.example.com/purchase_details.txt.
<purchase xlink:type="arc" xlink:from="ISBN0192839306" xlink:to="buy"
xlink:arcrole="http://www.example.com/purchase_details.txt" />The file purchase_details.html might then
contain the text "will be bought from." This would indicate that
the source of the link is bought from the target of the link; that
is, "The Wonderful Wizard of Oz will be
bought from Amazon," or "The Wonderful Wizard of
Oz will be bought from Powell's." However, although
this usage is possible, XLink processors do not require it, and
indeed there's really no way they could be asked to do this since
that would require that they actually understand what they read.
The xlink:arcrole attribute is
optional. You don't have to include it on your arcs, and XLink
processors don't have to do anything with it even if you
do.
Locators represent remote resources; that is, resources that
are not part of the document that contains the extended link.
Extended links can also contain local resources in which the data is
contained inside the extended link element. Each such resource is
represented by a resource element , which is an element of arbitrary type that has
an xlink:type
attribute with the value resource. For instance, in Example 10-1, the series extended link element contains an
author child element. This can be
made a local resource simply by giving it an xlink:type="resource" attribute:
<author xlink:type="resource">L. Frank Baum</author>
A resource element can and generally does have the same
attributes as a locator element; that is, xlink:label , xlink:role
, and xlink:title
. These all have the same semantics as they do for
locator elements. For instance, the label is a name that arcs use to
connect resources. An arc can connect a resource to a resource, a
resource to a locator, a locator to a resource, or a locator to a
locator. Arcs really don't care whether resources are local or
remote. To link to or from this resource, an arc needs an xlink:label attribute, like this:
<author xlink:type="resource" xlink:label="baum">L. Frank Baum</author>
To establish links from this local resource to all the books, we'd simply add these three arc elements:
<book xlink:type="arc" xlink:from="baum" xlink:to="oz1" /> <book xlink:type="arc" xlink:from="baum" xlink:to="oz2" /> <book xlink:type="arc" xlink:from="baum" xlink:to="oz3" />
To move in the other direction, you'd simply reverse the
values of the xlink:from and
xlink:to attributes.
As you've seen, extended link elements, locator elements, arc
elements, and resource elements can all have xlink:title attributes that provide a short blurb of text
identifying the link. However, this isn't always enough. For
instance, in a document that was a rather large extended link, you
might want to mark up the titles using XHTML or some other
vocabulary. To this end, a title can instead (or in addition) be
provided as a title type child element, that is, an element whose
xlink:type attribute has the value title.
<edition xlink:type="locator" xlink:href="urn:isbn:0700609857"
xlink:title="University Press of Kansas"
xlink:role="http://purl.org/dc/elements/1.1/identifier"
xlink:label="ISBN0700609857">
<publisher_info xlink:type="title">
<ul>
<li>The Kansas Centennial Edition</li>
<li>Illustrated by Michael McCurdy</li>
<li>Foreword by Ray Bradbury</li>
<li>1999</li>
<li>216 pages</li>
<li>SRP: $24.95</li>
</ul>
</publisher_info>
</edition>What markup you use inside the title element is up to you as long as it's well-formed XML. XLink doesn't constrain it in any way; how the application interprets that markup is its own business. Here we've used basic HTML that a browser might perhaps be able to render. Once again, however, this is far enough past the bleeding edge that exact browser behavior, even when browsers do support extended XLinks, is hard to predict.