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

Hi Doug,

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?

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.
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.
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.
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.

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. 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.


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 and in the tiny 1.2 test suite sample I have seen one
for events. There might be another one for XHTML 
(if it appears within the document), several more for RDF 
(what appears more often nowadays, because in several 
areas authors add information about licenses with this like 
GNU or CC). And there are namespaces
too from inkscape extensions, residuals from sodipody.
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.
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.
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.
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)

Olaf

Received on Monday, 25 January 2010 18:20:30 UTC