XML.com 
 Published on XML.com http://www.xml.com/pub/a/2000/09/xlink/index.html
See this if you're having trouble printing code examples

 

What Is XLink
By Fabio Arciniegas A.
September 18, 2000
"Only connect! That was the whole of the sermon"
                 -- E. M. Forster (1879 - 1970)

The very nature of the success of the Web lies in its capability for linking resources. However, the unidirectional, simple linking structures of the Web today are not enough for the growing needs of an XML world. The official W3C solution for linking in XML is called XLink (XML Linking Language). This article explains its structure and use according to the most recent Candidate Recommendation (July 3, 2000).

Overview

Every developer is familiar with the linking capabilities of the Web today. However, as the use of XML grows, we quickly realize that simple tags like <A HREF="elem_lessons.html">Freud</A> are not going to be enough for many of our needs.

Table of Contents

Introduction
An Example XLink
XLink Reference
  •The XLink Type Attribute
  •XLink Types: Use and
   Composition
  •Simple Links
Tools and References
Conclusion

Consider, for example the problem of creating an XML-based help system similar to ones used in some PC applications. Among other things (such as displaying amusingly animated characters), the system might be capable of performing the following actions when a user clicks on a topic:

Trying to code something like this (links with multiple targets, directions, and roles) in XML while having old "<a href..." in mind is confusing, and leads people to questions like the following:

In answer to these and many other linking questions, this article describes the structure and use of XLink. The article is composed of three parts: a brief example that illustrates the basics of the language, a complete review of the structure of XLink, and a list of XLink-related resources. The resources include some XSLT transformations that enable your HTML output to simulate required XLink behavior on today's browsers.

Table of Contents

Introduction
An Example XLink
XLink Reference
  •The XLink Type Attribute
  •XLink Types: Use and
   Composition
  •Simple Links
Tools and References
Conclusion

Before we start to dissect the structure of XLink, let's examine a concrete example.

The Artist/Influence problem

Suppose you want to express in XML the relationship between artists and their environment. This includes making links from an artist to his/her influences, as well as links to descriptions of historical events of their time. The data for each artist might be written in a file like the following:

   <?xml version="1.0"?>
   <artistinfo> 
    <surname>Modigliani</surname>
    <name>Amadeo</name>
    <born>July 12, 1884</born><died>January 24, 1920</died>
    <biography>
      <p>In 1906, Modigliani settled in Paris, where ...</p>
    </biography>
   </artistinfo>

Also, brief descriptions of time periods are included in separate files such as:

   <?xml version="1.0"?>
   <period> 
    <city>Paris</city>
    <country>France<country>
    <timeframe begin="1900" end="1920"/>
    <title>Paris in the early 20th century (up to the twenties)</title>
    <end>Amadeo</end>
    <description>
      <p>During this period, Russian, Italian, ...</p>
    </description>
   </period>

Fulfilling our requirement (i.e. creating a file that relates artists to their influences and periods) is a task beyond a simple strategy like adding "a" or "img" links to the above documents, for several reasons:

The XLink Solution

In XLink we have two type of linking elements: simple (like "a" and "img" in HTML) and extended. Links are represented as elements. However, XLink does not impose any particular "correct" name for your links; instead, it lets you decide which elements of your own are going to serve as links, by means of the XLink attribute type. An example snippet will make this clearer:

   <environment xlink:type="extended">
       <!-- This is an extended link -->
       <!-- The resources involved must be included/referenced here -->
   </environment> 

Now that we have our extended link, we must specify the resources involved. Since the artist and movement information are stored outside our own document (so we have no control over them), we use XLink's locator elements to reference them. Again, the strategy is not to impose a tag name, but to let you mark your elements as locators using XLink attributes:

   <environment xmlns:xlink="http://www.w3.org/1999/xlink" 
       xlink:type="extended">
       <!-- The resources involved in our link are the artist -->
       <!-- himself, his influences and the historical references -->
       <artist    xlink:type="locator" xlink:label="artist" 
             xlink:href="modigliani.xml"/>
       <influence xlink:type="locator" xlink:label="inspiration"
             xlink:href="cezanne.xml"/>
       <influence xlink:type="locator" xlink:label="inspiration"
             xlink:href="lautrec.xml"/>
       <influence xlink:type="locator" xlink:label="inspiration"
             xlink:href="rouault.xml"/>
       <history   xlink:type="locator" xlink:label="period"
             xlink:href="paris.xml"/>
       <history   xlink:type="locator" xlink:label="period"
             xlink:href="kisling.xml"/>
   </environment>

