XBRL: A case study in complexity

Subtitled

I reached more familiar ground when I read the authors' recommendation that XBRL (extensible business reporting language) should play a crucial role in future reform. Their proposed regulatory initiatives include "encouraging, possibly requiring, public firms to file their financial statements, prospectuses and other relevant information in XBRL formats in order to accelerate the use of XBRL by companies, investors and analysts."

Speedier information flow, transparency -- what's not to like? I wonder, though, if the authors have actually read the 151-page XBRL spec. Here's a taste:

"4.10 Equality predicates relevant to detecting duplicate items and tuples. There are several different senses that are relevant to detection of duplicates in XBRL instances: Identical, Structure equal (s-equal), Parent equal (p-equal), Value equal (v-equal), (XPath)-equal (x-equal), Context equal (c-equal) and Unit equal (u-equal). These different equality predicates are polymorphic and formally defined in a recursive fashion. They are all symmetric predicates, ie the result of X (predicate) Y = the result of Y (predicate) X."

Uh-oh. I thought BPEL4WS (business process execution language for web services) was a brain exploder, but it's a walk in the park compared to this stuff. The XBRL spec describes how the parts of an XBRL instance interrelate, using state-of-the-art XML technologies such as XLink and XPointer. And it talks at length about the syntax and semantics of "taxonomies" that abstractly define chunks of financial reports. No sign of any actual financial data, though. And the link to a sample page at xbrl.org, returned a "404 Not Found". I'm not surprised. The poor bloke whose job it was to produce that sample must have suffered a polymorphic recursive brain meltdown.

This isn't what the authors had in mind when they endorsed XBRL. They're right to point out that financial data published on the web today in HTML and PDF formats resists transformation and analysis. And they're right to say that "XML permits the tagging of individual data elements, and thus allows the users to rearrange or manipulate them". But you can't get from the Model T of today's HTML and PDF reports to the intergalactic cruiser of XBRL in one turn of the evolutionary crank.

Consider RSS. In 1999 I published my first RSS feed. It was (and is) an XML format so simple that I could (and sometimes still do) write it by hand. Five years later, RSS is wildly popular, as XML formats go. But hordes of people who should be using it have yet to figure it out. If the RSS spec looked like the XBRL spec, nobody ever would -- except vendors who regard Sarbanes-Oxley financial compliance as a growth industry. If we really want transparent data flow, let's keep it simple.