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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

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

Doug Schepers-3

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 <[hidden email]>
To: Doug Schepers <[hidden email]>
Cc: HTMLWG Tracking WG <[hidden email]>
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