XHTML 2.0 and the death of XLink and XPointer?

One interesting aspect of the recently released first public Working Draft of 
XHTML 2.0 is the Common Attributes Collection (see Chapter 6 of the WD).

Among the proposed common attributes is the href attribute which, as 
proposed, appears (assuming I understand the draft correctly) to be capable 
of being added to any XHTML element.

However, XLink 1.0 already defines linking attributes which can be placed on 
any XML element, not just XHTML elements.

We then appear to have two (competing?) hyperlinking technologies intended 
for use on some/all XML elements. 

Does it make sense for this competition to continue? 

Is the Common Attributes Collection in XHTML 2.0 an indication that W3C is 
quietly easing away from support of XLink? Is there a good reason for the 
duplication, remembering that the XHTML 2.0 WD explicitly states that 
backwards compatibility with HTML and XHTML is not an intention? So what is 
the reason for having two families of linking attributes which duplicate 
functionality?

Or could it be an indication of a battle in W3C between XLinks and HTML 
links?

Is this an issue for the TAG?

Additionally the XHTML 2.0 WD has no indication that I could find of support 
for XPointer. One wonders why the primitive # fragment identifier is the only 
(as far as I could see) fragment identifier in W3C's "new generation" XHTML? 

Are we to continue in perpetuity to be constrained to linking only to 
document fragments which a document author thinks are relevant?

Is the absence of mention of XPointer in the XHTML 2.0 WD an indication that 
the XHTML WG intends to forego in perpetuity the potential benefits of 
XPointer?

There are many more questions which could be posed about the place of 
XLink/XPointer and XHTML links. In the first instance it might be useful to 
know why the XHTML WG is taking this approach and if this potentially duplic
ate functionality makes sense to the TAG.

Andrew Watt

Received on Friday, 9 August 2002 05:52:36 UTC