The Absent Yet Present Link
When all is said and done, XHTML is one of the most important W3C specifications because, in principle, it affects the greatest number of users -- at least that's the theory. XHTML, like RDF, is still more often talked about and evangelized than it is actually used, but there are good reasons to think that it will eventually catch on. Which means that the continual evolution of XHTML is a key element of the future health of the Web as a means of intra-human exchange.
In last week's column, " XHTML 2.0: The
Latest Trick", I described the next step in the evolution of
XHTML, at least according to the 5 August XHTML 2.0 working
draft. The big changes include the addition of navigation lists;
significant changes to the way sections are conceptualized,
including a real
section container element and an unordered
section title or heading element (
h); deprecation of
br in favor of
line, and of
applet in favor of
object; and the addition of
href to every XHTML element.
As is often the case, however, reaction to a new W3C specification, even a very early draft, exposed a venerable, enduring fault line in the XML world, namely, the split between XML users and XML core developers. In this case, we'll let the former be represented by the weblogging community, the latter by the XML-DEV list. Of course, this division is mostly a fiction, a little heuristic I'm using to make a larger point, but it's not entirely divorced from reality.
In trying to measure reaction to the XHTML 2.0 draft, my Web
wanderings made two things plain. First, the weblogging community
focused its attention equally on the big XHTML 2.0 changes, the
community being, on average, about as interested in navigation lists
as in the deprecation of
img and the apotheosis of
href. That's just about what one might expect: many
webloggers still write a considerable amount of HTML by hand, and a
respectable percentage of them are committed to public standards,
are early adopters of XHTML, and, in general, junkies of all things
Web. Any significant changes to XHTML, including major deprecations
and additions, are going to get the attention of this crowd, and for
Second, for the hard-core XML-specification junkies -- the ones who not only know and regularly use, but often are the very first to use all those specification acronyms -- the nonpareil XHTML 2.0 issue is the absence of XLink. In fact, a kind of strange trick played itself out: the absence of XLink was so conspicuous, was felt so strongly by so many, that XLink became a kind of absent presence. Because it was absent from the XHTML 2.0 draft, discussion about that absence, what it might signify or portend, dominated the discussion of XHTML 2.0 on the XML-DEV list. Thus, its absent presence provoked many of XML development community's familiar concerns about specification coherence, interdependence, refactoring, and the like.
The Question of XLink
Perhaps the most common reaction to the possible ubiquity of
href was simply to wonder why the XHTML Working Group
hadn't decided to use XLink. Many XML developers seemed to be
wondering whether, if it wasn't suitable or appropriate for use in
XHTML 2.0, XLink had any future at all. Andrew Watt was one
of the first people to raise
the issue: "XLink 1.0 already defines linking attributes, which
can be placed on any XML element, not just XHTML elements. We... appear to have two... hyperlinking
technologies intended for use on some or all XML elements". Uche Ogbuji suggested that one
reason XML junkies are not getting behind XHTML 2.0 is that "layered
technologies are a good thing, and that a lack of layering is reason
for loud challenge". That is to say, XHTML 2.0 has provoked a loud
response because of "its refusal to layer with XLink".
No XML-DEV conversation would be complete without the inclusion of
namespaces. In the case of XHTML 2.0 versus XLink, some developers
took the position that since XHTML already uses namespaces, the
objection that using a namespaced
xlink:href) over a "bare"
href wasn't a
consistent objection. The typical response pointed out that linking
is in some way intrinsic to HTML, that namespaces are a fine
implementation tool, but that many, if not most potential XHTML 2.0
users will find them off-putting. Namespaces are
off-putting to most potential users of XHTML 2.0; we would do well
to remember that XHTML 1.0's well-formedness constraints are part of
the obstacle to its wider acceptance.
It stands to reason, then, that if namespaces prove to be an even
larger obstacle than well-formedness, the widespread success of
XHTML 2.0 really is a long-term proposition. But that conjecture
matter how well-grounded, isn't sufficient to decide the issue of
href should be a bare (because its part of XHTML's
CAC) or namespaced (because its taken from XLink) attribute in XHTML
2.0. Further, members of the XHTML Working Group object that the
href is not the reason it isn't using
XLink. They say that, in part, they're not using XLink because
rather than describing linking constructs for other markup
languages, XLink became the linking constructs. As the HTML
Working Group put it way back in 2000 in its
XLink Last Call comments:
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.
So, what's the technical way forward? Norm Walsh, in a comprehensive
and elegant post,
suggested that there are seven possibilities. First, abandon the
idea of a universal linking language; or, in Norm's words, give up
"the ability to write applications that unambiguously (and without
heuristics) recognize links in vocabularies about which they do not
have domain-specific knowledge". Second, take XHTML's
as the universal sign of a link and hope for the best, a kind of
capitulation to the status quo. Third, bite the bullet and use XLink
as is, even if that means XHTML does not use it. The next four
possibilities are all variations on the "fix XLink" theme. So,
fourth, add an
xlink:href-name attribute to XLink. Fifth,
xlink:???-name attributes to XLink, in which case each
link attribute that XLink gets can be renamed per element. Sixth,
"fix" XLink by tossing it out the window and starting over from
scratch, "using elements instead of attributes", as Norm says. Last,
still throw XLink out the window and do something altogether
different: perhaps, as Norm suggests in another
post, supplement the infoset with linking information.
Lying behind or beside the technical issues may well be a matter of internal W3C politics or, even more frustrating, a big pile of hurt feelings. There is some indication that the XHTML Working Group purposefully avoided the use of XLink because the XLink Working Group abandoned its mandate to support HTML 4.0 linking constructs, this in addition to the aforementioned objections to XLink. The point isn't to make either working group solely responsible for the present mess. There is blame enough to go around.
Also in XML-Deviant
As is often the case, the technical and the social interpenetrate each other in a kind of warp and weft, which can make things hard to sort out. Suffice it to say that if XLink (or, for that matter, XPointer) is absent from XHTML 2.0 because of rivalry or ill will between various W3C Working Groups, that would constitute a rather embarrassing process failure for the W3C; it's the sort of thing that concerned citizens of the Web should reject clearly and unambiguously. You should expect that this issue will end up as a TAG working item in the not-so-distant future.
- XLink 2.0 Requirements: XML-DEV thread.
- XML Needs Credible Linking: XML-DEV thread.
- XLink Olden Days: XML-DEV thread.
- When Should I Use XLink?
- xlink:href: By way of background, a www-tag thread from early July 2002.