Improving Web Linking Using XLink

The emerging XLink and XPointer standards could fundamentally change the way we use the Web, particularly how users interact with information. David Lowe and Dr. Erik Wilde take a look at some of the rich linking functionality these standards provide.

From the author of

The linking model that underpins the Web is an integral part of HTML and has
played a substantial role in supporting the incredible growth of the Web over
the last decade. The original model (a simple link from one piece of information
to another) was very simplistic, which led to much of its success. However, that
simplicity is now restricting the functionality that can be achieved with the
Web.

Much more sophisticated linking has been exhibited in a number of other
(usually standalone) hypertext systems. Many of these systems (and their
associated models) are indeed much older than the Web itself. The Web's
linking model was already outdated (in a technical sense) when it was created.
Some of the functionality can be enabled with the Webbut usually only with
complex nonstandard coding.

The emergence of XML and, in particular, the linking model that accompanies
itXLink and XPointerwill enable a much more sophisticated linking
model to be natively supported on the Web. In this article, we look at some of
the emerging possibilities that are enabled by XLink and XPointer.

We begin by considering typical link functionalities that are not possible
with the current Web. We then move on to look at how they might be supported
using XLink and XPointer. We finish with a typical scenario that highlights some
of these uses.

This article is not intended to be an introduction to XLink and XPointer.
Indeed, we assume a least a passing knowledge of these standards (though the
article should make sense even without this). Instead, the goal is to illustrate
how these standards can support more effective usability of the Web by providing
enhanced linking mechanisms.

Linking Functionality

The linking model that has underpinned the traditional Web model is very
simplistic. Essentially, the standard <A HREF="...">
link is a simple static, directional, single-source, single-destination link
that is embedded into the source document. It is static because the link
never changes (at least, not once it has been coded into an HTML page). It is
directional because the link has an explicit direction of association
(and, hence, usually has an explicit direction of navigation). It is
single-source because the link has only one point from which it can be
triggered. It is single-destination because the link has only one
resource to which the client traverses when the user activates the link. The
link is embedded into the source document (indeed, it is embedded within the
source anchor) because the description of the connection between the source and
destination anchors exists within the source anchor.

Even this simple model highlights a number of different linking
conceptswhich, in turn, indicate aspects that, if changed, can lead to
more complex and sophisticated linking. To start, we have
resourcesan addressable unit of information or service. In other
words, this is basically anything that we are able to request, including Web
pages, XML documents, images, audio clips, program outputs, and so on. A
resource (in the URI sense of the word) is not necessarily a computer-related
thing, but, at least conceptually, it could be anything you want to deal with,
such as paper documents or even animals.

By utilizing standards for addressing fragments of these things, we can also
treat fragments as resources. It is worth noting that Web standardsin
particular, RFC 2396distinguishes between addressing a whole resource
(referred to as an identifier, and typically implemented using universal
resource identifiers) and addressing a particular subresource (implemented using
resource type-specific fragment identifiers).

A resource (or subresource) can be used in various ways, but in the context
of this discussion, the most common use is related to linking. To do this, we
need to define the relevant regions of the resources (or resources themselves)
that are participating in a link. Within the context of a link, these regions
are referred to as anchorsor, in XML linking, they are referred to
as locators.

We also need to distinguish between links and arcs. This
requires an understanding of a third concept: traversal. In an HTML A
link, we have a single source anchor, a single destination anchor, and an
implied connection between them. When we view an HTML document and activate the
anchor (in most user interfaces, by simply clicking on it), the link is
traversed to the link destination. Other forms of linking in HTML work
differently. For example, the link between a document and an image (specified
using the IMG element) is traversed automatically when the document is
loaded, and the resultant image is embedded into the source. The link between a
document and a style sheet (specified using a LINK element) is
traversed automatically but does not result in any content being embedded. In
each case, the various link characteristics (such as how the traversal of the
link is initiated, the behavior upon traversal, and the specification of the
link semantics) are typically implicit for that link type.

The situation is somewhat differentand much more flexiblewith
linking in XML. XLink allows the definition of links, but a link does not imply
traversal! Instead, in XLink, a link is simply an association between a number
of resources (specified using locators). There is no link "source,"
nor is there a link "destination." This is because XLink has separated
the concept of associating resources (using a link) from the concept of
traversal among these resources. This traversal is specified using arcs.
A given link can contain a number of different arcs. Similarly, in many cases we
might not need to provide traversal informationespecially when the
association is being defined for a reason other than to support navigational
hyperlinking (for example, to define a collection of resources to be analyzed by
computer rather than to be viewed by a human user). We'll return to this
point again a little later in the article.

So, using the above concepts, we can identify a number of more sophisticated
forms of linking. For example, consider a situation in which we have a link that
has multiple participating resources, with an arc that starts from more than one
resource and ends on more than one resource. In other words, the arc traversal
can be activated from multiple different locations; when it is activated, it
results in the presentation of multiple new resources instead of just a single
resource. The result is a multisource, multidestination linksomething that
is not possible to easily implement using the simple linking model within
HTML.

We can also have dynamic links, with the destinations resource(s) resolved
only when traversal occurs. Specifically, a dynamic link has structure or
behavior that changes over time, or with different users or circumstances. These
changes can be with the link structure (such as changes in the link
destinations) or with the link semantics (such as whether the activation results
in the new resource replacing the existing content or being embedded in the
existing content). In the most common example of dynamic links, the link
destination is a service rather than a document, such as a CGI script. These
types of links can be important for supporting adaptive systems. For example, we
might want to change the destination of a link depending upon the pages a user
has previously visited. Although HTML has no inherent support for dynamic links,
it is possible to create them using server-side technologies such as CGI scripts
or servlets, possibly in conjunction with other technologies such as HTTP
cookies or URL rewriting.

A little more interestingly, generic links are links in which participating
resources are defined not by a specific location, but by a particular pattern
that can be matched to any relevant content. For example, we could have a link
from any occurrence of the word XML within a document to a definition of
the term XML.

This has several implications that are useful to look at briefly. The first
is that because the source anchor is defined for a particular pattern rather
than a particular location, it would be more accurate to refer to it as a
generic anchor (or generic subresource) than a generic link. Again, implementing
generic links with the conventional HTML linking model is very difficult (though
possible, given some complex back-end processing).

The above example illustrates some of the limitations of the existing HTML
linking modeland, hence, some of the potential areas that can be improved
with XML linking. We will now look in more detail at the XML linking model and
how it supports some of these concepts.