- From: Micah Dubinko <MDubinko@cardiff.com>
- Date: Fri, 27 Sep 2002 12:20:05 -0700
- To: "'tbray@textuality.com'" <tbray@textuality.com>
- Cc: "'www-tag@w3.org'" <www-tag@w3.org>
Tim Bray wrote: <img xlink:type="extended" <src xlink:type="locator" xlink:href="someURI"/> <src xlink:type="locator" lang="EN" xlink:href="desc-EN.html"/> <src xlink:type="locator" lang="JP" xlink:href="desc-JP.html"/> <src xlink:type="locator" xlink:title="Audio" lang="EN" xlink:href="desc-EN.wav"/> Hi Tim, I like this design, and I hope that XHTML 2.0 picks up on it, or something close to it. 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 can imagine a fairly painless change to XLink to fix this: Strawman: xlink:type="local-extended" A linking element of type "local-extended" acts the same as an extended link, except the element itself also serves as a local resource (endpoint) for the link. Appropriate arcs could also be defaulted, either one-way or two-way. So with one small change, the example could be a link with one local and four remote endpoints, and 20 (or maybe 8 or 4) arcs. This would be a step in the right direction, as well as a good use case in a requirements document. Thanks, .micah [1] http://lists.w3.org/Archives/Public/www-tag/2002Sep/0249.html
Received on Friday, 27 September 2002 15:20:09 UTC