OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
RE: [xml-dev] XPointer is dead. What about XLink?



I know little about how relational databases are put together but the us-gaap taxonomy was built in and stored in a relational database.  I’ll say that when the current taxonomy project started in 2007, the applications were pretty shaky but with constant user feedback we got it stable and where we needed it.  We had as many as 50 people hitting the database with changes at any point in time.  We could never have gotten it done without the multiuser capability, which presumably requires a database structure.  I imagine that most of the large XBRL taxonomies are maintained in databases.  The problem must have been resolved.


Louis Matherne


From: Kurt Cagle [mailto:kurt.cagle@gmail.com]
Sent: Thursday, August 27, 2009 2:28 PM
To: Michael Kay
Cc: Louis Matherne; xml-dev@lists.xml.org
Subject: 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.

Kurt Cagle
Managing Editor



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS