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.