XDT 1.0 Dimensions Specification

Introduction

The Dimensions Specification 1.0 is one of the Contributions of Ignacio Hernandez-Ros (Founder of Reporting Standard S.L.) to the XBRL Consortium during the period 2005-2007

The Dimensions Specification allows the transmission of multi-dimensional information (OLAP cubes) Online Analytical Processing using the XBRL syntax.

Dimensional concepts

The Dimensions Specification defines two concepts in order to build the building blocks it is based on:

1. Hypercubes: Taxonomy authors must define hypercubes in order to link concept definitions (also called primary items) with XBRL "cubes"
2. Dimensions: Taxonomy authors must define dimensions in order to link hypercubes with the set of dimensions that are part of the hypercube.

Other terms used:

1. Primary items: They are regular concept definitions
2. Members: Are values of a dimension. If the values can be enumerated in a list then they are typically Explicit dimensions. If the values cannot be enumerated then they are typically Typed dimensions.
3. Domain: This is a set of members of a dimension. Explicit dimension members can be organized in a hierarchy. A Domain is typically a Member (head elements) and the set of children elements in its hierarchy.

Relationships and operations with hypercubes

• The all relationships links a concept definition with an hypercube definition. The dimensions in the hypercube must be reported in the instance document for the fact that corresponds to the concept definition.
• The notAll relationship links a concept definition with an hypercube. Contrary to the all relationship, the notAll relationships tells that the dimensions in the hypercube cannot be reported in the instance document for the fact that corresponds to the concept definition.
• The hypercube-dimension relationship links an hypercube with a dimension. An hypercube may contain multiple dimensions.
• The dimension-domain relationship links a dimension with its head domain member.
• The domain-member relationship links a domain with other members in a explicit dimension hierarchy.

The existence of all and notAll means that the specification defines an algebra of validation of facts for which all members for dimensions in hypercubes linked with the notAll relationship must be excluded from the possible combinations of members for dimensions in hypercubes linked with the all relationship.

Note, in order to build a Dimensional processor and perform validation against the dimensions specification there is no need to create the Cartesian product of dimensions and members of an hypercube.

Dimensions syntax level vs. Dimensions semantic level

One of the consequences of the existence of Concepts, Hypercubes, Dimensions and Members and the relationships between them is that the same hypercube could potentially be used multiple times in the same taxonomy tree and linked with different primary items. Having different dimensions each time... and each dimension may also have different members each time it is used.

Reporting Standard XBRL processor has implemented a two layers approach in order to deal with this situation.

• During the processing of layer one (syntactical layer) the processor creates an object model that matches the syntactical layer (Post Taxonomy Validation Infoset) this is; once relationships removed by extensions are effectively not considered.

• During the processing of layer two (semantical layer) the processor creates a "compiled" layer representing the different uses of the syntactical layer.

Example:

A primary item P1 is linked with Hypercube H1 on extended link EXL1

A primary item P2 is linked with Hypercube H1 on extended link EXL2

The definition of H1 in EXL1 contains:

• Dimension D1 with members M1 and M2

The definition of H1 in EXL2 contains:

• Dimension D1 with members M1 (note M2 is not here)
• Dimension D2 with members M2 (note M2 is part of D2 in EXL2), N1 and N2

Conclusion

This approach makes our processor the most advanced processor in regard to the use of the Dimensions Specification as it allows a completely safe isolation between what the syntax is and what the semantics wants to transmit.