Written by David vun Kannon Posted on September 17, 2008
David vun Kannon was one of the first Co-Chairs of the XBRL Specification Working Group and has been an Editor of every version of the XBRL Specification. He is a Director for PricewaterhouseCoopers, LLP.
These are exciting times in the XBRL community. We can see uses of XBRL growing around the world, more companies becoming involved, and more being written about XBRL.
But instead of shouting "I'm king of the world!," I think now would be a great time for a little reality check.
There are some odd traditions in the computer science field. One of them is reusing titles of well known papers and books. One of the classic papers that pushed us along the road to better coding practices was titled "GOTO Considered Harmful" (not a caution against any Japanese person named Goto, but against so-called spaghetti code). Another classic title is "What Computers Can't Do," which attacked the symbol-manipulating tradition in Artificial Intelligence.
Now, the title "What XBRL Can't Do" is cool in a geeky kind of way, but what I'd like to talk about is more like "What XBRL Isn't Even Interested In Doing, and Doesn't Try."
The B and the R of XBRL really define its scope, and it is important to realize that XBRL has a scope, and that the scope is not infinite. B is for Business -- this drives the existence of the fact context. For every fact in an XBRL instance there is an entity, a time period, and a scenario for which that fact is true. XBRL is terrible for representing abstract math. 2+2=4 requires no entity, period, or scenario. So MathML is safe from encroachment by XBRL.
The R stands for Reporting. XBRL is not about transactions. OK, so what is reporting and what is a transaction? Here is a simple heuristic. Take whatever it is that you are trying to use XBRL for, and write it out as a sentence:
"The assets of Mumble, LLC on Dec 31, 2005, were $7."
"On Dec 31, 2008, Mumble, LLC calls the outstanding 7 3/4 bonds of 2015."
The first example uses a stative verb -- it is reporting a fact.
The second example uses an active verb -- it is a transaction. If I changed "calls" to "buys" the transaction would change from a corporate action to a more familiar market operation, but it would still be a transaction.
So there are a large number of transactional XML languages -- FpML, EBXML, etc. -- that are safe from encroachment from XBRL
I hope no one thinks I want to restrict XBRL to just financial reporting. I don't. There are lots of other kinds of reporting that I think are important -- internal controls, corporate social responsibility, and health care are examples. XBRL could be applied fruitfully in all of these areas, because they are valid examples of reporting.
Also, reporting frequently shows up inside transactions as part of an object description. So there is a place for XBRL as a part of a transactional system if the application needs a very capable description format. Using XBRL when the object descriptions are fixed would be overkill.
There is still a lot of "low hanging fruit" in the areas of reporting and metadata management. Enough that we don't have to go picking someone else's cherries!
Leave a comment