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

Doug Schepers:
> 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.  

It is a completely different language for a completely different purpose,
and is several years younger than HTML, it is XML - there could be
no more differences, why should someone expect the same syntax
than for HTML with its long and nasty history of tag-soup parsing,
not required for XML formats.

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

This would be more a problem for RDF data, because there is typically
no direct testable effect. For hyperlinking an author can immediately
test, if it works. And more: The copy-paste problem should not appear
in XML/SVG, just because the author will get an error-message about 
the missing namespace and can simply fix the problem before 
publishing the document.

> Yet another problem avoided is 
> the serialization problem with namespace prefixes that I suffered from
> even back when I used ASV, where.  

This is maybe related to the limitations of the DTDs too, the adobe
plugins seems to have followed. But this is only a bug of one specific
viewer, not updated anymore now (still this leaves signs in tutorials
to be careful to get some backwards compatibilities for this viewer).

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

XLink:role and for hyperlinks XLink:show can be of some use too, of couse
only, if something meaningful is implemented, especially for the first one ;o)


> Finally, XLink is 
> not a precise enough specification for clear implementation, leading to
> increased risk of non-interoperability.

From 2001-06-27 up to now there was a lot of time to improve the prose
in a second edition or to add some functionality in a newer, backwards
compatible version. That this did not happen up to now, is maybe
an indication, that it is not so bad at all ;o)


>
> Put together, all of these little things add up to a steeper learning
> curve and more error-prone development even for experts.  

Beginners just have to note xmlns:xlink="http://www.w3.org/1999/xlink"
in the root svg element and xlink:href instead of href - without some
further interest in XLink, there is not much to learn, just because SVG
implicates all required other attribute values.


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

Maybe, but this would have been a good consideration for SVG1.0, 
not for 1.1, 1.2 or 2.0 ;o)
Sounds a little bit like to switch the saddle of a horse, while it is
already in gallop ;o)


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

How could this help for old viewers? We know already, that many
people use browser versions, which are several years old - for example
it seemed worth to spend a lot of time and work in the HTML5
drafts to ensure, that old documents and old user-agents are
still usable, the first ones completely, and the last ones at least
to some amount.


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

With Opera 10, I used to test the sample, there is no effect.
(maybe due to the fact, that the content does not work without
script interpretation, I switch always off for unkown documents).

To get some forward and backward compatibility and avoiding
possible copy-paste-problems authors need to write something like:


<a xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="testlink.svg" 
href="testlink.svg"><text x="10" y="25" font-size="18" fill="crimson">Test 
Link</text></a>

This does not really look simpler as what we have now ;o)
Or one has to introduce a feature string and some switch - but because
the information from viewers about feature strings is often not really
relyable, this will fail for several of new viewers either, if they
have a comparable quality as current viewers and the authors has
an even more complex construction with three or more elements
instead of one.
  
And replacing href="testlink.svg" with 
xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="testlink.svg"
or vice versa or adding the missing notation with a script like scour 
may work for static documents, if some authors really have the time 
to do this, but it does not work for dynamic outputs from scripts.
Or one has to use some user-agent-sniffing on a server, just
to send a document version, which fits to the notations the
current viewer likes best - not really a promising approach for
a standard format like SVG.

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

It can have a different effect, if authors note an arbitrary change on such a
core feature of an almost 10 year old language, causing such big
compatibility problems and resulting in viewers, that cannot interprete
their already existing documents (and PHP-outputs) anymore, they can
get the impression, that SVG is corrupted and they should wait another
10 or 20 years until there is a more stable version of SVG or another
more stable language to use. Several may switch back to something
like flash or silverlight, just because it has no such nasty and 
superfluous problems. Or for PHP-outputs they will continue or get
back to create raster-image-outputs with the known accessibility 
problems. 


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

There could have been some better prose and some more examples
in XLink, indeed, but I have seen drafts from the W3C, much less
understandable ...

What is used in SVG fits more or less to the options of XLink, for the 
element a obviously actuate is 'onRequest' for image 'onLoad' and show
'embed', for the usage of XLink:href for animation elements this is 
'other' and needs to be specified in the host language SVG.
This could have been noted better in SVG, indeed, not directly
a problem of XLink. But it could have avoided the impression,
that XLink provides not much usable generic information.

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

For designers and artists, who do not care about the HTML collection
with its own legacy and backwards compatibility considerations, this
looks more like a burden to learn the historical background, why
there are so many attributes in HTML with almost the same functionality -
and for such a new SVG variant they have to learn both about the XLink
history and about the history of HTML to be able to provide even simple
documents displayable in old and new viewers.

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

Maybe, whatever went wrong, now we can admire the result in SVG tiny 1.2.
According to your latest change, now authors have to decide between 
general usability in compund documents and what technically works within 
SVG in a larger amount of current viewers. It is not possible anymore to
provide both on the same element. 
And such an approach for hyperlinking functionalities in SVG will produce
even more confusion and determent about what to do.


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

Is it your intention too to switch form image-element to img-element and
from g-element to span, from foreignObject to object? What about the
incompatibilities introduced in HTML5 for elements like video and audio.
As far as I understand, there was some desire from the HTML5 WG to
avoid name clashes with other formats, because the did not manage to 
integrate a namespace mechanism up to now. 
Obviously the HTML5 WG ignored the problem of name clashes for
audio and video and caused themselves problems, they cannot really solve.
I think, there was some discussion, to avoid such clashes in the future,
as far as possible? 
This adoption of HTML names sounds more like the opposite approach 
to escalate the name clash problem to force the HTML5 WG to introduce 
a namespaces mechanism ;o)
Apart from the assumption, that this could be a good result concerning
HTML5, it may cause some even more excited discussions in the 
future...


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

Because it exists already and there is no way to turn back time,
this lesson happened already and is present in several tutorials ...
And the lesson will get much longer, if the tutorial has to explain,
why there is more than one mechanism for the same purpose and
that XLink mechanisms have to be noted for user-agents published
before date X (Y, Z ... depending on the user-agent) and another
one for those published after this date.

Indeed, for tutorials it is pretty good to have it simple. But it
is 10 years too late now to reconsider this.

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

No, see above, in a tutorial there would be a clear requirement to explain
the complete story abut XLink syntax and new syntax, just because it may
take about 10 or more years, until an author can forget about the old
syntax.


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

The functionality it provides is simply not available in another way in an
arbitrary XML-format without a specific implementation of the format
itself. And it would have been much simpler do develop new formats,
if at least the simple type of XLink would have been implemented
properly in common XML-user-agents.

XLink is surely not self centric, it is (maybe too) general and the 
specification could have more prose and samples to explain better,
how to use it. This should be corrected with a new edition of XLink,
not within another format.

>
>
> [1] http://schepers.cc/svg/xlink/exxlink.svg
>
> Regards-
> -Doug Schepers
> W3C Team Contact, SVG and WebApps WGs

Received on Wednesday, 27 January 2010 16:58:51 UTC