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 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], and in particular for explicit dimensions, this modular extension to the base XBRL 2.1, Specification [XBRL] defines such a formalisation of the syntax of the body of the <segment> and <scenario> elements. so as to refer to elements from what are termed “dimensional taxonomies”. Such 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
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 three possible different roles that taxonomies can play in representing multidimensional information: measures, explicit dimensions, and templates.
1.1.1 Measure taxonomies
A measure taxonomy is an XBRL taxonomy that has no dimensional definitions. 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 measure taxonomy for a schema‑rooted DTS that represents only a single dimension, the elements that define the members of which are instantiated in an XBRL Instance. A financial taxonomy used for a variety of purposes including internal and external reporting may be extended with a variety of dimensional taxonomies appropriate to the reporting purpose.
1.1.2 Dimensional taxonomies
Implicit dimensional taxonomies as defined in requirement G03 [DIM-REQ] define syntactic constraints on the contents of segments and scenarios using no additional metadata other than what can be represented in XML Schema.
Explicit dimensional taxonomies are those in which the XBRL items form a discrete, countably 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. A dimensional taxonomy can be recognised because it will have an item that is the root of an acyclic graph of domain‑member relationships. 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 contains domain‑member relationships among items in both measure taxonomies and explicit dimension taxonomies. Since a measure taxonomy (by definition) has no dimensional information, there is an implication that the instance-rooted DTS must encompass domain‑member relationships in a linkbase that is not in the schema-rooted DTS of the measure taxonomy.
A template taxonomy imports all dimensional taxonomies with the measures taxonomies and adds the dimensional structures that will be used in the XBRL instance. By convention, a taxonomy that imports measure and dimensional 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 the dimensions needed for a measure. Each dimension in turn is defined over a domain. Note that in this formulation, a hypercube of a measure does not include the measure 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 measure, longitude and latitude being the two dimensions of a hypercube for that measure.
· Example: A table in a financial statement showing revenue for products, by territory, is a 3-dimensional hypercube, with one measure (revenue) and two explicit dimensions (products and territory). A loan report for a bank may be, in effect, an n‑dimensional hypercube with dimensions including loan size (a measure), borrower’s credit rating, loan maturity, borrower type, loan purpose, and other dimensions.
The main purpose of a template taxonomy is to define the structures of the hyper cubes and link the hyper cubes with the measures.
1.2 Relationship to other work
The specifications contained in this document pertain 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 and Specifications Working Groups of the XBRL consortium and documented in the [DIM-REQ] document.
1.3 Terminology
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 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 a 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. |
|
|
Domain |
A (possibly empty or possibly infinite) set of members. |
|
|
Domain Member |
Each one of the possibilities in the domain of a Dimension. Example: In the “Products Dimension” each one of the products in its domain is a Dimension Member. |
|
|
Explicit Dimension |
Occurs when the domain explicitly names its members. |
|
|
Implicit Dimension |
Occurs when the number of members is impractically large to enumerate explicitly. |
|
|
Empty Dimension |
An Explicit Dimension with no domain. |
|
|
Aggregator |
A dimension member that represents the result of summing facts about other members of the same dimension. Example: In the products dimension, the member “TotalProducts” is the aggregator of all possible products. |
|
|
Measure |
A measure is an item whose facts have contexts that contain dimensions. |
|
|
Measure Taxonomy |
A measure taxonomy is an XBRL taxonomy with items that can contain dimensional information |
|
|
Dimensional Taxonomy |
A taxonomy whose schema-rooted DTS includes a definition linkbase with one or more dimensional relationships. |
|
|
Template Taxonomy |
A taxonomy that defines hypercubes and the relationships between the hypercubes and the facts from the measure. |
|
|
Hypercube |
A hypercube is a combination of dimension members. The hypercube is defined by dimension-domain relations. |
|
|
Empty Hypercube |
A hypercube with no dimensions. |
|
|
Dimensional Element |
Refers to any non-measure element declaration used to represent hypercubes, explicit dimensions, implicit dimensions, domains and domain members. |
|
|
Discoverable relationship set |
A set of relationships constructed by traversing relationships and items 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. |
|
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:
2 Dimensional Taxonomies
2.1 Architecture
In XBRL Instances, certain elements that are defined by this specification are distinguished by the use of elements in the namespace http://xbrl.org/2005/xdi which is conventionally prefixed “xdi”; these elements appear within the scenario and segment elements only. XBRL instances are validated according to the syntax constraints implied by the implicit 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 published in the Link Role Registry [LRR]. These arc roles and associated attribute definitions are defined in the appinfo section of an XML schema containing no element definitions (the namespace of the schema file, were it to have elements, would be http://xbrl.org/2005/xdt).
This document describes all the arc roles in detail. Some of the arc roles require that their source or target be abstract, not abstract, numeric, string, or other types. These abstract elements function for the definition of the dimensional taxonomies in a way that is similar to the way that abstract elements function in the presentation linkbases (see [XBRL] section 5.2.4.2 and Example 48); they never appear in instances, but serve to organize relationships.
Figure 1. Relationships to define constraints on the content 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 measures, explicit dimension members, or as the root item that represents an entire dimension (implicit or explicit). These relationships need not all be within the same extended-type link. The notation {any, all, choice} means that there are three possible relationships. Additional attributes on the arc (i.e., negation and elt) and their types are shown on the arcs where they may appear.
Structured content in XML may be used in the contexts with implicit dimensions.
Any XBRL item defined in a taxonomy may be used as an explicit dimension member.
Each of the sections in this chapter defines 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.2 Segments and scenarios
The XBRL segment and scenario elements are containers having the same content model; it allows one or more elements, whose namespace must be something other than http://www.xbrl.org/2003/instance :
|
<sequence> <any namespace="##other" processContents="lax" maxOccurs="unbounded"/> </sequence> |
2.2.1.1 Segment and scenario elements of a context of a measure may contain any elements allowed by their XBRL content models, unless otherwise constrained by dimensional relationships.
The mere presence of dimensional relationships and items does not by itself change the validation behaviour of an XBRL processor.
2.3 Implicit dimensions
An implicit dimension is represented by an abstract item (as defined by 5.1.1.3 [XBRL]), that is the target of a definition relationship having the arc role http://xbrl.org/dim/arcrole/has-dimension, and that has nonempty content for the attribute dimensionURI. The dimensionURI attribute contains the URI of the definition of an element that defines the domain of the dimension.
The xbrli:balance, xbrli:periodType and nillable attributes of an implicit dimension item have no significance.
In any valid DTS there is a one-to-one relationship between dimension items (that are abstract) and dimension elements (that may appear in segment and scenario elements).
The domain of an implicit dimension contains all XML elements allowed by the type of the element referenced by dimensionURI. The implicit dimension element may have nillable="true" in which case the domain contains that element with nil="true".
Example 1. Implicit dimension elements and their domains
|
Dimension item |
Dimension |
Domain members |
|
<element name="dCustomer" substitutionGroup="xbrli:item" abstract="true" xbrli:periodType="duration" xdt:dimensionURI=="#id_phone" /> |
<element name="cust"> <simpleType> <restriction base="string"> <pattern value="[0-9][0-9][0-9][0-9][0-9]"/> </restriction> </simpleType> </element> |
<cust>12345</cust> <cust>01742</cust> |
|
<element name="dPhone" substitutionGroup="xbrli:item" abstract="true" xbrli:periodType="duration" xdt:dimensionURI="#id_phone" />
|
<element name="phone" id="id_phone" xsi:nillable="true"> <complexType name="phone" id="id_phone"> <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:
<phone> <country>7</country> <city>7</city> <number>5555555</number> </phone>
<phone xsi:nil="true"/> |
The separation of the dimension item from the element actually appearing in the instance is necessary because 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.3.1 Attribute dimensionURI
The dimensionURI attribute has type anyURI. Resolution of the URI is subject to the presence of an xml:base attribute.
|
<xs:attribute name="dimensionURI" type="xs:anyURI"/> |
2.3.1.1 If the dimensionURI attribute appears in an element declaration, the element must be an abstract item.
A validator must signal xde:DimensionURIError if the dimensionURI attribute appears on an XML Schema element definition that is not in a substitution group of xbrli:item with abstract="true".
2.3.1.2 When present, the dimensionURI attribute must locate the definition of a non-abstract element.
A validator must signal xde:ImplicitDimensionError if the dimensionURI attribute locates something that is not an XML Schema element definition, or a definition that is not an element definition, or is not abstract.
2.3.1.3 Distinct items in a DTS having dimensionURI attributes must not refer to the same dimension element.
A validator must signal xde:DuplicateImplicitDimension if a dimensionURI attribute locates the same element as another dimensionURI attribute in the same DTS. This rule does not prevent several dimensions from having the same domain but it does allow the appearance of a dimension element in a context to be unambiguously resolved to a dimension item.
2.4 Hypercubes
A hypercube is an abstract item that names a sequence of dimensions. A hypercube is the Cartesian product of a sequence of dimensions. The hypercube item names, and holds relationships to, the dimension items that constrain the syntax of contexts. One of these relationships is the has‑dimension arc role.
2.4.1 Arc role http://xbrl.org/dim/arcrole/has-dimension
The has-dimension relationship has a hypercube item as its source and a dimension item as its target.
A hypercube is the Cartesian product of one or more dimensions. A hypercube and a set of has-dimension relationships in a base set associate the hypercube with the dimensions in that base set.
The order attribute indicates the order in which the dimensions are sequenced to produce a Cartesian product.
The has-dimension relationship role must not have any directed cycles. A validator must signal error xdte:HasDimensionDirectedCycle if this occurs.
A validator must signal xdte:HasDimensionSourceError if the source of the relationship is not an abstract element in the substitution group of xbrli:item.
A validator must signal xdte:HasDimensionTargetError if the target of the relationship is not an abstract element in the substitution group of xbrli:item.
This arc role is defined as follows in the LRR:
|
<arcrole> <link:arcroleRef xlink:type="simple" arcroleURI="http://xbrl.org/dim/arcrole/has-dimension" xlink:href="http://www.xbrl.org/2005/xdt-2005-06-30.xsd#has-dimension"/> <status>IWD</status> <versionDate>2005-07-19</versionDate> <requirement xml:lang="en">A hypercube may have one or more dimensions. </requirement> <versionOfXBRL>2.1</versionOfXBRL> <minimumEditionDate>2004-11-14</minimumEditionDate> <impactsTaxonomyValidation>true</impactsTaxonomyValidation> <impactsInstanceValidation>true</impactsInstanceValidation> <conformanceSuiteURI>http://www.xbrl.org/conf/dim/tests.xml </conformanceSuiteURI> <validation xml:lang="en">The presence of an has-dimension arc role indicates how part of a context is to be validated. </validation> <attributes> <attribute namespaceURI="http://www.xbrl.org/2003/instance" use="required">elt</attribute> <attribute> namespaceURI="http://www.xbrl.org/2003/instance" use="optional">closed</attribute> </attributes> <sourceAbstract>required</sourceAbstract> <targetAbstract>required</targetAbstract> </arcrole> |
It is declared as follows:
|
<arcroleType id="has-dimension" cyclesAllowed="none" arcroleURI="http://xbrl.org/dim/arcrole/has-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 implicit dimensions, Team and Drink. This example shows a hypercube describing the occurrence of Team and Drink elements in the segment element of a context. The dimensionURI attributes are present but not relevant in the example.
Example 2. Hypercube of the Team and Drink implicit dimensions in segments
|
|
2.4.1.1 A base set must not contain more than one has-dimension relationship between any pair of hypercube and implicit dimension elements.
Dimensions must be represented by distinct dimension items. A validator must ensure that no hypercube has a repeated dimension. Violation of this rule must signal xdte:RepeatedDimensionInHypercube. Note that this is not guaranteed by XBRL itself which ensures only that there are no repeated arcs within an extended-type link.
2.4.2 Validity of a context with respect to a dimension
An implicit dimension is referenced in the segment of a context when the context contains an xbrli:segment element containing an element whose definition is referred to by a dimensionURI attribute.
Example 3. Two dimensions referenced in the segment of a context
|
<context id="c1"> <entity> <identifier scheme="http://nic.net">example.com</identifier> <segment> <d:Team>Lakers</d:Team> <d:Drink>Coors</d:Drink> </segment> </entity> <period><forever/></period> </context> |
· An implicit dimension is referenced in the scenario of a context when the context contains an xbrli:scenario element containing an element whose definition is referred to by a dimensionURI attribute.
Example 4. Two dimensions referenced in the scenario of a context
|
<context id="c2"> <entity> <identifier scheme="http://nic.net">example.com</identifier> </entity> <period><forever/></period> <scenario> <d:Team>Celtics</d:Team> <d:Drink>Sam Adams</d:Drink> </scenario> </context> |
Not all of the elements appearing in segment or scenario are necessarily dimension elements; see section 2.4.4 below (The optional “closed” attribute on the has-dimension arc).
2.4.2.1 A context must not contain more than one element whose dimensionURI attribute resolves to the same elements.
A validator must signal xdie:RepeatedDimensionInInstance when a context references a dimension more than once, whether those references occur in the segment or scenario elements.
Example 5. An invalid context containing two references to the same dimension
|
<context id="c3"> <entity> <identifier scheme="http://nic.net">example.com</identifier> <segment> <d:Team>Rams</d:Team> </segment> </entity> <period><forever/></period> <scenario> <d:Team>Lakers</d:Team> </scenario> </context> |
2.4.3 Validity of a context with respect to a hypercube
A context element in an XBRL instance is valid in a discoverable relationship set with respect to a hypercube if, for every simple dimension item that is the target of a has‑dimension relationship (in that discoverable relationship set) whose source is the hypercube, the dimension element that the target item’s dimensionURI attribute refers to appears in the particular descendant element named by the elt attributes. Additional conditions apply to explicit dimension items, as discussed below.
An elt attribute must have one of the values segment or scenario.
|
<simpleType name="eltType"> <restriction base="token"> <enumeration value="segment"/> <enumeration value="scenario"/> </restriction> </simpleType> <attribute name="elt" type="xdt:eltType"/> |
Being invalid with respect to a hypercube does not, by itself, mean the context is invalid; that depends also on the relationship between the context, its facts, the measures, and the hypercube.
Discoverable relationship sets are defined in section 2.6 below; in the examples below, the discoverable relationship set happens to be equivalent to the base set of the has‑dimension relationships.
Example 6. A context that is valid with respect to a hypercube
|
|
|
<context id="c3"> <entity> <identifier scheme="http://nic.net">example.com</identifier> <segment> <d:Team>Rams</d:Team> <d:Drink>Coors</d:Drink> </segment> </entity> <period><forever/></period> </context> |
Example 7. Three contexts that are not valid with respect to a hypercube
|
|
|
|
<context id="c2"> <entity> <identifier scheme="http://nic.net">example.com</identifier> <segment> <d:Team>Rams</d:Team> </segment> </entity> <period><forever/></period> </context> |
Missing a reference to the Drink dimension. |
|
<context id="c3"> <entity> <identifier scheme="http://nic.net">example.com</identifier> <segment> <d:Team>Rams</d:Team> </segment> </entity> <period><forever/></period> <scenario> <d:Drink>Coors</d:Drink> </scenario> </context> |
The Drink dimension must be referenced in the segment element. |
|
<context id="c1"> <entity> <identifier scheme="http://nic.net">example.com</identifier> <segment> <d:Drink>Coors</d:Drink> </segment> </entity> <period><forever/></period> </context> |
Missing a reference to the Team dimension. |
2.4.4 The optional “closed” attribute on the has-dimension arc
The optional Boolean attribute closed may appear on has-dimension arcs. If closed="true" on a has-dimension arc with elt="segment", the hypercube is said to be closed with respect to the segment element in that base set. If closed="true" on a has-dimension arc with elt="scenario", the hypercube is said to be closed with respect to the scenario element in that base set.
|
<xs:attribute name="closed" type="xs:boolean"/> |
A context is valid with respect to a closed hypercube when the only elements appearing in the segment or scenario elements are those referenced in the segment or scenario (respectively) of the context. For this purpose, a has-dimension relationship may have a target dimension that is an explicit dimension having no domain (an empty dimension).
Example 8. A closed hypercube
|
|
|
The arcs with closed="true" mean that a context is valid with respect to this hypercube if it has a Team and Drink reference and nothing else in the segment element, and nothing at all in the scenario element. Only one of the has-dimension arcs with the same value for the elt attribute needs to have closed="true". |
2.5 Measures and Hypercubes
To constrain the set of contexts that may appear on the facts of a given measure, a measure is associated with zero or more hypercubes.
A measure associated with no hypercubes has no constraint on the contexts in which its facts appear.
A nonempty set of hypercubes may be composed via conjunction (“all”), exclusive disjunction (“choice”), inclusive disjunction (“any”). These operators are conceptually no different from the similarly named compositors of XML Schema. They also have a similar semantics with respect to validating instances. However, the relationship between a compositor and its operands in XML Schema is represented by the XML node parent-child relationship, while in XBRL Dimensional Taxonomies the relationship between a compositor and its operands is represented by XLink arcs with distinct arc roles. The use of arcs opens the possibility of using prohibition, overriding, and augmentation in extension taxonomies.
There are three arc roles collectively known as the measure‑hypercube relationships; they are:
· http://xbrl.org/dim/arcrole/all,
· http://xbrl.org/dim/arcrole/any, and
· http://xbrl.org/dim/arcrole/choice.
The three composition operators are subject to negation via the “polarity” attribute on their corresponding arcs. This feature is unlike XML Schema.
2.5.1 The “all” arc role http://xbrl.org/dim/arcrole/all
Only relationships in the discoverable relationship set are relevant to instance validation with the arc role http://xbrl.org/dim/arcrole/all. A context is valid with respect to a conjunction of hypercubes only if it is valid with respect to all of the conjoined hypercubes individually. The conjunction of a single hypercube is the hypercube itself (Example 9).
Example 9. A measure with a single hypercube
|
|
|
The measure m_FluidCapacity is associated with a hypercube. A context will be valid with respect to this measure only if it has a Team and a Drink reference. |
Example 10. A measure with hypercubes composed by conjunction (“all”)
|
|
|
The measure m_FluidCapacity is associated with the composition of two hypercubes. A context will be valid with respect to this measure only if it has a Team, Drink, and a City reference. hcCity is a legal, but degenerate hypercube consisting of only a single dimension. |
A validator must signal xdte:MeasureHypercubeSourceError if the source of the relationship is an abstract element or not in the substitution group of xbrli:item.
A validator must signal xdte:MeasureHypercubeTargetError if the target of the relationship is not abstract element or not in the substitution group of xbrli:item.
The all arc role has the following LRR definition.
|
<arcrole> <link:arcroleRef xlink:type="simple" arcroleURI="http://xbrl.org/dim/arcrole/all" xlink:href="http://www.xbrl.org/2005/xdt-2005-06-30.xsd#all "/> <status>IWD</status> <versionDate>2005-07-19</versionDate> <requirement xml:lang="en">Hypercubes may be defined by intersection. </requirement> <versionOfXBRL>2.1</versionOfXBRL> <minimumEditionDate>2004-11-14</minimumEditionDate> <impactsTaxonomyValidation>true</impactsTaxonomyValidation> <impactsInstanceValidation>true</impactsInstanceValidation> <conformanceSuiteURI>http://www.xbrl.org/conf/dim/tests.xml </conformanceSuiteURI> <validation xml:lang="en">The presence of an “all” arc role indicates how part of a context is to be validated. </validation> <attributes> <attribute namespaceURI="http://www.xbrl.org/2003/instance" use="optional">polarity</attribute> </attributes> <sourceAbstract>prohibited</sourceAbstract> <targetAbstract>required</targetAbstract> </arcrole> |
|
<arcroleType id="all" cyclesAllowed="none" arcroleURI="http://xbrl.org/dim/arcrole/all"> <definition>Source (a measure) requires the target (hypercube) to appear in the context of the measure. </definition> <usedOn>definitionArc</usedOn> </arcroleType> |
2.5.1.1 If a measure element is the source of an “all” relationship in a base set, then it must not be the source of a “choice” arc role in that same base set.
2.5.1.2 If a measure is the source of an “all” relationship in a base set, then it must not be the source of an “any” arc role in that same base set.
The validator must signal error xdte:MeasureHypercubeOperatorInconsistency if either rule is violated.
2.5.2 The “any” arc role http://xbrl.org/dim/arcrole/any
Relationships in the discoverable relationship set of an http://xbrl.org/dim/arcrole/any relationship are relevant to instance validation.
A context is valid with respect to an inclusive disjunction of hypercubes if it is valid with respect to one of the disjoined hypercubes.
Example 11. A measure with hypercubes composed by disjunction (inclusive “or”)
|
|
|
The measure m_FluidCapacity is associated with two disjoined hypercubes. A context is valid with respect to this hypercube if it has either a City, or a Team and Drink. |
A validator must signal xdte:MeasureHypercubeSourceError if the source of a relationship is an abstract element or not in the substitution group of xbrli:item.
A validator must signal xdte:MeasureHypercubeTargetError if the target of a relationship is not an abstract element or not in the substitution group of xbrli:item.
The any arc role has the following LRR definition.
|
<arcrole> <link:arcroleRef xlink:type="simple" arcroleURI="http://xbrl.org/dim/arcrole/any" xlink:href="http://www.xbrl.org/2005/xdt-2005-06-30.xsd#any"/> <status>IWD</status> <versionDate>2005-07-19</versionDate> <requirement xml:lang="en">Hypercubes may be defined by inclusive union. </requirement> <versionOfXBRL>2.1</versionOfXBRL> <minimumEditionDate>2004-11-14</minimumEditionDate> <impactsTaxonomyValidation>true</impactsTaxonomyValidation> <impactsInstanceValidation>true</impactsInstanceValidation> <conformanceSuiteURI>http://www.xbrl.org/conf/dim/tests.xml </conformanceSuiteURI> <validation xml:lang="en">The presence of an "any" arc role indicates how part of a context is to be validated. </validation> <attributes> <attribute namespaceURI="http://www.xbrl.org/2003/instance" use="optional">polarity</attribute> </attributes> <sourceAbstract>prohibited</sourceAbstract> <targetAbstract>required</targetAbstract> </arcrole> |
|
<arcroleType id="any" cyclesAllowed="none" arcroleURI="http://xbrl.org/dim/arcrole/any"> <definition>Source (a measure) allows the target (hypercube) to appear in the context of the measure. </definition> <usedOn>definitionArc</usedOn> </arcroleType> |
2.5.2.1 If a measure is the source of an “any” arc role in a base set, then it must not be the source of an “all” relationship in that same base set.
2.5.2.2 If a hypercube is the source of an “any” arc role in a base set, then it must not be the source of a “choice” relationship in that same base set.
The validator must signal error xdte:MeasureHypercubeOperatorInconsistency if either rule is violated.
2.5.3 The “choice” arc role http://xbrl.org/dim/arcrole/choice
Relationships in the discoverable relationship set of an http://xbrl.org/dim/arcrole/choice relationship are relevant to instance validation. The source and target are measure and hypercube elements, respectively.
A context is valid with respect to an exclusive disjunction of hypercubes if it is valid with respect to one of the disjoined hypercubes and not valid with respect to the others.
Example 12. A hypercube composed by exclusive disjunction (exclusive “or”)
|
|
|
The measure m_FluidCapacity is associated with two hypercubes. A context is valid with respect to this exclusive disjunction of hypercubes if it has either a Team and Drink (as defined before) or a City, but not both. |
A validator must signal xdte:MeasureHypercubeSourceError if the source of the relationship is an abstract element or not in the substitution group of xbrli:item.
A validator must signal xdte:MeasureHypercubeTargetError if the target of the relationship is an abstract element or not in the substitution group of xbrli:item.
The choice arc role has the following LRR definition.
|
<arcrole> <link:arcroleRef xlink:type="simple" arcroleURI="http://xbrl.org/dim/arcrole/choice" xlink:href="http://www.xbrl.org/2005/xdt-2005-06-30.xsd#choice"/> <status>IWD</status> <versionDate>2005-07-19</versionDate> <requirement xml:lang="en">Hypercubes may be defined by exclusive union. </requirement> <versionOfXBRL>2.1</versionOfXBRL> <minimumEditionDate>2004-11-14</minimumEditionDate> <impactsTaxonomyValidation>true</impactsTaxonomyValidation> <impactsInstanceValidation>true</impactsInstanceValidation> <conformanceSuiteURI>http://www.xbrl.org/conf/dim/tests.xml </conformanceSuiteURI> <validation xml:lang="en">The presence of a "choice" arc role indicates how part of a context is to be validated. </validation> <attributes> <attribute namespaceURI="http://www.xbrl.org/2003/instance" use="optional">polarity</attribute> </attributes> <sourceAbstract>prohibited</sourceAbstract> <targetAbstract>required</targetAbstract> </arcrole> |
It is declared as follows:
|
<arcroleType id="choice" cyclesAllowed="none" arcroleURI="http://xbrl.org/dim/arcrole/choice"> <definition>Source (a measure) allows the target (hypercube) as one of a set of mutually exclusive alternatives. </definition> <usedOn>definitionArc</usedOn> </arcroleType> |
2.5.3.1 If a measure is the source of a “choice” relationship in a base set, then it must not be the source of an “all” relationship in that same base set.
The validator must signal error xdte:MeasureHypercubeOperatorInconsistency if this rule is violated.
2.5.3.2 If a measure is the source of a “choice” relationship in a base set, then it must not be the source of an “any” relationship in that same base set.
The validator must signal error xdte:MeasureHypercubeOperatorInconsistency if this rule is violated.
2.5.4 Negation of the measure-hypercube arcs
Measure-hypercube arcs also have an optional attribute polarity. The value of polarity is a Boolean and its default value is true.
|
<xs:attribute name="polarity" type="xs:boolean" default="true"/> |
A hypercube that is the target of an arc with polarity="false" is a negated hypercube.
A context is valid with respect to a negated hypercube if it is invalid with respect to the underlying hypercube.
A context is invalid with respect to a negated hypercube if it is valid with respect to the underlying hypercube.
Example 13. A hypercube composed by conjunction with a negated hypercube
|
|
|
The measure m_FluidCapacity has two conjoined hypercubes. A context is valid with respect to this measure if it has a Team and Drink but does NOT have a City. |
Note: Having a negation relationship means that DeMorgan’s Law could be applied to make one of the any, all or choice relationships unnecessary. However, this would require more deeply nested structures, such as hypercubes inside of hypercubes, violating P3 (Simplicity, Appendix B). A design choice has been made to retain all three relationships and their negations, and have a single layer of hypercubes and a single layer of (conjoined) dimensions within each hypercube.
2.6 Discoverable relationship sets
Taxonomy authors are able to partition relationships into distinct base sets using the xlink:role attribute on extended-type link elements. Applications that are aware of the names and meanings of the partitions may use different sets of relationships at different times for processing.
But 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 use together. To forbid this would violate P2 (Consistency, Appendix B).
However, a set of measures may have hypercubes in common among the targets of their measure‑hypercube relationships; hypercube elements in turn may have implicit dimensions in common among the targets of their has‑dimension relationships. Furthermore, in sections 2.7 through 2.9 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 arcs, violating P4 (Irredundancy, Appendix B).
The optional targetRole attribute on an arc allows a taxonomy author to specify the base sets of relationships that a validating processor must use together. As declared in their LRR entries, the targetRole attribute may appear on definition arcs having the following arc roles: all, any, choice, has‑dimension, dimension‑domain and domain‑member. The targetRole attribute has type anyURI. Resolution of the URI is not subject to the presence of an xml:base attribute.
|
<xs:attribute name="targetRole" type="xs:anyURI"/> |
The discoverable relationship set (DRS) of a relationship consists of all relationships in the transitive closure of the discovery relation defined in Figure 2 below. In Figure 2, role(arc) denotes the contents of the xlink:role attribute of the relationship’s base set; targetRole(arc) denotes the contents of the targetRole attribute on the arc itself.
Figure 2. Discovery relation 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 |
|||
|
domain‑member |
all, any, choice |
has‑dimension |
dimension‑domain |
|
|
domain‑member |
role(B) Î {role(A), targetRole(A)} |
False |
False |
False |
|
all, any, choice |
False |
False* |
role(B) Î {role(A), targetRole(A)} |
False |
|
has‑dimension |
False |
False |
False |
role(B) Î {role(A), targetRole(A)} |
|
dimension‑domain |
role(B) Î {role(A), targetRole(A)} |
False |
False |
False |
*If the all, any and choice operators could be nested, this cell would not be False.
Example 14. B is in the DRS of A although in a different base set
|
|
|
<linkbase ...> <definitionLink xlink:role="http://www.xbrl.org/2003/role/link"> <loc xlink:type="locator" xlink:href="tax1.xsd#first" xlink:label="lbl_1"/> <loc xlink:type="locator" xlink:href="tax1.xsd#second" xlink:label="lbl_2" /> <definitionArc xlink:type="arc" id="arc_A" xlink:arcrole="http://xbrl.org/dim/role/domain-member" targetRole="http://www.example.com/extended/role" xlink:from="lbl_1" xlink:to="lbl_2" /> </definitionLink> <definitionLink xlink:role="http://www.example.com/extended/role"> <loc xlink:type="locator" xlink:href="tax1.xsd#second" xlink:label="lbl_1"/> <loc xlink:type="locator" xlink:href="tax1.xsd#third" xlink:label="lbl_2"/> <definitionArc xlink:type="arc" id="arc_B" xlink:arcrole="http://xbrl.org/dim/role/domain-member" xlink:from="lbl_1" xlink:to="lbl_2" /> </definitionLink> </linkbase> |
2.6.1 Validation impact of discoverable relationship sets
Discoverable relationship sets do not impact validation of XBRL taxonomies. That is because each arc role either has a “False” value along the diagonal in Figure 2 above, or else, as with domain‑member, has cyclesAllowed="any". All other taxonomy validation rules are unaffected by base sets.
Discoverable arc sets do impact validation of XBRL instances. In section 2.4.3 above, “Validity of a context with respect to a hypercube,” validation is defined with respect to the set of relationships in the DRS; the relevant DRS is defined in section 2.5 above, “Measures and Hypercubes.”
2.7 Attribute group dimAttributes
Contexts may reference explicit dimension members using an XLink simple-type link with these attributes:
|
<xs:attributeGroup name="dimAttributes"> <xs:attributeGroup ref="xlink:simpleType"/> <xs:attribute ref="xlink:href" use="required"/> <xs:attribute ref="xlink:arcrole" use="optional"/> <xs:attribute ref="xlink:role" use="optional"/> <xs:attribute ref="xlink:title" use="optional"/> <xs:attribute ref="xlink:show" use="optional"/> <xs:attribute ref="xlink:actuate" use="optional"/> <xs:anyAttribute namespace="##targetNamespace" processContents="lax"/> </xs:attributeGroup> |
2.7.1.1 The required xlink:type attribute
The xlink:type attribute MUST occur and MUST have the fixed content “simple”.
2.7.1.2 The required xlink:href attribute
The xlink:href attribute MUST occur and must be a URI that resolves to an XML Schema root element. If the URI reference is relative, its absolute version MUST be determined as specified in [XML Base] before use. For details on the allowable forms of XPointer [XPTR] syntax in the URI see [XBRL] section 3.5.4.
2.7.1.3 The optional xml:base attribute on Member elements
The xml:base attribute MAY occur and participate in the resolution of relative URIs specified in xlink:href attributes [XML Base].
2.7.1.4 The optional xlink:title attribute on Member elements
The xlink:title attribute MAY occur. Processors MAY use the contents of this attribute as a convenient way to identify to a user the dimension to which the reference element points, without having to traverse the link.
2.8 Explicit dimensions
The domain of an explicit dimension consists of the QNames of items in a taxonomy. The items 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].
An explicit dimension is represented by an abstract element in the substitution group of xbrli:item that is numeric (as defined in section 5.1.1.3 in [XBRL]), and which is the target of a definition relationship with arc role http://xbrl.org/dim/arcrole/has-dimension. The xbrli:balance, xbrli:periodType and nillable attributes of an explicit dimension declaration have no significance.
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 domain contains the QNames of all items in the transitive closure of the domain‑member relation rooted at the domain item.
Example 15. An explicit dimension element and its domain
|
Dimension |
Domain |
Domain members |
|
<element name="ContinentDim" id="my_ContinentDim" substitutionGroup="xbrli:item" abstract="true" xbrli:periodType="duration"/>
|
<element name="Continent" id="geo_Continent" substitutionGroup="xbrli:item" xbrli:periodType="duration"/>
<element name="SouthAmerica" id="geo_SouthAmerica" substitutionGroup="xbrli:item" xbrli:periodType="duration"/> |
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.8.1 Arc role http://xbrl.org/dim/role/dimension-domain
A dimension‑domain relationship has an explicit dimension item as its source and any item as its target. It binds a dimension to a domain.
A validator must signal xdte:DimensionDomainDirectedCycle if there is a directed cycle of dimension‑domain relationships in any base set.
A validator must signal xdte:DimensionDomainSourceError if the source of the relationship is not an abstract element in the substitution group of xbrli:item.
A validator must signal xdte:DimensionDomainTargetError if the target of the relationship is not in the substitution group of xbrli:item.
This arc role is defined as follows in the LRR:
|
<arcrole> <link:arcroleRef xlink:type="simple" arcroleURI="http://xbrl.org/dim/role/dimension-domain" xlink:href="http://www.xbrl.org/2005/xdt-2005-06-30.xsd#dimension-domain"/> <status>IWD</status> <versionDate>2005-07-19</versionDate> <requirement xml:lang="en">An explicit dimension has one domain. </requirement> <versionOfXBRL>2.1</versionOfXBRL> <minimumEditionDate>2004-11-14</minimumEditionDate> <impactsTaxonomyValidation>true</impactsTaxonomyValidation> <impactsInstanceValidation>true</impactsInstanceValidation> <conformanceSuiteURI>http://www.xbrl.org/conf/dim/tests.xml</conformanceSuiteURI> <validation xml:lang="en">The presence of a dimension-domain arc role indicates how part of a context is to be validated. </validation> <attributes/> <sourceAbstract>required</sourceAbstract> <targetAbstract>optional</targetAbstract> </arcrole> |
|
<arcroleType id="dimension-domain" cyclesAllowed="none" arcroleURI="http://xbrl.org/dim/role/dimension-domain"> <definition>Source (a dimension) has only the target (a domain) as its domain. </definition> <usedOn>definitionArc</usedOn> </arcroleType> |
2.8.1.1 An explicit dimension item must not be the source of more than one dimension-domain relationship in a given base set.
A validator must signal xdte:DimensionDomainMultipleDomains if this rule is violated.
2.8.2 Arc role http://xbrl.org/dim/role/domain-member
A domain-member relationship binds a dimension to a domain. The purpose of this relationship is to create sets of explicit dimension members.
The base set of a domain-member relationship may have any kind of cycles.
A validator must signal xdte:DomainMemberSourceError if the source of the relationship is not in the substitution group of xbrli:item.
A validator must signal xdte:DomainMemberTargetError if the target of the relationship is not in the substitution group of xbrli:item or is abstract.
This arc role is defined as follows in the LRR:
|
<arcrole> <link:arcroleRef xlink:type="simple" arcroleURI="http://xbrl.org/dim/role/domain-member" xlink:href="http://www.xbrl.org/2005/xdt-2005-06-30.xsd#ddomain-member"/> <status>IWD</status> <versionDate>2005-07-19</versionDate> <requirement xml:lang="en">An explicit dimension has one domain. </requirement> <versionOfXBRL>2.1</versionOfXBRL> <minimumEditionDate>2004-11-14</minimumEditionDate> <impactsTaxonomyValidation>true</impactsTaxonomyValidation> <impactsInstanceValidation>true</impactsInstanceValidation> <conformanceSuiteURI>http://www.xbrl.org/conf/dim/tests.xml</conformanceSuiteURI> <validation xml:lang="en">The presence of a domain-member arc role indicates how part of a context is to be validated. </validation> <attributes/> <sourceAbstract>optional</sourceAbstract> <targetAbstract>prohibited</targetAbstract> </arcrole> |
|
<arcroleType id="domain-member" cyclesAllowed="none" arcroleURI="http://xbrl.org/dim/role/domain-member"> <definition>Source (a domain) contains the target (a member). </definition> <usedOn>definitionArc</usedOn> </arcroleType> |
2.8.3 Element Member
The xdt:Member element is a simple-type link whose content is a member of the domain of the dimension to which its xlink:href attribute refers.
|
<element name="Member"> <annotation><documentation xml:lang="en"> A simple-type link containing the QName of an item that is a member of an explicit dimension.</documentation></annotation> <complexType> <simpleContent> <extension base="QName"> <attributeGroup ref="xdi:dimAttributes"/> </extension> </simpleContent> </complexType> </element> |
A validator must signal xdie:MemberNotExplicitDimension if the content of the xlink:href attribute resolves (with xml:base) to anything other than an abstract numeric item definition that is either the source of a dimension-domain relationship or the target of a has-dimension arc.
2.8.4 Validation of contexts with respect to an explicit dimension
A segment or scenario element in an XBRL instance is valid in a DRS with respect to an explicit dimension if the dimension appears in the relevant descendant element named by the elt attribute of the has-dimension arc and the content of the xdt:Member element is a member of the domain of the dimension.
Example 16. A context that is valid with respect to a hypercube with two explicit dimensions
|
|
|
<context id="c90"> <entity> <identifier scheme="http://nic.net>example.com</identifier> <segment> <xdi:Member xlink:type="simple" xlink:href="t‑company.xsd#t_SalesRegion" >d:AllRegions</xdi:Member> <xdi:Member xlink:type="simple" xlink:href="t-company.xsd#t_Product" >d:RedWine</xdi:Member> </segment> </entity> <period><forever></period> </context> |
2.9 Validation of facts
An item in an instance must have a context and a measure. That measure may have a set of hypercubes, relationships to them (any, all, or choice, possibly negated), and for each of those relationships must have a DRS.
Whether the item appears inside a tuple has no relevance to whether its measure and context are valid with respect to dimensional relationships.
Figure 3 shows the signals that a validator must raise depending on what the measure‑hypercube relationship is, whether the relationship is negated, what the dimension type is, and what caused the validation failure.
Figure 3. Errors signalled by a validator when fact context is not valid with respect to the DRS of the hypercubes of its measure
|
Op |
Polarity |
Dim Type |
Result |
Error |
|
All |
True |
Implicit |
Reference not found in segment (scenario) |
xdie: ImplicitDimNotInSegment (xdie: ImplicitDimNotInScenario) |
|
All |
True |
Implicit |
invalid |
xdie:ImplicitDimInvalidContent |
|
All |
True |
Explicit |
xdi:Member not found in segment (scenario) |
xdie:ExplicitDimNotInSegment (xdie:ExplicitDimNotInScenario) |
|
All |
True |
Explicit |
QName is not an item |
xdie:ExplicitDimDomainInvalidContent |
|
All |
True |
Explicit |
MemRef not found in domain |
xdie:ExplicitDimDomainMemberNotFound |
|
All |
False |
Implicit |
Reference found in segment (scenario) |
xdie:ForbiddenImplicitDimInSegment (xdie:ForbiddenImplicitDimInScenario) |
|
All |
False |
Explicit |
xdi:Member found in segment (scenario) |
xdie:ExplicitDimDomainMemberNotFound |
|
All |
True |
* |
Reference not found in segment (scenario) |
xdie:NoAllowedDimsPresentInSegment (xdie:NoAllowedDimsPresentInScenario |
|
All |
False |
* |
All references are found in segments and scenarios |
xdie:AllDisallowedDimsPresent |
|
All |
True |
* |
No references are found |
xdie:NoneOfExclusiveDimsPresent |
|
Choice |
True |
* |
More than one reference is found |
xdie:MultipleExclusiveDimsPresent |
|
Choice |
False |
* |
* |
xdie:NotAllDimensionsCoincident |
The introduction of any, choice, and negation relationships weaken the specificity of the errors that can be raised. These would typically fail validation depending only on whether dimension references were present at all; validity of the content would be a secondary consideration.
2.10Domain-member relations and inheritance
A measure may be the source of a domain‑member relationship. When a measure is the source of both a domain‑member relationship and a measure‑hypercube relationship, and the target of the domain‑member relationship is not the source of any measure‑hypercube relationships, the target of the domain‑member arc is said to inherit the measure-hypercube relationship. Inheritance is transitive. Inheritance preserves the base set and DRS of the original measure‑hypercube relationship.
Example 17 shows a simple example in which two measures have a common ancestor from which they inherit an all relation to a hypercube.
Example 17. Two measures inheriting a hypercube
|
|
Measures Sales and CostOfGoods are not the source of any measure-hypercube arc; they inherit the hypercube hcRegion_x_Product from the measure GrossProfit. |
Example 18. Facts not valid because they violate their hypercube constraints
|
<GrossProfit contextRef="c92" unitRef="eur" decimals="INF"/> <CostOfGoods contextRef="c92" unitRef="eur" decimals="INF"/> <Sales contextRef="c92" unitRef="eur" decimals="INF"/>
<context id="c92"> <entity> <identifier scheme="http://nic.net>example.com</identifier> <segment> <xdi:Member xlink:type="simple" xlink:href="t company.xsd#t_SalesRegion" >r:Barbados</xdi:Member> <xdi:Member xlink:type="simple" xlink:href="t-company.xsd#t_Product" >p:RedWine</xdi:Member> </segment> </entity> <period><forever></period> </context> |
r:Barbados is not a domain member in SalesRegion; hence the constraint is violated by all three facts even though only GrossProfit had an explicit “all” arc to hcRegion_x_Product. |
A measure having no measure‑hypercube relationships of its own may inherit any number of measure‑hypercube relationships, from any number of distinct base sets.
If the resulting set of inherited measure-hypercube relationships would violate any of the syntax rules 0, 2.5.1.2, 0, 2.5.2.2, 2.5.3.1, or 2.5.3.2 above, then a validating processor must detect this and signal the same errors as specified for those rules.
The impact of the measure‑hypercube relationships on instance validation is unchanged merely because the relationships have been inherited.
2.11Element declarations and linkbase syntax
Implicit dimensions, explicit dimensions, domains and hypercubes are all represented using elements in the substitution group of xbrli:item. These elements which are the targets of measure-hypercube, domain-member, has-dimension, and dimension-domain relationships are collectively called dimensional elements as defined in section 1.3 above.
2.11.1.1 There must be exactly one standard label of a dimensional element for any given language and base set in the schema-rooted DTS of the schema where the element is defined.
A validator must signal xdte:NoStandardLabel if a dimensional element has no standard label in any language in the schema-rooted DTS of the schema where the element is defined.
A validator must signal xdte:TooManyStandardLabels if there is a language and base set for which a dimensional element has more than one standard label in the schema-rooted DTS of the schema where the element is defined.
There may be any number of standard labels of a dimensional element in the base set in the schema-rooted DTS of the schema where the element is defined. Dimensional elements may have multiple labels, but they must either be in different base sets or have different values of the xml:lang attribute. Therefore, extension taxonomies may provide multiple labels even with the same value of the xml:lang attribute.
3 Aggregators
The summation-item relationship of the calculation linkbase has no special meaning when its source and target elements are dimensional elements. Calculations that bind and detect inconsistencies using the summation-item relationship do so irregardless of whether the facts in question appear in domain‑member relationships and irregardless of whether the fact contexts have references to domain members. Because expansion of the meaning of the summation‑item relationship, and consequent change in the behaviour of validating processors would imply a change to the underlying specification, thus violating P5 (Priority, Appendix B), summation is defined instead in dimensional taxonomies using a new calculationArc arc role, aggregator‑contributor.
Summation in dimensional taxonomies is performed by projecting the aggregator-contributor relationship (within a base set) onto contexts, and thence onto facts, where inconsistencies may be detected via “cross context calculation”.
The relationship aggregator-contributor is an polymorphic binary relationship defined over pairs of domain members, pairs of contexts, and pairs of facts. The relationship aggregator‑contributors is a polymorphic binary relationship defined over a domain member and set of members, a context and a set of context, and a fact and set of facts.
The source of the aggregator-contributor relationship is said to be an aggregator of the target, which is its contributor. If the relationships are in the same base set then the set of contributing sources are the contributors.
When two contexts are identical except that one has the QName of an aggregator as the content of an xdi:Member element and the other has the QName of a contributor in its corresponding xdi:Member element, then that context is said to be an aggregator of the other context, which is its contributor. All contexts for which their QName was among the contributors are the contributors of the aggregator.
When two p‑equal, u-equal (section 4.10 [XBRL]) facts in an instance have the same element name and the context of one is an aggregator of the context of the other, then the fact is said to be an aggregator of the other. The facts whose contexts were contributors are contributors of the aggregator.
Example 19 below shows two aggregator-contributor relationships that can be derived from a valid set of facts, contexts, and aggregator-contributor relationship in a dimensional taxonomy; the Sales value in SouthAmerica is an aggregator of the Sales value in Argentina, when all other aspects of the context are held equal.
Example 19. Aggregator-Contributor relationship
|
|
A fact that is the aggregator of one or more contributing facts must have a numeric value that is consistent with the sum of the numeric values. The value is defined to be consistent if the rounded value of the summation item is equal to the total of the contributing values rounded to the precision or inferred precision of the aggregator.
Validating processors may signal xdie:InconsistentAggregation upon detecting an inconsistency thus defined.
Contexts are not aggregators of, and are not contributors to, contexts that differ along more than one dimension.
Inconsistency in calculations does not impact instance validation. Therefore there is no impact on instance validation.
Duplicate facts within a set of contributors render the aggregator consistent.
Aggregator-contributor relationships cannot be defined for implicit dimensions.
3.1.1 Arc role http://xbrl.org/int/dim/arcrole/aggregator-contributor
A validator must signal xdte:AggregatorContributorCycleError if there is a directed or undirected cycle of aggregator‑contributor relationships in any base set.
A validator must signal xdte:AggregatorContributorSourceError if the source of the relationship is an abstract element or is not in the substitution group of xbrli:item.
A validator must signal xdte:AggregatorContributorTargetError if the target of the relationship is an abstract element or is not in the substitution group of xbrli:item.
This arc role is defined as follows in the LRR:
|
<arcrole> <link:arcroleRef xlink:type="simple" arcroleURI="http://xbrl.org/int/dim/arcrole/aggregator-contributor" xlink:href="http://www.xbrl.org/2005/xdt-2005-06-30.xsd#aggregator-contributor"/> <status>IWD</status> <versionDate>2005-07-19</versionDate> <requirement xml:lang="en">Calculations may aggregate across contexts. </requirement> <versionOfXBRL>2.1</versionOfXBRL> <minimumEditionDate>2004-11-14</minimumEditionDate> <impactsTaxonomyValidation>true</impactsTaxonomyValidation> <impactsInstanceValidation>true</impactsInstanceValidation> <conformanceSuiteURI>http://www.xbrl.org/conf/dim/tests.xml</conformanceSuiteURI> <validation xml:lang="en">The presence of an aggregator-contributor arc may be used to signal a calculation inconsistency. </validation> <attributes/> <sourceAbstract>prohibited</sourceAbstract> <targetAbstract>prohibited</targetAbstract> </arcrole> |
It is declared as follows:
|
<arcroleType id="aggregator-contributor" cyclesAllowed="none" arcroleURI="http://xbrl.org/int/dim/arcrole/aggregator-contributor"> <definition>Source (a member) is the aggregator of the target (a member). </definition> <usedOn>definitionArc</usedOn> </arcroleType> |