The Absent Yet Present Link

August 14, 2002

Kendall Grant Clark

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 img and 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 good reason.

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 href (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 alone, no matter how well-grounded, isn't sufficient to decide the issue of whether 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 namespaced 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 href 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, add 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

The More Things Change

Agile XML


Apple Watch

Life After Ajax?

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.