Lists Home |
Date Index |
I've spent some time thinking about XLink, HLink, and why hardly anybody
likes either one enough to cough up an implementation.
My impression is that both XLink and HLink miss the 80/20 mark; both cover
an amazingly rich amount of ground for a version 1.0 specification. Nearly
everyone I talk to agrees that smaller, more understandable, more modular
specifications would be better. A smaller specification that leaves room to
grow might be a better approach.
Thinking along these lines, I proposed on www-tag a 'modest hyperlinking
proposal'  that consisted of only two attributes, 'href' and 'src', both
conveniently in the http://www.w3.org/XML/1998/namespace namespace. 'href'
links indicate the author's intent that a link should be presented to the
user for traversal. 'src' links indicate the author's intent that a link
should be automatically traversed and used to render the containing page. In
either case, a client is free to interpret the author's intention in any way
that makes sense.
With these attributes, arbitrary XML vocabularies could include the most
common kinds of hyperlink, for example:
<svg:image xml:href="linked_description.xml" xml:src="graphic.png"/>
One of my formative experiences with XLink was the May 1999 Scientific
American article, which sadly seems to have been removed from the official
site, though a few mirrors remain . That article had a terrific
illustration of how a multi-ended link could, through a context menu,
provide all sorts of useful functionality to a web user. I was somewhat
disappointed when HLink didn't address multi-ended links at all, and the
official XLink spec gave only vague references to how this would work.
This disappointment led to the idea that each arc could have a value called
a 'prominence', which could be used as a guide to determine how a pop-up
menu or any other representation of a multi-ended link could be prioritized
for presentation to a user. Another example: in a multi-ended link, the arc
with the highest prominence could be activated with a single click, while
arcs with lower prominences could reside on a context menu (or perhaps a
context sub-menu). Arcs with equal prominences mean the user has to make a
This proposal isn't perfect. It probably has too aggressively cut features.
In particular, there's no standardized way to associate a label with an arc,
which would cause problems when trying to actually construct a readable
context menu. It does, however, have the following advantages:
* Short and to the point. Sketches a data model for future linking efforts.
* Extremely amenable to learning and dissemination via 'view source'
* Provides an easy way to add multi-ended links to any language, notably
* Encourages element-based design, without interfering with modularization
But the point here isn't to be a complete solve-all-the-world's-problems
specification. The point is to encourage further discussion, which got off
to a great start at the hypertext town hall at XML 2002.
P.S. Extra thanks to Tim Bray for the skunks. :-)