XLink Reference

September 18, 2000

Fabio Arciniegas A.

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:

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:

• simple: a simple link
• extended: an extended, possibly multi-resource, link
• locator: a pointer to an external resource
• resource: an internal resource
• arc: a traversal rule between resources

• title: a descriptive title for another linking element

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.

Table 1 - Attribute usage (from the W3C specification)

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:

• show: This attribute is used to determine the desired presentation of the ending resource. Its possible values are "new" (open a new window), "replace" (load the referenced resource in the same window), "embed" (embed the pointed resource -- a movie, for example), "none" (unrestricted), and "other" (unrestricted by the XLink spec, but the processor should look into the subelements for further information).

• title: Just as with resources, this is simply a human-readable string with a short description for the arc.

• actuate: This attribute is used to determine the timing of traversal to the ending resource. Its possible values are "onLoad" (load the ending resource as soon as the start resource is found), "onRequest" (e.g., user clicks the link), "other," and "none."

• arcrole: The advanced uses of arcrole (and its counterpart, the role attribute) are beyond the scope of this article. (Please refer to section 5 of the XLink specification for a discussion on linkbases). For our discussion, suffice it to say that this attribute must be a URI reference for some description of the arc role.

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.

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.