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

Hi, SVG and XLink Folks-

This was a comment sent to the HTML WG by a Mozilla implementor.  Their 
plans may be of interest to you.

Regards-
-Doug Schepers

-------- Original Message --------
Date: Sat, 15 Mar 2008 13:12:36 -0500
From: Boris Zbarsky <bzbarsky@MIT.EDU>
To: Doug Schepers <schepers@w3.org>
Cc: HTMLWG Tracking WG <public-html@w3.org>
Subject: 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 Sunday, 16 March 2008 16:53:06 UTC