Table of Contents

1 Abstract

Taxonomy authors using taxonomy-defined dimensions will run into the situation that certain concepts are not allowed for specific combinations of dimensions and domain members. XBRL provides a number of mechanisms for enforcing and communication the allowed combinations, and taxonomy authors must select which approach is most appropriate. This document provides guidance on the available approaches, and also covers how to prohibit the use of any taxonomy-defined dimensions for specific concepts. This guidance is targeted towards taxonomy authors and architects.

2 Identify dimensionally invalid combinations

Consider a company selling products to multiple countries. The company produces products A, B and C and sells its products to countries 1, 2 and 3, but does not sell product B to country 2.

Figure 1: This example has been modelled as a sales concept, reported with dimensions for product (with domain members A, B and C) and country (with domain members 1, 2 and 3). The taxonomy must prohibit a fact reporting sales for B2.

This document considers three possible approaches to prohibiting the reporting of sales for B2.

2.1 Approach 1A: Using a dimensional structure that uses a single positive hypercube per table, and a number of negative hypercubes

Positive and negative hypercubes work together to define a set of valid data points. A positive hypercube defines permitted combinations of dimension values and concepts. A negative hypercube prohibits some of the allowed combinations.

For modelling the example in Figure 1, using this approach requires one positive hypercube allowing all combinations of A, B, C and 1, 2, 3 and one negative hypercube excluding B2.

Characteristics

• If errors are found in an XBRL report when validated against the dimensional structure, a technical error message is produced that cannot be tailored to a specific audience. To make them more user-friendly, an application should catch them and translate into messages that will be more meaningful to the end user.
• The dimensional structure can become very complex. For example, consider a dimensional structure with ten dimensions in which many combinations are disallowed. This may result in a large number of hypercubes for excluding specific sets of domain members².
• The taxonomy can be processed to automatically identify which combinations are allowed. Many report creation applications will use the dimensional information in rendering: they will "grey out" any disallowed combinations, making it impossible for the user to enter data for it and thereby preventing errors ever being made.
• It should be noted that a data point will be considered valid if it is valid against any of the hypercubes with which it associated. As such, in order to prohibit a data point effectively, it must be prohibited in each hypercube in which it participates.

Example: Indian MCA taxonomy

2.2 Approach 1B: Using a dimensional structure that uses only positive hypercubes

Do not define the combination B2 at all; only define positive hypercubes covering A1, A2, A3, B1, B3, C1, C2 and C3. There are a number of ways that this can be done, including using one hypercube per data point, or using a number of hypercubes that cover regions of valid data points.

Characteristics

This approach shares the same characteristics as approach 1A, and additionally:

• When using positive hypercubes only, it may be difficult or impossible to derive the overall structure of a table from the dimensional structure in the taxonomy as there is no information about how the different allowed regions of the table fit together¹. Using the example above, approach #2 might be modelled as 8 hypercubes, with no information about these regions fit together. Under approach #1, the single positive hypercube defines the overall structure of the table, with the negative hypercube simply invalidating a cell within it.

Examples: CRD IV, Solvency II

2.3 Approach 2: Using XBRL Formula Rules

Define a hypercube allowing all combinations of A, B, C and 1, 2, 3, and use an XBRL formula rules to show a validation error for facts reporting sales for the combination B2.

Characteristics

• The XBRL formula rules messaging extension provides the ability to create a custom message that is specific to the business scenario, and thus will be readily comprehensible to business users.
• The XBRL formula rules allows conditional inclusion of domain members (e.g. B2 may only be reported if A1 is less than 1,000).
• Although a user-specific message can be created for the specific case of B2 being disallowed, a technical error message relating to dimensions will still be raised if an unforeseen combination is used (e.g. only provide product A, no country info).
• XBRL dimensions allow the validation of a single fact in isolation, however XBRL Formula Rules can only be meaningfully applied to a full XBRL report.
• Report creation software cannot use the XBRL formula rules to determine which cells are not allowed; formula rules can only be used to establish the validity of an XBRL report. Therefore, software cannot, for example, grey out invalid cells in order to provide assistance to a user in entering only the allowed data.

2.4 Additional aspects for consideration

2.4.1 Extensions

Extension taxonomies may want to be consistent with the approach chosen in the base taxonomy. Base taxonomy authors may need to consider how their taxonomies would be extended by preparers or other taxonomy authors.

2.4.2 Complexity and sparsity of the dimensional structure

In some cases the dimensional structure may be "sparse", meaning that only a small proportion of the possible dimensional combinations are valid and allowed to be reported. In some cases a sparse dimensional structure may require a very large number of hypercubes under the positive and negative hypercubes approach (approach 1A), but only a relatively small number of positive hypercubes (approach 1B). The reduction in the number of hypercube needs to be offset against the benefits of the positive and negative hypercubes approach (1A).

2.5 Guidance

Look at all aspects listed, weigh the importance of them for your taxonomy and choose the best approach.

• Ease of creating and maintaining the structure by the taxonomy creator,

• Ease of understanding of the structure by people other than the taxonomy creator,

• Ease of understanding errors by users, e.g. creators or viewers of XBRL reports,

• Ability of a software application to use the structures defined to visualize the allowed and disallowed combinations for the users of those applications. For ease of understanding and maintainability it is considered best to pick one approach for all dimensional structures.

If the taxonomy is an extension of another taxonomy, follow the approach taken by that taxonomy. It is easier to understand for any user of this taxonomy if a consistent approach is followed.

If this taxonomy will be a base taxonomy extended by others, pick an approach that is easy to understand by those extension builders and flexible enough that the extenders can make the extension.

3 Prohibit the use of taxonomy defined dimensions for non-dimensional concepts

Hypercubes constrain the permitted combinations of taxonomy-defined dimensions that may be reported on facts using that concept. Where a concept is not associated with any hypercubes there is no constraint at all on which dimensions may be reported on facts using that concept.

Where concepts are not intended to be used with any taxonomy-defined dimensions, this should be explicitly prohibited by associating the concept with an empty hypercube. This improves data quality by preventing facts from being reported with inappropriate dimensions.

In the example in Figure 1, there are two taxonomy-defined dimensions, "Product" and "Country", which means these dimensions can be used by any concept not constrained in the dimensional structure. The following approach can be defined in the taxonomy to prohibit dimensional qualification for the concept "Assets" which is expected to be only reported against non-dimensional facts.

Include all concepts (e.g. Assets) which should only be reported non-dimensionally in the empty hypercube. This approach is in-line with Technical Considerations for the use of XBRL Dimensions 1.0 which recommends that "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."

3.1 Further Considerations

• A technical error message will be produced to flag invalid usage of taxonomy-defined dimensions.

• The construct needs to be explained in a taxonomy architecture document as the dimensional structure may not be intuitive to understand the purpose.

• Creation of such dimensional structure for non-dimensional concepts should be automated in the taxonomy development process as manual processes can lead to errors and omissions.

• Refer to the document Technical Considerations for the use of XBRL Dimensions 1.0 for further technical details.