Introduction: In my previous article, I have discussed a broad overview of the concepts of XBRL dimensions. Today I am going to discuss about the semantics of XBRL dimensions. Hope you enjoy reading. This article assumes that the reader has gone through the former article here.
Primary taxonomy and template taxonomy: The XBRL dimensions specification has been designed in
a way that a non-dimensional taxonomy can be extended to include dimensions. The non-dimensional taxonomy is known as the primary taxonomy.
The DTS formed by primary taxonomy does not have any dimensional arcs.
Instance document: So, let us first see how dimensions look like in the instance document. Let's
assume that we need to provide the details of product prices according to zone. The following gives an example of how that can be achieved
using XBRL dimensions.
As can be seen in the example, there is a separate context for each value of the zone dimension. The corresponding value of the price can
be represented simply by having items point to the appropriate context through the contextRef attribute. The above is an example of using
explicit dimensions. This could have also been achieved through the use of typed dimensions. There are a lot of constrains as to what can
go where, which I would explain in the rest of the article
Primary item: The items that are part of XBRL 2.1 are primary items. Here is how the specification
defines them, "Primary item declarations are elements defined in XBRL taxonomies that are in the xbrli:item substitution and are not in the xbrldt:hypercubeItem or xbrldt:dimensionItem substitution group".
In other words, the primary items are the items that have nothing to do with dimensions.
Hypercubes: As explained in my earlier article, a hypercube is a tuple of dimensions. It can be
thought of as a coordinate system composed of multiple dimensions. One of the dimension is the value of the item that uses it. Other dimensions
are defined with use of dimensional links. Semantically, hypercubes are also items in the substitution group of xbrldt:hypercubeItem where the
prefix xbrldt is bound to the namespace http://xbrl.org/2005/xbrldt. Just defining the element will not achieve anything though. Because we
need to attach dimensions to the hypercube.
Dimensions: Dimensions are also defined using items, only they are in the substitution group of
xbrldt:dimensionItem. If the dimension is an explicit dimension, containing predefined values, nothing else is required. If on the other hand,
it is a typed dimension, the domain must be declared in the very definition of this element with the xbrldt:typedDomainRef attribute. Hypercubes
are attached to the corresponding dimensions with hypercube-dimension arcs.
Domains: Domains are actually values for the dimensions. In case of explicit dimensions, the domains
must be primary items. In this case, the qualified name of each domain becomes a value for the dimension. In case of typed dimensions, the domains
are just any element declaration. In this case, an instance of the domain will be the value of the dimension.
The explicit domains can also have sub-domains defined through the domain-member relationship. If a domain is attached to a dimension, all the
sub-domains also get automatically attached. The following diagram will give a view of the relationships.
Hypercube-sets: Primary items are attached to the hypercubes applicable to them by has-hypercube relationships.
There are two relationships of that kind. all and not-all. A hypercube is valid in a primary item in the instance if all conditions for such
validations are met. I will discuss the conditions little later. Only if a hypercube is valid, a primary item is considered to be a providing
a value in the coordinate system the hypercube is providing. All has-hypercube relationships in a single link role (the value of the xlink:role
attribute if the link that defines the has-hypercube relationship) make a hypercube-set. A hypercube-set is valid for a primary item instance
if all the hypercubes in 'all' relationships are valid and all the hypercubes in 'not-all' relationships are invalid. Not-all relationships are
there to exclude certain possible values from the dimensions in a hypercube that would otherwise be valid.
A hypercube is valid for a primary item instance if the context attached to it contains values for all the dimensions in that hypercube with
valid values for each. I already discussed in the earlier article that the values of the dimensions can be provided either in the segment or
in the scenario element. The has-hypercube arcs contain the information as to where the values of the dimensions would be provided- segment or
scenario. This is done through the attribute xbrldt:contextElement on the has-hypercube arc.
Now we are in a position to see an example how the dimensional system can be defined in the taxonomy for the above example instance document.
This article only highlights the fundamentals of the semantics. More detailed discussion will be coming afterwards.