Re: xlink:href

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