Improving Web Linking Using XLink
- Linking Functionality
- XLink and XPointer
- Linking Scenario
- Conclusions
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
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.