This is the first installment of a series of posts which I am going to make relating to rendering XBRL. When I say rendering, I am talking about both the output of XBRL and the input or the tool used to create the XBRL and the information the XBRL represents.
I have been fiddling with how to render XBRL information for years. It is actually quite easy to render XBRL. This was created by applying a style sheet to the XBRL instance which generated XSL-FO which was then sent to an FO processor which generated PDF. You can see more information about this here.
The problems with that rendering are the following:
- It is a "one off" rendering, meaning that the rendering process works only for that particular XBRL instance. This is not a good thing for a number of reasons, keep reading.
- The typical business user cannot create that rendering, at least not using the tools which exist today.
- The rendering is not "interactive" in nature, meaning that you get ONE format, what you see. The user cannot reconfigure the rendering if they desire to see the information formatted in a different way.
- The rendering will not handle extensions. If someone adds an extension, it will simply not show up in the rendering which is clearly not acceptable. Rendering static forms is basically a cake walk. It is the dynamic forms of information which make use of XBRL's extensibility which are the challenge.
So what is the answer? Inline XBRL? In my view, inline XBRL is little better than the PDF version above. It has pretty much the same negative characteristics.
This is how I see things.
- The goal: In my view, the PDF type rendering is a good starting point for communicating the goal. Basically, if you want to replace what you have today with something else, you need to meet all the needs being met today, plus more. So, this is what a business report commonly looks like today (I am using a financial statement).
- How to get there: If you take a look at the business report above you will notice that what it is, is lots of little tables of information strung together in the form of a report. To show this, what I did was take the information and put it into Excel. I then created an Excel pivot table for every piece of the report. That spreadsheet can be found here. There are two sheets for each table. The first is the actual pivot table, the second is the data which drives the pivot table.
- Interactive information: This is a prototype of the theoretical goal in my mind. All I did was to take the pivot tables from the bullet above, take a screen shot of each, and put them into a Word document and print the Word document to PDF.
Now, it would be nice if Excel pivot tables rendered the XBRL information better, but they don't for two reasons. First, I am no expert in Excel. You can probably get this better, but you will not be able to get it exactly how you want it because of the second reason. The second reason is that Excel pivot tables (as most of the multidimensional tools that I have seen) are optimized for (a) numbers and (b) aggregation of those numbers. Maybe there are ways around this, but I have not been able to find them.
So, what is the answer? Well, that is the $64,000 question. This is what I am trying. The first thing you need is use cases and I have been nurturing a set of use cases for a number of years. I have broken these use cases into three sets:
- Metapatterns: This is the essence of what needs to be achieved. This condenses the business use cases down to their essence. You can distill all the business use cases into one of these metapatterns. Here is this set of use cases: http://www.xbrlsite.com/Demos/Metapatterns/2009-03-14/
- Business use cases: These are actually the same thing as the metapatterns above, but packaged differently. They are more along the lines of business use cases, easier for a business person to get their heads around. But, there is nothing in this set which the meta patterns does not address. Here is this set: http://www.xbrlsite.com/Patterns/2008-04-18/
- Comprehensive example: This is really the starting point from above, the goal. This looks like a financial statement. But what it really is, is the set of business use cases put into the form of a financial statement, again, so it is more understandable to business people. Here is this set: http://www.xbrlsite.com/examples/ComprehensiveExample/
(Keep in mind that these three sets of XBRL taxonomies and XBRL instances are about two years old and have helped me get to where I am today in terms of my thinking about rendering XBRL. I need to make some adjustments and corrections to these files to better tune them to my existing ideas.)
This is a work in progress, but what I have tried to do is build a tool to render the XBRL information in a form which would be usable by humans. This little Excel tool reads each of these sets of XBRL instances and XBRL taxonomies above.
For now let me summarize by saying this: It is impossible to have a great rendering tool and a poorly constructed XBRL taxonomy and get what you will desire. It is likewise impossible to take a well constructed XBRL taxonomy and use a poorly constructed or poorly designed rendering tool and get what you want. It takes two things to enable what most business users will want: a good XBRL taxonomy and a good tool which leverages the XBRL taxonomy information to render XBRL instance information. (I would love to be proven wrong. If you have a tool which can render these small taxonomies in a manner that a business user will be happy with, please let me know. Until that time, I will assume that I am correct.)
I am going to stop here for now. If you want to follow this thread of thoughts relating to rendering XBRL, I encourage you to thoroughly examine the metapatterns, business use cases, and the comprehensive examples shown above. Part of this is having a look at the sets of XBRL instances and XBRL taxonomies via the little Excel tool.