I took a prototype XBRL taxonomy that I had, modified it, and created three different XBRL taxonomies that help people focus on and see one specific thing related to XBRL Dimensions. The specific area of focus is the use of hypercubes.
In XBRL there are three general approaches to representing information:
- Mixtue of dimensional and nondimensional
XBRL International has issued guidance that says"Don't mix dimensional and nondimensional models." XBRL International's guidance (Recommendation 3.5) states, "Where a taxonomy makes use of dimensions, all concepts should be associated with at least one hypercube, even if that hypercube has no associated dimensions."
Both the US GAAP and IFRS XBRL taxonomies violate that guidance. I predict that ultimately, both of those taxonomies will be corrected.
Now, if you are using a dimensional model, using XBRL Dimensions, the next question you might have is HOW should you be using XBRL Dimensions. The one specific aspect that I want to focus on is the naming of hypercubes.
There are FOUR possibilities:
- Unique hypercubes: Give each hypercube a unique name.
- Single hypercube: Create ONE hypercube and use that for representing EACH set of facts you report.
- Single hypercube, single line items: This is the same as #2 but in addition to unique hypercubes you also have one unique concept for representing the primary items dimension or what the US GAAP and IFRS taxonomy call [Line Items].
- Nonunique hypercubes: Give each hypercube different meanings from time-to-time.
Below I will explain each alternative, provide an example XBRL instance and XBRL taxonomy for the alternative (i.e. download), an HTML page you can use to view the taxonomy (i.e. view), and highlight the pros and cons of each alternative.
By unique hypercube I mean that each hypercube has a different unique name and is used to represent one specific report fragment. In the example below you see the hypercube label "Financial Highlights [Table]" which has the corresponding name "gaap:HypercubeTable". Note also that the primary items are labeled consistent with the hypercube, "Financial Highlights [Line Items]. (Download | View)
The primary advantage of this approach is that you can extract information from an XBRL instance using the hypercube. Because each hypercube has a unique name such as "BalanceSheet" or "IncomeStatement", you can identify the report fragment using the hypercube to reliably extract information because each hypercube is unique.
The primary disadvantage of this approach is that you have to provide all of those hypercube names and the related names for the primary items.
By single hypercube I mean that you create a single hypercube, say labeled "Hypercube [Table]" and named "gaap:HypercubeTable", and then use that single hypercube to report each report fragment. Note that the primary items are still unique to the report fragment represented. (Download | View)
The primary advantage of this approach is that you don't need to create all those hypercube names.
The primary disadvantage of this approach is that you cannot use the hypercube to extract information for fragments of the report because each fragment uses the exact same name.
Single hypercube, single line items
This is the exact same as "single hypercube" above, but you also use one concept to represent each set of primary items. Note below that the primary items are labeled "Hypercube [Line Items]" and named "gaap:HypercubeLineItems" as contrast to the unique label and name above. (Download | View)
The primary advantage of this approach is that like having one concept that is used for each hypercube; if you use one concept for the primary items of each hypercube, you don't have to fiddle with coming up with all those names.
The primary disadvantage; well, I really don't see any disadvantage. Having a single concept such as "Hypercube [Line Items]" helps you realize that the primary items is really just like a dimension. The only difference between primary items and members is that primary items have data types because they will contain fact values.
"Nonunique hypercubes" is a possibility, but I reject that approach because it really does not make much sense. Why would you do this? An example of this is some XBRL-based public company financial reports to the SEC. One example is Microsoft. They use "us-gaap:StatementTable" for each of the primary financial statements, for some disclosures, and then specific hypercubes for other disclosures. (Download)
There are no real advantages to this approach really. Frankly, it is confusing. You can see that confusion when you compare how different public companies report information to the SEC.
The disadvantages of this approach is that, again, you cannot use the hypercube to extract information for a specific report fragment from a report.
So there you have it. Which alternative is best? Well, that depends on what you want to achieve I guess.