XBRL: just about the complex - Chapter 3. Anatomy of taxonomy

3. Anatomy of taxonomy

This chapter, titled as a song from a rock band from the 1960s, describes the structure of the XBRL taxonomy. More attention is paid to what can be done with the help of taxonomies, and less - to how this is done from a technical point of view. We will leave this level of detail for another chapter.

Let's start with this: what we call a taxonomy, in fact, represents, as a rule, a whole set of related documents, called the Discoverable Taxonomy Set, for brevity - DTS .

The starting point of the DTS is the Taxonomy Scheme . This is the document referenced by the XBRL report. This taxonomy scheme may refer to other documents, which in turn may also refer to other documents, etc.

Reading the DTS involves navigating through all the links until all of the related documents have been read.

Taxonomy can refer to two types of documents:

• Taxonomy is the case when one taxonomy (Extended Taxonomy) extends another taxonomy (Base Taxonomy)
• Linkbase - it is used to provide additional information about the concepts defined in the taxonomy. Reference databases describe the relationships between different concepts, as well as between the concept and the additional information to it. In total there are five main types of linkbases (each of which will be discussed in detail later):
  
  • Definitions
  • Calculations
  • Presentation
  • Labels
  • Resources (Reference)

Schematically it can be represented as follows:

Please note that some reference databases (Reference and Label) are unidirectional , i.e. link leads from taxonomy to linkbase resources. Other linkbases (Definition, Calculation, and Presentation) are bidirectional . Links point from one part of the taxonomy to another part.

If necessary, the taxonomy also refers to the XBRL report schema “xbrl-instance-2003-12-31.xsd” (or, more correctly, imports it) - it contains the basic elements necessary to define all concepts.

These are examples of technical details that I will ignore for most of this book. I simply assume that, for example, the taxonomy scheme exists in some context (in this case, the XBRL report schema), and I focus on more functional aspects of XBRL.

The rest of this chapter will describe each type of document in more detail.

3.1. Taxonomy scheme

The core of the taxonomy is its scheme, which is a mandatory document. This scheme, which we have been talking about all this time, is actually an XML Schema document (a W3C standard that allows you to define the structure of XML documents). The XBRL specification uses XML Schema as the base language for describing taxonomies. On top of this basic language, it defines a set of XBRL-specific add-ons and restrictions.

Within the taxonomy scheme, you can:

• Import another, “basic” taxonomy, which allows you to create extensions of existing taxonomies;
• Determine the concepts for which reports will be compiled;
• Identify the roles used in linkbases;
• Refer to linkbases.

3.1.1. Definition of concepts

The XBRL specification contains a number of requirements and recommendations for defining concepts:

• Each concept must have a unique name within the taxonomy scheme;
• Each concept must have a Type attribute, which determines what type of data can be provided (see below);
• Concepts are defined in the taxonomy schema as item (item) or tuple;
  

  This means that each concept must have a substitution group attribute with the value xbrli:item or xbrli:tuple
  

• It is recommended to specify in each concept an attribute with a unique identifier, this simplifies reference to the concept.

XML Schema provides several ways to improve the definition of concepts:

• You can specify whether the concept is required or not;
• A concept can be defined as an abstract one , then it is not required to transfer facts through it - this is used when extending concepts, as described below, or when the root of the hierarchy is needed in the presentation base of links.

In addition, XBRL defines periodType and balance attributes for concepts:

• The periodType attribute periodType required for item concepts ( xbrli:item ). It allows you to separate concepts, measured as of a certain date, from concepts measured over a period of time;
  

  In an XBRL report, facts are specified in a specific context . The periodType attribute of the concept by which the fact is transmitted must correspond to the type of period in the context of the fact.
  

• If the concept type is monetary, then the balance attribute can be used to indicate whether the concept defines a debit or credit value. This is very convenient for accounting concepts, as for example. assets, liabilities, income and expenses.

Concepts can be extended to form a structured concept tree . An example is the concept of "manager", which expands to "manager of the business unit" and "manager of the unit."

Since only facts on non-abstract concepts can be listed in an XBRL report, it is possible to prevent the transmission of unnecessary facts. In the example above, it is possible to allow the transfer of facts on the concepts “manager of a business unit” and “manager of a department”, but not on the concept of “manager”. This is possible by defining the concept “manager” as an abstract one.

3.1.1.1. Concept Data Types

For all item concepts, the type of data to be transferred must be specified. Available data types are defined by the XML Schema standard and the XBRL specification.

