XLink Basics

To the uninitiated, XML can often seem more trouble than it's worth. There's the complex jargon, the fundamentally different design principles, the confusing array of technologies, each with its own unpronounceable acronym, and - probably the most annoying aspect - the long and convoluted specifications, most of which immediately induce drowsiness and deep sleep...

Once you've figured out the basics, though, and played with the tools a little - even if it's something as simple as marking up your to-do list and transforming it with XSLT - it quickly becomes obvious that this is a technology with tremendous potential. By providing a set of rules for data description, together with the technology necessary to transform and present this data, XML opens up whole new possibilities for better (read: more efficient) data interpretation, usage and exchange.

Now, while these applications are certainly not restricted to the Internet, the Web is still XML's most potent proving ground. And if XML is to succeed on the Web, it needs to find a way to incorporate the most fundamental construct of the wired universe - in fact, the very thing that makes the Web so powerful.

Links.

Luckily, you and I are not the only people in the room who've realized this. The guys who came up with XML know it too, and they've expended an enormous amount of time, energy and brainpower on coming up with a way to link XML data and documents together. It's called XLink, and it's easily one of the most interesting pieces of the XML jigsaw. Keep reading, and I'll tell you why.{mospagebreak title=Out With The Old...} Before getting into the details of how XLink works, it's important to understand the context in which it was developed, and the need and rationale behind it.

You already know that HTML comes with a way to link documents together - it's called the anchor tag, and it's the standard way of creating connections between different pieces of information in today's version of the Web. However, although the anchor tag is simple to understand and easy to use, it has a couple of drawbacks:

1. Every HTML link connects a single source to a single destination; it's not possible to have a single link point to multiple destinations.

2. Only specific, pre-defined HTML elements - the <A> tag, for example - can serve as links.

3. The definition of a link (the location it points to) cannot be separated from its source (the file in which it is contained.) Or to put it another way - you can't create a link without write permission to the source document.

These drawbacks might seem trivial in the context of today's Internet - it ain't broke, you're probably thinking, so why fix it? - but they assume serious proportions in the context of an XML world, which is built around data and the relationships inherent in it.

XLink was designed to address these drawbacks.

If you take a look at the requirements document for XLink - it's available online at http://www.w3.org/TR/NOTE-xlink-req - you'll see that XLink was designed to represent links in an abstract yet easily-understandable and usable manner. To this end, the XLink specification states the XLinks must:

- be defined using standard XML constructs, and follow the rules of well-formed XML;

- be human-readable;

- express information on the nature of the link (the type of link, its title and destination, or its endpoints) as well as its behaviour (the rules by which a link processor can access or traverse the link);

- support multiple destinations;

- allow link authors to define link endpoints and traversal rules without requiring write access to either the source or destination resource;

- provide constructs to allow link authors to control the direction of travel between links;

- maintain compatibility with existing HTML4 linking constructs.

>>> More XML Articles          >>> More By Vikram Vaswani, (c) Melonfire

blog comments powered by Disqus