XBRL: Just About the Difficult - Chapter 5. Discovering New Dimensions

5. Discovering new dimensions.

The previous chapters showed you what XBRL is, and what you can do with it. As you already know, it is an extensible standard. In this chapter, we will look at one of the modules that extend the standard specification - XBRL Dimensions.

The chapter is based on the XBRL Dimensions specification version 1.0 of CR dated 06.19.2006. At the time of writing, the specification is in the status of Candidate Recommendation, but it is expected that the final version will not bring any significant surprises.

As for the XBRL specification itself, this chapter highlights some of its important points that are necessary for a confident basic understanding of XBRL Dimensions. The rest of the nuances are given in the full specifications.

5.1. Introduction

Usually, the facts in reports are classified in some way, for example:

• Sales in different periods;
• Sales by grocery lines;
• Sales by region;
• Sales by department;
• Number of employees by age;
• Number of employees by gender;
• ...

Two of these categories are explicitly defined by the XBRL specification — the period and report writer (company, department, company department). These categories are always present in contexts referenced by the facts of the report.

The desire to expand these opportunities to allow taxonomy authors to specify their own categories, such as product line, gender, etc., is quite natural. This is exactly what XBRL Dimensions allows. In this specification, such categories are called dimensions.

As defined in the XBRL specification, the included script and segment can have any valid XML content. XBRL Dimensions defines a formalized way to use such elements to add new dimensions (categories) to the context.

The example we used earlier is very well suited for illustration:
We just need to define the concept of nr_employees and a pair of measurements: gender (gender) with values ​​{men ',' women '} and age group (age group) with values ​​{... 20, 21–40 41–… '}.

The report contains a set of contexts for each combination of the period and dimension, and each context has its own fact:

Context	Fact
01-01-2015	nr_employees = 35
01-01-2015 + 'men'	nr_employees = 23
01-01-2015 + 'women'	nr_employees = 12
01-01-2015 + '...– 20'	nr_employees = 5
01-01-2015 + '21 –40 '	nr_employees = 23
01-01-2015 + '41 - ... '	nr_employees = 7
31-12-2015	nr_employees = 41
12/31/2015 + 'men'	nr_employees = 27
12/31/2015 + 'women'	nr_employees = 15
12/31/2015 + '...– 20'	nr_employees = 9
31-12-2015 + '21 –40 '	nr_employees = 21
12/31/2015 + '41 - ... '	nr_employees = 11

5.1.1. Measurement concepts

The XBRL Dimensions specification uses a number of concepts that are briefly presented here and will be discussed in more detail in the next section.

• Dimension
  Measurement is essentially a categorization of facts. Dimensions are defined in the Domain Members Taxonomy (DMT), and its elements can be used in report contexts to categorize the facts being transmitted.
• Domain and Domain Members
  The set of valid measurement values ​​is called its domain. Domain element is one of these values. There are two types of elements: typed and explicit. Typed elements are defined by syntactic restrictions, for example. "Integers from 0 to 100". Explicit domain elements are item-concepts that are explicitly indicated by dimension domain members. It turns out the list of elements, for example. 'men' and 'women' to measure gender.
• Hypercube
  Measurements can be combined, for example. “Sales by region and product line” or “number of employees by gender and age group”. The set of possible values ​​of such a combination of measurements can be represented as elements in n-dimensional space:
  
  • for n = 1, the elements form a segment on a line;
  • when n = 2, the elements form a square in the plane;
  • with n = 3, the elements form a cube in space;
  • cases of n> 3 are not so easy to visualize, since we live in three-dimensional space; The mathematical term for such cases is the hypercube.
• Primary taxonomy
  This is a common taxonomy according to the XBRL specification. It defines the concepts by which reports can be generated. The XBRL Dimensions specification takes care not to require any changes in the primary taxonomy.
• Taxonomy of domain elements (domain members taxonomy, DMT)
  Dimensions and dimension elements are defined as DMT concepts.
• Template taxonomy
  Combines the primary taxonomy and the taxonomy of domain elements, defining the structure of hypercubes and linking them with the primary concepts.

The specification defines three types of taxonomies. This division into three types is only a concept. Three separate taxonomies can be used, but the specification does not require the use of separate taxonomies for each type. Combining different types in the same taxonomy is perfectly normal. It is even possible to use the concept as a primary concept in one relationship, and as an element of measurement in another.

5.2. Taxonomy measurements

This section discusses how to extend taxonomies for applying the XBRL Dimensions specification. I'll start with an architectural diagram showing how all the components are related.

