8 14 2005-01-31T17:03:33-05:00 $Date: 2005-09-11 10:27:02 -0400 (Sun, 11 Sep 2005) $ NormanWalsh 2005Norman Walsh The W3C XML Core Working Group has proposed a few modest improvements to make XLink more usable. Despite some controversy, and while hardly setting the world on fire, XLink has seen some implementation (SVG, XML Topic Maps, XBRL, etc. See Robin Cover’s excellent (as always) summary for more details). What's more, I think there's plenty of hope for continued adoption. I'm currently using it in DocBook NG and I hope to extend the stylesheets to provide at least some support for extended links. But this essay is not intended to spark controversy. I've had enough of that recently. You like XLink, you hate it, you haven't made up your mind; it's all good to me. Even the proponents of XLink, I think, will grant that it has at least one significant usability flaw. In order to define a simple link, you must specify not only the hypertext reference, but also the link type: <myLink xlink:href="someURI" xlink:type="simple">hot text</myLink> XLink was designed in the age of DTDs and the idea of relying on the DTD to provide default attribute values to work around this inconvenience didn't seem unreasonable. But it sure does now, especially in an age of well-formed documents validated by many different schemas. The honest truth is, I don't think it was even a good answer in the DTD days, not really, but I didn't notice at the time (I won't attempt to speak for others). Recently, the XML Core Working Group published a very short note, Extending XLink 1.0, that describes a few small changes that could be made to XLink to improve it's usability. The chief proposal is that the XLink link type should be an application default. In other words, an application that sees <myLink xlink:href="someURI">hot text</myLink> should infer that myLink is an XLink simple link (in the absence of any other declaration that provides a value for the xlink:type attribute). That single change will significantly simplify the authoring process and separate XLink from any particular schema requirements. Because that construction is not valid now, this change cannot break any existing, valid documents. Any existing documents that don't specify a link type will go from being invalid to being valid simple links, and I can't imagine that answer being wrong in any but the most pathological cases. The other changes, explicitly reserving other attributes in the XLink namespace, explicitly allowing IRIs, and providing some additional non-normative schemas, are all nearly trivial. I hope the community can come to consensus that these are small and reasonable changes that can be made without harm irrespective of anyone's position on the merits, or lack thereof, of XLink as a whole.