Fundamentals of Extensible Business Reporting Language Dimensions

What is XBRL dimensions: XBRL dimensions specification is a modular extension for the XBRL specification. It uses the segment and scenario elements of the context to use the elements defined in it to divide the data according to dimensions, as I will explain shortly. The dimension specification is too big to be fully covered in a single article, so in this, I will only discuss the fundamentals and in another, I will explain the other syntactic details. Since the article assumes the reader's prior knowledge of XBRL, the reader is advised to first read the articles on XBRL here.

Dimensions concept: In XBRL dimensions, facts are reported as points in a multi-dimensional space.

Which means, facts for the same concepts are repeated over and over to report the values for different values of the independent dimensions. For example, the sales can be reported for different zones like east, west, north, south or for different products. This is achieved by reporting the sales fact for different contexts which have different domains specified in either the segment or the scenario element of the context. Dimensions can be of two kinds, typed and explicit.

Typed Dimensions: Typed dimensions are used mainly for having continuous dimension axis. For example, temperature, time etc. However, typed dimensions are really flexible, and you can even have a dimension whose value is a complex number. This is possible because the domains associated with a typed dimension are elements of any type (even a complexType) and the element appears as the value in the segment or scenario. Now the question is, what is a domain?

Domain: Domains are simply the values the dimensions can take. In case of typed dimensions, the domains are simply any globally defined elements which appear inside the segment or scenario elements of the contexts. In case of explicit dimensions, the domains are elements in the substitution group of item (so technically, they are items). The element never appears in the instance, instead, their qualified names appear in the segment or scenario elements of the context. In this case, the qualified name of the domain is the value.

Explicit Dimension: As already mentioned in the above discussion about domains, explicit dimensions are attached to explicit domains. The names of the explicit domain are the values of the explicit dimensions. Explicit domains are allowed to have sub-domains. This allows for organization of the domains.

Since, the names of the domains are the values of the dimensions, all domain values must be a part of the taxonomy. This is in contrast to the explicit domains, in which, the values can be specified in the instance itself. It should be remembered that typed dimensions are broader and more powerful than explicit dimensions. However, it is more difficult to create a standard display logic for them that will work with all typed dimensions including complex types. As such, typed dimensions are not commonly used in financial reporting.

Hypercubes: Now that we are familiar with the concept of dimensions, we can now learn about hypercubes. Hypercubes are simply collection of dimensions that go together. A hypercube can be thought of as a coordinate system. While specifying hypercubes in the taxonomy, we only specify the independent axes which are the dimensions. The dependent axis is the values of the item. Hypercubes are allowed to have a mix of typed and explicit dimensions. For example, if you want to report the taxi fare in different states according to the distance, you can have distance as a typed dimension and state as an explicit dimension.

How are these defined: Well I will cover the semantic details in later articles. So, stay tuned.