XML Schema includes the following types: boolean, text (text), decimal (decimal), date (date), parts of dates, etc. (a full list can be found in section 5.1.1.3 of the XBRL specification).

Note: For each type of XML Schema, there is a corresponding XBRL type definition.

The XBRL specification adds the following data types:

• Monetary (monetary) - used for concepts that reflect monetary values;
• Shares - for equity concepts, for example. shares;
• Simple (pure) - for concepts in which the numerator and denominator are implicitly expressed in a general sense, for example. growth rates, interest;
• Fractional (fractions) - when the facts can not be accurately represented by any of the other types, for example. the value ⅓ does not have an exact decimal representation, but it can be specified using the fractional type. Fractions are set as separate values ​​of the numerator and denominator.

3.1.2. Links links

A taxonomy schema may contain, and usually contains, references to linkbases that provide additional information about taxonomy concepts.

A link can point to a specific kind of Link Base by defining a role . The XBRL specification allows the following roles:

• Definition
• Calculation
• Presentation
• Label
• Resource (Reference)
• Footnote (Footnote)

Note: Separate linkbases are not created for footnotes. This role is used only within the XBRL report.

It is also possible to define custom roles, which is another example of XBRL extensibility .

To further restrict the use of a linkbase, you can define the type of facts to which the link types in the base can point.

3.1.3. Roles and arc roles

Roles are used to identify different types of links within the linkbases. The XBRL specification defines one basic role to ensure that all links have a role. However, the author of a taxonomy or linkbase usually defines its additional roles. They are used to group links into so-called base sets. Such segmentation can be useful, for example, to define different sections of a report when using the presentation base of links. In the calculation base, they are necessary for all calculations except the most primitive ones, in order to prevent errors due to the mixing of links.

Links that are defined by arcs are typed by arc roles. Basic arcs, such as concept-label or summation-item, are predefined by the XBRL specification. It is also possible to define your own arcs. But it is usually used for technical purposes, for example. to define new relationships in the XBRL specification extension. An example of this is the arcs defined in the XBRL Dimensions specification, which we will discuss in Chapter 5.

3.1.4. Example

Let's go back to the taxonomy example:

')
Here we can roughly define the following concepts:

Name	Type of
nr_employees_total	non-negative integer item
nr_employees_male	non-negative integer item
nr_employees_female	non-negative integer item
nr_employees_age_up_to_20	non-negative integer item
nr_employees_age_21_to_40	non-negative integer item
nr_employees_age_41_and_up	non-negative integer item

We will look at these concepts in the next section about the linkbase.

3.2. Linkbases

The concepts defined in the taxonomy scheme are the minimum necessary building blocks of taxonomy. They contain accurate data on what facts can be passed as part of the XBRL report.

Linkbases extend this definition as follows:

• Allow to develop definitions with additional documentation, for example. give human readable labels or references to the normative literature;
• Describe the structure of concepts with internal connections between concepts, for example. defining calculation rules;

Let's first look at some of the possible linkbases for the “taxonomy” from our example in order to understand what they are.

Note: The “linkbases” given here are not complete or correct. They are merely illustrative.

Label Linkbase (label linkbase)
The link base of labels can assign a Russian label to each concept used in the form:

Concept	Label
nr_employees_total	Total
nr_employees_male	Men
nr_employees_female	Women

Another link base of labels can be used to assign English labels to concepts:

Concept	Label
nr_employees_total	Total
nr_employees_male	Men
nr_employees_female	Women

Note: This example of a linkbase link database is not entirely correct. We will return to it later.

Definition linkbase (definition linkbase)
Concept definitions provide various kinds of information. For example, that a certain concept requires the presence of another concept:

Concept	Requires
nr_employees_male	nr_employees_female
nr_employees_female	nr_employees_male

If you indicate a fact by the number of men, you must also indicate the fact by the number of women, and vice versa.

If the concept of nr_employees were defined, the definition base of references could indicate that it is the equivalent of all nr_employees ... concepts:

Concept	Nickname
nr_employees	nr_employees_total
nr_employees	nr_employees_male
nr_employees	nr_employees_female

Calculation Reference Base (calculation linkbase)
C using the calculation, you can set the following rules:

• nr_employees_male + nr_employees_female = nr_employees_total

Such a rule would automatically catch the arithmetic error in the completed form.

Reference Linksbase
Suppose taxonomy describes a report required by law. A full description of what exactly is required to provide, detailed in the legislation, for example. how exactly to report on part-time employees. The base of links to resources allows you to link the concept with the corresponding section of the legislative act:

