- From: Tim Bray <tbray@textuality.com>
- Date: Wed, 17 Jul 2002 12:42:01 -0700
- To: Steven Pemberton <steven.pemberton@cwi.nl>
- Cc: www-tag@w3.org, Paul Prescod <paul@prescod.net>
Steven Pemberton wrote: Steven's been irritated about this for a couple of years now and nothing I can say is going to change that, but just for the record, here's the other side of the story - I was only on the XLink WG for a few months and that ended a while ago so I'm not the best possible source but I think I have this more or less right. > It wasn't the XLink charter that lead the HTML WG to believe this, but the > XLink requirements document http://www.w3.org/TR/NOTE-xlink-req/, in > particular requirement B2: > > <<<< > 2: It must be possible to apply XML link semantics to existing documents by > modifying the documents' DTDs only, requiring no modification to the > document instances themselves. Yes, the XLink WG failed to meet this requirement. > We also thought that requirement 2.3: > > XLink must support HTML 4.0 linking constructs. > > meant that XLink would support, well, HTML 4.0 linking constructs. This > turned out to be a matter of interpretation. Yes, the XLink WG interpreted this to mean that what they built should have power and flexibility as rich as that in HTML4. Where I recall the XLink debate ending up: - you make any element an xlink by slapping on one or more attributes from the xlink namespace. E.g. xlink:href, xlink:title - *all* xlink markup is namespaced This means that XLink does not provide a way to say that "The 'a' element is an Xlink and the 'href' attribute is where you put the URI". The upside is that the design is very clean and never impinges on anybody else's namespace, and is guaranteed to layer onto any other XML language with minimal impact on the design of that language. What *could* have been done was to say that any element that carries an "xlink:type" attribute is to be considered an XLink, and must have an "href" attribute for the URI. Or, it could have had something like Norm suggested, xlink:href-attr-name="href". Both of these would have allowed treating HTML "a" as an XLink. Neither would have been as simple and clean as the existing XLink design. The reason (if I recall correctly) why XLink stayed with the simple design, and accepted the cost of not grandfathering HTML markup, was that they couldn't see what the benefit was in the grandfathering. Every user-agent in the world that processes HTML knows what "a" and "link" and so on mean, they work well, there's no ambiguity, what's the benefit in retroactively declaring that they're now also XLinks? I'm not saying that decision was correct, I'm just outlining the path that got there. So, what are some outstanding issues: - are there things really wrong with xlink such that it should be deprecated or rebuilt? For example, the decision not to grandfather existing namespace-free markup? - there's an obvious overlap between XLink and RDF; how do you decide when to use which? (Strawman answer: xlink is optimized for the use in apps that do presentation to humans, RDF for machine precessing). - if you are going to be building hyperlinks into your XML language, and xlink provides capabilities do describe what you want, is it OK to go ahead and invent something else to do the same job? (Strawman answer: no). > The HTML WG agrees that better linking would be desirable, and seriously > wanted to use XLink, which is why we spent so much time trying to achieve a > version that we could use. Clearly there's no benefit for HTML to adopt XLinks for untyped one-directional anchored links, HTML is already very good at that. But if HTML wanted to add links with multiple ends, or which could be out of line, or could have some simple behaviors, why invent your own rather than adopt XLink? The question is serious, not rhetorical. -Tim
Received on Wednesday, 17 July 2002 15:41:57 UTC