HTML WG Last Call Comments, part 1 of 2

(My apologies for the formatting of the previous post: it looked different
on my screen... Hopefully this one is better)

This is part one of the last call comments for
http://www.w3.org/TR/2000/WD-xlink-20000221/

The HTML WG is splitting its comments into two parts: philosophical and
detail.

This part covers the philosophy of Xlink.

Best wishes,

Steven Pemberton
Chair, W3C HTML WG

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.