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

Francis Hemsher:
> Hi Dr O, and Boris,
>  I don't know of any SVG applications by developers that have used the
> linking capabilites of XLink in the many years it has been available.
> Can someone point me to some current projects that use it?
> I'd want to look at them to assure myself that my support to axe
> xlink:href was not too hasty;)
>
> Thanks,
> Francis

Every time you write xlink:href in SVG, you use it, typically for elements
like a, image, use, animate, animateTransform, animateMotion, set,
in SVG tiny 1.2 animation, audio, video, several more.

I think, the use of XLink for other applications may appear more in 
compound documents, just because those use XLink for a hyperlinking 
mechanism (I have seen it for example for the format FictionBook,
typically for hyperlinks and images), alternatively to switching to the 
XHTML or DAISY etc namespace.

If someone simply removes the prefix, this will typically not work
anymore. Due to the bug, Doug already mentioned, in the adobe
plugin it will not even work, if you define a different prefix than 'xlink'
for XLink attributes. I think, there is a similar and surprising restriction
noted for SVG in HTML5 as well in the HTML5 draft.
Therefore authors have to be careful. Up to now, the basic XLink 
functionality/notation as used in SVG works good in most viewers 
with a noticable support for SVG.
If only the type of notation changes, this will/can be a source of new 
problems for authors due to different implementations, implementation
gaps. What might look in theory as a nice simplification for author can
cause a lot of more work for 5 or 10 years after such a new notation
of an already established functionality is introduced.
And because we can expect, that many authors do not want to do
much extra work, this has consequences for the audience too.
This can be the source of more indications of 'Best viewed with ...'
again, just because authors want to keep it simple in one or the
other way.

The problem is not, that XLink itself is pretty useful for SVG or
that XLink itself is not good implemented. The problem is, that
only this notation like 'xlink:href' works in almost all current viewers 
and nothing else. For many viewers now one could define another
prefix, but not for the adobe plugin (and maybe a few other, due to
implementation bugs), therefore authors already stuck into this
specific notation, if they want to avoid as much problems as
possible for the audience. Working from scratch it would not
be very important, how to note such functionality. But just
the fact, that there is an old and a new notation, alternatively
or parallel will cause problems, because it is always the 
decision of the author, which notation to use, if there is more
than one, but viewers may not know both and the audience
will have problems, if the author does not note both - and
many authors are too lazy for this (and to note both is not
really the intended simplification, at least for the next 5 or
10 years after such a new recommendation appears), for
implementors this time is even longer, just because it can
be assumed, that several old documents will not vanish,
just because a new recommendation appears. Because
implementors tend to have no separate implementations for
different versions of the same format, this may cause more
potential problems for the audience ('In our viewer version
37.3 we removed the XLink functionality, just because we
don't like it and the W3C group responsible for it').

If there is a new element with new attributes, there is no need to
reuse XLink again, because older viewers will ignore this new
element anyway. However it is not very intuitive to create other
attributes just for new elements, if XLink does the same for 
older elements.
It is the task of the author to explore, if there are already enough
implementations for the new element or to provide an alternative 
view for the next 5 or 10 years.
Such a complication is not necessary for already existing,
documented and implemented functionalities, especially if the
functionality is not even improved, just the notation.

The same applies for something, that is indicated as an
erratum - typically authors can forget such a feature for
several years, just because they can assume, that there are
different implementations and the feature is not relyable anymore
(if it ever was). While for erratas such a problem is typically not 
intended, it is for a change of notation.

Olaf

Received on Thursday, 28 January 2010 10:38:33 UTC