Concept	Resource
nr_employees_total	Legislative act; Part IV; Section 156-32.d
nr_employees_male	Legislative act; Part IV; Section 156-32.d
nr_employees_female	Legislative act; Part IV; Section 156-32.d

Note: This can also be expressed by the many-to-one relationship; consider this further.

Base links to presentations (presentation linkbase)
Presentations describe how concepts can be hierarchically presented in a reporting form. Our example could have the following hierarchy:

Concept	Lower level hierarchy
nr_employees_total	nr_employees_male
nr_employees_total	nr_employees_female

3.2.1. General characteristics of linkbases

When you begin to delve into the database of links, you will see that they have many common characteristics. Consider some of them.

3.2.1.1. Arcs

All linkbases use arcs to describe the relationships between concepts and their resources or between different concepts. The arc is a two-way directed communication, i.e. she points from one side to the other. Each party may consist of one or more concepts or resources.

In our example base of links to resources, we can use the many-to-one arc to link all three concepts with one link:



The from and to arc attributes can be resources included in an extended link (extended link) or locators in an extended link that point to concepts or resources in other documents.

A locator points to a concept or resource using the href attribute, which can contain an id concept or an XPointer standard expression.

3.2.1.2. Ban and Override

When the taxonomy expands, it may be necessary to change the existing relationships between the concepts. There are two mechanisms for this: prohibiting and overriding .

The arc may have a priority attribute. When several arcs occur, a “conflict” prevails, the one that has the highest priority, in effect overriding the remaining arcs.

If the existing arc is no longer valid, you can add a forbidding arc to your linkbase with a higher priority than the existing one. The inhibit arc is one in which the optional use attribute has the value prohibit .

When applying the rules of prohibition and redefinition, the “basic” network of interrelations is changed by extensions. Using priority, new relationships can be added, existing ones removed, or existing ones replaced with new ones.

The XBRL specification specifies that the rules apply to equivalent relationships, and specifies exactly when relationships are equivalent based on the attributes of arcs and sides "from" and "to".

3.2.1.3. Cycles

Arcs form a network of relationships. The network can become very complex. Loops within a network occur when there are two or more paths from one node to another. Taxonomy should indicate which cycles are allowed:

• Any (any) - all cycles are allowed, there are no restrictions on the relationship;
• Undirected - this strangely named variant allows cycles if there is no way back to the starting node. For example, nodes A and B can have many paths from A to B, but there should not be a path from B to A;
• None (none) - no cycles are allowed, the network can not have more than one path between two nodes. This places great restrictions on interconnections.

Note: A path consists of a set of arcs between nodes. The path can be short (one arc between two nodes) or long (hundreds of arcs between hundreds of nodes).

3.2.1.4. Roles

Each link in the linkbase can have one of several roles. The role determines the use of the link. The available roles depend on the type of linkbase; they are described in the next section.

As mentioned earlier, the XBRL specification provides a set of “general purpose” roles for each type of linkbase. Instead, it is possible to define your own, more specific roles.

Roles can be used in resources and in arcs between them.

3.2.2. Specific Characteristics of Linkbases

Although different linkbases look very similar in structure, there are differences in them. This section describes the characteristics specific to each type of linkbase.

3.2.2.1. Label Link Database

Labels provide human-readable text in a specific language. Each resource must identify the language used in the label.

Labels can have the following roles:

• label (default role) - used for standard labels;
• terseLabel - used for abbreviated labels, where part of the description is omitted;
• verboseLabel - used for extended labels describing the concept in detail;
• positiveLabel , positiveTerseLabel and positiveVerboseLabel — standard, abbreviated, and extended labels used for positive fact values;
• negativeLabel , negativeTerseLabel and negativeVerboseLabel - standard, abbreviated and extended labels used for negative fact values;
• zeroLabel , zeroTerseLabel and zeroVerboseLabel — standard, abbreviated, and extended labels used for zero fact values;
• totalLabel - used for labels of concepts that define the final values;
• periodStartLabel and periodEndLabel - used for labels of concepts that define the facts associated with the beginning or end of the period;
• documentation - for labels providing documentation on the concept;
• definitionGuidance , disclosureGuidance , presentationGuidance , measurementGuidance , commentaryGuidance and exampleGuidance - for labels that provide explanations on such aspects of the concept as definition, measurement method or example of filling.

The label arc has the “concept label” role, which means that it always points from concept to label. Therefore, label arcs never form circular links between concepts.

