Re: Agenda Request: @xlink:href, @href, @src, @data, @target, etc.

Hi, Dr. Olaf-

Dr. Olaf Hoffmann wrote (on 1/25/10 11:12 AM):
>
> the main advantage I can see is, that authors have not to provide a
> namespace. If all attributes from XLink are specified in SVG, just the
> notation of the attribute name is slightly shorter.
> Are there other significant advantages?

That is one advantage.  Another is ease of learning; authors already 
familiar with HTML will expect the same syntax, and this lowers the 
barrier for using SVG.  Another advantage is that it avoids the 
copy-paste problem, where a namespace declaration may be in another part 
of the document than the attribute prefix is used, and copying just the 
attribute usage will confound new users.  Yet another problem avoided is 
the serialization problem with namespace prefixes that I suffered from 
even back when I used ASV, where.  Then there is the problem of all the 
related XLink attributes, which merely confuse most authors in their 
details and how they may modify xlink:href (needlessly, since SVG 
doesn't really use them, except for @xlink:title).  Finally, XLink is 
not a precise enough specification for clear implementation, leading to 
increased risk of non-interoperability.

Put together, all of these little things add up to a steeper learning 
curve and more error-prone development even for experts.  If there 
really were a major advantage to XLink, such as a strong network effect 
with other languages using it, or if it added functionality to SVG, it 
would be worth the overhead, but as it stands, it is a net loss.

Despite saying all this, I think the SVG spec did the right thing at the 
time it was being developed... had XLink been a better spec, and had it 
been more widely used (like in XHTML), and had it added functionality, 
and had it been updated to track new requirements, it would have been 
worth keeping.  As it is, it is simply clumsy and adds no concrete value 
to SVG.


> Disadvantages: Backwards incompatibility with older viewers and
> documents and problem for authors to provide both notations or
> to decide to address only old viewers or new viewers.

Yes, this is a very real problem, as it is with any new or changed 
feature; this is the normal risk involved in changing or growing a 
technology.  We are communicating with the various implementers to 
encourage them to update their implementations (luckily, this particular 
change would be fairly simple to implement).

One thing that would help older implementations is a script lib that 
updates elements appropriate to the implementation (see my trivial 
example [1]), or an XSLT script or Scour extension to do the same for 
authoring tools.


> Even more, if more viewers come up interpreting the new
> syntax, authors of older documents maybe have to consider
> to update millions of documents and scripts, if such a new
> specification does not indicate, that the old XLink notation is
> still ok and must be interpreted by viewers.

See above.  As mentioned elsewhere, the number of documents authored up 
to this point will be dwarfed by those to come.


> Another disadvantage - the probability of proper implementations
> of XLink decreases, what is a downside for other XML formats
> using this too and for documents with mixed formats, which
> can profit from only one hyperlinking functionality for all the
> formats used in one document.

This may be due to flaws in the XLink spec and the lack of uptake of 
XLink among technologies related to SVG in a meaningful way.


> If you add more aliases for XLink:href like href, src, data this
> blows up the vocabulary, an author has to keep in mind for SVG,
> without real benefits of significant different functionality.

But decreases the number of differences between HTML and SVG that an 
author has to keep in mind.  Here is a rule of thumb: @src for inbound 
linking, @href for outbound linking, and when in doubt, an author can 
always use @xlink:href.


> We have seen already the problem with the generic xml:id
> compared to the language specific id - no real solution for
> compound documents and the generic attribute is not
> implemented in several viewers because there is a specific
> attribute with the same purpose.

@xml:id was, in my opinion, a demonstration of the wrong way to approach 
the problem.  Rather than making the commonly understood solution, @id, 
work everywhere, it tried to impose a new attribute that would have made 
implementations and authoring more complex, and wasn't backwards 
compatible with the common case (HTML).


>To introduce a format specific
> syntax for hyperlinking can have even more dramatic effects
> in the future for the acessibility of older documents with newer
> viewers - or vice versa the accessibility of new documents with
> older viewers.

See above.


> I think, the weight of the disadvantages is much bigger than
> the advantage of shorter attribute name notations and having
> no extra namespace for XLink - there is still one to note for
> SVG itself ...
> If an author uses foreignObject, this is typically related to
> other namespaces too.
> I think, you cannot save people from namespaces in SVG
> anyway, therefore it is not much simpler, if XLink is removed.

This isn't only about namespaces... it's about expected syntax and 
behavior.  HTML already set a precedent long about about the syntax for 
attributes for <a> and <img> and <script> elements, and where possible 
it will be good for SVG's learnability to adopt those conventions just 
to save authors from gotchas.  I think SVG has a much better model than 
HTML in many ways, and I don't want to abandon those, but I don't think 
the use of XLink is one of the ways in which it's better.



> The use of a general hyperlinking mechanism like XLink is
> more an indication for a modern language with the
> possibility to mix with (arbitrary) other XML languages
> (in difference to HTML for example). Because XLink is
> widely used and it is documented, how to use it, this might
> even help new authors to understand the concept of
> namespaces and what it means if there appear others
> for example in relation to RDF or in outputs of inkscape.

That's true, it did help me to do so.  But authors will learn about 
namespaces just as easily (and perhaps more easily) by mixing SVG and 
XHTML.  I don't want to sacrifice SVG's learnability and ease of use 
just for the sake of an object lesson.


> Following this chain of arguments, it does not really help
> new SVG authors to remove XLink, it moves just the time of
> confrontation with namespaces a few hours or days in the future
> for them.

In my view, those lessons will be more easily learned when mixing 
multiple presentational or logical markup languages (stuff you can see) 
than an abstract and obscure meta-linking languages like XLink, which is 
not used anywhere else in the common Open Web stack, just in languages 
like RDDL, METS, and (*shudder*) XBRL.


> As can be seen with HTML5 - if a format is too self centric,
> there are much more problems to improve/extent it or any
> improvement has the tendency to reinvent the wheel
> (but with corners ;o)

That was the problem with using XLink, which we are trying to correct.

Lest I seem too harsh on XLink, I actually like a lot of the aspects of 
the spec, many of the concepts, and the general idea of a common linking 
language.  I think in many ways, it simply didn't go far enough to offer 
novel functionality, and it wasn't literal enough in how it suggested 
being used.  It wasn't a terrible spec for the time, but standards for 
standards have outgrown it.


[1] http://schepers.cc/svg/xlink/exxlink.svg

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Received on Tuesday, 26 January 2010 23:42:18 UTC