Only one thing is missing: We must specify how the resources relate to each other. We do this by specifying arcs between them:

   <environment xmlns:xlink="http://www.w3.org/1999/xlink" 
        xlink:type="extended">
        <!-- an artist is bound to his influences and history -->
        <artist    xlink:type="locator" xlink:role="artist"
              xlink:href="modigliani.xml"/>
        <influence xlink:type="locator" xlink:label="inspiration"
              xlink:href="cezanne.xml"/>
        <influence xlink:type="locator" xlink:label="inspiration"
              xlink:href="lautrec.xml"/>
        <influence xlink:type="locator" xlink:label="inspiration"
              xlink:href="rouault.xml"/>
        <history   xlink:type="locator" xlink:label="period"
              xlink:href="paris.xml"/>
        <history   xlink:type="locator" xlink:label="period" 
              xlink:href="kisling.xml"/>
        <bind xlink:type="arc" xlink:from="artist"  
              xlink:to="inspiration"/>
        <bind xlink:type="arc" xlink:from="artist"
              xlink:to="period"/>
      </environment>

As you can see, using XLink, our problem is reduced to creating an XML file full of elements like the above, where all the resources and their relationships are clearly and elegantly specified.

In this section we saw a small example of the use and syntax of XLink. In the next one, we will examine in detail the constructs and rules of this linking mechanism.

XLink Reference

Table of Contents

Introduction
An Example XLink
XLink Reference
  •The XLink Type Attribute
  •XLink Types: Use and
   Composition
  •Simple Links
Tools and References
Conclusion

Now that we have a basic idea of how XLink looks, it's time to dive into the details. This section presents all the constructs and rules contained in the XLink specification.

Basics

XLink works by proving you with global attributes you can use to mark your elements as linking elements. In order to use linking elements, the declaration of the XLink namespace is required:

       <my_element xmlns:xlink="http://www.w3.org/1999/xlink"> ...

Using the global attributes provided by XLink, one may specify whether a particular element is a linking element, and many properties about it (e.g., when to load the linked resources, how to see them once they are loaded, etc.). The global attributes provided by XLink are the following:

Type definition attribute

type

Locator attribute

href

Semantic attributes

role, arcrole, title

Behavior attributes

show, actuate

Traversal attributes

label, from, to

The next sections explain each of these attributes, their possible values and the rules that govern their use.

The XLink type attribute

The type attribute may have one of the following values:

By convention, when an attribute includes the type attribute with a value V, we will refer to it as a V-type element, no matter what its actual name is.

     <!-- bookref is a locator-type element -->
     <bookref xlink:type="locator" ...  

Two restrictions stem from the fact that an element belongs to a certain XLink type:

  1. Given an element of a particular type, only elements of certain types are relevant as XLink subelements.
         <!-- since A is a simple-type element, all the information
         it needs is on the href attribute. It would make no
         sense to have a locator-type subelement -->
    
         <a xlink:type="simple" href="monet.html"> ... no other
        xlink element would make sense here... </a>
    
  2. Given an element of a particular type, only some XLink attributes apply:
         <!-- since bookref is a locator-type element, it needs an href
         attribute to point to the external resource, but it
         would make no sense for it to have a from attribute, which
         is reserved for arcs. -->
         <bookref xlink:type="locator" href="ficciones.xml"/>    
    

The following two tables summarize the attribute and subelement restrictions of each type (they are included here as a reference, but each element will be properly explained later on). In Table 1, "R" indicates "required," and "O" indicates "optional." A blank space indicates an invalid combination. Table 2 shows which XLink elements are permitted which XLink subelements.

