Describing Linking on the Web

Steven Pemberton

One of the major advantages of moving from HTML to XML-based languages on the Web is the ability to define your own tags to meet the needs of your application.
The concomitant disadvantage is that we lose the in-built semantics that we have been able to profit from over the years of using the Web: if people use new tags, we don't know what they are meant to represent.

For presentation semantics luckily we already have CSS. This is a perfect technology for its task, because you don't have to change a document in order to describe its presentation, and you can change the presentation without changing the document too. So regardless of the document type of a Web page, we can still view it without change.

Another important semantic of a web page, perhaps the most important after presentation, is linking. What is needed is a sort of 'Linking Sheets for the Web': a way to tell generic XML application which attributes represent a link, and how to interpret them. There are many different sorts of application that can benefit from such a description:

	* search engines can continue to do their work and follow all the links on a page 	  regardless of the document type of a Web page;

	* browsers can still know where to let you click;

	* a link-checker program can still verify that all links point somewhere;

and so on.

Xlink apparently started off as a link description language (though with some shortcomings) by allowing you to describe one linking attribute per element. Although this meant that you couldn't use it to describe linking in languages that have more than one URL per element, such as HTML, or the WAP Markup language WML, or SMIL, it was a step in the right direction.

However, sometime in 1999, Xlink stopped describing linking, and started being it. This is a major change, because all of a sudden you are forced to change your documents if you want to use Xlink, even though the current Xlink draft still claims it is a requirement that documents not need to be changed.

Another result of the change from description to namespace is there is no way you can use it to describe the millions of pages that are already on the Web; nor can you use it after the fact when you realise that something can usefully be a link, even though up to now it hasn't. For instance, a travel application may have documents with elements of the form:

	<train from="London" to="Paris"/>

or a calendar application may have elements of the form:

	<event start="2000-04-21" end="2000-04-24">Easter</event>

Later it might occur to the designers that the 'from' and 'to' attributes or the 'start' and 'end' attributes, could usefully be links, pointing to a description of the day, or of the city. With link *description* all you need to do is add this fact to the description; your documents remain unchanged. With a linking namespace, you would have to go and change all documents.

A Linking Namespace is useful

Xlink is now an XML namespace that allows various types of linking. This in itself is useful: people don't need to reinvent the wheel if they want to do linking in a new document type, and the new types of linking the Xlink namespace allows are sure to prove very useful.
However, we are still left with the problem of what to do with the general problem: how do we describe linking on the Web.

How can we save the situation?

One option would be to reject Xlink on the grounds that it doesn't meet the basic requirements (which it doesn't). However Xlink has been such a long time coming that to delay it further would be unfortunate.

Another option would be to build a description mechanism on top of Xlink, using the same 
values as the Xlink namespace attributes. The following is a sketch of one possible solution, though others are possible, and have been suggested.

1. Linking elements are identified using XML (As per requirement 4: The XLink expression language must be XML.) Attributes are as defined in Xlink. Here is an example that describes the <a> and <img> elements of XHTML 1.0: 

<xlink> 
        <element name="a" type="simple">
              <link name="href" show="replace" actuate="onRequest"/>
        </element>
        <element name="img" type="simple">
              <link name="src" show="embed" actuate="onLoad"/>
              <link name="longdesc" show="new" actuate="onRequest"/>
        </element>
</xlink>

2. Such a linking description is available via a standard URL, such as http://www.w3.org/Linking/xhtml1. 

3. DTDs then assert the existence of such a description with a standard attribute, xmllink, on the root element:
<!ATTLIST html
           %i18n;
           xmlns   %URI;   #FIXED   'http://www.w3.org/TR/xhtml1'
           xmllink %URI;   #FIXED   'http://www.w3.org/Linking/xhtml1' >

4. Documents of other types can use that standard linking definition as well: 
<myhtml xmllink="http://www.w3.org/Linking/xhtml1"> ... </myhtml> 

5. Or they can include definitions or overrides in a document instance :
<myhtml>
     <head>
              <xlink xmlns="http://www.w3.org/TR/xlink">
                       <element name="a" type="simple">
                              <link name="href" show="replace" actuate="onRequest"/>
                       </element>
                       <element name="img" type="simple">
                               <link name="src" show="embed" actuate="onLoad"/>
                               <link name="longdesc" show="new" actuate="onRequest"/>
                       </element>
              </xlink> 
... 
</myhtml> 

Conclusion

Xlink does not meet the basic requirements it set itself, nor of its 'customers', and as such is insufficient for the needs of the future web. Any linking proposal that requires documents to be changed in order to use linking is not suitable. The proposal here would leverage the current Xlink proposal to create a description language that does meet the original requirements, without needing too much extra work or time.