The following subsections describe each component of the architecture in more detail.

5.2.1. Measurements

DMT defines dimensions as abstract item concepts with a xbrldt:dimensionItem value of the substitution group attribute.

Note: The xbrli:balance , xbrli:periodType and nillable ignored.

Measurements can be typed or explicit, as mentioned above, each of them uses its own method of determining domain elements.

5.2.1.1. Typed dimension

The definition of a typed domain must have an xbrldt:typedDomainRef attribute xbrldt:typedDomainRef that refers to the declaration of the element that defines the domain of the dimension.

Domain is defined using XML Schema types:

• The SimpleType type can, for example, define values ​​from 0 to 100 as an integer of a company’s client as an integer or string of 5 characters;
• The ComplexType type can be used to determine an address that includes a city, a street, a house number, an index, etc.

5.2.1.2. Explicit dimension

An explicit dimension domain is identified by a dimension-domain link from the dimension to the root of the domain-member network of connections between domain elements. An explicit dimension cannot contain the xbrldt:typedDomainRef .

Elements of the domain dimension are all qname-elements in the network of links domain-member . Each item is a definition of an item concept with the value of the xbrli:item attribute of the substitution group (it cannot belong to the xbrldt:hypercubeItem or xbrldt:dimensionItem group).

domain-member links form a hierarchy of elements. You can add members to the hierarchy, for example, to create a root of a nested hierarchy that is not intended to be used as a domain member. To do this, the boolean usable attribute, which is true by default, is false .

An explicit dimension can have a default member, this is done using a dimension-default relationship to a domain member. This default value is used in context if no dimension item is specified. The default value itself cannot be explicitly specified in the context; it is always automatically determined.

Note that dimension-default does not, by itself, add an element to a domain and is not equivalent to a domain-member relationship.

5.2.2. domain-member and inheritance relationships

Primary concepts can inherit hypercubes of other primary concepts by specifying the domain-member relationship between primary concepts.

Suppose we have two primary concepts, one of which (item) is associated with the hc_age hypercube, and the other (another item) - the domain-member relationship with the first concept:


')
Since the first concept has a connection with the age_group dimension via the hc_age hypercube, and the second concept has a domain-member connection with the first concept, the second concept inherits the age_group dimension.

5.2.3. Hypercubes (hypercube)

Hypercubes are defined in a template taxonomy by combining zero (the hypercube can be empty) and more dimensions.

The declaration element is an abstract concept that must have the xbrldt:hypercubeItem value of the substitution group attribute.

Dimensions are linked to the hypercube by arcs with the role of the hypercube-dimension . These relationships are ordered by the value of the order attribute in each arc. Arcs cannot form cyclic bonds.

5.2.4. Connection of primary concepts with hypercubes

When creating a taxonomy with dimensions, you will want to be able to control which dimensions each of the concepts can be associated with. Template taxonomy provides this capability by defining links between hypercubes and primary concepts through has-hypercube links between the primary concept and the hypercube concept.

There are two types of has-hypercube links — all and notAll :

• an all type relationship is used to define the dimensions (and dimension members) that are allowed for the concept;
• A notAll used to define dimensions (and dimension members) that are not allowed.

The combination of these types of links allows you to precisely control the composition of dimensions and measurement elements for each concept.

Suppose we have two hypercubes:



A primary concept with an all has-hypercube type has-hypercube connection with the hc_age_x_gender cube can have all the elements of the gender and age_group dimensions. If we add to this concept a connection of the type notAll with the notAll hypercube, the element 'Female' of the gender dimension and the element '... – 20' of the age_group dimension will become inaccessible to it.

The has-hypercube relationship must indicate in which part of the context the dimensions, segment or scenario , should be defined, for which the contextElement attribute is contextElement :

• The segment value is used for measurements that define a part of the organizational structure of a company forming a report, for example. department, region, etc .;
• the scenario value is used for measurements not related to the organizational structure of the company, such as age group, product, etc.

To indicate that the concept is accessible only to elements within the dimensions of the hypercube, the optional boolean attribute of closed has-hypercube is set to true . This attribute applies only to the script segment in accordance with the contextElement attribute contextElement in the link. The default value is false , which leaves a segment or script open.

5.2.5. Dimensional relationship sets (DRS)

Relationships defined in XBRL Dimensions are included in definition linkbase definition bases. According to the XBRL specification, relationships are grouped into networks according to their roles. This is called the basic set of relationships.

