Re: two failings of XLink

Elliotte,

> I don't care about XLink 1.0 terms. I care about XHTML terms. If
> XHTML decides to do this. XHTML can, and it can do so completely
> within the confines of XLink.

Just to be clear: you're advocating using XLink syntax (xlink:href
attributes etc.) but ignoring XLink semantics (namely the distinction
between simple and extended links).

> As to the link harvester, you're putting the cart before the horse.
> Link harvesters know a lot more about HTML than XLinks. I do not
> find it the least bit improbable that XLink harvesters will know and
> understand the relationships of XHTML link usages, whatever form
> that eventually takes.

You're also advocating that XHTML is a "special case" as a markup
language and therefore should be treated differently from other markup
languages when it comes to tool support.

I take the opposite point of view on both these points.

I think that the XLink linking model is very helpful, but that the
syntax with which links are defined, while good for some markup
languages, is a demonstrably poor fit with others. One of the powerful
features of XML is that it is *extensible* and that people can develop
their own methods of representing their information. To say that all
links *must* be specified through an xlink:href attribute undermines
that principle.

I also think that as far as is possible XHTML should not try to be a
special case when it comes to generic XML processors (though I think
it should continue to be a *very* special case when it comes to web
browsers). I don't think that W3C XML Schema validators should work
differently with XHTML than they do with other markup languages, nor
XSLT processors, and nor XLink harvesters. If they did, then I don't
think XHTML could claim to be XML.

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/

Received on Friday, 27 September 2002 10:23:05 UTC