Digital Financial Reporting

This is a continuation of the post "Thoughts on Rendering XBRL (First Installment)".

These are, in my view, the things which need to be achieve when addressing rendering XBRL information for consumption by humans:

• Renderings need to be interactive, meaning they can be easily reorganized to meet a user's specific needs without the need to re-key information.
• Renderings need to be in a usable form.
• Extensions to an XBRL taxonomy must not break the rendering.
• There should be no need to specify rendering information beyond what is provided within an XBRL taxonomy.
• The rendering algorithm should not be proprietary to any specific software application. (This defeats the fundamental purpose of XBRL)
• All this should be easy enough for business users to make work, both the creator of the information and the consumer of the information.
• It needs to work consistently and predictably.  If this is not achieved, automated information exchange is a non-starter.

Here are some things which I am NOT part of the rendering equation, in my view:

• It is NOT the case that "pixel perfect rendering" is the target.  While pixel perfect rendering of XBRL information is definitely needed, it is not needed for every use case. It is not in scope for what I am trying to achieve in terms of rendering.  (Besides, I can already do that using XSLT and a one-to-one rendering solution.  The problem is, you cannot make that interactive.)
• It is NOT the case that "every user needs to get exactly what they want in all cases" for the target I am talking about.  Should users get what they want?  Absolutely.  But what do you REALLY want: (a) the ability to automate the exchange of information or (b) haggle about whether something needs a double underscore or a single underscore. Life is full of trade offs.
• It is NOT about forms.  Rendering the information collected from a form is child's play because the metadata of the form does not change, it is static.  By definition here, if the metadata does not change, what you have is a form.

So, how to do it?  First off, borrow the multidimensional model. (See Getting Started with ADAPT and the OLAP Council White Paper).  Now, I did NOT say borrow OLAP, I said the multidimensional model, which is part of OLAP.  The part of OLAP which is not needed and generally seems to get in the way is it's desire to aggregate things.  Well, there are may times when we don't need that with XBRL.  But, the multidimensional model and OLAP are two different things.  Here is a quote from the OLAP Council White Paper:

"A multidimensional view of data provides more than the ability to "slice and dice"; it provides the foundation for analytical processing through flexibile access to information."

So, does XBRL need OLAP?  Sure, when it needs it.  But when it does not, it needs to not be constrined by OLAP.

An example of this constrain in a general slice and dice type tool is Microsoft Excel pivot tables.

Here is a bunch of XBRL (these were pointed out in the first installment also, they are the same thing):

• Metapatterns: http://www.xbrlsite.com/Demos/Metapatterns/2009-03-14/
• Business use cases: http://www.xbrlsite.com/Patterns/2008-04-18/
• Comprehensive example: http://www.xbrlsite.com/examples/ComprehensiveExample/

These are still a work in progress.  The metapatterns and the business use cases represent what I am trying to represent better than the comprehensive example at this point.  But, I will adjust these XBRL taxonomies until I get the desired result which is an acceptable rendering of the information the XBRL instances contain.

How I am achieving the rendering (or attempting to) is to use the following things:

1. The taxonomy XBRL information.
2. The taxonomy information model (i.e. how the taxonomy is constructed).
3. A datacube of XBRL instance information based on 1 and 2 above.

Here are examples of each of these for one of the metapatterns, the "Combined" example.  This is the taxonomy information in XML and in HTML. A human can "see" the HTML, but I use the XML to gather information about the XBRL and about the information model.  This is basically a pre-processed view of the presentation network.  I do this because I am not a good enough programmer to use an XBRL processor API.  So, I use this which is created by using some of the XBRL Cloud stuff that I have access to.

I use that network view to create something else I need.  I have tried a number of times to try and get a Microsoft Excel pivot table to render XBRL.  See the first installment of this post and take a look at this file I created way back in 2007. Look at both the pivot tables I was able to create and more importantly the DATA which DRIVES the pivot tables!

That data format (i.e. the denormalized data in Excel) and some ideas that Rene van Egmond, Cliff Binstock, some others at UBmatrix led to the creation of this: the datacube. Or rather, I call this an "interactive information cube".  It has what we need from the multidimensional model and provides flexibly, but it does not use the OLAP piece that gets in the way.  Look in the metapatterns, business use cases, and comprehensive example, a datacube is provided for each.  These datacubes are modeled after what XBRL Cloud has implemented, but adjusted to make them work how I need them to work.

The information within the datacubes are quite easy to load into Excel.  In fact, see this tool which allows you to do that (same one pointed out in the prior installment of this post).  The problem is that Excel pivot tables don't render these how I need them rendered.  So, I have to create my own approach to rendering (unless I find someone who is willing to help out who knows how to program, if you do, please let me know, charleshoffman@olywa.net).

This may seem like a goofy way to approach solving this problem, but it is all I have to work with.  There are a lot of moving parts.  This is about creating a proof of concept and an approach, not about me creating the actual control which one could use to render XBRL. That would be for programmers to do.

I am going to call that good for now, a third installment will be forthcoming.

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:

1. 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.
2. The typical business user cannot create that rendering, at least not using the tools which exist today.
3. 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.
4. 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.

Now, there are two important ideas to understand here.  The first is the notion of "shape".  The second is the notion of "flow".  Read the two links to blog entries which explain these two ideas.

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.