David vun Kannon was one of the first -Chairs of the XBRL Specification Working Group and has been an Editor of every version of the XBRL Specification. He is a Director with the Technology and Knowledge Management team of Deloitte & Touche LLP.

Recently Kurt Cagle wrote a post on this blog on alternative representations for XBRL. He freely admitted that his perspective was an interest in the XML language design, not based in domain expertise. In one of his follow-ups to a mment on his post, he says:

Many of the big headache issues that have faced the mmittee uld be readily solved if they simply admitted the obvious — that XBRL IS XML, not some weird variant, and that the tools exist, are freely available, are powerful, and are preferable to the cumbersome solutions put in place to try to turn XBRL into its own meta-language.

I’m actually somewhat surprised by Kurt’s stance from the outset, namely, that significant and insightful criticism of a design can be acmplished without knowing very much about what business problem the design was trying to solve. In fact, this business problem was stated during the beginnings of XBRL to be very broad – namely, a single language for business reporting that would be applicable to every link in the information supply chain.

XBRL makes an important distinction. Business reporting data has a bimodal distribution. Some data is fact data, produced by many reporters, changing every period. Some data is metadata about the facts, changes slowly, and is primarily produced by sources other than the fact producers. Fact producers must, however, be able to produce and integrate their own metadata, and multiple metadata systems must be able to be interrelated. In a nutshell, this is the business problem that XBRL has historically aimed to solve.

Facts do carry ntextual metadata, and XBRL’s design for handling this has changed over time. With the rise of dimensional XBRL, I uld easily be nvinced that we have not done a great job with ntext metadata, just OK. ntexts were designed to be shared between many facts, and dimensional XBRL instances can lead to one ntext per fact.

But Kurt makes this assertion:

…XBRL has the notion of a ntext, in which all data items from a given report each have a ntext attribute which points to a rresponding data structure that gives details about the ntext: the reporting period, reporting agency, any specifics about the preparer, and so forth. Any XML designer would likely fold up all of the key information about that ntext into a ntained element, with an appropriate identifier, and any elements that span ntexts uld then reference the primary ntext as an IDREF.

Frankly, I don’t fully understand this. ntexts today are referenced with an IDREF attribute, so exactly what his suggestion would do better rather than different is not clear.

On the metadata side of the XBRL design, taxonomy design is based on XML Schema and XLink. I still wouldn’t trade the immediate value of schema validation for the forward looking (still, after 10 years) value that may, in the future, arue to using the semantic technologies of RDF/OWL, etc. There are warts on both XML Schema and XLink that I would love to see fixed. On XML Namespaces, too! Fixing any of them would provide more value to XBRL users that adopting RDF/OWL.

So what does it mean to admit the obvious? Here’s what obvious:  XBRL is a database transfer format in XML syntax. Human readability is not a priority. In applications where that is regnized (such as many banking systems), XBRL has been a quiet suess. Several large security regulators are hybrids of data transfer and human presentation, and XBRL has been a tough sell and slow going for these applications.

It still is not clear that the Web, defined as the experience of non-expert nsumers, has — or should — drive design and technology choices for XBRL. This is a point I made in response to Tim Bray mparing XBRL to RSS in terms of trajectories of technology aeptance. I do not think they are mparable, certainly not just because they are both XML. XBRL both in design and ncern (and adoption path) is closer to RDBMS than the Web.

This is NOT because database vendors had any large ntribution to the design of XBRL. It is because of the choice of business problem to be solved. It is still true that it is more important for XBRL to displace CSV files and Excel spreadsheets as the data transfer format of choice in rporate culture than it is for XBRL to shift focus to another syntax choice.

On the subject of alternative syntaxes, it is important to make a distinction between a replacement syntax and multiple syntaxes. A replacement syntax faces a powerful hurdle of overming the strength of incumbency. You can’t just be as good, you have to be a lot better, to replace an incumbent. Multiple syntaxes face the issue of nfusing users. A general rule of language design is to not give multiple ways to “skin the cat.”

It is a truism of XML that you’re only a style sheet away from some other format. But multiple exchange formats seriously detracts from the value of an exchange format in the first place. There is also the problem of exchanging executable de (the style sheet) as well as data.

If XBRL was XML in the "admit the obvious" sense that I think Kurt meant, then there would be no XLink in XBRL. The XML schema would instantiate a particular ntainment structure that matched the ntainment hierarchy chosen by … who? And that would make loading thousands of reporting mpanies filings into a regulatory database easier … how?

I fot, it’s obvious.