10.4. Extended Links
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.
Simple links are very easy to understand by analogy with HTML links.
However, there's no obvious analogy for extended
links. What they look like, how applications treat them, what user
interfaces present them to people, is all up in the air. No simple
visual metaphors like "click on the blue underlined
text to jump to a new page" have been invented for
extended links, and no browsers support them. How
they'll be used and what user interfaces will be
designed for them remains to be seen.
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, that 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, that 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.
10.4.2. Arcs
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.
Example 10-1. An extended link with three locators and four arcs
<series xlink:type="extended" xmlns:xlink="http://www.w3.org/1999/xlink">
<author>L. Frank Baum</author>
<!-- locator elements -->
<novel xlink:type="locator" xlink:label="oz1"
xlink:href="ftp://archive.org/pub/etext/etext93/wizoz10.txt">
<title>The Wonderful Wizard of Oz</title>
<year>1900</year>
</novel>
<novel xlink:type="locator" xlink:label="oz2"
xlink:href="ftp://archive.org/pub/etext/etext93/ozland10.txt">
<title>The Marvelous Land of Oz</title>
<year>1904</year>
</novel>
<novel xlink:type="locator" xlink:label="oz3"
xlink:href="ftp://archive.org/pub/etext/etext93/wizoz10.txt">
<title>Ozma of Oz</title>
<year>1907</year>
</novel>
<!-- arcs -->
<next xlink:type="arc" xlink:from="oz1" xlink:to="oz2" />
<next xlink:type="arc" xlink:from="oz2" xlink:to="oz3" />
<previous xlink:type="arc" xlink:from="oz2" xlink:to="oz1" />
<previous xlink:type="arc" xlink:from="oz3" xlink:to="oz2" />
</series>
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,
this doesn't really tell us anything about how a
browser might present it 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.
Figure 10-1. An extended link with three resources and four arcs between them
10.4.2.3. Arc roles
Arc elements cannot have
xlink:role attributes. However, an arc element can
have an xlink:arcrole
attribute that contains an absolute URI pointing to a description 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 the URL 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 Fatbrain," or
"The Wonderful Wizard of Oz
will be bought from Barnes & Noble." However,
although this usage is suggested, XLink processors will not enforce
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.
10.4.3. Local Resources
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. This 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
easily 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 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, it
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.
10.4.4. Title Elements
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.
For example, suppose you wanted to provide a more complete
description of each edition of The Wonderful Wizard of
Oz than simply who published it. Then you would give the
edition element a title type element containing
any convenient markup like this:
<edition xlink:type="locator" xlink:href="urn:isbn:0700609857"
xlink:title="University Press of Kansas"
xlink:role="http://www.kansaspress.ku.edu/"
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.
 |  |  | 10.3. Link Semantics |  | 10.5. Linkbases |
Copyright © 2002 O'Reilly & Associates. All rights reserved.
|