Attribute

simple

extended

locator

arc

resource

title

type

R

R

R

R

R

R

href

O

 

R

 

 


role

O

O

O

 

O

 

arcrole

O

 

 

O

 

 

title

O

O

O

O

O

 

show

O

 

 

O

 

 

actuate

O

 

 

O

 

 

label

 

 

O

 

O

 

from

 

 

 

O

 

 

to

 

 

 

O

 

 

Table 1 - Attribute usage (from the W3C specification)

Parent type

Significant child element types

simple

-

extended

locator, arc, resource, title

locator

title

arc

title

resource

-

title

-

Table 2 - Significant child types (from the W3C specification)

XLink Types: Use and Composition

Let's review each of the XLink types. To do this, we'll use an example of linking actresses and the movies they played in.

Resources (resource-type and locator-type elements)

The resources involved in a link can be either local (resource-type elements) or remote (pointed to by locator-type elements). For a rough equivalent in HTML, think of resource-type elements as "<a name..>" and locator-type elements as "<a href...>". The following code shows a DTD declaration of a resource element:

<!ELEMENT actress   (first_name,surname)>
<!ATTLIST actress
        xlink:type        (resource)       #FIXED "resource"
        xlink:title       CDATA            #IMPLIED
        xlink:label       NMTOKEN          #IMPLIED>
        xlink:role        CDATA           #IMPLIED

Note that the element has another two XLink-based attributes besides xlink:type. The first one, "title," is a semantic attribute used to give a short description of the resource. The second one, "label," is a traversal attribute, used to identify the element later, when we build arcs. The third attribute, "role," is used for describing a property of the resource.

An actress element may look like the following:

      <actress xlink:label="maria">
         <first_name>Brigitte</first_name>
         <surname>Helm</surname>
      </actress>

It is important to note also that the subelements of resource-type elements (here, the first_name and surname elements) have no significance for XLink (see Table 2).

As we mentioned before, remote resources are pointed to by locators. Here is the DTD for a locator-type element:

      <!ELEMENT movie             EMPTY>
      <!ATTLIST movie
              xlink:type        (locator)        #FIXED "locator"
              xlink:title       CDATA            #IMPLIED
              xlink:role      CDATA           #IMPLIED
              xlink:label       NMTOKEN          #IMPLIED
              xlink:href        CDATA            #REQUIRED>

Locators can have the same attributes as resources (i.e., title, label, and role), plus a required href semantic attribute, which points to the remote resource. A locator movie element will look like the following:

      <movie xlink:label="metropolis" xlink:href="metropolis.xml"/>

Navigation rules (arc-type elements)

The relationships between resources involved in a link are specified using arcs. Arc-type elements (i.e. those with xlink:type="arc") use the "to" and "from" attributes to designate the start and end points of an arc:

      <acted xlink:type="arc" xlink:from="maria" xlink:to="metropolis"/>

Aside from the traversal attributes "to" and "from," arcs may include the following:

Note that XLinks permit both inbound and outbound links. Outbound links are akin to normal HTML links, where a link is made from the current document to an external resource. An inbound link is constituted by an arc from an external resource, located with a locator-type element, into an internal resource.

The following DTD will illustrate the above attributes:

      <!ELEMENT acted EMPTY>
      <!ATTLIST acted
              xlink:type       (arc)           #FIXED "arc"
              xlink:title      CDATA           #IMPLIED
              xlink:show       (new | replace |
                                embed | other | none)
                                               #IMPLIED
              xlink:from       NMTOKEN         #IMPLIED
              xlink:to         NMTOKEN         #IMPLIED>

Putting together our resource and locator examples with this arc, we have the following snippet of an XML instance:

      <!-- A local resource -->
      <actress xlink:label="maria">
          <first_name>Brigitte</first_name>
          <surname>Helm</surname>
      </actress>

      <!-- A remote resource -->
      <movie xlink:label="metropolis" xlink:href="metropolis.xml"/>

      <!-- An arc that binds them -->
      <acted xlink:type="arc" xlink:from="maria" xlink:to="metropolis"/>

