two failings of XLink

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:1.3.6.1.4.1.6320 is another possibility altogether

Received on Thursday, 26 September 2002 12:17:24 UTC