W3C home > Mailing lists > Public > www-tag@w3.org > September 2002

Re: two failings of XLink

From: Micah Dubinko <MDubinko@cardiff.com>
Date: Fri, 27 Sep 2002 12:20:05 -0700
Message-ID: <E840F0B7E6189547BDB91DA8BF2228AB28C79A@csmail.cardiff.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:11 GMT