1 Introduction (non-normative)
The architecture of XBRL as defined in the base XBRL 2.1, Specification [XBRL] defines a rich set of syntactic and semantic rules for specifying concepts that are members, or elements, of one dimension and relationships among them in what is termed a “taxonomy” (plural “taxonomies”). It also defines extensibility mechanisms for taxonomies and “Discoverable Taxonomy Sets” (or DTSs - see [XBRL] section 3.2). These rules employ XML Schemas [SCHEMA-1][SCHEMA‑2] to identify the various concepts involved and XLINK linkbases [XLINK] to define relationships between those concepts and between those concepts and other resources. It also defines a rich set of syntactic and semantic rules for how such DTSs are to be referenced and interpreted when used in conjunction with an XBRL instance. XBRL also provides a mechanism for instance preparers to define other dimensional metadata that describe facts that are reported in the XBRL instance. This mechanism involves the notion of “contexts” (defined by the <context> element) and, within those contexts, the use of <segment> and/or <scenario> elements along with additional schemas that specify all dimensional metadata that is not otherwise given semantic meaning by the specification itself. Dimensions that ARE provided such semantic meaning by the specification itself are the “time” dimension, which leverages the sophisticated semantic mechanisms provided in XML Schema [SCHEMA-1], and, to a limited extent, “units” which may sometimes be viewed as dimensional and at other times as properties of individual facts depending on the application.
The contents of the <segment> and <scenario> elements are deliberately left open to permit users to fashion their own mechanisms for defining and referencing this dimensional metadata. It has, however, become apparent that, in practice, there is a need to formalise a consistent system for defining this dimensional metadata and a need to define a mechanism for specifying not only the names of such metadata elements but also their interrelationships. It has also become apparent that often the nature of such metadata and metadata relationships resembles very closely that which is already addressed by the XBRL taxonomy mechanism which is used for the “concepts” dimension.
For the purposes defined in the Dimensional Taxonomies Requirements [DIM-REQ] this modular extension to the base XBRL 2.1, Specification [XBRL] defines a formalisation of the syntax of the body of the <segment> and <scenario>. This specification defines the syntax and semantics of dimensional taxonomies, which in turn define the dimensions that may be used in an XBRL instance document. This specification also defines the additional rules to which an XBRL instance document must adhere in order to be an XBRL Dimensional Taxonomies (XDT) compliant instance document.
Dimensional taxonomies are syntactically identical to taxonomies that are defined in the base XBRL 2.1, Specification [XBRL] with certain restrictions that must be adhered to when they are to be used as dimensional taxonomies (see section 2). In addition certain additional semantics are defined with respect to a taxonomy when it is used as a dimensional taxonomy and referenced as such by an XBRL instance.
1.1 Background (non-normative)
As should be apparent from the requirements [DIM-REQ], dimensional metadata was not invented with XBRL. XBRL standardizes the representation of only two dimensions: the time dimension and the entity dimension. Many reporting purposes, both internal and external to organisations, require multiple dimensions. What the XBRL 2.1 specification did create was the principles for this specification to exist while defining two open elements in the context of XBRL instance documents: the segment and scenario elements. The present specification defines the syntax of elements that may occur in the segment and scenario elements and defines standard arcs that define the valid content of those elements. That content should be validated by dimensional XBRL processors and standard errors are raised if the XBRL instance is not conformant with the multidimensional model defined in the taxonomy. This specification uses three possible different roles that taxonomies can play in representing multidimensional information: primary taxonomies, domain member taxonomies, and template taxonomies. This taxonomy role differentiation is only illustrative. Because the multidimensional information is represented by arcs and XBRL concepts and there is no way in XBRL to specify the role of a taxonomy it is possible for one taxonomy to play two or all of these roles simultaneously. The differentiation in this specification provides an architectural framework to projects that incorporate multidimensional information into existing taxonomies.
1.1.1 Primary taxonomies
A primary taxonomy is the DTS of an XBRL taxonomy that has no dimensional elements and no arcs defined in this specification. Requirement G16 [DIM-REQ] states “Taxonomy authors must be able to extend a base taxonomy that does not have dimensional information, to have dimensions, without changing the concepts in the base.” This specification uses the term primary taxonomy for a DTS of elements that may be instantiated in an XBRL instance. For example, a taxonomy used for external financial reporting may be extended with a variety of dimensional taxonomies appropriate to the reporting purpose.
1.1.2 Domain members taxonomies
Typed dimensional taxonomies as defined in requirement G03 [DIM-REQ] define syntactic constraints on the contents of segments and scenarios.
Explicit dimensional taxonomies are those in which the XBRL items form a discrete, countable finite partitioning of a set of members, which hereinafter is called a domain. Examples include a taxonomy on the domain of geographic territories, or a taxonomy on a domain of product lines. Inclusion relationships (requirement G09 [DIM-REQ]) are represented by domain‑member relationships. XBRL instances may use any number of dimensional taxonomies, with the members of their domains possibly appearing in a variety of combinations within XBRL segment and scenario elements.
1.1.3 Template taxonomies
The DTS of an instance using dimensional information may contain domain‑member relationships among items in both primary taxonomies and domain members taxonomies. Since a primary taxonomy typically does not have dimensional information, that implies that the instance-rooted DTS must contain domain‑member relationships in a linkbase that is not in the schema-rooted DTS of the primary taxonomy.
A template taxonomy imports all domain member taxonomies and primary taxonomies and adds the dimensional structures that will be used in the XBRL instance. By convention, a taxonomy that imports primary and domain member taxonomies and defines all the necessary dimensional information is called a template taxonomy. In particular, a template defines hypercubes. A hypercube describes the Cartesian product of zero or more dimensions. Each dimension in turn is defined over zero or more domains and domains are composed of members. Note that in this formulation, a hypercube of a primary item does not include the primary item itself.
· Example: a topographic map is a 3-dimensional hypercube; it has thee dimensions, elevation, longitude and latitude, all of which are defined over the domain of real numbers. The elevation can be represented as a primary item, longitude and latitude being the two dimensions of a hypercube for that primary item.
· Example: A table in a financial statement showing revenue for products, by territory, is a 3-dimensional hypercube, with one primary item (revenue) and two explicit dimensions (products and territory).
· Example: A loan report for a bank may be, in effect, an n‑dimensional hypercube with dimensions including loan size (a primary item), borrower’s credit rating, loan maturity, borrower type, loan purpose, and other dimensions.
The purpose of a template taxonomy is to define the structures of the hypercubes and link the hypercubes with the primary items.
1.2 Relationship to other work (non-normative)
This document pertains to XBRL as defined in the XBRL Specification [XBRL].
Parts of this document may reiterate for expository clarity certain syntactic and semantic restrictions imposed by XBRL, but this document does not modify XBRL. In the event of any conflicts between this document and XBRL, XBRL prevails. This document does place additional restrictions beyond those prescribed by XBRL.
This document implements the business requirements agreed in the Domain Working Group of the XBRL consortium and documented in the [DIM-REQ] document.
1.3 Terminology (non-normative)
Terminology used in XBRL frequently overlaps with terminology from other fields.
The following terms are used as described in the table below:
|
Term |
Meaning (Normative) |
|
|
Arc, arcroleRef, base set, child, concept, context, duplicate item, descendant, DTS (discoverable taxonomy set), element, entity, fact, instance, item, linkbase, linkbaseRef, p‑equal, roleRef, taxonomy, taxonomy schema, u‑equal, XBRL instance. |
As defined by XBRL [XBRL]. |
|
|
relationship |
An arc defines a relationship between its source concepts and target concepts that is determined by its xlink:arcrole and other attributes. |
|
|
source [concept(s)] |
The concepts identified by the URI content of the href attributes of the locator-type elements in the same extended-type link element, which have the same label attribute content as the content of the “from” attribute of an arc. |
|
|
target [concept(s)] |
The concepts identified by the URI content of the href attributes of the locator-type elements in the same extended-type link element, which have the same label attribute content as the content of the “to” attribute of an arc. |
|
|
must, must not, required, shall, shall not, should, should not, may, optional
|
See [RFC2119] for definitions of these and other terms. These include, in particular: should: Conforming documents and applications are encouraged to behave as described. must: Conformant documents and consuming applications are required to behave as described; otherwise they are in error. |
|
|
XDT Compliant (XDT-compliant) |
Describes an element, attribute, linkbase, schema, instance document or DTS satisfying all applicable mandatory (“must”) rules in this document. Any of such artefacts that violates or ignores a recommended (“should”) rule is inferior to one that obeys it and should not be emulated. |
|
|
XBRL |
Extensible Business Reporting Language (XBRL) 2.1 Recommendation [XBRL]. |
|
|
XBRL valid (XBRL-valid) |
XML instances and schemas that satisfy the syntax requirements of XBRL. |
|
|
Dimension |
Each of the different aspects by which a fact may be characterised. A dimension has only one effective domain. A typical example of a dimension is the “product” dimension that identifies for a concept (Sales) the domain consisting of the possible products that its fact can be expressed about. Dimensions are abstract elements in the substitution group of xbrldt:dimensionItem. |
|
|
Domain |
A (possibly empty or possibly infinite) set of members. A typical example could be the Longitude and Latitude dimensions. The numbers from -180 to +180 are a domain. In this case, both dimensions have the same domain. (In real life longitude is in a domain from -90 to +90 and latitude is in a domain from -180 to +180, but we are assuming both are the same for demonstration purposes only) |
|
|
Effective Domain |
A dimension may have multiple dimension-domain relationships; the effective domain is the conjoint set of all related domains. |
|
|
Domain Member / Valid Member |
Each one of the possibilities in the domain of a Dimension. Explicit domains are defined by domain-member relations. Example: In the “Products Dimension” an explicit domain can be created with each one of the products as a domain-member. Domain member items are in the substitution group of xbrli:item. |
|
|
Explicit Dimension |
Occurs when the domain explicitly names its members. The “Products Dimension” in the example above could be an explicit dimension. Explicit dimensions are defined by dimension-domain relations. |
|
|
Typed Dimension |
Occurs when the number of members is impractically large to enumerate explicitly. The “Longitude and Latitude” dimensions in the example above are typed dimensions because the domain is made of the infinite numbers in the range of -180 and +180. |
|
|
Empty Dimension |
An Explicit Dimension with no domain. |
|
|
Primary Item |
An XBRL v2.1 item. [XBRL] |
|
|
Primary Item Declaration |
The declaration of XBRL v2.1 item in a taxonomy. |
|
|
Primary Item Descendant |
Any child, grand-child etc. of a Primary Item according to the domain-member relationship. |
|
|
Primary Taxonomy |
A primary taxonomy is a taxonomy that contains primary items. |
|
|
Dimensional Taxonomy |
A taxonomy whose schema-rooted DTS includes a definition linkbase with one or more arcs defined in this specification. |
|
|
Template Taxonomy |
A taxonomy that defines hypercubes and the relationships between the hypercubes and primary items. |
|
|
Hypercube |
A hypercube represents a set of dimensions. Hypercubes are abstract elements in the substitutionGroup of hypercubeItem that participate in has-hypercube relations and hypercube-dimension relations. |
|
|
Empty Hypercube |
A hypercube with no dimensions. |
|
|
Hypercube Declaration |
The declaration of a hypercube in a schema document. This is represented by an abstract element declaration in the xbrldt:hypercubeItem substitution group |
|
|
Dimension Declaration |
The declaration of a dimension in a schema document. This is represented by an abstract element declaration in the xbrldt:dimensionItem substitution group |
|
|
Typed Dimension Element |
Refers to the non XBRL element used in the segment or scenario of a context as the dimension identifier. |
|
|
Dimensional relationship set |
A set of relationships constructed by traversing relationships (as described in section 2.4) not only within base sets but across base sets, thus possibly including relationships from extended-type links with different roles, and relationships with different arc roles. |
|
|
Base Set |
As defined in 3.5.3.9.7.3 Networks of relationships in a DTS in the [XBRL] specification. |
|
|
Dimensional Processor |
A dimensional processor consumes XBRL dimensional instance documents or taxonomies and checks the conformance of that input document according to the rules declared in this document. |
|
|
Raise an error |
The phrase “a dimensional processor MUST raise an error” means that a dimensional processor MUST signal something to the consuming application that is calling the validation process. The specific type of signal is application dependent. An example of how XPath signals its errors can be seen in http://www.w3.org/TR/xquery-operators/#func-error |
|
1.4 Document conventions (non-normative)
The following highlighting is used to present normative technical material in this document:
|
|
The following formatting is used for non-normative examples in this document:
The following formatting is used for non-normative counterexamples (examples of poor, discouraged or disallowed usage) in this document:
1.5 Namespaces (normative)
This table contains all the prefixes used within the text and the correspondent namespace URI:
|
Prefix |
Namespace URI |
|
xbrldt |
http://xbrl.org/2005/xbrldt |
|
xbrldi |
http://xbrl.org/2006/xbrldi |
|
xbrldte |
http://xbrl.org/2005/xbrldt/errors |
|
xbrldie |
http://xbrl.org/2005/xbrldi/errors |
|
xbrli |
|
|
xs |
|
|
xlink |
|
|
link |
http://www.xbrl.org/2003/linkbase |
The Prefix column in the table above is non normative. The Namespace URI column is normative.
2 Dimensional Taxonomies (normative)
2.1 Architecture (normative)
In XBRL Instances, certain elements defined by this specification are distinguished by the use of elements in the namespace http://xbrl.org/2006/xbrldi which is conventionally prefixed “xbrldi”; these elements appear within the scenario and segment elements only. XBRL instances are validated according to the syntax constraints implied by the typed dimensions (which require XML Schema validation and nothing more) and by the explicit dimensions (which require description of each member element and relationships among the members using linkbases).
Dimensional taxonomies are distinguished by the use of several arc roles. These arc roles and associated attribute declarations are in the appinfo section of an XML schema.
The namespace of the schema is http://xbrl.org/2005/xbrldt. The prefix xbrldt is used in this document to refer to elements and attributes defined in that schema.
Dimensional taxonomies MAY import the xbrldt schema and MUST be schema valid according to schema rules defined in [SCHEMA-1][SCHEMA‑2]. Dimensional taxonomies according to this specification MUST also be valid XBRL 2.1 [XBRL] taxonomies.
XBRL instances using the elements defined in xbrldi-2006.xsd MUST be XML Schema valid according to validation rules defined in [SCHEMA-1] [SCHEMA‑2]. XBRL instances whose DTS includes dimensional taxonomies MUST be also valid instances according to the XBRL 2.1 [XBRL] specification.
Figure 1. Relationships to define constraints on the content and meaning of contexts
Figure 1 schematically shows the various relationships and the type of elements at their source and target, and the purpose that these elements serve either as primary items, explicit domain members, or as the root item that represents an entire dimension (typed or explicit). These relationships need not all be within the same extended-type link element; the xbrldt:targetRole attribute is used to connect the different pieces from Primary Items to Members across multiple extended-type link elements. The notation {all, notAll} means that there are two possible relationships. Additional attributes on the arc (xbrldt:closed, xbrldt:usable, xbrldt:typedDomainRef and xbrldt:contextElement) and their types are shown on the arcs where they may appear.
[Def, 1] 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.
Only XBRL items defined in the substitution group of xbrli:item may be used as an explicit dimension member.
[Def, 2] Consecutive relationships are two relationships connected together according to the rules specified in section 2.1.1.
[Def, 3] The Dimensional relationship set (DRS) is the set of consecutive relationships [Def, 2] that represents the relationships between a primary item declaration [Def, 1] and its multidimensional metadata. Figure 1 demonstrates a DTS.
The following sections in this chapter each define a syntax component and its consequences for validation (its semantics) with positive and negative examples. The rules of syntax that apply to dimensional schemas, linkbases and instances are stated individually within each section.
2.1.1 Consecutive relationships
Two relationships may be consecutive. A pair of consecutive relationships consists of an initial relationship and a following relationship. For two relationships to be consecutive:
1. The value of the xlink:arcrole attribute on the arc that represents the initial relationship and the value of the xlink:arcrole attribute on the arc that represents the following relationship MUST correspond to one of the ordered pairs of arcrole values listed in Table 1; and
2. The set of nodes pointed to by locators identified by the xlink:to attribute of the arc that represents the initial relationship MUST be the same set of nodes pointed to by locators identified by the xlink:from attribute of the arc representing the following relationship.
Table 1 arcrole values for potentially consecutive relationships
|
Initial arc |
Following arc |
|
all |
hypercube-dimension |
|
not-all |
hypercube-dimension |
|
hypercube-dimension |
dimension-domain |
|
dimension-domain |
domain-member |
|
domain-member |
domain-member |
2.2 Hypercubes (normative)
[Def, 4] A hypercube declaration is an abstract item declaration in the xbrldt:hypercubeItem substitution group. A hypercube is an ordered list of dimensions, defined by the set of zero or more dimension declarations linked to the hypercube by hypercube-dimension relationships in a dimensional relationship set [Def, 3], and ordered according to the order of these relationships.
|
<xs:element name="hypercubeItem" id="xbrldt_hypercubeItem" abstract="true" substitutionGroup="xbrli:item" type="xbrli:stringItemType" xbrli:periodType="duration"/> |
2.2.1 Constraints on hypercube declarations
1. A dimensional processor MUST raise an error [Dim Err, 1] xbrldte:HypercubeElementIsNotAbstractError if an element that is in the substitution group of xbrldt:hypercubeItem is not abstract.
2.2.2 Arc role http://xbrl.org/int/dim/arcrole/hypercube-dimension
The hypercube-dimension relationship has a hypercube declaration [Def, 4] as its source and a dimension declaration [Def, 7] as its target.
The order of the hypercube-dimension relationship for taxonomy representation purposes in taxonomy editing tools is defined by the value of the order attribute on the arc defining the relationship.
The hypercube-dimension relationship role must not have any directed or undirected cycles.
It is declared as follows:
|
<arcroleType id="hypercube-dimension" cyclesAllowed="none" arcroleURI="http://xbrl.org/int/dim/arcrole/hypercube-dimension"> <definition>Source (a hypercube) contains the target (a dimension) among others.</definition> <usedOn>definitionArc</usedOn> </arcroleType> |
Example 1 shows a hypercube consisting of two typed dimensions, Team and Drink. This example shows a hypercube describing the occurrence of Team and Drink elements in either the segment or scenario element of a context.
Example 1. Hypercube of the Team and Drink typed dimensions
|
|
2.2.2.1 Constraints on hypercube-dimension arcs
1. The source of a hypercube-dimension arc MUST be a hypercube declaration [Def, 4]. A dimensional processor must raise an error [Dim Err, 2] xbrldte:HypercubeDimensionSourceError if this rule is violated.
2. The target of a hypercube-dimension arc must be a dimension declaration [Def, 7]. A dimensional processor must raise an error [Dim Err, 3] xbrldte:HypercubeDimensionTargetError if this rule is violated.