Introducing HLink
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".
- HLink should be part of XML Schemas, maybe?
2002-10-14 08:56:58 Scott Means
