Introducing HLink
September 25, 2002
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 |
|
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".