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

two failings of XLink

From: Simon St.Laurent <simonstl@simonstl.com>
Date: Thu, 26 Sep 2002 12:17:23 -0400
To: www-tag@w3.org
Message-ID: <r01050300-1015-709A2B2DD16B11D68A750003937A08C2@[]>

I see two large technical problems with XLink in general, and both have
a negative effect on its appropriateness for HTML.

The first is the shift from XLink's early conception as a set of
structures that could be mapped into any vocabulary to XLink as a set
of attributes in a particular namespace that can be added on top of any
vocabulary.  That means that every hyperlink must be xlink:href,
whatever it's purpose.  There's no room for <img src="" /> in XLink.

(XSLT or DOM processing is one possible answer to that, but HLink is far
less intrusive, far more akin to the original conception of XLink with
its remappable attributes.  Namespace disambiguation is both weaker and
more intrusive than equivalence-defining approaches.)

The second issue is the only-one-URI-per-element rule.  While I can
understand to some extent the arguments in favor of that from an
abstract point of view, in practice it seems bizarrely limited if not
simply broken.

XLink may be suitable for situations where the designers have a
conception of linking that corresponds to XLink's existing structure and
where mixing namespaces at the attribute level is accepted as a matter
of course.  

Unfortunately, that does not appear to be the case with (X)HTML, which
has a long history, a slightly different conception of hyperlink
structures, and a user base of millions.  XLink appears to have chosen
to ignore those understandings.

Simon St.Laurent - SSL is my TLA
http://simonstl.com may be my URI
http://monasticxml.org may be my ascetic URI
urn:oid: is another possibility altogether
Received on Thursday, 26 September 2002 12:17:24 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:32:34 UTC