- From: Tim Bray <tbray@textuality.com>
- Date: Fri, 27 Sep 2002 12:41:54 -0700
- To: Micah Dubinko <MDubinko@cardiff.com>
- Cc: "'www-tag@w3.org'" <www-tag@w3.org>
On Friday, September 27, 2002, at 12:20 PM, Micah Dubinko wrote: > As I mentioned earlier [1], this doesn't hold up in XLink 1.0 terms, > though. > This looks like a link with four remote endpoints, 12 (defaulted) > arcs, and > no relationship to the <img> element. I'm not convinced; but oops, I notice several typo/thinkos in my proposal. Better: <img xlink:type="extended"> <src xlink:type="locator" xlink:href="someURI"/> <longdesc xlink:type="locator" lang="EN" xlink:href="desc-EN.html"/> <longdesc xlink:type="locator" lang="JP" xlink:href="desc-JP.html"/> <longdesc xlink:type="locator" xlink:title="Audio" lang="EN" xlink:href="desc-EN.wav"/> </img> So, as to the arcs, XLink doesn't require any of that stuff, and the embedding language can add as much semantics as it wants. The relationship to the img is pretty obvious isn't it? Yes, I suppose that adding the arcs could make it more explicit, but does anyone really care what order (in this case) you go from point to point? I imagine that an XHTML2 processor, on mouse-over, would float up a menu allowing you to choose longdesc resources. Having said that... > I can imagine a fairly painless change to XLink to fix this: > > Strawman: xlink:type="local-extended" ... not bad. -Tim
Received on Friday, 27 September 2002 15:41:55 UTC