The Absent Yet Present Link
August 14, 2002
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 |
|
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.
Resources
- 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.