Re: [xml-dev] XPointer is dead. What about XLink?
I think the interesting question to ask is whether XBRL gains any benefits
as a result of the decision to use the XLink vocabulary for linking, rather
than inventing its own? For example, does the reuse of vocabulary elements
enable any reuse of an underlying software layer? Or does it enable the
reuse of skills and knowledge associated with that vocabulary? Because
unless it achieves such benefits, it would surely have been better to design
a vocabulary more finely tuned to the specific needs of XBRL.
This is very much the same argument that I've used with people like David Vun Kannon. XLinks and link bases were seen as a way of solving a perceived problem - differences in semantic representation as well as localization and computational efforts, rather than dealing with these issues primarily as schematic issues or SemWeb (in defence of the position, I'd also argue that SemWeb has matured considerably since XBRL first emerged as well). The downside with XBRL is link resolution - link arcs force a two or three level deep dereferencing problem that can be hellish on most XML implementations, and that apparently give relational databases heartburn as well.
Unfortunately, there comes a point where legacy implementations carry their own weight, regardless of the merit of the technology. If I was an ontologist working with the nascent XBRL.org group in 2000 with the tools we have today, I would have recommended a different architecture, but this is probably true of a late of BIG ontologies.
Having said that, I think the other issue involved is the degree to which xlink overlaps with SemWeb, which I see as the natural extrapolation of such linkage systems. As Michael Kay indicated, xlink as it exists right now is very much tied into the notion of client implementations, and its a valid question as to whether the specific characteristics of such links should in fact be very much client language specific (which also raises the intriguing notion of whether link characteristic specification may not in fact also have schematic implementation beyond the base-bones notion of ID and IDREF). Given the recent work to push HTML 5 forward, it may be a good time to revisit xlink and its more feature-rich sister xinclude.
As to XPointer - yeah, it's dead, Jim. XPointer was a very early attempt to introduce some type of basic document query capability into an XML document, and as such it placed too many expectations on the server responding in a systematic way to such a query. What seems to be emerging in its place are RESTful services based upon existing data stores (XRX being the primary proponent there in the XML space) with utilize a query mechanism (XQuery or SPARQL, in this case) in order to retrieve appropriate fragments. I don't think many people mourn its passing.