The XBRL Dimensions specification extends the notion of a base set by introducing the targetRole attribute for link types such as all , notAll , hypercube-dimension , dimension-domain and domain-member . The targetRole attribute refers to another role and defines the transition from the linkbase in one base set to the linkbase in the base set with the role specified in the attribute. The set of such grouped relationships is called the Measurement Relationship Set, DRS.

Creating a DRS can be useful and even necessary when the taxonomy of measurements becomes more complex. Without DRS, you are likely to include items in dimensions to which they do not belong, or add dimensions to those hypercubes. You can easily get a set of relationships that have no meaning or may even be contradictory and invalid.

This mechanism of moving from one linkbase (role) to another makes the process of validating a taxonomy or a report much more complex, since relationships exist outside the bounds of the base sets, as defined in the XBRL specification.

The XBRL Dimensions specification uses the concept of consecutive relationship. It means that, for example, the elements of a hypercube are determined first by the hypercube-dimension relationship, and then for all found measurements, sequentially for each of the domain-member relationships.

All consecutive relationships are within the same role of linkbases, unless the value of the targetRole attribute is targetRole . If in the arc this attribute is present, then the search for relationships goes to the linkbase with the specified role. Consecutive relationships in the source base of references (roles) are absent in this case.

Relationships that can be combined as sequential are limited to what you would logically expect — has-hypercube ( all , notAll ) notAll can have hypercube_dimension as serial relationships, but not dimension_domain or domain_member , as they skip the links.

5.3. Dimensions in XBRL reports

As stated in the introduction, dimensions are used in a segment or report context scripts. The choice between them is made with the contextElementType attribute of the has-hypercube link.

5.3.1. Types of measurement items

5.3.1.1. Typed members

For typed dimensions, values ​​are specified as xbrldi:typedMember child elements within a segment or script. The dimension attribute of such elements must refer to the definition of a typed dimension. The content of typedMember is an element with the type as the dimension specified in the xbrldt:typedDomainRef attribute xbrldt:typedDomainRef . The value to measure is the value of this item.

Suppose we have a ageDim dimension of type age with integer values ​​from 0 to (optimistic) 150. The dimension value 45 is set as a child of age inside, for example, a segment as follows:

 <xbrldi:typedMember dimension=”d:ageDim”> <d:age>45</d:age> </xbrldi:typedMember> 

5.3.1.2. Explicit member

For explicit dimensions, values ​​are specified using xbrldi:explicitMember elements. The dimension attribute of such elements must refer to the definition of an explicit dimension. The value for the dimension is the content of this element and it must be the qname-element of one of the explicitly defined measurement values.

Suppose we have an ageGroupDim dimension with the following clearly defined elements: ageLessThan20, ageFrom21To40, and age41OrMore. The measurement value for the age group 21–40 is set by the child inside, for example, a segment as follows:

 <xbrldi:explicitMember dimension=”d:ageGroupDim”>d:ageFrom21To40</xbrldi:explicitMember> 

5.3.2. Validation

The XBRL Dimensions specification complements the validation rules set from the XBRL specification.

5.3.2.1. Validation of primary facts

Facts on primary concepts must be validated based on the concept and context. A fact is automatically considered valid in terms of dimensions if the has-hypercube relationship is not defined for its concept.

If a has-hypercube relationship is defined in the concept, the hypercubes they specify must be valid in terms of dimensions. The fact context must contain a valid combination of domain elements or values ​​for each of the associated hypercube dimensions within at least one basic set. If no measurement value is specified, the default measurement value (if available) is used. It is not allowed to specify more than one measurement value.

Note that when determining the validity of a specified value within a dimension, attributes such as usable in the domain-member and closed links in the has-hypercube links are taken into account.

It took several pages of the XBRL Dimensions specification to describe the normative definition of measurement validation, so the reality is a bit more complicated than what I described here. However, the above simple rules and common sense should give you a good understanding of what measurement validation is.

5.3.3. Equality of Measurement

The XBRL Dimensions specification adds a new type of equality to the extensive list given in the XBRL specification - d-equality . Two facts are considered d-equal for one dimension if they have the same value of this dimension.

Chapter navigation

• Comment from the translator
• Chapter 1. Introduction
• Chapter 2. What is XBRL?
• Chapter 3. Anatomy of taxonomy
• Chapter 4. XBRL Report
• Chapter 5. Discovering New Dimensions
• Chapter 6. Immersion in XBRL
  
  • Part 1. Getting Started
  • Part 2. Improving the result
  • Part 3. Calculations and validation
  • Part 4. How to make life easier
  • Part 5. New measurements
  • Part 6. Multidimensionality
• PS from translator