Digital Financial Reporting

I stumbled across something interesting.  Below is a little widget provided by Amazon.com. Imagine a business report viewer widget which operated similar to the control below.  This is similar to the iTunes prototype control I put together.  

If you look at the web page which provides information about the control, you can navigate to a page which explains some of the metadatawhich helps power the control. None of this stuff is magic. Imagine trying to put something like this together without product IDs or other metadata.

The folks working on the FINREP (FINancial REPorting for financial institutions) have provided a prototype XBRL taxonomy and related documentation which provides insight into how to model information using XBRL. Serious students of XBRL should consider taking a look at that they have done which you can find here:

• FINREP taxonomy main page
• Proof of concept taxonomy files
• Proof of concept taxonomy architecture documentation
• Bank of Italy "Matrix Schema" documentation (see page 25 onward), referenced

There is one very unique aspect of this taxonomy worth pointing out because it helps to answer a big question that I, and others, have. The FINREP taxonomy has only one hypercube which it uses over, and over, and over to express information. This was done intentionally to force the business semantics of the dimensions and primary items pulled together by the hypercube onto the network containing the hypercube.

This is not to say that I like that approach (i.e. using one hypercube for everything as compared to making each hypercube unique and the hypercube contains the semantics of what the hypercube defines).

What this basically points out is the two extremes of creating hypercubes:

• make each one unique (and each has meaning)
• create only one (and the hypercbue has ZERO semantics, the network contains the semantics which describes what the network/hypercube means)

What is not good is mixing those two approaches.  It makes no sense if one hypercube has multiple meanings (i.e. hypercubes should not be polymorphic).

In discussing the characteristics of the FINREP taxonomy on the Eurofiling news list someone made the following statement about XBRL:

The flexibility and extensibility of XBRL provides numerous solutions which is a double-edged sword.

I could not agree with this statement more. Particularly today because the dust has not settled from the experimentation of trying to figure out the best approaches to use XBRL and the best approaches are not coded into software applications to help guide those making use of XBRL; a cautious "buyer beware" type attitude is quite appropriate.