Re: XAG 2.3 and xlink

"Charles McCathieNevile" <charles@w3.org>
> On Mon, 2 Sep 2002, Al Gilman wrote:
> >
> >We don't need an existence proof from Jim to know there is a problem.
> >The HTML WG has taken the position that they have considered XLink and
> >found it wanting.
> >
> >For the purposes of the current XAG draft, where it says
> >
> >"2.3 Use the standard XML linking and pointing mechanisms (XLink and
> >XPointer).
> >
> >it might as well say "Use standard W3C methods for associating
information
> >in the current document with information elsewhere, and semantics
bound
> >to the current markup vocabulary with related semantics used more
widely
> >or more narrowly."
>
> It is true that a simple xlink can only have one link in it. But an
extended
> Xlink can contain many links, with the sole proviso that each one is an
> element (and can be annotated, have a role as defined in the Xlink
namespace,
> etc) rather than an attribute.

Consider this:

<image xlink:href="shepherds.jpg">
 <alternative xlink:href="shepherds.html" type="text/html">
 <alternative xlink:href="shepherds.rdf" type="application/rdf+xml">
 <alternative xlink:href="shepherds.svg" type="image/svg+xml">
</image>

Seems a reasonably flexible way to define alternatives to our image
element.  However I think it's a hard sell, and is only really for the
situation where there are multiple types, where there's only one
alternative url (either with that uri content negotiated, or is a
fragment to the same/different document.) then an attribute is more than
enough.

Another problem is what happens when someone uses xpointer to annotate or
link to one of the "alternative" elements, what does the annotation/link
point to?  Okay, that's a problem with people mis-using links, but it's
one we wouldn't have if it wasn't for the elements.

In general I'd prefer something more like:

<image xlink:href="shepherd.jpg" alternative="someuri" />

this means that where there's only one alternative, it's very simple, and
it's an easy "sell".

If you have more types then we can construct something similar to the
first:

<image xlink:href="shepherd.jpg" alternative="#alts" />

<alternatives id="alts">
 <alternative ... />
</>

etc.  Which also means that the alternatives are nicely reusable if you
use the image more than once. (and you could even define them in a
seperate document so as to be re-usable across documents.)

I don't think xlink actually makes it impossible to create accessible
formats, it just makes it harder, and breaks the paradigm developers
currently have, so I agree legacy support of formats isn't that
important, legacy support of developers is.

Jim.

Received on Tuesday, 3 September 2002 05:57:22 UTC