XBRL-based structured digital financial reporting - Blog: Digital Financial Reporting (using XBRL)

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

The first and second installment of these thoughts relating to rendering XBRL lead to this third installment. Be sure to go back to the other two posts. Also, be aware that this post may seem to ramble. That is brainstorming, trying to figure this out. A conclusion will be reached, bear with the process. If you just want to skip to the conclusion below, you can do so.

First, let me summarize the requirments of what I am trying to achieve:

Requirements:

A human readable rendering usable by business users across different software applications (i.e. proprietary means of exchanging information already exist, but they are proprietary and don't work across different software applications).
Reconfigurable information (i.e. interactive information, or interactive data as the SEC refers to it), for example much like you can reconfigure information using a Microsoft Excel pivot table.
Extensibility has to be supported
Business users must be able to perform all aspects of this process without the IT department getting involved (i.e. it is actual quite easy to exchange information if you do get the IT department involved).
Automationof the process (i.e. you can already exchange information in a non-automated manner, for example exchanging an Excel spreadsheet, but you cannot reliably automate that process).

Here are prototypes of the outputs of the process (you have to use your imagination here and try and meld these different pieces together into a hybrid of something which does not exist today):

Goal: This is a two dimensional depiction of the output, it gives you a sense of what the information might look like so you can see what you would get in terms of a "human readable rendering."
Automated so far: This is where I have been able to get to thus far, this is 100% automated. This was created using the "inputs" which will be discussed in a moment.
Interactive characteristics: This is an example of the "interactive" characteristics of the information. I would imagine that this would better be created using something such as Adobe FLEX or Microsoft Windows Presentation Foundation which are allow for very flexible interfaces to be created.
Automation characteristics: This Microsoft Excel application pulls in prototype XBRL instances created using the information model discussed below. Basically, this is not about reading information from a web page, it is about automating the reliable exchange of information. Although, users will need to read that data to check on things as they deem appropriate.

OK, so how do you get to the set of outputs described above and meet the requirements which we started out with? That, still, is the $64,000 question. Here are the inputs which are needed in order to make this work, it seems:

Some global standard: To be non-proprietary, clearly we need a standard. XBRL is a standard, so that fits.
A data model: To exchange information you have to be able to define that information. XBRL let's you do that with an XBRL taxonomy so that the creator of the information and the consumer of the information can be on the same page and truly automate the process. But while an XBRL taxonomy is necessary, it is not sufficient. Now, the trick is that you still have to keep it standard XBRL.
An information model: An information model of some sort is needed. What that means is that everyone cannot create arbitrary or random XBRL taxonomies and expect the information exchange process to be (a) easy for business people and (b) automatable. Every major XBRL taxonomy today has some sort of explicit or implied (i.e. undocumented information model). Random XBRL taxonomies simply will not work. The US GAAP Taxonomy, COREP, XBRLS all have documented information models which you can work with.
Hypercubes: You simply cannot take a wide variety of different pieces of information and expect a rendering engine to render the pieces which have vastly different characteristics well. But, if you do what BI (business intelligence software) does and use the multidimensional model, you create cubes of information (or really hypercubes), you can break the larger set of information down into small enough pieces so that the pieces which need to fit together do fit together, and they can be rendered. Basically, all the information in a hypercube has the same "shape".
Flow: The hypecubes need to be organized, there is a flowto a business report. So, you need some mechanism for organizing the hypercubes.
Multidimensional model: You need some mechanism to allow you to reconfigure the information, to enable the interactivity piece of the equation. Lots of different approaches would work. One approach used is the multidimensional model. The US GAAP Taxonomy uses that, COREP uses it, and XBRLS uses it. But what you don't seem to need is the OLAP piece which seems to get in the way of rendering information correctly.
Metapatterns: The information model may need metapatterns which further break down an information model. Although, that may not be the case. I can see that a well articulated taxonomy could have the needed information gleaned from it using things which are rigid enough in XBRL to be predictable. These include the way XBRL Dimensional information is articulated within the definition linkbase, the way XBRL calculations are articulated, the way XBRL Formulas works. On the other hand, those structures do need to be created in some manner. I cannot see business users doing this. However, if you distill information down into a number of metapatterns and then use those metapatterns to drive application interfaces, then this task will be made quite simple for business users within software applications. I see three metapatterns at this time: roll up, roll forward, hierarchy. There are likely more metapatterns, adding new ones is not a problem. Not having them makes working with the information model exponentially more complex, even to the extent that business users simply cannot work with the technology.

Conclusion

Given the requirements, the output goal, the inputs discussed above (and additional details of those inputs discussed on the previous two blog posts related to rendering XBRL and other information all of which is somewhere on this blog), this is what I see:

Three pieces needed for rendering: I see three pieces needed for rendering XBRL given the requirements above. The first pieceis that you need well organized network/hypercubes articulated within a specified information model making the use of metapatterns to succinctly articulate the information you desire to exchange. An example of this is provided by the following in XML and in HTML. These well organized pieces allow for the possibility of rendering and the possiblitiy of extendeing the information model in a predictable manner. The second piece can be seen from this datacube of this application which reads datacubes. The third pieceis a set of dimensions. This expressed both in the XBRL taxonomy and in XBRL itself. The entity, period, and units are dimensions, whether they are called dimensions by XBRL or not.
A rendering algorithm: You need an algorithm for rendering this information. You only get those three pieces above for rendering because that is all that an XBRL taxonomy and an XBRL instance provide. But, that seems to be enough. Although you cannot know for certain until you actually SEE the rendering algorithm work within a software application. There are three parts to this rendering algorithm. The first two are fairly easy, the second seems to be more challenging than I can handle, but I think a good programmer can make it work. Here are the parts: (1) You need to identify the set of information you are working with, that is what the hypercubes do. Because of the way XBRL work, you can do one of two things. Make each hypercube unique within a taxonomy or use the network/hypercube combination to uniquely identify the sets. (2) You need to identify which dimensions are fixed and therefore can be put into the category of "slice" because they apply to every fact value, and which are unique to fact values and therefore need to appear in the fact table. (3) You need to use the XBRL taxonomy structure, the dimensions, and the fact values to build a fact table which a human can understand and read. THAT is the part part! The fact table is the piece of this that I cannot get to work because of my lack of programming skills, it is the colorful piece of this document. All I can do is list the facts, I cannot put them in order or get the right dimensions. The dimensions could be in a slice, they could be in the fact table, or they could be grouped within the fact table.

Now, granted...none of this may be clear to you, it may take some effort to understand all these moving pieces because this information is not that well organized. I have to figure out a better way to communicate this information. But, I think I am right about what I see and am definitely willing to be wrong if someone has a better idea. But, until I see the requirements stated above being met, I will assume that I am at least on the right track.