XBRL: A case study in complexity

Accounting isn't my strong suit. So I read Following the Moneyto learn what a team of financial academicians think really happened with Enron and WorldCom, and what should be done about it.

Free IT resource TechNet: More ways to know it, share it, and keep it running. Sponsored by Microsoft Free IT resource Attend the SOA Executive Forum: Breaking SOA Bottlenecks SOAExecForum.com/may2007 Sponsored by InfoWorld

Subtitled TheEnron Failure and the State of Corporate Disclosure,the book introduced me to a realm of standards wonkery that's way outside my comfort zone. Will the Financial Accounting Standards Board (FASB) merge U.S. GAAP (Generally Accepted Accounting Principles) with the International Accounting Standards Board's (IASB's) IFRS (International Financial Reporting Standards), or will IFRS instead supersede GAAP? Beats me. Web services has nothing on these guys when it comes to slinging acronyms.

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, i.e. 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 compliance as a growth industry. If we really want transparent data flow, let’s keep it simple.