XML.com: XML From the Inside Out
oreilly.comSafari Bookshelf.Conferences.

advertisement

When the first public XHTML 2.0 Working Draft was released in early August, one of the most common reactions, at least in the XML developer community, was to wonder why the HTML Working Group (HWG) wasn't using XLink. XHTML 2.0's refusal to use XLink as its hypertext linking layer was seen as its chief defect. Perhaps, if it isn't suitable or appropriate for use in XHTML 2.0, XLink hasn't any future at all? As early as the Final Call for comments on XLink, (members of the) HWG suggested that 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.

HLink

Whether or not its objections to XLink are germane or accurate, the HWG cannot be accused of idle sniping from the sidelines -- rather than waiting for XLink to evolve into something it could endorse, HWG took matters into its own hands and, as of 13 September, issued a first public draft of a linking specification, HLink: Link recognition for the XHTML Family.

On its face HLink is a very simple specification, even if, as Joe English and Tim Bray have noted, it amounts to a kind of rehabilitation of SGML's (infamously complex, as I recall) architectural forms extensions. The point of HLink is to provide a way of saying one or more of the following things: that (1) some elements or attributes within an XHTML markup language (or, better: within a namespace) are or can be treated as a hypertextual link; that (2) the functional semantics -- how the link behaves under various conditions -- are such and such; (3) that an attribute of some element which is a link has such and such effect on its semantics. Perhaps the most interesting aspect of HLink is that the accumulated attributes of the hlink element are largely taken from XLink, though additions are made so that HLink can model the XHTML links, too.

The HLink specification accomplishes all of this, again, in a very simple way. It first establishes a namespace,

http://www.w3.org/2002/06/hlink

and, second, declares two elements, hlinks and hlink. The former is semantically inconsequential and would be used only in an external (as the root element, basically just a container, of a resource representation pointed to by the URI value of an attribute, hlink:definition, of the root html element) HLink deployment scenario, not the internal one (as a set of hlink:hlink elements contained by head -- in other words, hlink:hlink elements are contained internally within an XHTML document by the head element, or they are contained externally, referenced by URI, in an hlinks element). The real workhorse here is hlink and its accumulation of various attributes and their semantics.

Link Properties

The HLink specification neatly divides the hlink attributes into two groups: first, the namespace-element pair and, second, all the rest, which are properties of element. The namespace attribute is required, element is optional. For example,

<hlink namespace="http://www.w3.org/1999/xhtml"
       element="a"
       ...>

which says that in the XHTML namespace, the a element is a link. The element attribute is optional; if absent, the other attributes are taken to be global properties of namespace. Finally, before we turn to the link-property attributes, HLink establishes an attribute-value convention. If the first character of the value of an attribute is a @, then the value of a link-property attribute is to be taken from the value of the attribute so named on the element being defined. In other words, for every link-property foo which has a value "@bar", the value of foo is just the value of the "host" element's bar attribute, where the "host" element is the value of hlink's element attribute. So,

<hlink namespace="http://www.w3.org/1999/xhtml"
       element="a"
       locator="@href"
       ...>

says that the value of the link-property, locator, is to be taken (in effect) from the value of http://www.w3.org/1999/xhtml:a's href attribute.

Some of the more notable link properties are as follows. The locator attribute specifies the URI reference of the link in question. The effect attribute says what effect is to be achieved upon actuating the link in question. It takes one of five possible values, the semantics of which are mostly what you'd expect: "new", "replace" (the default), "embed", "submit", and "map". The meaning of that last possible value, "map", is one I confess I don't particularly understand. The HLink specification says that a map locator points "to a resource that itself is a further link that describes how the presentation of the current link is to be interpreted as a series of links to further resources." Uh, okay, maybe it's just me, but an example of that would be very helpful.

The next link-property attribute, actuate, says how or when the link can be actuated, and it has three possible values: "onLoad", "onRequest" (the default), and "onRequestSecondary". For example,

<hlink namespace="http://www.w3.org/1999/xhtml"
       element="a"
       locator="@href"
       effect="replace" 
       actuate="onRequest"
       ...>

The mediaType link property specifies the media type of the resource being linked to; the value of this attribute is, presumably, one of the legal, registered MIME types; even though the HLink specification doesn't say that explicitly, I suspect that's an early draft wart which will be remedied eventually.

The onSuccess attribute, which has two possible values, "processChildren" (processing should proceed by looking at the children of the element) and "ignoreChildren" (which is the the default: processing should ignore children), specifies the kind of processing which should be undertaken after successful actuation of a link, where two conditions obtain: the value of effect is "embed" and the value of actuate is "onLoad".

The onFailure attribute is the inverse of onSuccess, with the same two conditions; the types of failure include network failure, missing link resource, or user agent inability to process the link resource, because of the value of mediaType or some other reason. onSuccess has two possibile properties, "warn" and "fail", in addition to process- and ignoreChildren. A value of "warn" says that the user agent should continue but must signal the user that actuation has failed; a value of "fail" says that processing should abort.

HLink specifies the XLink link properties: arcrole, label, from, to. It also specifies some link properties I'm not going to discuss further: replacement, role, reverseRole, shape, and coords.

Putting several of these attributes together, the HLink specification models several kinds of link element, including XHTML img:

<hlink namespace="http://www.w3.org/1999/xhtml"
       element="img"
       locator="@src"
       effect="embed"
       actuate="onLoad"
       onFailure="warn"/>
<hlink namespace="http://www.w3.org/1999/xhtml"
       element="img"
       locator="@longdesc"
       effect="new"
       actuate="onRequestSecondary"/>
<hlink namespace="http://www.w3.org/1999/xhtml"
       element="img"
       locator="@usemap"
       effect="map"
       actuate="onLoad"/>

Interestingly, HLink also allows the creation of content-domain and site-specific link constructs; for example, a home element:

<hlink namespace="http://www.example.com/markup"
       element="home"
       locator="/"
       effect="replace"
       actuate="onRequest"/>
<hlink namespace="http://www.example.com/markup"
       element="home"
       locator="/icons/home.png"
       effect="embed"
       actuate="onLoad"/>

Widespread support for that kind of easily extensible markup construct would open up interesting possibilities, including the easing of site maintenance and the creation of sets of navigable icons exported by popular, complex, or any other second party sites. Imagine, for example, Yahoo or CNN or IndyMedia.org creating packages of navigable link icons, which site creators would be free to make available in their own XHTML markup using the external deployment scenario described above.

Also in XML-Deviant

The More Things Change

Agile XML

Composition

Apple Watch

Life After Ajax?

Whether HLink can succeed, either where XLink appears to have failed, at least with regard to XHTML 2.0, or in gaining the widespread approval of the XML developer community, remains to be seen. Tim Bray puts the design trade-offs nicely. With HLink

you can have the semantics of XLink without having to have all the markup explicitly there. The price you pay is that your instance is less self-descriptive and requires a bit more complexity in processing. Not a hard trade-off to understand. My personal design bias is for highly self-descriptive and simple-to-process markup, but I recognize that this feeling may not be universal.

For an interesting slant on some of the thinking behind HLink and XLink, read Micah Dubinko's dialogue, "A Hyperlink Offering".



1 to 1 of 1
1 to 1 of 1






close