Table of Contents

This document provides guidance on a number of technical issues related to the use of dimensions in an XBRL taxonomy. It does not attempt to provide guidance on the modelling of specific business requirements using dimensions.

This document is aimed at taxonomy architects looking for guidance on the best way to use dimensions within a taxonomy.

1 Which of "segment" or "scenario" should be used as the dimension container?

For historical reasons, XBRL provides two alternative containers in which XBRL dimensions can be included, known as "segment" and "scenario". These container elements pre-dates the introduction of XBRL Dimensions, and the split is now redundant.

The choice of which to use is arbitrary, as it does not affect the semantic meaning of the dimensions.

Taxonomy authors should pick one option and use it consistently. Where a taxonomy needs to be consistent with prior versions, or needs to interoperate with other taxonomies, the decision should be guided by what is done in those taxonomies.

In the absence of other factors, it is suggested that the scenario element is used.

2 Should hypercubes be open or closed?

Hypercubes can be defined as being "open" or "closed". Facts reported against closed hypercubes may only use the dimensions linked to that hypercube, whereas facts reported against open hypercubes may include additional dimensions.

It is recommended that positive (all) hypercubes should aways be closed, and that negative (notAll) hypercubes are always open. Doing otherwise can lead to unexpectedly lax validation of dimensional facts, with a corresponding risk to data quality. For a full explanation of the reasoning behind this, please see the Technical Considerations for the Use of Dimensions Working Group Note.

It should be noted that closed hypercubes do not in any way limit the ability of extension taxonomy creators to extend hypercubes in a base taxonomy.

3 Should dimension defaults be usable?

All domain members can be flagged as being usable, or not. Non-usable members are used to provide structure to the domain hierarchy, but cannot be used in XBRL reports.

Dimensions may have a default member, which is the value that is assumed for a dimension if it is not explicitly reported. The default member can only be reported by omitting the dimension completely: it is not permitted to report a default member explicitly. This gives rise to the question of whether a default member can or should be defined be as being usable.

The XBRL Specification Working Group has confirmed that in order to be used as a default, a member must be defined as being usable. There have been reports of inconsistent software behaviour on this point, and the Working Group is preparing new tests to remove this inconsistency.

In summary, default members must be specified as being usable.

4 Should a taxonomy use multiple hypercube elements, or re-use a single hypercube element in different extended link roles?

In order to be considered valid, a fact is required to be valid according to the hypercubes defined in at least one extended link role. As a consequence, where a concept is associated with multiple different hypercubes, for example, to provide different types of breakdown in different statements, the hypercubes must be in different extended link roles.

It is perfectly legal for the same hypercube element to be re-used across different extended link roles. This means that hypercubes are effectively identified by the combination of the extended link role and the hypercube element: the same hypercube element used in two different extended link roles is really two different hypercubes.

As a result, some taxonomies have chosen to re-use a single hypercube element, often named "Statement", "Table" or similar for all hypercubes defined in the taxonomy and relying on the extended link role to differentiate the hypercubes. With the introduction of the Generic Labels specification, which makes it possible to provide alternative, multi-language labels for an extended link role, the approach of re-using a concisely-labelled hypercube concept and applying unique, descriptive labels to extended link roles is likely to lead to the best visualisation in general-purpose XBRL tools, which will typically show both the extended link role and the concept label.

5 Should presentation relationships be provided for dimensional concepts and their associated dimensions?

Some taxonomies have adopted the approach of creating a "copy" of the dimensional structure defined in a taxonomy in the presentation tree. The reasons for this are largely historical: providing presentation relationships made the taxonomy accessible to viewing tools that did not support the Dimensions specification, and prior to the introduction of the Generic Preferred Labels specification, it was only possible to capture preferred label information, which is widely used to provide hints for rendering tools, in the presentation tree.

With the introduction of Generic Preferred Labels, and support for the XBRL Dimensions specification being widespread, the technical need for such presentation relationships is reduced. There is little downside to including them, but where this is done, it is recommended that automated processes are used to generate the necessary presentation relationships in order to ensure consistency and avoid an unnecessary maintenance burden.

It should be noted that some dimensional taxonomies take different approaches to the use of the presentation tree that does not directly mirror the dimensional structure.

6 Should dimension default values be overridden in extension taxonomies?

Defaults should not be overridden in extension taxonomies because the default dimension value is carefully chosen to be an integral and logical part of the definition of an explicit taxonomy-defined-dimension.

It is technically possible to override base taxonomy dimension defaults when creating an extension. However, this will lead to the case where two different XBRL reports that rely on the default dimension value would have different meanings even though the contents of the reports are the same. One would take on the default dimension value of the base, one would take on the default dimension value of the extension.

Overriding dimension defaults can be seen as changing an integral part of the definition of a dimension. In addition, there may be unintended and non-obvious side effects of doing this, particularly considering simplifying assumptions made by those processing XBRL reports.

While sometimes explicitly prohibited by filing rules, even in the absence of such rule, the default should never be overridden.