In order to encapsulate relationships like the above we need containers, that is, extended-type XLink elements

Extended links (extended-type elements)

Extended links are marked by the type "extended" and may contain locators (pointing to remote resources), local resources, arcs, and a title. The diagram below illustrates the composition of an extended link.

The Composition of an Extended Link

One can simply consider the extended-link elements as meaningful wrappers that provide a nest for resources and arcs:

<!ELEMENT divas (actress,movie,acted)*>
<!ATTLIST divas
        xmlns:xlink  CDATA      #FIXED "http://www.w3.org/1999/xlink"
        xlink:type   (extended) #FIXED "extended"
        xlink:title  CDATA      #IMPLIED>

Putting together all the previous elements, we finally have a complete and valid extended link. (Note in particular the one-to-many link that has been generated, something previously not possible in HTML.)

    <divas xlink:title="German divas 1920s">          
        <actress xlink:label="maria">
          <first_name>Brigitte</first_name>
          <surname>Helm</surname>
        </actress>

        <movie xlink:label="silent" xlink:title="Metropolis" 
               xlink:href="metropolis.xml"/>
        <movie xlink:label="silent" xlink:title="Alaraune"
               xlink:href="alaraune.xml"/>
        <acted xlink:type="arc" xlink:from="maria" xlink:to="silent"/> 
        ...
     <divas>

Title elements

An alternative way to provide titles to extended, locator, and arc type elements is by using a title-type subelement (xlink:type="title"). This was included in order to have a standard way for applications to express complex titles that include more than a string. (For instance, one might use multiple titles in different languages, to provide localization features.) The contents of title-type elements are not constrained by XLink.

Simple links

Simple links are, conceptually, a subset of extended links. They exist as a notation for links where you don't need the overhead of an entire extended link. All the XLink-related aspects of a simple link are encapsulated on one element (i.e., XLink doesn't care about the subelements of a simple link).

The valid XLink attributes of a simple link are "href" (just like in HTML's "a" or "img"), "title," "role," "arcrole," "show," and "actuate," which keep the same semantics as when used in arc-type elements.

The following shows a typical simple link element:

<!-- first, a DTD declaration -->
<!ELEMENT director (#PCDATA)>
<!ATTLIST director
    xmlns:xlink    CDATA       #FIXED "http://www.w3.org/1999/xlink"
    xlink:type     (simple)    #FIXED "simple"
    xlink:href     CDATA       #IMPLIED
    xlink:show     (new)       #FIXED "new"
    xlink:actuate  (onRequest) #FIXED "onRequest">
        
          ...
<!-- now, a typical instance -->
<director xlink:href="fincher.xml">David Fincher</director>       

That's all there is to it. We have covered all the types and attributes of XLink. As you can see, this is a powerful but compact specification that is bound to prove useful in future projects. We will wrap up by presenting some pointers to useful XLink tools.

Tools and references

The following is a (non-exhaustive) list of XLink-aware tools and references you might find useful for your projects:

  1. Mozilla M17 Browser (Mozilla). Open source browser with restricted XLink support
  2. Link (Justin Ludwig). A small, XLink-aware XML browser
  3. psgml-xpointer.el (David Megginson). A very useful extension to psgml for emacs that generates XPointer expressions
  4. Reusable XLink XSLT transformations (Fabio Arciniegas A.). This set of XSLT templates allow the transformation of extended links to HTML and JavaScript representations.
  5. The XLink Specification (W3C - July 3, 2000)
  6. XMLhack XLink news Latest XLink news and software releases.

Conclusion

XLink is a powerful and compact specification for the use of links in XML documents. This article has explored the structure and basic uses of XLink as described in the current W3C spec (July 3rd, 2000).

Even though XLink has not been implemented in any of the major commercial browsers yet, its impact will be crucial for the XML applications of the near future. Its extensible and easy-to-learn design should prove an advantage as the new generation of XML applications develop. For questions and comments, please contact the author.

XML.com Copyright © 1998-2006 O'Reilly Media, Inc.