Considering the above, now we can more accurately determine the link base of the labels from our example:

Concept	Tongue	Role	Label
nr_employees_total	ru	totalLabel	Total
nr_employees_male	ru	terseLabel	Men
nr_employees_female	ru	terseLabel	Women
nr_employees_total	en	totalLabel	Total
nr_employees_male	en	terseLabel	Men
nr_employees_female	en	terseLabel	Women

3.2.2.2. Resource Reference Database

The links provide an opportunity to link definitions of concepts with the provisions published in the business, financial and accounting literature. The element should provide only the information that is necessary to identify and search for the relevant publication. It should never contain the text of the publication itself.

Links may consist of parts (for example). "Legislative act; Part IV; Section 156-32.d. In the XBRL specification, the part element is abstract because the way a publication is divided into parts varies for each publication / jurisdiction.

Links may have the following roles:

• reference (default) is used for the standard concept resource;
• definitionRef - used to refer to the exact definition of the concept;
• disclosureRef , mandatoryDisclosureRef and recommendedDisclosureRef are used to refer to explanations of disclosure requirements;
• unspecifiedDisclosureRef - used to refer to explanations of unspecified disclosure requirements, such as general practice, completeness, and structure;
• presentationRef - used to refer to the explanation of the concept presentation;
• measurementRef - used to refer to the method for measuring the concept value;
• commentaryRef - used to refer to any conceptual general comment;
• exampleRef is used to refer to documentation illustrating the use of a concept with an example.

A resource arc has a concept-reference role, which means that it always points from concept to resource. Therefore, resource arcs never form circular links between concepts.

3.2.2.3. Presentation reference database

Presentation arcs have the role of "parent-child", which allows you to define the hierarchical structure of concepts. Both the parent and child side of the relationship should point to the concept.

When there is no concept that could naturally act as the root of the presentation hierarchy, you can use an abstract concept specifically defined for this purpose instead.

The arc may have a preferredLabel attribute that identifies the preferred role of the label to indicate on the child-concept of the presentation. This is especially useful when the concept is used several times in different ways in DTS. Each link in the presentation may indicate a separate label (according to its role) for use on this concept.

To determine the order of concepts in a presentation, an attribute of the order arc can be used.

3.2.2.4. Computation Reference Database

Computation arcs have the “summation-item” role, representing summing interrelations between concepts (subtraction in this case is provided by summing the concept multiplied by -1, see later). A link points from a summing concept to several summable concepts. The arc of computation can only connect item concepts.

Calculations are possible only on concepts that are equivalent in context and unit of measure.

Note: Relationships defined by tuples also play a role in the calculations. For example, it is not possible to perform summation over the elements of duplicated tuples.

The calculation arc has a weight attribute, which is used as the multiplication factor for the summed value. This allows for more complex calculations than simple addition. At the time of multiplication, the required rounding is performed.

DTS takes into account a complete set of calculations. All calculations with the same role on the same concept will be performed in full. If several details of the same value are present in one report, each of its calculations must have its own role. Otherwise, all the calculations will be summarized together, which will lead to zadvoenie, zatroeniyu, etc. the resulting value.

An XBRL report is considered correct with respect to the reference base of the calculations, if all the calculations within this report are consistent. This allows you to automatically verify calculations.

The possibilities provided by the base of reference calculations are rather limited.

You can perform more complex calculations than simple addition, but this is not easy, and even in this case, the limitations are quite serious. For example, it is impossible to calculate the difference between the facts on the same concept, but in different contexts, say, at the beginning and at the end of a period.

Currently another base of references is being developed - formulas (formula linkbase). It will be available for use in the near future and will provide more functionality for defining calculation formulas.

3.2.2.5. Definition Reference Database

The arc of definitions can have the following roles, denoting different types of relationships:

• general-special
  The relationship of item-concepts with their generalization / detail. Such relationships can be viewed as “is one of,” for example. the concept “division manager” is a detailing of the concept “manager”. , . , , .
  , .
• essence-alias
  item-. , , (essence). (alias) essence-.
  Alias- essence- , (periodType) balance, .
  , .
• similar-tuples
  This relationship is used between concept tuples and similar essence-aliasfor item concepts — it identifies tuples with equivalent definitions. An example would be a postal address, which may be reflected in different formats, but contain equivalent data.
• requires-element
  This relationship is used between tuples or item concepts and defines requirements within the XBRL report. If the report uses fact for the concept on the “from” side, then the report must also have a fact for the concept on the “k” side.

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