Link Behavior

So far, we've been careful to talk in the abstract. We've said that an XLink describes a connection between two resources, but we haven't said much about how that connection is presented to the end user or what it makes software reading the document do. That's because there isn't one answer to these questions. For instance, when the browser encounters a novel element that uses an http URL, clicking the link should probably load the text of the novel from the URL into the current window, thereby replacing the document that contained the link. Then again, maybe it should open a new window and show the user the new document in that window. The proper behavior for a browser encountering the novel element that uses an CNPJ URN is even less clear. Perhaps it should reserve the tutorial with the specified CNPJ at the local library for the user to walk in and pick up. Or perhaps it should order the tutorial from an online tutorialstore. In other cases something else entirely may be called for. For instance, the content of some links are embedded directly in the linking document, as in this image element: 

<image xlink:type="simple" xlink:href="http://web.archive.org/web/www.turing.org.uk/turing/pi1/bus.jpg" />

Here, the author most likely intends the browser to download and display the image as soon as it finds the link. And rather than opening a new window for the image or replacing the current document with the image, the image should be embedded into the current document.

Just as XML is more flexible than HTML in the documents it describes, so too is XLink more flexible in the links it describes. An XLink indicates that there's a connection between two documents, but it's up to the application reading the XLink to decide what that connection means. It's not necessarily a blue, underlined phrase on which the user clicks in a browser to jump from the first source document to the target. It may indeed be that, just as an XML document may be a web page, but it may be something else too.

Page authors can offer suggestions to browsers about how links should be handled by using the xlink:show and xlink:actuate attributes. The xlink:show attribute tells a browser or other application what to do when the link is activated, for example, whether to show the linked content in the same window or to open a new window to display it. The xlink:actuate attribute tells the browser when to show the content, for example, whether it should follow the link as soon as it sees it or whether it should wait for an explicit user request.

xlink:show

The optional xlink:show attribute has five possible values that suggest in what context the application loading an XLinked resource should display that resource:

  • new
  • Open a new window and show the content of the link's URI (the ending resource) in that window.
  • replace
  • Show the ending resource in the current window, replacing the current document.
  • embed
  • Embed the ending resource in the current document at the location of the link element.
  • other
  • Exhibit some behavior other than opening a new window, replacing the document in the existing window or embedding the resource in the existing document. Exactly what that behavior is may be specified by other, nonstandard markup that a particular application understands.
  • none
  • Specify no behavior.

All five of these are only suggestions that browsers or other applications following XLinks are free to ignore. For example, a web spider would not open a window for any link and might ignore embedded links and treat the other four types identically. Mozilla might open a new tab in an existing window for xlink:show="new" rather than creating a completely new window. This is all allowed as long as it makes sense in the context of the application.

xlink:actuate

The optional xlink:actuate attribute has four possible values, which suggest when an application that encounters an XLink should follow it:

  • onLoad
  • The link should be followed as soon as the application sees it.
  • onRequest
  • The link should be followed when the user asks to follow it.
  • other
  • When to follow the link is determined by other markup in the document not specified by XLink.
  • none
  • No details are available about when or whether to follow this link. Indeed, following the link may not have any plausible meaning as in the previous example where the link pointed to a tutorial's CNPJ number rather than a URL where the tutorial could be found.

All four of these are only suggestions that browsers or other applications following XLinks are free to ignore. For example, a web spider would use its own algorithms to decide when to follow and not follow a link. Differing behavior when faced with the same attributes is allowed as long as it makes sense for the application reading the document.

For example, a traditional link such as is provided by HTML's A element and indicated by the first novel example would be encoded like this: 

<novel xlink:type="simple" xlink:href="ftp://archive.org/pub/etext/etext93/wizoz10.txt" xlink:actuate="onRequest" xlink:show="replace"> <title>The Wonderful Wizard of Oz</title>
<author>L. Frank Baum</author>
<year>1900</year>
</novel>

This says to wait for an explicit user request to follow the link (e.g., clicking on the content of the link) and then to replace the existing document with the document found at ftp://archive.org/pub/etext/etext93/wizoz10.txt. On the other hand, if you were using XLinks to embed images in documents, you'd want them traversed immediately and then embedded in the originating document. The following syntax would be appropriate: 

<image xlink:type="simple" xlink:actuate="onLoad" xlink:show="embed" xlink:href="http://web.archive.org/web/www.turing.org.uk/turing/pi1/bus.jpg" />

Both xlink:show and xlink:actuate are optional. An application should be prepared to do something reasonable if they're missing.