« XBRL and Databases: Some Thoughts and Observations | Main | Analysis of Document and Entity Information Across SEC XBRL Filers »

Understanding Intersections

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:


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:


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:


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.


Posted on Friday, July 26, 2013 at 01:15PM by Registered CommenterCharlie in | CommentsPost a Comment

PrintView Printer Friendly Version

EmailEmail Article to Friend

Reader Comments

There are no comments for this journal entry. To create a new comment, use the form below.

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
All HTML will be escaped. Hyperlinks will be created for URLs automatically.