XLink [was: Re: SVG and MathML in text/html]

Doug Schepers wrote:
> Not well.  It was before my time.  My impression is that it was thought 
> that the XLink spec would define the fundamental linking aspect of the 
> Web to a whole host of XML languages, and that it would provide a 
> semantic and incrementally richer linking model with each revision, 
> without the dependent specs needing to change anything.  But then 
> browser development took a hiatus for a few years, and the whole plan 
> didn't live up to expectations.

Completely off-topic (hence the subject change), but I'd like to set the record 
straight here from a UA implementor point of view.

XLink 1.0 became a W3C Recommendation on June 27, 2001.

Looking at the Gecko CVS history, there were checkins to make actuate="onLoad" 
work for simple XLinks (with basic functionality working by then) back in May 
2000.  Between then and now, Gecko had a fairly complete simple XLink 
implementation.  It didn't matter much for most of that time, because no one 
used XLink except a few synthetic testcases.

Then we started trying to implement SVG and discovered that either many of the 
XLink uses in SVG contradicted the XLink specification or the XLink 
specification was a lot more vague about behavior than we'd thought.  Attempts 
to clarify the situation were unsuccessful: the SVG working group (correctly, in 
my opinion) passed the issue to the XML Linking working group.  The XML Linking 
working group answered e-mail about once every 6 months if we were lucky.

The net result is that most of the XLink use in SVG is a "black box" for Gecko. 
  For example, for <svg:img> we get the xlink:href attribute, but it could just 
as well be in any namespace and called anything.  We've had to special-case what 
we _do_ with it.  And if someone sticks a xlink:type="simple" on that image 
(which admittedly is not conformant SVG), then our generic XLink implementation 
might actually make us do the wrong thing (clicks on the image will traverse to 
the image URI).  Last I'd checked, the SVG working group was pretty clear that 
this was the wrong behavior.

Oh, and <svg:a> might not have an xlink:type, which is required in generic XLink 
for the node to be treated as a link, but needs to be treated as a link anyway 
per the SVG specification.

Given all that, our generic XLink implementation is absolutely useless for all 
aspects of SVG.  It's not used for anything SVG-related.

So we've had this code in our tree for going on 8 years now, and it's completely 
useless.  The one time we came close to having it actually used for something, 
it turned out that the spec was so vague that the generic implementation 
couldn't actually handle the ways people were using it, and that there was no 
sane way to write a "generic implementation" that would do said handling.

The net result is that the current plan is to just remove the generic XLink 
implementation whenever someone finds the time to do it.

Part of the problem is that the XLink spec really is very vague.  An xlink:href 
points to something, but XLink allows the consumer language to do whatever it 
wants with that pointing.  It might load a subresource and render it as an 
image, it might trigger a traversal on click, it might read metainformation from 
there, it might  reference another part of the same DOM for reading gradient 
information, etc, etc.  So in the end, a UA has to special-case every XLink 
usage.  All XLink tells the UA is that something is pointing to something else. 
  This might be useful for some sort of tool that doesn't know the document 
language and is trying to extract what information it can from the document, but 
for a UA trying to implement the language it's too vague to be useful.

> (It actually does 
> have some cool stuff, like extended links, role, and arcrole.  Just not 
> compelling enough for implementors, though, I guess.)

Part of the issue, as I said, is that the XLink spec just talks about these 
defining relationships.  It says nothing about what one would _do_ with these 
relationships: that's up to the embedding language.  So in a sense, there's 
nothing there for UAs to implement until some language is actually using this 
stuff.  At which point the UA would have to implement what that language says. 
And it could do that whether the language uses XLink or not.

So in the end, XLink provides a convenient framework for language creators, with 
a number of concepts that they can map onto specific parts of their language. 
But there's nothing there for a UA to implement other than the language that's 
using XLink.

This last is not just my conclusion, by the way, but pretty much matches the 
last official thing I heard from the XML Linking working group on the matter, 
one of the few times they deigned to respond to a query on the whole thing.

-Boris

Received on Saturday, 15 March 2008 18:13:19 UTC