Digital Financial Reporting

I posted some informationto the XBRL-DEV news list which is worth making more generally available. So, I will repost that information here on my blog:

There are a lot of misconceptions surrounding the "dimension-default".  Many of the misconceptions relate to the unfortunate choice of the term "default".  The dimension-default has nothing to do with defaults like what pops in one's mind when you generally think about default. What the dimension-default really does is enable the ability to create intersections between hypercubes or as the US GAAP Taxonomy calls them [Table]s.

I created a video which I believe walks you through what "dimension-default" really does.  You can get that video here:

http://www.youtube.com/watch?v=lNPjwKy2Obs

While in the video, I showed the fact tables of the balance sheet and property, plant and equipment components within the XBRL Cloud viewer; you have to have a subscription to XBRL Cloud to view the reference implementation I am using.  However, I have made available the same information in another form, not dynamic, but you can see the fact tables for yourself.  You can get to that human readable rendering here:

http://www.xbrlsite.com/DigitalFinancialReporting/ReferenceImplementation/2013-05-15/evidence-package/index.html#Rendering-BalanceSheet-abc_BalanceSheetTable.html

The bottom line is this:  "Dimension-default" has ZERO to do with "default" like most people think, probably because of that unfortunate name.  What is going on is that whenever one hypercube or as the US GAAP Taxonomy calls the [Table] intersects with another hypercube/[Table] and share a fact; and the hypercubes/[Table]s have different dimensions/[Axis], you cannot physically put both sets of dimensions/[Axis] there physically.  XBRL processors put them there virtually, depending upon which hypercube/[Table] you are using to view that fact.  So, those dimensions or [Axis] exist whether you see them in the context or not.

You don't get to have an opinion about this. This reality is not open for interpretation.  It is written into the XBRL specification.  Full stop.

Proof of this is simply running the XBRL instance through an XBRL processor.  If you do, you will note that the XBRL instance links to an XBRL formula linkbase (actually a number of them, the one I refer to is the report level rules).  That XBRL Formula linkbase has a formula with the ID "FILER_RollUp_PropertyPlantAndEquipmentNet".

That XBRL Formula calculates the member aggregation of the PPE components.  That is definitive proof that XBRL works precisely as I am saying.

That reference implementation is rich with relations such as these.  You can get to the XBRL instance and related taxonomies and other information from here:

http://www.xbrlsite.com/DigitalFinancialReporting/ReferenceImplementation/2013-05-15/

The XBRL Formula for this and other [Table]s which have intersections and computations proves the views of the fact tables as shown in the XBRL Cloud viewer are correct.  The UBmatrix, Arelle, XBRL Cloud, and CoreFilings XBRL processors all report the same results from running the XBRL Formula.  That is first hand information.  I have second hand information that the Fujitsu processor and Reporting Standards processor report the same information as the other four XBRL processors which I have access to.

So, just because you cannot see the explicit dimensions physically within the XBRL instance context does not mean that they are not there.  They are there.  The representation in the XBRL taxonomy says that they are there and XBRL processors say that they are there.