- From: Jim Ley <jim@jibbering.com>
- Date: Tue, 3 Sep 2002 09:52:38 -0000
- To: "Charles McCathieNevile" <charles@w3.org>, "Al Gilman" <asgilman@iamdigex.net>
- Cc: "WAI Cross-group list" <wai-xtech@w3.org>
"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