Recommendation, dated 2006-09-18 + Corrected Errata of 2009-09-07
Copyright © 2005, 2006, 2009 XBRL International Inc., All Rights Reserved
This version:
XDT-REC-2006-09-18+Corrected-Errata-2009-09-07.htm
is NON-NORMATIVE. The normative version is in the file XDT-REC-2006-09-18+Corrected-Errata-2009-09-07.rtf.
Authors
|
Name |
Contact |
Affiliation |
|
Ignacio Hernández-Ros |
Reporting Estandar S.L. formerly XBRL International Inc. |
|
|
Hugh Wallis |
XBRL International Inc. |
Contributors
|
Name |
Contact |
Affiliation |
|
David vun Kannon |
Deloitte, formerly PricewaterhouseCoopers |
|
|
Walter Hamscher |
US Securities and Exchange Commission, formerly Standard Advantage |
|
|
Charles Hoffman |
UBmatrix |
|
|
Cliff Binstock |
Coyote Reporting, formerly UBmatrix |
|
|
Herm Fischer |
UBmatrix / Mark V Systems |
|
|
Paul Warren |
CoreFiling Ltd. |
Abstract
This specification allows XBRL taxonomy authors to define and restrict dimensional information that instance authors may use in the segment and scenario elements of the context element of XBRL instance documents. It satisfies XBRL International’s dimensional taxonomy requirements [DIM-REQ]. It is a modular extension to the XBRL 2.1 Specification [XBRL]. It provides a generalised mechanism to define dimensional metadata and to reference it in XBRL instances. Its architecture is such that any XBRL artefacts (instances and their Discoverable Taxonomy Sets) that conform to this specification also conform to the base specification [XBRL] and may be processed without error by any processor that is capable of correctly processing XBRL artefacts, even if those processors are unaware of this modular extension. It is also designed in such a way that it makes maximum use of components of the XBRL 2.1 Specification [XBRL] in its components so as to require a minimum amount of retooling of applications in order to be implemented. Accordingly certain compromises have, of necessity, been made in the design that would not have been made if 100% compatibility with the base specification had not been a requirement.
Status
Circulation of this Recommendation is unrestricted. Recipients of this draft are invited to submit comments to the authors and contributors, and to submit notification of any relevant patent rights of which they are aware and to provide supporting documentation.
Table of Contents
Recommendation, dated 2006-09-18 + Corrected Errata of 2009-09-07
Copyright © 2005, 2006, 2009 XBRL International Inc., All Rights Reserved
1.1.2 Domain members taxonomies
1.2 Relationship to other work
1.3 Terminology (non-normative)
2.1.1 Consecutive relationships
2.2.1 Constraints on hypercube declarations
2.2.2 Arc role http://xbrl.org/int/dim/arcrole/hypercube-dimension
2.3 Primary item declarations and hypercubes
2.3.1 The “all” and “notAll” arc roles
2.3.2 The required “xbrldt:contextElement” attribute on has-hypercube arcs
2.3.3 The optional “xbrldt:closed” attribute on has-hypercube arcs
2.4 Partitioning of a Dimensional relationship set across multiple base-sets. 14
2.4.1 Taxonomy validation impact of splitting dimensional relationship sets
2.4.2 Instance validation impact of splitting dimensional relationship sets
2.4.3 Constraints on the value of a xbrldt:targetRole attribute
2.5.1 Constraints on the dimension declaration
2.6 Domain-member relations and inheritance
2.6.1 Processing of multiple has-hypercube arcs
2.7 Default values for dimensions
2.7.1 Arc role http://xbrl.org/int/dim/arcrole/dimension-default
3 Dimensions in instance documents. 28
3.1 Validation of primary items
3.1.1 Constraints on the validity of primary items
3.1.2 Mutual validity of hypercubes in a base set
3.1.3 Individual validity of hypercubes
3.2 Definition of dimensionally equal facts
B Requirements Reference (non-normative)
2. Intellectual Property Status (non-normative)
3. Acknowledgements (non-normative)
4. Document History (non-normative)
5. Approval process (non-normative)
6. Errata Corrections incorporated in this document
Table of Examples
Example 1. Hypercube of the Team and Drink typed dimensions
Example 2. A primary item declaration with a single hypercube
Example 3. A primary item declaration with two hypercubes composed by conjunction “all” and “notAll”
Example 5. Two closed hypercubes
Example 7. The arc in base set link2 is in the DRS of the arc in base set link1
Example 8. Typed dimension elements and their domains
Example 9. An explicit dimension element and its domain
Example 10. Two primary item declarations inheriting a hypercube
Example 11. Inheritance and processing of multiple hypercubes.
Example 12. Multiple all hypercubes in a domain-member network
Example 13. Automatic inference of default values for summation-item relationships
Example 14. Primary item at the root of a dimensional relationship set
Example 15. Dimensionally invalid context containing two references to the same dimension
Example 16. A segment that is valid with respect to a hypercube
Example 17. Two segments not dimensionally valid with respect to a hypercube
Example 18. Valid and Invalid Hypercubes according to its dimensions and domains
Example 20. Two dimensions referenced in the segment of a context
Example 21. Two dimensions referenced in the scenario of a context
Example 23. Multiple contexts and the result of the d-equal operation
Table of Figures
Figure 1. Relationships to define constraints on the content and meaning of contexts
Figure 2. Valid consecutive relationships between relationship A and relationship B
Figure 3. Combination of multiple hypercubes and the result operation.
Figure 4. Hypercube validity table
Table of Definitions
[Def, 1] Primary item declarations are elements defined in XBRL taxonomies that are in the xbrli:item substitution group and are not in the xbrldt:hypercubeItem or xbrldt:dimensionItem substitution group......... 8
[Def, 10] An explicit dimension is a dimension declaration [Def, 7] that has no xbrldt:typedDomainRef attribute and has dimension-domain arcs to zero or more domain member declarations [Def, 11].................. 20
[Def, 11] A domain member declaration is an element defined in a taxonomy in the xbrli:item substitution group and not in the xbrldt:hypercubeItem or xbrldt:dimensionItem substitution groups................... 20
[Def, 12] A domain of valid members of a explicit dimension is the set of QNames of all usable elements (see 2.5.3.3 below) in the dimensional relationship set [Def, 3] for the domain-member relation rooted at one domain member [Def, 11].............................................................................................................................. 20
[Def, 13] A dimension domain for explicit dimensions is the set of QNames of domain member declarations [Def, 11] in the dimensional relationship set [Def, 3] rooted at the target of a dimension-domain arc and connected together with domain-member arcs........................................................................................................ 21
[Def, 14] The effective domain of a dimension is the union of all dimension domains [Def, 13] declared using dimension-domain arcs that exist for a particular dimension in the dimensional relationship set [Def, 3]. 22
[Def, 15] The dimension value is defined as the QName that is the content value of the explicit dimension container [Def, 16] for explicit dimensions or the XML fragment that is the first child element of the typed dimension container [Def, 16] for typed dimensions. A dimension value [Def, 15] exists for one specific dimension in one of the two possible context containers: segment or scenario. The default values are also possible dimension values but they are not enclosed in dimension containers [Def, 16].......................................................................... 31
[Def, 16] The dimension container is the element xbrldi:typedMember for typed dimensions or the element xbrldi:explicitMember for explicit dimensions....................................................................... 31
[Def, 17] The default value is the QName of the default member........................................... 31
[Def, 18] Two facts are d-equal for one dimension if they have the same dimension value [Def, 15] for that dimension 37
[Def, 2] Consecutive relationships are two relationships connected together according to the rules specified in section 2.1.1..................................................................................................................................... 8
[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. 8
[Def, 4] A hypercube declaration is an abstract item declaration in the xbrldt:hypercubeItem substitution group. 8
[Def, 5] The source base set is the content of the xlink:role attribute of the relationship’s base set. 15
[Def, 6] The target base set is the content of the targetRole attribute on the arc itself......... 15
[Def, 7] A dimension declaration is an abstract item declaration in the xbrldt:dimensionItem substitution group. 18
[Def, 8] The domain of members is either the instantiation of XML elements according to their XML schema definitions for typed dimensions or the QNames of the members for explicit dimensions.................... 18
[Def, 9] A typed dimension is a dimension declaration [Def, 7] whose domain of members [Def, 8] is defined in another XML element referenced in the xbrldt:typedDomainRef attribute........................................ 19
[Def, 19] A consecutive relationship set is the set of relationships starting at an “all” or “notAll” relationship, and following all subsequent consecutive relationships [Def, 2]
[Def, 20] The instantiation of a primary item declaration [Def, 1] as a fact in an instance document is dimensionally valid with respect to a hypercube
[Def, 21] The instantiation of a primary item declaration [Def, 1] as a fact in an instance document is dimensionally valid with respect to a closed hypercube
1 Introduction
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 with 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 in practice that 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> elements. 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.
All parts of this document not explicitly identified as non-normative are normative. In the event of any conflict or apparent conflict between the English language text of this document and/or schema fragments included in the main body of this document and the normative schemas contained herein, the more restrictive interpretation that is possible from the information provided by the English language text and that provided by the normative schemas SHALL prevail. The schema fragments incorporated into the body of the text are non-normative and are generally indicated as such by means of shading (1.4). The normative schemas do not necessarily always provide the most restrictive interpretation, either because it is not possible to express certain limitations using the syntax of XML Schema or because, as at the time of publication of this specification, some commonly available commercial implementations of XML Schema do not implement otherwise necessary features correctly or fully. The schemas and other documents published separately and contemporaneously with the specification are non-normative and are provided for the convenience of users of this specification.
1.1 Background
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 hereafter 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, this 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 three 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, with longitude and latitude being the two dimensions of a hypercube for that primary item.
· Example: A table in a financial statement showing revenue by products and 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 structure of the hypercubes and link the hypercubes with the primary items.
1.2 Relationship to other work
This document pertains to XBRL as defined in the XBRL 2.1 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 |
|
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. |
|
Term |
Meaning (non-normative) |
|
|
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] 2.1 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
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:
Non-normative editorial comments are denoted as follows and removed from final recommendations:
1.5 Namespaces
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
2.1 Architecture
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 typed dimensions (which require XML Schema validation and nothing more) and by 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 their 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 specification [XBRL].
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 element (abstract, xbrldt:typedDomainRef) or arc (xbrldt:closed, xbrldt:usable 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 group 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 DRS.
The following sub-sections in this section 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
[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 attribute 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.
2.3 Primary item declarations and hypercubes
To constrain the set of contexts that may appear on primary items, a primary item declaration may be associated with zero or more hypercubes.
This specification defines no additional constraints on primary items whose corresponding primary item declaration is not associated with any hypercubes in the applicable DTS.
A set of hypercubes may be composed via conjunction of “all” and “notAll” compositors. The relationship between a compositor and its operands is represented by XLink arcs with distinct arc roles to define the different operators.
There are two arc roles collectively known as has‑hypercube relationships:
· http://xbrl.org/int/dim/arcrole/all,
· http://xbrl.org/int/dim/arcrole/notAll.
These relationships may be in different base sets. When has-hypercube relationships are in different base sets, a primary item that is dimensionally valid in any base set is dimensionally valid.
These relationships allow prohibition, overriding, and augmentation in extension taxonomies.
2.3.1 The “all” and “notAll” arc roles
Relationships in the dimensional relationship set [Def, 3] of an http://xbrl.org/int/dim/arcrole/all relationship are relevant to instance validation. The source and target are primary item declarations and hypercube declarations [Def, 4], respectively.
The negated version of the “all” relationship is the “notAll” relationship defined as http://xbrl.org/int/dim/arcrole/notAll
The instantiation of a primary item declaration [Def, 1] in an instance document is dimensionally valid with respect to a conjunction of hypercubes only if it is valid with respect to all of the conjoined hypercubes individually. A negated hypercube “notAll” is valid if the non negated version of the same hypercube definition is invalid. The conjunction of a single hypercube is the hypercube itself (Example below).
Example 2. A primary item declaration with a single hypercube
|
|
|
The primary item declaration p_FluidCapacity is associated with a hypercube. A context will be dimensionally valid with respect to this primary item only if it has a Team and a Drink reference. |
Example 3. A primary item declaration with two hypercubes composed by conjunction “all” and “notAll”
|
|
|
The primary item declaration p_FluidCapacity is associated with the composition of two hypercubes in the same base set. A context will be valid with respect to the primary item only if it has a City reference in its segment that is a member of the hc_CityHypercubeAll and not a member of hc_CityHypercubeExcluded. |
The http://xbrl.org/int/dim/arcrole/all arc role is declared as follows:
|
<arcroleType id="all" cyclesAllowed="undirected" arcroleURI="http://xbrl.org/int/dim/arcrole/all"> <definition>Source (a primary item declaration) requires a combination of dimension members of the target (hypercube) to appear in the context of the primary item.</definition> <usedOn>definitionArc</usedOn> </arcroleType> |
The http://xbrl.org/int/dim/arcrole/notAll arc role is declared as follows:
|
<arcroleType id="notAll" cyclesAllowed="undirected" arcroleURI="http://xbrl.org/int/dim/arcrole/notAll"> <definition>Source (a primary item declaration) requires a combination of dimension members of the target (hypercube) not to appear in the context of the primary item.</definition> <usedOn>definitionArc</usedOn> </arcroleType> |
Example 4. A primary item with domain members and a negated hypercube that limits the values for the country dimension of p_CostOfSales by removing m_India from the domain
|
|
|
The primary item declaration p_GrossProfit has two children in the domain-member network. The valid members in the hc_CountriesDim dimension are {CountriesDomain | m_Argentina | m_France | m_India | m_Spain} for p_GrossProfit and p_Sales but p_CostOfSales has only {CountriesDomain | m_Argentina | m_France | m_Spain} possibilities in the country dimension (m_India has been removed from the domain). |
2.3.1.1 Constraints on “all” or “notAll” arcs
1. A dimensional processor MUST raise an error [Dim Err, 4] xbrldte:HasHypercubeSourceError if the source of an “all” or “notAll” arc is not a primary item declaration [Def, 1].
2. A dimensional processor MUST raise an error [Dim Err, 5] xbrldte:HasHypercubeTargetError if the target of an “all” or “notAll” arc is not a hypercube declaration [Def, 4].
3. A has-hypercube arc MUST have an xbrldt:contextElement attribute. A dimensional processor MUST raise an error [Dim Err, 6] xbrldte:HasHypercubeMissingContextElementAttributeError if this rule is violated.
2.3.2 The required “xbrldt:contextElement” attribute on has-hypercube arcs
Every has-hypercube arc must have an xbrldt:contextElement attribute.
|
<xs:simpleType name="contextElementType"> <xs:restriction base="xs:token"> <xs:enumeration value="segment"/> <xs:enumeration value="scenario"/> </xs:restriction> </xs:simpleType> <xs:attribute name="contextElement" type="xbrldt:contextElementType"/> |
2.3.2.1 Constraints on the value of the xbrldt:contextElement attribute
1. According to the xbrldt XML Schema, the xbrldt:contextElement attribute must have one of the values segment or scenario.
2.3.3 The optional “xbrldt:closed” attribute on has-hypercube arcs
The optional Boolean attribute xbrldt:closed may appear on has‑hypercube arcs.
|
<xs:attribute name="closed" type="xs:boolean" default="false"/> |
If the xbrldt:closed attribute is specified with a true value on a has‑hypercube arc with the value segment for the xbrldt:contextElement attribute, the hypercube is closed with respect to the segment element in that base set.
If the xbrldt:closed attribute is specified with a true value on a has‑hypercube arc with the value scenario for the xbrldt:contextElement attribute, the hypercube is closed with respect to the scenario element in that base set.
[Def, 20] The instantiation of a primary item declaration [Def, 1] as a fact in an instance document is dimensionally valid with respect to a hypercube when:
· For every dimension of the hypercube for which the primary item has a has-hypercube relationship, either:
a. The has-hypercube relationship has xbrldt:contextElement="segment" and the segment dimensional container [Def, 16] of the fact’s context has a dimension value [Def, 15] for that dimension, or
b. The has-hypercube relationship has xbrldt:contextElement="scenario" and the scenario dimensional container [Def, 16] of the fact’s context has a dimension value [Def, 15] for that dimension, or
c. The dimension has default value [Def, 17].
[Def, 21] The instantiation of a primary item declaration [Def, 1] as a fact in an instance document is dimensionally valid with respect to a closed hypercube when:
· The fact is dimensionally valid with respect to the hypercube [Def, 20] and
· For every dimension value [Def, 15] in the segment dimensional container [Def, 16] of the fact’s context, the dimension of that value is a dimension of the closed hypercube, and
· For every dimension value [Def, 15] in the scenario dimensional container [Def, 16] of the fact’s context, the dimension of that value is a dimension of the closed hypercube.
Example 5. Two closed hypercubes
|
|
|
The arcs with xbrldt:closed="true" mean that a context is valid with respect to the target hypercube if it has a Team and Drink and nothing else in the segment element, and nothing at all in the scenario element. Note that the all arc to hc_Team_x_Drink has segment in its xbrldt:contextElement attribute and the all arc to hc_Empty has scenario in its xbrldt:contextElement attribute. |
2.3.3.1 Constraints on the value of the xbrldt:closed attribute
1. According to the xbrldt XML Schema, the xbrldt:closed attribute, if present, must have a Boolean value.
2.4 Partitioning of a Dimensional relationship set across multiple base-sets
Taxonomy authors are able to partition relationships into distinct base sets using the xlink:role attribute on extended-type link elements.
However, it is more than a useful feature. In the case of summation‑item relationships in the calculation linkbase, partitioning is essential to ensure that incompatible summations are not commingled. Taxonomy authors may specify distinct base sets of dimensional relationships that a validating process would apply separately. To forbid this would violate P2 (Consistency, Appendix B).
Furthermore, a set of primary item declarations may have hypercubes in common among the targets of their has‑hypercube relationships. Hypercube declarations, in turn, may have typed dimensions in common among the targets of their hypercube-dimension relationships. In sections 2.5.2 and 2.5.3 below, additional relationships will also introduce tangled graphs, with some items as the source of separate and distinct sets of relationships to define different dimensions. If all the dimensional relationships used together in a validation were forced to be in the same base set, there would be redundancy among dimensional relationships, violating P4 (Irredundancy, Appendix B).
Example 6. When the same dimension must have different domain members, partitioning among different extended-type link elements and a mechanism to indicate the extended link flow must be implemented. xbrldt:targetRole is used for this purpose.
|
|
|
The RegionDim dimension must have different members when it is part of hc_ExcludeRegions cube and when it is part of the hc_AllRegions cube. |
The optional xbrldt:targetRole attribute on an arc allows a taxonomy author to connect together two arcs that represent a consecutive relationship [Def, 2] that exist in different roles. As declared in this document, the xbrldt:targetRole attribute MAY appear on definition arcs having the following arc roles: all, notAll, hypercube-dimension, dimension‑domain and domain‑member. The xbrldt:targetRole attribute has the type anyURI. Resolution of the URI is not subject to the presence of an xml:base attribute and its value must be an absolute URI.
|
<xs:attribute name="targetRole" type="xs:anyURI"/> |
[Def, 5] The source role is the content of the xlink:role attribute of the relationship’s base set. In Figure 2 it is identified as role(arc).
[Def, 6] The target role is the content of the targetRole attribute on the arc itself. In Figure 2 it is identified as targetRole(arc).
Two arcs that represent a consecutive relationship [Def, 2] that exist in different extended-type link elements MUST be connected together using the xbrldt:targetRole attribute. Not doing so causes the construction to be unconnected and results in, for example, empty hypercubes, dimensions and domains.
The xbrldt:targetRole attribute is optional. If it is present on a relationship, any other relationship that represents a consecutive relationship [Def, 2] in the source role [Def, 5] MUST NOT be considered as part of the dimensional relationship set [Def, 3]. Instead, relationships representing consecutive relationships [Def, 2] in the target role [Def, 6] MUST be considered for the construction of the dimensional relationship set [Def, 3].
Figure 2. Valid consecutive relationships between relationship A and relationship B
|
Arc role of Relationship A |
Arc role of Relationship B with a source among the targets of Relationship A |
|||
|
all, notAll |
hypercube-dimension |
Dimension‑domain |
domain‑member |
|
|
all, notAll |
False |
role(B) Î targetRole(A) |
False |
False |
|
hypercube-dimension |
False |
False |
role(B) Î targetRole(A) |
False |
|
dimension‑domain |
False |
False |
False |
role(B) Î targetRole(A) |
|
domain‑member |
False |
False |
False |
role(B) Î targetRole(A) |
Example 7. The arc in base set link2 is in the DRS of the arc in base set link1
|
|
|
<definitionLink xlink:type="extended" xlink:role="http://example.com/role/link1" id="link1"> <loc xlink:type="locator" xlink:href="m-2005-07-23.xsd#m_AllRegions" xlink:label="AllRegions"/> <loc xlink:type="locator" xlink:href="m-2005-07-23.xsd#m_SouthAmerica" xlink:label="SouthAmerica"/> <definitionArc xlink:type="arc" xbrldt:targetRole="http://example.com/role/link2" xlink:arcrole="http://xbrl.org/int/dim/arcrole/domain-member" xlink:from="AllRegions" xlink:to="SouthAmerica" order="1.0"/> </definitionLink> <definitionLink xlink:type="extended" xlink:role="http://example.com/role/link2" id="link2"> <loc xlink:type="locator" xlink:href="m-2005-07-23.xsd#m_SouthAmerica" xlink:label="SouthAmerica"/> <loc xlink:type="locator" xlink:href="m-2005-07-23.xsd#m_Argentina" xlink:label="Argentina"/> <definitionArc xlink:type="arc" xlink:arcrole="http://xbrl.org/int/dim/arcrole/domain-member" xlink:from="SouthAmerica" xlink:to="Argentina" order="1.0"/> </definitionLink> |
2.4.1 Taxonomy validation impact of splitting dimensional relationship sets
Splitting dimensional relationship sets [Def, 3] into multiple roles impacts the validity of XBRL taxonomies. Consecutive relationships [Def, 2] having the same arcrole MUST not violate the cyclesAllowed constraint that would normally apply within in a base set.
The xbrldt:targetRole attribute itself must contain a declared role.
2.4.2 Instance validation impact of splitting dimensional relationship sets
Splitting dimensional relationship sets [Def, 3] into multiple roles does not impact the validity of XBRL instances according to this specification. The rules in section 3.1 below, “Validation of primary items,” have the same meaning irrespective of whether the dimensional relationship set [Def, 3] is defined in one role or in multiple roles.
2.4.3 Constraints on the value of a xbrldt:targetRole attribute
1. If the value, V, of the xbrldt:targetRole attribute on a definitionArc is not the standard extended link role (http://www.xbrl.org/2003/role/link), the ancestor linkbase element of the definitionArc element MUST have a child roleRef element with V as the value of its roleURI attribute. A dimensional processor must raise an error [Dim Err, 7] xbrldte:TargetRoleNotResolvedError if this constraint is not satisfied.
2. [Def, 19] A consecutive relationship set is the set of relationships starting at an “all” or “notAll” relationship, and following all subsequent consecutive relationships [Def, 2]. A dimensional processor MUST raise an error [Dim Err, 8] xbrldte:DRSDirectedCycleError for each consecutive relationship set [Def, 19] that contains a directed cycle.
3. According to the xbrldt XML Schema, the content of the xbrldt:targetRole attribute must be a valid URI.
2.5 Dimensions
[Def, 7] A dimension declaration is an abstract item declaration in the xbrldt:dimensionItem substitution group.
|
<xs:element name="dimensionItem" id="xbrldt_dimensionItem" abstract="true" substitutionGroup="xbrli:item" type="xbrli:stringItemType" xbrli:periodType="duration"/> |
The xbrli:balance, xbrli:periodType and nillable attributes of a dimension item declaration have no significance.
There are two dimension types in this specification: Typed dimensions and Explicit dimensions. The dimension declaration is referenced by using its QName in a dimension attribute in the dimension container [Def, 16] element in the context elements of XBRL instances. The value of those dimension container [Def, 16] elements MAY be a QName for explicit dimensions or a complex type XML element for typed dimensions.
A non empty dimension has a domain of members.
[Def, 8] The domain of members is either the instantiation of XML elements according to their XML schema definitions for typed dimensions or the QNames of the members for explicit dimensions.
The domain of elements for typed dimensions is represented by a global element definition in an XML schema. See section 2.5.2 below.
The domain of members for explicit dimensions is composed by traversing the arcs that connect the dimension with the domain and the domain with the members. See section 2.5.3 below.
2.5.1 Constraints on the dimension declaration
1. A dimensional processor MUST raise an error [Dim Err, 9] xbrldte:DimensionElementIsNotAbstractError if an element that is in the substitution group of xbrldt:dimensionItem is not abstract.
2.5.2 Typed dimensions
[Def, 9] A typed dimension is a dimension declaration [Def, 7] whose domain of members [Def, 8] is defined in another XML element referenced in the xbrldt:typedDomainRef attribute.
A typed dimension must have nonempty content for the attribute xbrldt:typedDomainRef.
The xbrldt:typedDomainRef is an xlink:href to an element declaration in an XML Schema that defines the dimension domain.
In the instance document below, a typed dimension value [Def, 15] is the child of an xbrldi:typedMember element that has a dimension attribute whose value locates the typed dimension element declaration.
Example 8. Typed dimension elements and their domains
|
Dimension item declaration in tax.xsd |
Domain declaration in schema.xsd |
Domain members in instance.xbrl |
|
<element name="dCustomer" id="tax_dCustomer" substitutionGroup="xbrldt:dimensionItem" type="xbrli:stringItemType" abstract="true" xbrli:periodType="duration" xbrldt:typedDomainRef="schema.xsd#id_cust" /> |
<element name="cust" id="id_cust"> <simpleType> <restriction base="string"> <pattern value="[0-9][0-9][0-9][0-9][0-9]"/> </restriction> </simpleType> </element> |
<xbrldi:typedMember dimension="tax:dCustomer"> <cust>12345</cust> </xbrldi:typedMember>
<xbrldi:typedMember dimension="tax:dCustomer"> <cust>01742</cust> </xbrldi:typedMember> |
|
<element name="dPhone" id="tax_dPhone" substitutionGroup="xbrldt:dimensionItem" type="xbrli:stringItemType" abstract="true" xbrli:periodType="duration" xbrldt:typedDomainRef="schema.xsd#id_phone" />
|
<element name="phone" id="id_phone" xsi:nillable="true"> <complexType> <sequence> <element name="country" type="integer"/> <element name="city" type="integer"/> <element name="number" type="integer"/> </sequence> </complexType> </element> |
Elements valid for the domain type, such as:
<xbrldi:typedMember dimension="tax:dPhone"> <phone> <country>7</country> <city>7</city> <number>5555555</number> </phone> </xbrldi:typedMember>
<xbrldi:typedMember dimension="tax:dPhone"> <phone xsi:nil="true"/> </xbrldi:typedMember> |
The separation of the dimension item from the element actually appearing in the instance is necessary because sections 5.2.6, 5.2.6.1 and 5.2.6.2 of the [XBRL] 2.1 specification states that relationships in the definition linkbase may only have a target in the xbrli:item or xbrli:tuple substitution group, but such a restriction on the domain itself would be neither necessary nor desirable.
2.5.2.1 The xbrldt:typedDomainRef attribute
The xbrldt:typedDomainRef attribute is used in a typed dimension element to locate the element in an XML Schema that defines the content of the typed dimension.
The value of the xbrldt:typedDomainRef attribute MUST be an URI reference as defined in [RFC3986]. The value of xbrldt:typedDomainRef MUST have a fragment identifier conformant with the section 3.2 of the XPointer framework [XPTR].
The URI referenced in the xbrldt:typedDomainRef attribute has the type anyURI. If the URI reference is relative, before use its absolute version MUST be computed by the method of [XML Base].
|
<xs:attribute name="typedDomainRef" type="xs:anyURI"/> |
The schema pointed to by the xbrldt:typedDomainRef MUST be part of the DTS.
2.5.2.1.1 Constraints on the xbrldt:typedDomainRef attribute
1. A dimensional processor MUST raise an error [Dim Err, 10] xbrldte:OutOfDTSSchemaError if the xbrldt:typedDomainRef attribute points to a schema that is not included in the taxonomy DTS.
2. A dimensional processor MUST raise an error [Dim Err, 11] xbrldte:TypedDomainRefError if the xbrldt:typedDomainRef attribute appears on an XML Schema element declaration that is not a dimension declaration [Def, 7].
3. A dimensional processor MUST raise an error [Dim Err, 12] xbrldte:TypedDimensionError if the xbrldt:typedDomainRef attribute locates (with xml:base and following definition in section 3.2 of [XPTR]) any of the following:
· Nothing
· Something that is not a global XML Schema element declaration
· A global abstract element declaration.
4. A dimensional processor MUST raise an error [Dim Err, 13] xbrldte:TypedDimensionURIError if the xbrldt:typedDomainRef attribute does not contain a fragment identifier.
5. According to the xbrldt XML Schema, the content of the xbrldt:typedDomainRef attribute must be a valid URI.
2.5.3 Explicit dimensions
[Def, 10] An explicit dimension is a dimension declaration [Def, 7] that has no xbrldt:typedDomainRef attribute and has dimension-domain arcs to zero or more domain member declarations [Def, 11] whose QNames comprise the dimension domain [Def, 8].
[Def, 11] A domain member declaration is an element defined in a taxonomy in the xbrli:item substitution group and not in the xbrldt:hypercubeItem or xbrldt:dimensionItem substitution groups.
[Def, 12] A domain of valid members of a explicit dimension is the set of QNames of all usable elements (see 2.5.3.3 below) in the dimensional relationship set [Def, 3] for the domain-member relation rooted at one domain member [Def, 11]. This is the effective domain [Def, 14] without the elements that are marked as not usable.
The domain members, therefore, inherit all the features of XBRL items, such as labels in multiple languages, presentation ordering, references, and extensibility of relations through prohibition, overrides, and augmentation. The members of the domain may also be arranged into a relationship domain‑member that satisfies the requirements for an inclusion relationship [DIM-REQ].
The domain of an explicit dimension is represented by the target item of a dimension‑domain relationship whose source is the explicit dimension element. The QName of the domain item is a valid member of the domain.
According to the architecture defined in Figure 1 above, primary items and explicit dimension domain members are both in the substitution group of xbrli:item. A primary item defined in a taxonomy can play two different roles in an instance document: it can be used as a member of an explicit dimension in the context of another item or it can be used as an item. The QName of a primary item MUST NOT be a member of the domain of any of its explicit dimensions.
Example 9. An explicit dimension element and its domain
|
Dimension Item Declaration in a taxonomy schema |
Domain Members Declaration in a taxonomy schema |
Domain Members in XBRL instances |
|
<xs:element name="ContinentDim" type="xbrli:stringItemType" abstract="true" substitutionGroup="xbrldt:dimensionItem" nillable="true" id="geo_ContinentDim" xbrli:periodType="instant"/>
|
<xs:element name="SouthAmerica" id="geo_SouthAmerica" type="xbrli:decimalItemType" substitutionGroup="xbrli:item" nillable="true" xbrli:periodType="instant"/>
<xs:element name="Continent" id="geo_Continent" type="xbrli:decimalItemType" substitutionGroup="xbrli:item" nillable="true" xbrli:periodType="instant"/> |
QNames (assuming that the namespace prefix of the targetNamespace is geo and there is a domain‑member arc from Continent to SouthAmerica):
geo:Continent geo:SouthAmerica |
2.5.3.1 Arc role http://xbrl.org/int/dim/arcrole/dimension-domain
A dimension‑domain relationship has an explicit dimension declaration [Def, 10] as its source and any domain member declaration [Def, 11] as its target. It binds a dimension to a domain.
The xbrli:balance, xbrli:periodType and nillable attributes of a domain declaration have no significance.
The arc may have a nonempty xbrldt:usable attribute as stated in 2.5.3.3 below.
The http://xbrl.org/int/dim/arcrole/dimension-domain arc role is declared as follows:
|
<arcroleType id="dimension-domain" cyclesAllowed="none" arcroleURI="http://xbrl.org/int/dim/arcrole/dimension-domain"> <definition>Source (a dimension) has only the target (a domain) as its domain.</definition> <usedOn>definitionArc</usedOn> </arcroleType> |
2.5.3.1.1 Constraints on the dimension-domain arcs
1. A dimensional processor must raise an error [Dim Err, 14] xbrldte:DimensionDomainSourceError if the source of the arc is not a explicit dimension declaration [Def, 10].
2. A dimensional processor must raise an error [Dim Err, 15] xbrldte:DimensionDomainTargetError if the target of the arc is not a domain member declaration [Def, 11].
3. A dimensional processor MUST raise an error [Dim Err, 16] xbrldte:PrimaryItemPolymorphismError if there is a cycle in which the primary item source of the hypercube is also a member of the domain of valid members [Def, 12].
2.5.3.2 Arc role http://xbrl.org/int/dim/arcrole/domain-member
A domain-member relationship binds a domain to a member of a domain. The purpose of this relationship is to create sets of explicit domain members.
[Def, 13] A dimension domain for explicit dimensions is the set of QNames of domain member declarations [Def, 11] in the dimensional relationship set [Def, 3] rooted at the target of a dimension-domain arc and connected together with domain-member arcs.
The base set of a domain-member relationship MAY have undirected cycles but MUST NOT have directed cycles.
The http://xbrl.org/int/dim/arcrole/domain-member arc role is declared as follows:
|
<arcroleType id="domain-member" cyclesAllowed="undirected" arcroleURI="http://xbrl.org/int/dim/arcrole/domain-member"> <definition>Source (a domain) contains the target (a member).</definition> <usedOn>definitionArc</usedOn> </arcroleType> |
2.5.3.2.1 Constraints on the domain-member arcs
1. A dimensional processor must raise an error [Dim Err, 17] xbrldte:DomainMemberSourceError if the source of a domain-member arc is not a primary item declaration.
2. A dimensional processor must raise an error [Dim Err, 18] xbrldte:DomainMemberTargetError if the target of a domain-member arc is not a primary item declaration.
3. A dimensional processor MUST raise an error [Dim Err, 16] xbrldte:PrimaryItemPolymorphismError if there is a cycle in which the primary item source of the hypercube is also a member of the domain of valid members [Def, 12].
2.5.3.3 The optional xbrldt:usable attribute
The xbrldt:usable attribute is used to denote domain members that must not be used as values of a domain in an instance document. This allows members to be introduced into the domain member hierarchy for the purpose of organising the hierarchy.
The xbrldt:usable attribute may appear on http://xbrl.org/int/dim/arcrole/dimension-domain arcs or on http://xbrl.org/int/dim/arcrole/domain-member arcs.
The default value of the xbrldt:usable attribute is true.
If an arc has an xbrldt:usable attribute whose value is false, its targets are excluded from the domain of valid members.
The exclusion does not affect subsequent children in the domain-member DRS rooted at the excluded element.
[Def, 14] The effective domain of a dimension is the union of all dimension domains [Def, 13] declared using dimension-domain arcs that exist for a particular dimension in the dimensional relationship set [Def, 3].
If during the evaluation of the domain of valid members of a explicit dimension [Def, 12] within the effective domain [Def, 14] of the dimension the same member had xbrldt:usable=false in one dimension domain [Def, 13] and xbrldt:usable=true in another dimension domain [Def, 13] the member MUST be considered as effectively excluded from the domain of valid members of a explicit dimension [Def, 12].
2.5.3.3.1 Constraints on the value of the xbrldt:usable attribute
1. According to the xbrldt XML Schema, the value of the xbrldt:usable attribute must be Boolean.
2.6 Domain-member relations and inheritance
A primary item declaration may be the source of a domain‑member relationship. When a primary item declaration is the source of both a domain‑member relationship and a has‑hypercube relationship, the target of the domain‑member relationship is said to inherit the has-hypercube relationship of the source element. Inheritance is transitive. Inheritance preserves the base set and DRS of the original has‑hypercube relationship, as well as the values of its xbrldt:contextElement attribute and xbrldt:closed attribute.
The example below shows two primary item declarations that have a common ancestor from which they inherit an all relation to a hypercube.
Example 10. Two primary item declarations inheriting a hypercube
|
|
Primary item declarations p_Sales and p_CostOfGoods are not the source of any has‑hypercube arc; they inherit the hypercube hc_Region_x_Product from the primary item declaration p_GrossProfit. They are all roots of the same dimensional base sets. |
A primary item declaration having no direct has‑hypercube relationships may inherit any number of has‑hypercube relationships from its parents in the domain-member network.
The impact of has‑hypercube relationships on instance validation is unchanged merely because the relationships have been inherited.
2.6.1 Processing of multiple has-hypercube arcs
In Example 6 above, the domain-member network created with elements from the primary taxonomy may have multiple has-hypercube arcs at different levels of the tree.
As stated in section 3.1.2 below “Mutual validity of hypercubes in a base set” below, only hypercubes that are found within the same base set are considered together for validation.
Example 11. Inheritance and processing of multiple hypercubes.
|
|
|||||||||||||||||||||||||||
|
Hypercube inheritance is across the entire dimensional relationship set [Def, 3] of the domain-member network.
In example 12 below there is another example of this particular use case:
Example 12. Multiple all hypercubes in a domain-member network
|
|
||||||||||||||||||||
|
This is the table of the possible values for each primary item:
|
The order in which the has-hypercubes arcs are processed is not relevant to the result.
2.7 Default values for dimensions
Dimensions are allowed to have default values.
The dimension-default relationship specifies which domain member plays the role of the default member for that dimension.
The default values for dimensions are automatically inferred by dimensional processors and MUST not appear in the context of an instance (see 3.1.4.1 below “Obtaining the dimension value for a dimension.”).
The automatic inference of default values for dimensions MAY be used in taxonomies to allow summation-item or other relationships between some specific facts reported without a particular dimension.
Example 13. Automatic inference of default values for summation-item relationships
|
<tx:GrossProfit contextRef="ctx1" unitRef="JPY">100000000</tx:GrossProfit> <tx:GrossProfit contextRef="ctx2" unitRef="JPY">50000000</tx:GrossProfit> <tx:Taxes contextRef="ctx1" unitRef="JPY" >35000000</tx:Taxes> <tx:NetProfit contextRef="ctx1" unitRef="JPY">65000000</tx:NetProfit>
<context id="ctx1"> <entity> <identifier scheme="http://nic.net">example.com</identifier> </entity> <period><forever/></period> </context> <context id="ctx2"> <entity> <identifier scheme="http://nic.net">example.com</identifier> <segment> <xbrldi:explicitMember dimension="tp:ProductDim">p:Cars</xbrldi:explicitMember> </segment> </entity> <period><forever/></period> </context> |
|
In the tx taxonomy only the GrossProfit primary concept has a products dimension, and the default member in the products dimension is the p:TotalProducts member. A calculation network exists in the primary taxonomy tx to represent that NetProfit = GrossProfit – Taxes. The concept GrossProfit for TotalProducts (the one with contextRef="ctx1") is dimensionally valid (ProductDim = p:TotalProducts) and used in summation-items relationships with Taxes and NetProfit. |
2.7.1 Arc role http://xbrl.org/int/dim/arcrole/dimension-default
The dimension-default arc role identifies in its source a dimension element and in its target the default member.
The default member indicated in the target of a dimension-default arc is global. If one dimension-default arc exists in one extended link, then the default member is considered as defined in all the extended links where the dimension is used and the domain contains the domain member indicated in the target of the arc.
The dimension-default relationship is not subject to the effect of the xbrldt:targetRole attribute.
The existence of a dimension-default arc does not add the target item to any of the domains of the source dimension.
The http://xbrl.org/int/dim/arcrole/dimension-default arc role is declared as follows:
|
<arcroleType id="dimension-default" cyclesAllowed="none" arcroleURI="http://xbrl.org/int/dim/arcrole/dimension-default"> <definition>Source (a dimension) declares that there is a default member that is the target of the arc (a member).</definition> <usedOn>definitionArc</usedOn> </arcroleType> |
2.7.1.1 Constraints on dimension-default arcs
1. A dimensional processor MUST raise an error [Dim Err, 19] xbrldte:DimensionDefaultSourceError if the source of the arc is not an explicit dimension declaration [Def, 10].
2. A dimensional processor MUST raise an error [Dim Err, 20] xbrldte:DimensionDefaultTargetError if the target of the arc is not a domain member declaration [Def, 11].
3. A dimension MUST NOT have more than one default member. A dimensional processor MUST raise an error [Dim Err, 21] xbrldte:TooManyDefaultMembersError if this rule is violated.
2.7.1.2 Constraints on instance documents about the member that is the default for a dimension
1. The default member of a dimension MUST NOT appear in a context. A dimensional processor MUST raise an error [Ins Err, 1] xbrldie:DefaultValueUsedInInstanceError when a default member appears.
3 Dimensions in instance documents
Primary taxonomies define the concepts that will be used to represent the facts in a XBRL instance document.
An instance document whose DTS contains dimensional relationships according to this specification MUST be validated using the rules defined in this specification.
NON NORMATIVE NOTE: The validation of the instance document must be made item by item. A dimensional processor must find the hypercubes related to an item in the document DTS and must validate the hypercubes one by one. One hypercube is valid if all its dimensions are valid. A dimension is valid if in the context there is a member of its domain or if the dimension contains a default member. The result of the hypercubes validation must be combined for those hypercubes that coexist in the same base set using the specified operator “all”, “notAll”. One primary item is valid if it is not associated with any hypercube or if there is at least one extended link role in which the primary item is associated to a combination of hypercubes whose combined validation result is valid.
The following sections describe in more detail the rules that apply to the validation of every dimensional component.
3.1 Validation of primary items
Every primary item [Def, 1] that has hypercubes in the DTS of the instance document MUST be valid according to at least one of the base sets in which its hypercubes are defined.
A primary item declaration [Def, 1] is the root of a dimensional relationship set [Def, 3] in a base set when the base set contains at least one has‑hypercube relation (all, notAll) whose source is that primary item declaration [Def, 1].
When a primary item declaration [Def, 1] is the root of a base set, it is also the root of the dimensional relationship set [Def, 3] of that base set.
A dimensionally valid primary item instantiation must be either the source of no dimensional relationship sets [Def, 3], or the root of a dimensional relationship set [Def, 3] in which its context is dimensionally valid.
Example 14. Primary item at the root of a dimensional relationship set
|
|
|
Primary item declaration p_Sales is the root of the dimensional relationship set that includes, among others, all arcs in base set http://example.com/role/link3. |
Whether a primary item declaration [Def, 1] appears inside a tuple has no relevance to whether its primary item instantiation and context are dimensionally valid.
Primary items are dimensionally valid if the hypercubes found in at least one base set are mutually valid.
3.1.1 Constraints on the validity of primary items
1. A primary item is dimensionally valid if the hypercubes found in at least one base set are mutually valid. See 3.1.2 below, “Mutual validity of hypercubes in a base set”. A dimensional processor MUST raise an error [Ins Err, 2] xbrldie:PrimaryItemDimensionallyInvalidError if the hypercube combinations found in all base sets are invalid.
3.1.2 Mutual validity of hypercubes in a base set
A primary item is valid according to the hypercubes defined in a base set if the operation that joins all the hypercubes is satisfied.
Figure 3 below shows the warnings that a dimensional processor MAY raise when a primary item is not valid according to its hypercubes and the operation that combines multiple hypercubes within the same base set.
Figure 3. Combination of multiple hypercubes and the result operation.
|
Nº of cubes |
Operator |
Hypercube(s) evaluation |
Primary Item eval. Result |
Warning |
|
1 |
all |
Valid |
Valid |
No error |
|
1 |
notAll |
Invalid |
Valid |
No error |
|
2 |
all notAll |
Valid Invalid |
Valid |
No error |
|
1 |
all |
Invalid |
Invalid |
There is just one hypercube and is invalid for the all operation |
|
1 |
notAll |
Valid |
Invalid |
There is just one hypercube and is valid for the notAll operation |
|
2 |
all notAll |
Valid Valid |
Invalid |
There are multiple hypercubes defined in a base set and the result of the combination is invalid |
3.1.3 Individual validity of hypercubes
Figure 4. Hypercube validity table
|
Closed |
Empty |
Dimensions |
Dimension values |
Dimension validity |
Result |
|
Yes |
Yes |
N/A |
None |
N/A |
Valid |
|
No |
Yes |
N/A |
N/A |
N/A |
Valid |
|
Yes |
Yes |
N/A |
Dimension values found |
N/A |
Invalid |
|
Yes |
No |
Dim1 and Dim2 |
Dimension value found for Dim1 and Dim2 |
Dim1 OK and Dim2 OK |
Valid |
|
Yes |
No |
Dim1 and Dim2 |
Dimension value found for Dim1 and Dim2 and Dim3 (Note 1) |
N/A |
Invalid |
|
No |
No |
Dim1 and Dim2 |
Dimension value found for Dim1 and Dim2 and Dim3 (Note 2) |
Dim1 OK and Dim2 OK and Dim3 N/A |
Valid |
|
Yes/No |
No |
Dim1 |
Dimension value not found for Dim1 |
N/A |
Invalid |
|
Yes/No |
No |
Dim1 |
Dimension value found for Dim1 |
Dim1 NOT OK |
Invalid |
All dimensions in a hypercube MUST be validated according to rules defined in section 3.1.4 “Validity of dimensions”.
Note 1: Invalid because the hypercube is closed and Dim3 is not expected.
Note 2: This hypercube is open, so Dim3 is allowed.
3.1.3.1 Constraints on the individual validity of hypercubes
1. A closed hypercube must not contain unexpected dimension values. If a closed hypercube contains any unexpected dimension value the hypercube is invalid.
2. There must be a dimension value in the container indicated in the value of the xbrldt:contextElement attribute in the has-hypercube arc. If there is no value for the dimension in the indicated container the hypercube is invalid.
3. All dimensions defined in the hypercube must be valid according to the rules defined in 3.1.4 below. If one dimension is invalid the hypercube is invalid.
3.1.4 Validity of dimensions
[Def, 15] The dimension value is defined as the QName that is the content value of the explicit dimension container [Def, 16] for explicit dimensions or the XML fragment that is the first child element of the typed dimension container [Def, 16] for typed dimensions. A dimension value [Def, 15] exists for one specific dimension in one of the two possible context containers: segment or scenario. The default values are also possible dimension values but they are not enclosed in dimension containers [Def, 16].
[Def, 16] The dimension container is the element xbrldi:typedMember for typed dimensions or the element xbrldi:explicitMember for explicit dimensions.
A dimension value must be valid according to its domain [Def, 8]. Validation of typed dimensions and explicit dimensions is defined in sections 3.1.4.4 below and 3.1.4.5 below respectively.
3.1.4.1 Obtaining the dimension value for a dimension
A dimensional processor must be able to obtain from the segment or scenario element the value reported for a typed or explicit dimension.
The dimension value content [Def, 15] for typed dimensions is the content of the xbrldi:typedMember element whose dimension attribute value is the QName of the dimension in use.
The dimension value [Def, 15] for explicit dimensions is the QName that is the content of the xbrldi:explicitMember element whose dimension attribute value is the QName of the dimension in use or the QName of the default member if the value is not reported in the instance and the dimension has a default member.
[Def, 17] The default value is the QName of the default member.
3.1.4.2 Constraints about dimension values
1. A context must not contain more than one dimension value [Def, 15] for each dimension. A validator must signal an error [Ins Err, 3]