XBRL Dimensions 1.0

Republished in HTML

Recommendation 18 September 2006 with errata corrections to 25 January 2012

Copyright © 2005, 2006, 2009, 2012 XBRL International Inc., All Rights Reserved.

This version:
<http://www.xbrl.org/Specification/dimensions/REC-2006-09-18/dimensions-REC-2006-09-18+corrected-errata-2012-01-25.html>
Editors:
Ignacio Hernández-Ros, Reporting Estandar S.L., formerly XBRL International Inc. < ihr@xbrl.org ignacio@reportingstandard.com >
Hugh Wallis, IBM, formerly XBRL International Inc. < hughwallis@xbrl.org hugh.wallis@ca.ibm.com >
Contributors:
David vun Kannon, Deloitte, formerly PricewaterhouseCoopers <dvunkannon@deloitte us.pwc.com>
Walter Hamscher, US Securities and Exchange Commission, formerly Standard Advantage <walter@hamscher.com>
Charles Hoffman, UBmatrix <charleshoffman@olywa.net>
Cliff Binstock, Coyote Reporting, formerly UBmatrix <cliff.binstock@coyotereporting ubmatrix.com>
Herm Fischer, UBmatrix / Mark V Systems < fischer@markv.com herman.fischer@ubmatrix.com >
Paul Warren, CoreFiling, formerly Decisionsoft <pdw@corefiling decisionsoft.com>

Status

Circulation of this Recommendation is unrestricted. This document is normative. Recipients are invited to submit comments to dimensions-feedback@xbrl.org, and to submit notification of any relevant patent rights of which they are aware and provide supporting documentation.

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 [Dimensions Requirements]. It is a modular extension to [XBRL 2.1]. 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 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 [XBRL 2.1] 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.

Table of Contents

1 Introduction (non-normative)
1.1 Background (non-normative)
1.1.1 Primary taxonomies
1.1.2 Domain members taxonomies
1.1.3 Template taxonomies
1.2 Relationship to other work
1.3 Terminology (non-normative)
1.4 Document conventions
1.5 Namespaces (normative)
2 Dimensional Taxonomies (normative)
2.1 Architecture (normative)
2.1.1 Consecutive relationships
2.2 Hypercubes (normative)
2.2.1 Constraints on hypercube declarations
2.2.2 Arc role http://xbrl.org/int/dim/arcrole/hypercube-dimension
2.2.2.1 Constraints on hypercube-dimension arcs
2.3 Primary item declarations and hypercubes (normative)
2.3.1 The "all" and "notAll" arc roles
2.3.1.1 Constraints on "all" or "notAll" arcs
2.3.2 The required @xbrldt:contextElement attribute on has-hypercube arcs
2.3.2.1 Constraints on the value of the @xbrldt:contextElement attribute
2.3.3 The optional @xbrldt:closed attribute on has-hypercube arcs
2.3.3.1 Constraints on the value of the @xbrldt:closed attribute
2.4 Partitioning of a Dimensional relationship set across multiple base-sets (normative)
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 Dimensions (normative)
2.5.1 Constraints on the dimension declaration
2.5.2 Typed dimensions
2.5.2.1 The @xbrldt:typedDomainRef attribute
2.5.2.1.1 Constraints on the @xbrldt:typedDomainRef attribute
2.5.3 Explicit dimensions
2.5.3.1 Arc role http://xbrl.org/int/dim/arcrole/dimension-domain
2.5.3.1.1 Constraints on the dimension-domain arcs
2.5.3.2 Arc role http://xbrl.org/int/dim/arcrole/domain-member
2.5.3.2.1 Constraints on the domain-member arcs
2.5.3.3 The optional @xbrldt:usable attribute
2.5.3.3.1 Constraints on the value of the @xbrldt:usable attribute
2.6 Domain-member relations and inheritance (normative)
2.6.1 Processing of multiple has-hypercube arcs
2.7 Default values for dimensions (normative)
2.7.1 Arc role http://xbrl.org/int/dim/arcrole/dimension-default
2.7.1.1 Constraints on dimension-default arcs
2.7.1.2 Constraints on instance documents about the member that is the default for a dimension
3 Dimensions in instance documents (normative)
3.1 Validation of primary items (normative)
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.1.3.1 Constraints on the individual validity of hypercubes
3.1.4 Validity of dimensions
3.1.4.1 Obtaining the dimension value for a dimension
3.1.4.2 Constraints about dimension values
3.1.4.3 Examples of context and their dimension validity
3.1.4.4 Typed dimensions
3.1.4.4.1 The xbrldi:typedMember element
3.1.4.4.2 Constraints about the @dimension attribute in xbrldi:typedMember elements
3.1.4.4.3 Constraints on the content of xbrldi:typedMember elements
3.1.4.5 Explicit dimensions
3.1.4.5.1 The xbrldi:explicitMember element
3.1.4.5.2 Constraints on the @dimension attribute in xbrldi:explicitMember elements
3.1.4.5.3 Constraints on the content of the xbrldi:explicitMember elements
3.2 Definition of dimensionally equal facts (normative)

Appendices

A Errors
A.1 Validating Taxonomies
A.2 Validating Instances
B Requirements Reference (non-normative)
C References
D Schemas (normative)
D.1 xbrldt-2005.xsd (normative)
D.2 xbrldi-2006.xsd (normative)
E Intellectual property status (non-normative)
F Acknowledgements (non-normative)
G Document History (non-normative)
H Errata Corrections incorporated in this document

Tables

1 Namespaces and namespace prefixes
2 arcrole values for potentially consecutive relationships
3 "Instance Error"

Figures

1 Relationships to define constraints on the content and meaning of contexts
2 Valid consecutive relationships between relationship A and relationship B
3 Combination of multiple hypercubes and the result operation.
4 Hypercube validity table

Examples

1 Hypercube of the Team and Drink typed dimensions
2 A primary item declaration with a single hypercube
3 A primary item declaration with two hypercubes composed by conjunction "all" and "notAll"
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
5 Two closed hypercubes
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.
7 The arc in base set link2 is in the DRS of the arc in base set link1
8 Typed dimension elements and their domains
9 An explicit dimension element and its domain
10 Two primary item declarations inheriting a hypercube
11 Inheritance and processing of multiple hypercubes.
12 Multiple all All hypercubes in a domain-member network
13 Automatic inference of default values for summation-item relationships
14 Primary item at the root of a dimensional relationship set
15 Dimensionally invalid context containing two references to the same dimension
16 A segment that is valid with respect to a hypercube
17 Two segments not dimensionally valid with respect to a hypercube
18 Valid and Invalid Hypercubes according to its dimensions and domains
19 Primary items that are not dimensionally valid because they violate their hypercube constraints
20 Two dimensions referenced in the segment of a context
21 Two dimensions referenced in the scenario of a context
22 A context that is dimensionally valid with respect to a hypercube with two explicit dimensions
23 Multiple contexts and the result of the d-equal operation

Definitions

[Def, 10] explicit dimension
[Def, 11] domain member declaration
[Def, 12] domain of valid members of an explicit dimension
[Def, 13] dimension domain
[Def, 14] effective domain
[Def, 15] dimension value
[Def, 16] dimension container
[Def, 17] default value
[Def, 18] d-equal
[Def, 19] consecutive relationship set
[Def, 1] primary item declaration
[Def, 20] dimensionally valid with respect to a hypercube
[Def, 21] dimensionally valid with respect to a closed hypercube
[Def, 2] consecutive relationships
[Def, 3] dimensional relationship set
[Def, 4] hypercube declaration
[Def, 5] source role
[Def, 6] target role
[Def, 7] dimension declaration
[Def, 8] domain of members
[Def, 9] typed dimension

Error codes

xbrldte:DRSDirectedCycleError
xbrldte:DimensionDefaultSourceError
xbrldte:DimensionDefaultTargetError
xbrldte:DimensionDomainSourceError
xbrldte:DimensionDomainTargetError
xbrldte:DimensionElementIsNotAbstractError
xbrldte:DomainMemberSourceError
xbrldte:DomainMemberTargetError
xbrldte:HasHypercubeMissingContextElementAttributeError
xbrldte:HasHypercubeSourceError
xbrldte:HasHypercubeTargetError
xbrldte:HypercubeDimensionSourceError
xbrldte:HypercubeDimensionTargetError
xbrldte:HypercubeElementIsNotAbstractError
xbrldte:OutOfDTSSchemaError
xbrldte:PrimaryItemPolymorphismError
xbrldte:PrimaryItemPolymorphismError
xbrldte:TargetRoleNotResolvedError
xbrldte:TooManyDefaultMembersError
xbrldte:TypedDimensionError
xbrldte:TypedDimensionURIError
xbrldte:TypedDomainRefError

xbrldie:DefaultValueUsedInInstanceError
xbrldie:DefaultValueUsedInInstanceError
xbrldie:ExplicitMemberNotExplicitDimensionError
xbrldie:ExplicitMemberUndefinedQNameError
xbrldie:IllegalTypedDimensionContentError
xbrldie:PrimaryItemDimensionallyInvalidError
xbrldie:RepeatedDimensionInInstanceError
xbrldie:TypedMemberNotTypedDimensionError


1 Introduction (non-normative)

The architecture of XBRL as defined in [XBRL 2.1] 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 section 3.2). These rules employ XML Schemas [XML Schema Structures] [XML Schema Datatypes] 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 <context> s, 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 [XBRL 2.1]. Dimensions that ARE provided such semantic meaning by [XBRL 2.1] are the "time" dimension, which leverages the sophisticated semantic mechanisms provided in XML Schema [XML Schema Structures], 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 ,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 [Dimensions Requirements] this modular extension to [XBRL 2.1] 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 [XBRL 2.1] 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 ( Section 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 (non-normative)

As should be apparent from the requirements [Dimensions Requirements], dimensional metadata was not invented with XBRL. [XBRL 2.1] standardises 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 [XBRL 2.1] 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. This 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 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 define syntactic constraints on the contents of segments and scenarios.

Explicit dimensional taxonomies are those in which the XBRL items form a discrete, countable finite partitioning of a set of members, which hereinafter is called a domain. Examples include a taxonomy on the domain of geographic territories, or a taxonomy on a domain of product lines. Inclusion relationships ( Requirement G09) 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, thisthat 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 Hypercube. A Hypercube describes the Cartesian product of zero or more dimensions. Each dimension, in turn, is defined over zero or more domains and domains are composed of members. Note that in this formulation, a hypercube of a Primary Item does not include the Primary Item itself.

  • Example: a topographic map is a 3-dimensional hypercube; it has thee dimensions - , elevation, longitude and latitude - , all of which are defined over the domain of real numbers. The elevation can be represented as a Primary Item, with longitude and latitude being the two dimensions of a hypercube for that Primary Item.
  • Example: A table in a financial statement showing revenue byfor 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 structures of the hypercubes and link the hypercubes with the Primary Item.

1.2 Relationship to other work

This document pertains to XBRL as defined in the XBRL Specification.

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 [Dimensions Requirements] document.

1.3 Terminology (non-normative)

Terminology used in XBRL frequently overlaps with terminology from other fields.

Term Meaning (non-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 2.1].
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 , RECOMMENDED, MAY , and OPTIONAL As described in [IETF RFC 2119].
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].
XBRL valid XML instances and schemas that satisfy the syntax requirements of [XBRL 2.1].
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 which 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 2.1] item.
Primary Item Declaration The declaration of [XBRL 2.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 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 substitution group 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 The non XBRL element used in the <segment> or <scenario> element 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 [XBRL 2.1].
Dimensional Processor A processor that 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 2.0] 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 highlighting is used to present non-normative examples in this document:

 

The following highlighting is used to present 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 (normative)

This table contains all the prefixes used within the text and the correspondent namespace URI:

Table 1: Namespaces and namespace prefixes
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 http://www.xbrl.org/2003/instance
xs http://www.w3.org/2001/XMLSchema
xlink http://www.w3.org/1999/xlink
link http://www.xbrl.org/2003/linkbase

The Prefix column in the table above is non normative. The Namespace URI column is normative.

2 Dimensional Taxonomies (normative)

2.1 Architecture (normative)

In XBRL Instances, certain elements defined by this specification are distinguished by the use of elements in the namespace http://xbrl.org/2006/xbrldi which is conventionally prefixed xbrldi. T; these elements appear within the <scenario> and <segment> elements only. XBRL instances are validated according to the syntax constraints implied by thetyped dimensions (which require XML Schema validation and nothing more) and by the explicit dimensions (which require description of each member element and relationships among the members using linkbases).

Dimensional taxonomies are distinguished by the use of several arc roles. These arc roles and 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 [XML Schema Structures] and [XML Schema Datatypes]. Dimensional taxonomies according to this specification MUST also be valid [XBRL 2.1] taxonomies.

XBRL instances using the elements defined in xbrldi-2006.xsd MUST be XML Schema valid according to validation rules defined in [XML Schema Structures] and [XML Schema Datatypes]. XBRL instances whose DTS includes dimensional taxonomies MUST be also valid instances according to [XBRL 2.1].

Figure 1: Relationships to define constraints on the content and meaning of contexts
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. T; 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, @xbrldt:typedDomainRef and @xbrldt:contextElement) and their types are shown on the arcs where they MAY appear.

[Def, 1] Primary item declarations are elements defined in XBRL taxonomies that are in the xbrli:item substitution 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 DRSDTS.

The following sub-sections in this sectionchapter 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 2; 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 2: arcrole values for potentially consecutive relationships
Initial arc Following arc
all hypercube-dimension
notAll hypercube-dimension
hypercube-dimension dimension-domain
dimension-domain domain-member
domain-member domain-member

2.2 Hypercubes (normative)

[Def, 4] A hypercube declaration is an abstract item declaration in the xbrldt:hypercubeItem substitution group. A hypercube is an ordered list of dimensions, defined by the set of zero or more dimension declarations linked to the hypercube by hypercube-dimension relationships in a dimensional relationship set [Def, 3], and ordered according to the @order 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

  • A dimensional processor MUST raise an error xbrldte:HypercubeElementIsNotAbstractError if an element that is in the substitution group of the xbrldt:hypercubeItem element 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

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 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 xbrldte:HypercubeDimensionTargetError if this rule is violated.

2.3 Primary item declarations and hypercubes (normative)

To constrain the set of <context> s 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; they are:

  • 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 2.

Example 2: A primary item declaration with a single hypercube

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"

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

A primary item with domain members and a negated hypercube that limits the values

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 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 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 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:

[Def, 21] The instantiation of a primary item declaration [Def, 1] as a fact in an instance document is dimensionally valid witih respect to a closed hypercube when no other elements are children of a <segment> or <scenario> element except those appearing in the closed hypercube. dimensionally valid with respect to a closed hypercube when:

Example 5: Two closed hypercubes

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 (normative)

Taxonomy authors are able to partition relationships into distinct base sets using the @xlink:role attribute on extended-type link elements.

However,But it is more than a useful feature. I; 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 Requirement P2.

Furthermore, a set of primary item declarations MAY have hypercubes in common among the targets of their has-hypercube relationships.;hHypercube declarations in turn MAY have typed dimensions in common among the targets of their hypercube-dimension relationships. In Section 2.5.2 and Section 2.5.3, 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 Requirement P4.

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.

Same dimension, different domain members

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 rolesbase sets. 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 base set 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 base set 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 relationshipin an arc, any other relationshiparc that represents a consecutive relationship [Def, 2] in the source role [Def, 5]base set   MUST NOT be considered as part of the dimensional relationship set [Def, 3]. Instead, relationshipsarcs representing consecutive relationships [Def, 2] in the target role [Def, 6]base set  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
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

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 base sets impacts the validity of XBRL taxonomies. ; cConsecutive relationships [Def, 2] having the same arcrole MUST NOT violate the cyclesAllowed constraint that would normally apply within in a base set. All other taxonomy validation rules are unaffected by base sets.

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 base sets does not impact the validity of XBRL instances according to this specification. The rules in Section 3.1 below have the same meaning irrespective of whether the dimensional relationship set [Def, 3] is defined in one rolebase set or in multiple rolesbase sets.

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 (3.5.2.4 [XBRL 2.1]) with V as the value of its @roleURI attribute (5.1.3 [XBRL 2.1]). A dimensional processor MUST raise an error xbrldte:TargetRoleNotResolvedError if this constraint is not satisfied the URI content of an @xbrldt:targetRole attribute cannot be resolved via a link:roleRef element as defined in section (3.5.2.4 [XBRL 2.1]) of the [XBRL 2.1] specficiation. to a link:roleType element (5.1.3 [XBRL 2.1]).
  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 check the cycles in two arcs that represents a consecutive relationship connected with an @xbrldt:targetRole attribute according to the value of the @cyclesAllowed attribute in the arc definition in the xbrldt schema as if the two arcs that represent the consecutive relationship [Def, 2] were created in the same extended-type link element. A dimensional processor MUST raise an error xbrldte:DRSDirectedCycleError for each consecutive relationship set [Def, 19] that contains a if invalid directed cycles are found.
  3. According to the xbrldt XML Schema, the content of the @xbrldt:targetRole attribute MUST be a valid URI.

2.5 Dimensions (normative)

[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 implicit 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 connects the dimension with the domain and the domain with the members. See section Section 2.5.3 below.

2.5.1 Constraints on the dimension declaration

  1. A dimensional processor MUST raise an error 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] below 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 this typed dimension.

The value of the @xbrldt:typedDomainRef attribute MUST be an URI reference as defined in [IETF RFC 3986]. The value of @xbrldt:typedDomainRef MUST have a fragment identifier conformant with the section 3.2 of the XPointer framework [XPOINTER].

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] before use .

<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 xbrldte:OutOfDTSSchemaError attribute points to a schema that is not included in the taxonomy DTS.
  2. A dimensional processor MUST raise an error 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 xbrldte:TypedDimensionError if the @xbrldt:typedDomainRef attribute locates (with @xml:base and following definition in section 3.2 of [XPOINTER]) 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 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 an explicit dimension is the set of QNames of all usable elements (see Section 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 [Dimensions Requirements].

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, Primary Items and explicit dimension domain s 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 could be used as a member of an explicit dimension in the <context> of another item or it can be used as an item too. 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 Section 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 xbrldte:DimensionDomainSourceError if the source of the arc is not an explicit dimension declaration [Def, 10].
  2. A dimensional processor MUST raise an error xbrldte:DimensionDomainTargetError if the target of the arc is not a domain member declaration [Def, 11].
  3. A dimensional processor MUST raise an error 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 xbrldte:DomainMemberSourceError if the source of a domain-member arc is not a primary item declaration.
  2. A dimensional processor MUST raise an error xbrldte:DomainMemberTargetError if the target of a domain-member arc is not a primary item declaration.
  3. A dimensional processor MUST raise an error 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 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, then 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 an 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 an explicit dimension [Def, 12].

2.5.3.3.1 Constraints on the value of the @xbrldt:usable attribute

According to the xbrldt XML Schema, the value of the @xbrldt:usable attribute must be Boolean.

2.6 Domain-member relations and inheritance (normative)

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 arc 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

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 chapter Section 3.1.2, "Mutual validity of hypercbues in a base set" below , only the hypercubes that are found within the same base set are considered together for validation.

Example 11: Inheritance and processing of multiple hypercubes.

Inheritance and processing of multiple hypercubes
Element under validation Extended link Hypercubes
p_PrimaryParent link1 hc_One
p_FirstChild link1 hc_One and hc_Two
p_SecondChild link1 hc_One and hc_Two
p_ThirdChild link1 hc_One and hc_Two
p_PrimaryParent link2 None
p_FirstChild link2 None
p_SecondChild link2 hc_Three
p_ThirdChild link2 hc_Three

Hypercube inheritance is across the entire dimensional relationship set [Def, 3] of the domain-member network. When locating hypercubes associated with a Primary Item P, the network of has-hypercube arcs MUST include all has-hypercube arcs in the current base set and any other has-hypercube arc found in Primary Items that are ancestors of P in the domain-member network in any base set.

In Example 12 below there is another example of this particular use case:

Example 12: Multiple all All hypercubes in a domain-member network

Multiple All hypercubes in a domain-member network

This is the table of the possible values for each Primary Item:

Element Product Dimension Region Dimension Explanation
p_GrossProfit 1,2,3 A,B,C Directly linked hypercube hc_Reg_x_Prod defined in cube1
p_Sales 1,2,3 A,B,C Inherited from parent p_GrossProfit
p_CostOfGoods 1,2,3 C Inherited from parent is cube1, but cube2 with notAll excludes combinations of A,B with all members from the product dimension and keeps element C from the regions dimension combined with all members in the product dimension
p_ImportedGoods 1,2,3 No combination is possible, a warning MAY be raised by dimensional processors. Inherited from parent p_CostOfGoods are only the combinations of the C region with all members in the products domain. cube3 is incompatible because it only includes region A. Either hypercube declared in (cube1 and not cube2) or hypercube declared in (cube3) will be invalid so the hypercubes are not compatible and it is not possible to create a dimensionally valid instantiation of p_ImportedGoods.

The order in which the has-hypercubes arcs are processed is not relevant to the result.

2.7 Default values for dimensions (normative)

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 Section 3.1.4.1).

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 = GrossProfitTaxes. 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 xbrldte:DimensionDefaultSourceError if the source of the arc is not an explicit dimension declaration [Def, 10].
  2. A dimensional processor MUST raise an error 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. There MUST be no more than one default member in a domain. A dimensional processor MUST raise an error 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 xbrldie:DefaultValueUsedInInstanceError when a default member appears.

3 Dimensions in instance documents (normative)

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 base set with a valid 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 (normative)

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 set [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 at the root of a dimensional relationship set

Primary item declaration [Def, 1] 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 Section 3.1.2. A dimensional processor MUST raise an error 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 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
Yes Yes 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 Yes Dim1 Dimension value not found for Dim1 N/A Invalid
Yes Yes 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.

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 Section 3.1.4 "Validity of dimensions" 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 content 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 Ddefault 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. Validation of typed dimensions and explicit dimensions is defined in Section 3.1.4.4 below and Section 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 xbrldie:RepeatedDimensionInInstanceError when this rule is violated.
  2. According to Section 2.7.1.2 above a dimension the default values [Def, 17] cannot appear in the instance document and an error xbrldie:DefaultValueUsedInInstanceError MUST be raised if the default value is found.

3.1.4.3 Examples of context and their dimension validity

Example 15: Dimensionally invalid context containing two references to the same dimension

<context id="c3">
<entity>
<identifier scheme="http://nic.net">example.com</identifier>
<segment>
<xbrldi:typedMember dimension="tax:Team">
<d:Team>Rams</d:Team>
</xbrldi:typedMember>
</segment>
</entity>
<period>
<forever/>
</period>
<scenario>
<xbrldi:typedMember dimension="tax:Team">
<d:Team>Lakers</d:Team>
</xbrldi:typedMember>
</scenario>
</context>

Example 16: A segment that is valid with respect to a hypercube

A segment that is valid with respect to a hypercube
<context id="c4">
<entity>
<identifier scheme="http://nic.net">example.com</identifier>
<segment>
<xbrldi:typedMember dimension="tax:TeamDim">
<d:Team>Rams</d:Team>
</xbrldi:typedMember>
<xbrldi:typedMember dimension="tax:DrinkDim">
<d:Drink>Coors</d:Drink>
</xbrldi:typedMember>
</segment>
</entity>
<period>
<forever/>
</period>
</context>

Example 17: Two segments not dimensionally valid with respect to a hypercube

Two segments not dimensionally valid with respect to a hypercube
<context id="c5">
<entity>
<identifier scheme="http://nic.net">example.com</identifier>
<segment>
<xbrldi:typedMember dimension="tax:TeamDim">
<d:Team>Rams</d:Team>
</xbrldi:typedMember>
</segment>
</entity>
<period>
<forever/>
</period>
</context>
Missing a reference to the Drink dimension.
<context id="c7">
<entity>
<identifier scheme="http://nic.net">example.com</identifier>
<segment>
<xbrldi:typedMember dimension="tax:DrinkDim">
<d:Drink>Coors</d:Drink>
</xbrldi:typedMember>
</segment>
</entity>
<period>
<forever/>
</period>
</context>
Missing a reference to the Team dimension.

Example 18: Valid and Invalid Hypercubes according to its dimensions and domains

Dimensions Domains Member Result
RegionDim r:Europe, r:Asia, r:Africa, r:SouthAmerica r:Europe Valid (member is in the domain)
RegionDim r:Europe, r:Asia, r:Africa, r:SouthAmerica p:Wine, p:Cars, p:Other r:Japan Invalid (member is not in the domain)
RegionDim and ProductDim r:Europe, r:Asia, r:Africa, r:SouthAmerica p:Wine, p:Cars, p:Other p:Wine Invalid (missing value for the Region Dimension) xbrldie:PrimaryItemDimensionallyInvalidError xbrldie:hypercubeMissingInSegmentDimensionError MUST be raised
RegionDim and ProductDim r:Europe, r:Asia, r:Africa, r:SouthAmerica p:Wine, p:Cars, p:Other r:Japan Invalid (missing value for the Products Dimension) xbrldie:PrimaryItemDimensionallyInvalidError xbrldie:hypercubeMissingInSegmentDimensionError MUST be raised
RegionDim and ProductDim r:Europe, r:Asia, r:Africa, r:SouthAmerica p:Wine, p:Cars, p:Other r:Africa p:Soja Invalid (member is not in the product domain)
RegionDim and ProductDim r:Europe, r:Asia, r:Africa, r:SouthAmerica p:Wine, p:Cars, p:Other r:Africa p:Cars Valid (members are in the Region and Product domains)

Example 19: Primary items that are not dimensionally valid because they violate their hypercube constraints

<unit id="eur">
<measure>iso4217:EUR</measure>
</unit>
<context id="c19">
<entity>
<identifier scheme="http://nic.net">example.com</identifier>
<segment>
<xbrldi:explicitMember dimension="p:ProductDim">p:m_RedWine</xbrldi:explicitMember>
<xbrldi:explicitMember dimension="p:RegionDim">p:m_Barbados</xbrldi:explicitMember>
</segment>
</entity>
<period>
<forever/>
</period>
</context>
<p:p_GrossProfit contextRef="c19" unitRef="eur" decimals="INF">10000</p:p_GrossProfit>
<p:p_CostOfGoods contextRef="c19" unitRef="eur" decimals="INF">50000</p:p_CostOfGoods>
<p:p_Sales contextRef="c19" unitRef="eur" decimals="INF">60000</p:p_Sales>
Assuming the context is using the DRS defined in Example 10 and Example 20. p:m_ Barbados is not a domain member of in hc_ RegionDim; hence the constraint is violated by all three facts even though only p_Sales GrossProfit had an explicit "all" arc to hc_Product_x_Region.

3.1.4.4 Typed dimensions

The member of a typed dimension is the instantiation of an element that conforms to the element referenced in the @xbrldt:typedDomainRef attribute of a typed dimension declaration [Def, 9].

3.1.4.4.1 The xbrldi:typedMember element

The xbrldi:typedMember element is an XML element whose content MUST be another element whose schema declaration is located by the @xbrldt:typedDomainRef attribute (see section Section 2.5.2.1).

<element name="typedMember">
<annotation>
<documentation xml:lang="en">This element constains one child of anyType. </documentation>
</annotation>
<complexType>
<sequence>
<any namespace="##other"/>
</sequence>
<attribute name="dimension" type="QName" use="required"/>
</complexType>
</element>

The content of the @dimension attribute of an xbrldi:typedMember element MUST resolve to the QName of a typed dimension declaration [Def, 9] within the DTS of the instance.

A typed dimension is valid if the dimension value [Def, 15] is XML valid according to the schema declaration referred to in the @xbrldt:typedDomainRef attribute.

Example 20: Two dimensions referenced in the segment of a context

<context id="c1">
<entity>
<identifier scheme="http://nic.net">example.com</identifier>
<segment>
<xbrldi:typedMember dimension="tax:TeamDim">
<d:Team>Lakers</d:Team>
</xbrldi:typedMember>
<xbrldi:typedMember dimension="tax:DrinkDim">
<d:Drink>Coors</d:Drink>
</xbrldi:typedMember>
</segment>
</entity>
<period>
<forever/>
</period>
</context>

Example 21: 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>
<xbrldi:typedMember dimension="tax:TeamDim">
<d:Team>Celtics</d:Team>
</xbrldi:typedMember>
<xbrldi:typedMember dimension="tax:DrinkDim">
<d:Drink>Sam Adams</d:Drink>
</xbrldi:typedMember>
</scenario>
</context>

Not all of the elements appearing in <segment> or <scenario> are necessarily dimension elements; see section Section 2.3.2.1 regarding the @closed attribute.

3.1.4.4.2 Constraints about the @dimension attribute in xbrldi:typedMember elements
  1. The content of the @dimension attribute of an xbrldi:typedMember element MUST be the QName of a typed dimension declaration [Def, 9] defined in a schema within the DTS of the instance document. A dimensional processor MUST raise an error xbrldie:TypedMemberNotTypedDimensionError if the element whose QName appears in the @dimension attribute of xbrldi:typedMember resolves to anything other than a typed dimension declaration [Def, 9].
3.1.4.4.3 Constraints on the content of xbrldi:typedMember elements
  1. According to the xbrldi XML Schema, every instance of xbrldi:typedMember  MUST have only one child element.
  2. The typed dimension value [Def, 15]  MUST be XML valid according to the XML Schema declaration of the element referenced in the @xbrldt:typedDomainRef attribute.
  3. The typed dimension content [Def, 15] MUST be an instantiation of the element pointed to by the @xbrldt:typedDomainRef of the typed dimension indicated in the @dimension attribute of the xbrldi:typedMember element. A dimensional processor MUST raise an error xbrldie:IllegalTypedDimensionContentError if this rule is violated.

3.1.4.5 Explicit dimensions

The member of an explicit dimension is the QName that is the content of the xbrldi:explicitMember element. It MUST be a valid member of the explicit dimension [Def, 12].

3.1.4.5.1 The xbrldi:explicitMember element

The xbrldi:explicitMember element is an XML element whose content MUST be a QName. The explicit dimension is valid if the dimension value [Def, 15] (QName) is a valid member of the explicit dimension domain [Def, 12] to which its @dimension attribute refers.

<element name="explicitMember">
<annotation>
<documentation xml:lang="en">This element contains the QName of an item that is a member of an explicit dimension. </documentation>
</annotation>
<complexType>
<simpleContent>
<extension base="QName">
<attribute name="dimension" type="QName" use="required"/>
</extension>
</simpleContent>
</complexType>
</element>
<element name="explicitMember">
<annotation>
<documentation xml:lang="en">This element contains the QName of an item that is a member of an explicit dimension. </documentation>
</annotation>
<complexType>
<simpleContent>
<extension base="QName">
<attribute name="dimension" type="QName" use="required"/>
</extension>
</simpleContent>
</complexType>
</element>

Example 22: A context that is dimensionally valid with respect to a hypercube with two explicit dimensions

A context that is dimensionally valid with respect to a hypercube with two explicit dimensions
<context id="c16">
<entity>
<identifier scheme="http://nic.net">example.com</identifier>
<segment>
<xbrldi:explicitMember dimension="tax:RegionDim">r:m_Iberia</xbrldi:explicitMember>
<xbrldi:explicitMember dimension="tax:ProductDim">p:m_RedWine</xbrldi:explicitMember>
</segment>
</entity>
<period>
<forever/>
</period>
</context>
3.1.4.5.2 Constraints on the @dimension attribute in xbrldi:explicitMember elements
  1. The content of the @dimension attribute of an xbrldi:explicitMember element MUST be the QName of an explicit dimension element defined in a schema within the DTS of the instance document. A dimensional processor MUST raise an error xbrldie:ExplicitMemberNotExplicitDimensionError if the element whose QName appears in the @dimension attribute of xbrldi:explicitMember resolves to anything other than an explicit dimension declaration [Def, 10].
3.1.4.5.3 Constraints on the content of the xbrldi:explicitMember elements
  1. The content of the xbrldi:explicitMember element MUST be a QName whose global element definition can be found in the taxonomy schema referenced by the namespace of the QName. A dimensional processor MUST raise e an error xbrldie:ExplicitMemberUndefinedQNameError if this rule is violated.

3.2 Definition of dimensionally equal facts (normative)

[Def, 18] Two facts are d-equal for one dimension if they have the same dimension value [Def, 15] for that dimension.

d-equal is an independent operation of c-equal, u-equal, s-equal defined in section 4.10 of [XBRL 2.1] d-equal is defined only for two facts and one dimension. Two dimension values [Def, 15] are the same when they are s-equal2. Two facts have the same dimension if both have a dimension container whose content of the @dimension attribute are s-equal2 and both refer to the same dimension declaration [Def, 7].

The s-equal2 operation is the same operation defined in section 4.10 of [XBRL 2.1] replacing XPATH 1.0 with XPATH 2.0 in the definition of the x-equal operation and with the "XPath 1.0 compatibility mode" property set to false in the static <context> (See the implementation note below).

In order to allow the summation-item relationships defined in section 5.2.5.2 of [XBRL 2.1] to work, all dimensional elements (xbrldi:explicitMember and xbrldi:typedMember) found in the <segment> or <scenario> container of the <context>   MUST be s-equal as defined in the section 4.10 of [XBRL 2.1].

IMPLEMENTATION NOTE: [XBRL 2.1] is based on [XPath 1.0]. According to section 5.3 of [XPath 1.0], the content of attributes is always a string-value rather than a QName. XBRL APIs implementing dimensions should take care of this and normalise the prefixes of QNames that appear in the @dimension attribute of the dimension container and in the content of the dimension container within the instance document.

Two facts related to different <context> s that appear in different instances MAY be d-equal for all dimensions regardless of the order in which the elements appear inside the <segment> or the <scenario> .

Example 23: Multiple contexts and the result of the d-equal operation

Fact Sales in Context A Fact Sales in Context B d-equal( Sales, prodDim)
<segment>
<xbrldi:explicitMember dimension="tax:prodDim">p:product</xbrldi:explicitMember>
</segment>
<segment>
<xbrldi:explicitMember dimension="tax:prodDim">   p:product</xbrldi:explicitMember>
</segment>

Yes.

Note the spaces between elements are different.

<segment>
<xbrldi:explicitMember dimension="tax:prodDim">p:product</xbrldi:explicitMember>
<xbrldi:explicitMember dimension="tax:dept_dim">r:sales</xbrldi:explicitMember>
</segment>
<segment>
<xbrldi:explicitMember dimension="tax:dept_dim">r:sales</xbrldi:explicitMember>
<xbrldi:explicitMember dimension="tax:prodDim">p:product</xbrldi:explicitMember>
</segment>

Yes.

Note that the order of the two explicit elements is different. According to the text in this section these two <context> s MUST NOT occur in the same instance.

<segment>
<xbrldi:explicitMember dimension="tax:prodDim">p:product</xbrldi:explicitMember>
</segment>
<scenario>
<xbrldi:explicitMember dimension="tax:prodDim">p:product</xbrldi:explicitMember>
</scenario>

No,

Dimensions MUST be reported in the same container type.

Appendix A Errors

A.1 Validating Taxonomies

The hyperlinked index that appeared in the original version of this specification is not included here since it is automatically included at the head of the document. Similarly the third column from the table below has been removed as it contained only hyperlinks to the relevant section whereas now the actual error code is hyperlinked directly.

The namespace xbrldte is defined as http://xbrl.org/2005/xbrldt/errors

  Taxonomy Error Meaning
[Dim Err, 1] xbrldte:HypercubeElementIsNotAbstractError Hypercube element MUST be abstract
[Dim Err, 10] xbrldte:OutOfDTSSchemaError The schema referenced in the @xbrldt:typedDomainRef attribute is not in the DTS
[Dim Err, 11] xbrldte:TypedDomainRefError The @xbrldt:typedDomainRef attribute appears on an element declaration that is not a dimension declaration.
[Dim Err, 12] xbrldte:TypedDimensionError The @xbrldt:typedDomainRef attribute does not locate a typed dimension.
[Dim Err, 13] xbrldte:TypedDimensionURIError The @xbrldt:typedDomainRef attribute contains an invalid URI or does not contain a fragment identifier
[Dim Err, 14] xbrldte:DimensionDomainSourceError The source of a dimension-domain arc is not the correct type.
[Dim Err, 15] xbrldte:DimensionDomainTargetError The target of a dimension-domain arc is not the correct type.
[Dim Err, 16] xbrldte:PrimaryItemPolymorphismError A cycle exists, the Primary Item cannot be a member of the domain of any of its dimensions
[Dim Err, 17] xbrldte:DomainMemberSourceError Constraints on the dimension-domain arcs
[Dim Err, 18] xbrldte:DomainMemberTargetError The target of a domain-member arc is not the correct type.
[Dim Err, 19] xbrldte:DimensionDefaultSourceError The source of a dimension-default arc is not an explicit dimension declaration
[Dim Err, 2] xbrldte:HypercubeDimensionSourceError The source of the hypercube-dimension arc is not the correct type.
[Dim Err, 20] xbrldte:DimensionDefaultTargetError The target of a dimension-default arc is not a domain member declaration
[Dim Err, 21] xbrldte:TooManyDefaultMembersError The dimension has two or more members in its domain that MAY play the role of the default member.
[Dim Err, 3] xbrldte:HypercubeDimensionTargetError The target of the hypercube-dimension arc is not the correct type.
[Dim Err, 4] xbrldte:HasHypercubeSourceError The source of an all, notAll arc is not the correct type.
[Dim Err, 5] xbrldte:HasHypercubeTargetError The target of an all, notAll arc is not the correct type.
[Dim Err, 6] xbrldte:HasHypercubeMissingContextElementAttributeError The all, notAll arc does not have an @xbrldt:contextElement attribute.
[Dim Err, 7] xbrldte:TargetRoleNotResolvedError The URI content of a @xbrldt:targetRole attribute cannot be resolved via a roleRef to a roleType.
[Dim Err, 8] xbrldte:DRSDirectedCycleError Within a dimensional relationship set there MUST NOT be directed cycles not allowed by the arc declaration.
[Dim Err, 9] xbrldte:DimensionElementIsNotAbstractError Dimension elements MUST be abstract

A.2 Validating Instances

The hyperlinked index that appeared in the original version of this specification is not included here since it is automatically included at the head of the document. Similarly the third column from the table below has been removed as it contained only hyperlinks to the relevant section whereas now the actual error code is hyperlinked directly.

The namespace xbrldie is defined as http://xbrl.org/2005/xbrldi/errors

Table 3: "Instance Error"
  Instance Error Meaning
[Ins Err, 1] xbrldie:DefaultValueUsedInInstanceError Default values of dimension MUST NOT NOT be reported in instances.
[Ins Err, 2] xbrldie:PrimaryItemDimensionallyInvalidError The Primary Item contains invalid hypercubes in all base sets
[Ins Err, 3] xbrldie:RepeatedDimensionInInstanceError It is not allowed to report a value for the same dimension more then once.
[Ins Err, 4] xbrldie:TypedMemberNotTypedDimensionError The xbrldi:typedMember element does not refer to a typed dimension.
[Ins Err, 5] xbrldie:ExplicitMemberNotExplicitDimensionError The xbrldi:explicitMember element does not refer to an explicit dimension.
[Ins Err, 6] xbrldie:ExplicitMemberUndefinedQNameError The QName value of the xbrldi:explicitMember element is not an element defined in the taxonomy schema.
[Ins Err, 7] xbrldie:IllegalTypedDimensionContentError The content of a typed dimension container does not correspond to the element indicated in the dimension definition

Appendix B Requirements Reference (non-normative)

This section cross references to the dimensional taxonomy requirements [Dimensions Requirements].

Id Requirement Satisfied by reference / Not satisfied
P1 Flexibility: The solution MUST be applicable to multiple environments in which dimensions are a good solution. Satisfied. Any set of Primary Item for internal or external reporting MAY be augmented with dimensions.
P2 Consistency: XBRL concepts and terminology SHOULD be used to describe the solution. In particular, dimensions SHOULD be described using taxonomy schemas and linkbases when Satisfied. Section 2.5.2, Typed dimensions; Section 2.5.3, Explicit dimensions; Section 2.6 Domain-member relations and inheritance; use of arc roles all, notAll, hypercube-dimension, dimension-domain, domain-member.
P3 Simplicity: The solution MUST NOT include features for which there is no documented need. Satisfied.
P4 Irredundancy: The solution SHOULD NOT require instances, schemas or linkbases to encode the same information in multiple places. Satisfied. Use of base sets in validation to avoid redundancy explained in Section 2.4, "Partitioning of a Dimensional relationship set" Association of typed dimension items and dimensional elements has a unidirectional reference, Section 2.5.2.1, "The xbrldt:typedDomainRef".
P5 Priority: An implementation of these requirements MUST NOT violate the most current edition of [XBRL 2.1]. Satisfied. Definition links are defined only on items, explained in Section 2.1, "Architecture".
G01 Taxonomy authors MUST be able to define the valid combinations of Dimensions and Dimension members that MUST NOT , MAY or MUST occur in the <segment> s and <scenario> s of the <context> s of the facts of any concept, and whether other elements MAY or MUST NOT appear in <segment> s and <scenario> s. Satisfied; Section 2.3, "Primary item declarations and hypercubes;" and Section 3.1, "Validation of primary items".
G02 One <context>   MAY have multiple Dimensions. The Dimensions MAY be implicit or explicit. Satisfied; Section 2.2, "Hypercubes."
G03 Taxonomy authors MUST be able to name Implicit Dimensions. Satisfied; Section 2.5.2, "Typed dimensions."
G04 Taxonomy authors MUST be able to define constraints on valid implicit dimension members, while allowing instance authors to enumerate the members. Satisfied; Section 2.5.2, "Typed dimensions."
G05 Taxonomy authors MUST be able to extend or restrict the members of Implicit Dimensions of a base taxonomy. Satisfied. Section 2.5.2, "Typed dimensions," allows implicit dimensions to be defined on any XML Schema element of any type.
G06 Taxonomy authors MUST be able to define explicit dimensions. An Explicit Dimension has a discrete list of valid explicit dimension Members. Satisfied; Section 2.5.3, "Explicit dimensions."
G07 Taxonomy authors MUST be able to define a suggested presentation ordering relation on explicit dimension Members. Satisfied; Section 2.5.3, "Explicit dimensions."
G08 Taxonomy authors MUST be able to define suggested labels to be associated with explicit dimension Members in different situations and in different languages. Satisfied. Section 2.5.3, "Explicit dimensions," explicit dimension members are non-abstract items that MAY have labels.
G09 Taxonomy authors MUST be able to define an inclusion relationship on Dimension Members. Satisfied. Section 2.5.3.2, the domain-member relationship is the inclusion relationship.
G10 Taxonomy authors MUST be able to extend a base explicit dimension by adding Dimension Members, prohibiting or supplementing inclusion relationships, preferred presentation order, or text strings. Satisfied. Section 2.5.3, "Explicit dimensions." explicit dimensions are represented using the existing XBRL definition linkbase.
G11 Taxonomy authors MUST be able to define Dimension Member combinations among explicit dimensions that are valid or invalid in <context> s of specific concepts. Satisfied. Section 2.3, "Primary item declarations and hypercubes" and Section 3.1, "Validation of primary items."
G12 Taxonomy authors MUST be able to use the same explicit dimension Members in any number of explicit dimensions. Satisfied. Section 2.5.3.1 and Section 2.5.3.2 define dimension-domain and domain-member relationships to allow reuse of both dimensions and domains.
G13 Taxonomy authors MUST be able to define summations over explicit dimension Members. Not satisfied. This functionality will be implemented in a separate LRR entry.
G14 Taxonomy authors MUST be able to limit summations over explicit dimension Members to apply only to certain concepts. Not satisfied. This functionality will be implemented in a separate LRR entry.
G15 Taxonomy authors MUST be able to define an equivalence relationship on Explicit Dimension Members within the same explicit dimension. Not satisfied. This functionality will be implemented in a separate LRR entry.
G16 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. Satisfied. Existing items and relationships from a primary taxonomy, such as summation-item relationships, are not used in dimensional taxonomies, guaranteeing separation.
G17 The specification SHOULD minimise the number of elements required to express constraints on combinations of Concepts and Dimension Members. Satisfied. Section 2.3, "Primary item declarations and hypercubes" allows a minimum of one element per hypercube; Section 2.4, "Partitioning of a Dimensional relationship set," allows a set of dimension or domain relationships to be used by any number of hypercubes or primary item declarations.
G18 Formula linkbase authors MUST be able to select concepts that are reported in multiple dimensions. Not satisfied in this specification, will be part of a function specification.
T1 The specification MUST include a conformance suite and the requirement that there be two independent implementations correctly processing that conformance suite. Satisfied.

Appendix C References

Dimensions Requirements
XBRL International Inc.. "XBRL Dimensional Taxonomy Requirements"
Ignacio Hernández-Ros
, Walter Hamscher, David vun Kannon, and Hugh Wallis.
(See http://www.xbrl.org/technical/requirements/DIM-REQ-PWD-2005-06-21.rtf)
IETF RFC 2119
IETF (Internet Engineering Task Force). "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels"
Scott Bradner.

(See http://www.ietf.org/rfc/rfc2119.txt)
IETF RFC 3986
IETF (Internet Engineering Task Force). "RFC 3986: Uniform Resource Identifier (URI): Generic Syntax"
T. Berners-Lee
, R. Fielding, and L. Masinter.
(See http://www.ietf.org/rfc/rfc3986.txt)
XBRL 2.1
XBRL International Inc.. "Extensible Business Reporting Language (XBRL) 2.1 Includes Corrected Errata Up To 2008-07-02"
Phillip Engel
, Walter Hamscher, Geoff Shuetrim, David vun Kannon, and Hugh Wallis.
(See http://www.xbrl.org/Specification/XBRL-RECOMMENDATION-2003-12-31+Corrected-Errata-2008-07-02.htm)
XLINK
W3C (World Wide Web Consortium). "XML Linking Language (XLink) Version 1.0"
Steve DeRose
, Eve Maler, and David Orchard.
(See http://www.w3.org/TR/xlink/)
XML Base
W3C (World Wide Web Consortium). "XML Base"
Johnathan Marsh.

(See http://www.w3.org/TR/xmlbase/)
XML Schema Datatypes
W3C (World Wide Web Consortium). "XML Schema Part 2: Datatypes Second Edition"
Paul V. Biron
, and Ashok Malhotra.
(See http://www.w3.org/TR/xmlschema-2/)
XML Schema Structures
W3C (World Wide Web Consortium). "XML Schema Part 1: Structures Second Edition"
Henry S. Thompson
, David Beech, Murray Maloney, and Noah Mendelsohn.
(See http://www.w3.org/TR/xmlschema-1/)
XPATH 2.0
W3C (World Wide Web Consortium). "XML Path Language (XPath) 2.0"
Anders Berglund
, Scott Boag, Don Chamberlin, Mary F. Fernández, Michael Kay, Jonathan Robie, and Jérôme Siméon.
(See http://www.w3.org/TR/xpath20/)
XPOINTER
W3C (World Wide Web Consortium). "XPointer Framework"
Paul Grosso
, Eve Maler, Jonathan Marsh, and Norman Walsh.
(See http://www.w3.org/TR/xptr-framework/)
XPath 1.0
W3C (World Wide Web Consortium). "XML Path Language (XPath) 1.0"
James Clark
, and Steve DeRose.
(See http://www.w3.org/TR/xpath/)

Appendix D Schemas (normative)

The following is the XML schema provided as part of this specification. It is normative. A non- normative version (which should be identical to this except for appropriate comments indicating its non-normative status) is also provided as a separate file for convenience of users of the specification.

XBRL taxonomies using this dimensional specification MAY import the xbrldt-2005.xsd schema and MUST be schema valid according to the schema validation rules defined in [XML Schema Structures][XML Schema Datatypes]. Any XML Schema validation error MAY stop dimensional processors from continuing to validate dimensional relationships.

XBRL instances using the elements defined in xbrldi-2006.xsd MUST be XML Schema valid according to validation rules defined in [XML Schema Structures][XML Schema Datatypes]. Any XML Schema validation error MAY stop the processing of the instance document.

NOTE: (non-normative) Following the schema maintenance policy of XBRL International, it is the intent (but is not guaranteed) that the location of a non-normative version of this schema on the web will be as follows:

While any schema is the most current RECOMMENDED version and until it is superseded by any additional errata corrections a non-normative version will reside on the web in the directories http://www.xbrl.org/2005/ and http://www.xbrl.org/2006/ respectively.

D.1 xbrldt-2005.xsd (normative)

<xs:schema
xmlns
="http://www.xbrl.org/2003/linkbase"

xmlns:xl
="http://www.xbrl.org/2003/XLink"
targetNamespace="http://xbrl.org/2005/xbrldt" elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:annotation>
<xs:appinfo>
<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>
<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>
<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>
<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>
<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>
<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>
</xs:appinfo>
</xs:annotation>
<xs:import namespace="http://www.xbrl.org/2003/instance" schemaLocation="http://www.xbrl.org/2003/xbrl-instance-2003-12-31.xsd"/>
<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"/>
<xs:attribute name="typedDomainRef" type="xs:anyURI"/>
<xs:attribute name="closed" type="xs:boolean" default="false"/>
<xs:attribute name="usable" type="xs:boolean" default="true"/>
<xs:attribute name="targetRole" type="xs:anyURI"/>
<xs:element name="hypercubeItem" id="xbrldt_hypercubeItem" abstract="true" substitutionGroup="xbrli:item" type="xbrli:stringItemType" xbrli:periodType="duration"/>
<xs:element name="dimensionItem" id="xbrldt_dimensionItem" abstract="true" substitutionGroup="xbrli:item" type="xbrli:stringItemType" xbrli:periodType="duration"/>
</xs:schema>

D.2 xbrldi-2006.xsd (normative)

<schema
xmlns
="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://xbrl.org/2006/xbrldi" elementFormDefault="qualified" attributeFormDefault="unqualified">
<annotation>
<appinfo>
<documentation xml:lang="en">This schema is used by XBRL instances that use dimensions to define legal segment and scenario element contents.</documentation>
</appinfo>
</annotation>
<element name="explicitMember">
<annotation>
<documentation xml:lang="en">This element contains the QName of an item that is a member of an explicit dimension. </documentation>
</annotation>
<complexType>
<simpleContent>
<extension base="QName">
<attribute name="dimension" type="QName" use="required"/>
</extension>
</simpleContent>
</complexType>
</element>
<element name="typedMember">
<annotation>
<documentation xml:lang="en">This element constains one child of anyType. </documentation>
</annotation>
<complexType>
<sequence>
<any namespace="##other"/>
</sequence>
<attribute name="dimension" type="QName" use="required"/>
</complexType>
</element>
</schema>

Appendix E Intellectual property status (non-normative)

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to XBRL International or XBRL organizations, except as required to translate it into languages other than English. Members of XBRL International agree to grant certain licenses under the XBRL International Intellectual Property Policy (www.xbrl.org/legal).

This document and the information contained herein is provided on an "AS IS" basis and XBRL INTERNATIONAL DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

The attention of users of this document is directed to the possibility that compliance with or adoption of XBRL International specifications may require use of an invention covered by patent rights. XBRL International shall not be responsible for identifying patents for which a license may be required by any XBRL International specification, or for conducting legal inquiries into the legal validity or scope of those patents that are brought to its attention. XBRL International specifications are prospective and advisory only. Prospective users are responsible for protecting themselves against liability for infringement of patents. XBRL International takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Members of XBRL International agree to grant certain licenses under the XBRL International Intellectual Property Policy (www.xbrl.org/legal).

Appendix F Acknowledgements (non-normative)

This document could not have been written without the contributions of many people.

Appendix G Document History (non-normative)

DateAuthorDetails
15 October 2004Walter Hamscher

First skeletal draft created.

17 October 2004Hugh Wallis

Rules of syntax, semantics, examples, and schema created.

11 February 2005Ignacio Hernández-Ros

Added dimensions definition in a separate file.

06 June 2005Ignacio Hernández-Ros

Created a new version adapted to Test cases.

15 June 2005Walter Hamscher

Edits to bring implicit and explicit dimensions into similar syntax.

04 July 2005Walter Hamscher

Second round of edits to bring implicit and explicit dimensions into a syntax that directly supports validation of contexts. Incorporated text edits suggested by Hugh Wallis.

11 July 2005Walter Hamscher

Combined the two variants of implicit dimensions and allowed XML Schema level validation of reference contents. Added the aggregator-contributor calculation arc role.

12 July 2005Walter Hamscher

Fixed typographical errors in schemas.

13 July 2005Walter Hamscher

Fixed namespace discrepancies. Changed xdi schema so that it no longer imports the xdt schema. Added definition arc attribute declarations to the xdt schema. Completed the error table.

14 July 2005Walter Hamscher

Typographical corrections. Corrected usages of ‘item’ and ‘concept’. Replaced usages of ‘arc’ with ‘relationship’ and defined it. Added a table correlating requirements with features. Added syntax constraint on the appearance of dimensionURI. Redefined arc roles using LRR DCR3 syntax, separating LRR declaration from schema declaration of arc roles.

Allow implicit dimensions to have any type. Correct namespace and locations in LRR entries.

19 July 2005Hugh Wallis

Editorial updates to indicate Public Working Draft status.

23 July 2005Walter Hamscher

Replaced the term "measure" with "primary item" or "primary item declaration" throughout. Made explicit that distinct base sets are disjunctive with respect to validation. Used the order attribute to force ordering of dimension references in segments and scenarios. Updated error tables to include closed attribute and to remove errors that would be signalled by XML Schema or XBRL validation. Added rule that a target role MUST be declared. Updated all examples to consistent terminology and created accompanying source files. Added the summable attribute to the has-hypercube arcs and removed aggregator-contributor arc role.

24 July 2005Walter Hamscher

Editorial changes to move syntax rules into separately numbered sections, motivated by draft conformance suite. Addition of rules to ensure that the content of definitionArc attributes are tested. Editorial changes to refer to ‘declarations’ rather than ‘definitions’.

26 July 2005Ignacio Hernández-Ros

Editorial changes to add xdt: prefix on attributes. Added the skeleton of an example about how to calculate a Cartesian product of dimensions. Added comments about some validation rules that are covered by xml schema. Added the possibility of having abstract elements in domain-member networks. Changed wording to avoid the mixture of all, any and choice in the child elements of the primary dimension in the domain-member network.

28 July 2005Ignacio Hernández-Ros

Changed summable attribute and example related to it. Changed also the Figure 1 with the overall structure of the dimensional elements.

01 August 2005Ignacio Hernández-Ros

Wording and some examples. The arc roles have been changed in the document. The XDT schema allows undirected cycles in the any, all, choice arcs. The LRR entries have been updated to add the namespaceURI attribute to attributes.

04 August 2005Ignacio Hernández-Ros

Added namespace definitions for instance errors and taxonomy errors. Each time an element is mentioned to be in substitutionGroup of xbrli:item added the text "in the head" to allow inheritance of element attributes if needed in the taxonomy design.

12 August 2005Ignacio Hernández-Ros

Minimum editorial changes. Some typos corrected. Added xdie:RepeatedDimensionInInstance in the instance errors list Changed reference to error xdie:MemberNotExplicitDimension it now points to the right description. Changed point 2.8.4.1 to make it stronger in validation.

19 August 2005Ignacio Hernández-Ros

Rebuilding of Example 19.

Added a new rule to check consistency of xdt:elt attribute, but it was removed on next day.

Added examples to the definition of "domain", "explicit dimension" and "implicit dimension" terms.

New example 15 created to demonstrate Empty Dimensions

Changed most of the wording in the terms definitions

Added some text to clarify how the @xdt:summation attribute works.

26 August 2005Ignacio Hernández-Ros

Prefixed changes from xdt to xbrldt and xdi to xbrldi.

Namespaces changed accordingly.

Changed arcrole has-dimension to hypercube-dimension.

Changed attribute @dimensionURI to @implicitDimensionRef.

Changed attribute @xdt:elt to @xbrldt:contextElement (it will be removed in next version of this document).

Wording changes to clarify some parts of the document.

Added point 2.10.1 and 2.10.2 to set up the has-hypercube priority order.

Changed the examples.

07 September 2005Ignacio Hernández-Ros

Removed polymorphism of Hypercube elements and Dimension element, now they MUST be in the substitution group of hypercubeItem and dimensionItem respectively.

Added the @xbrldt:usable attribute to exclude members from a domain that helps in the member definition but are not valid members.

Removed the overloading of the abstract attribute.

Changed the @implicitDimensionRef attribute to @implicitDomainRef.

Added the ImplicitMember in the instances.

Changed the chapter 2.9 about the validation of a context and removed most of the errors defined there.

Removed the chapter 2.10 about the priority of hypercubes operations.

Added a section 1.5 to define the namespaces used in this document.

Examples updated and wording changes in the terms definition (hypercubes) and other parts.

New schemas updated.

Updated the error tables.

09 September 2005Walter Hamscher

Updated xbrldt schema definitions of hypercubeItem and dimensionItem to be valid XBRL.

Updated LRR entries to 2005-08-11 CR3.

Incorporated Geoff Shuetrim editorial comments on 2005-08-26 draft.

Added missing default value of "false" to "closed" attribute.

Reworded syntax rules that would ordinarily be handled by XML Schema validation to "may signal" errors.

Re-sorted the instance error table.

12 September 2005Ignacio Hernández-Ros

Corrected minor but important mistakes in the definition of source and target of all, any and choice arc roles.

Corrected the type of arc on which the aggregator-contributor arcs MAY exist.

Incorporated changes from Walter Hamscher.

15 September 2005Ignacio Hernández-Ros

Reordering of the overall document. Taxonomies first then instances and validation.

Removal of @xbrldt:polarity attribute and definition of the new notAll, notAny and notChoice arcs.

26 September 2005Ignacio Hernández-Ros

Renamed Implicit dimension to typed dimensions.

Added default values for dimensions

Reviewed the aggregators section, removed references to dimensions ordering.

27 September 2005Ignacio Hernández-Ros

Updated LRR definitions.

Changed first letter to lowercase in typedMember, explicitMember, dimensionItem and hypercubeItem.

Reviewed the aggregators section.

Removed references to dimensions ordering.

07 October 2005Ignacio Hernández-Ros

Incorporated comments from Paul Warren.

A new structure of the document has been created and there are a lot of changes everywhere.

18 October 2005Ignacio Hernández-Ros

Removed any, notAny, choice, notChoice operations.

Added the new memberItem substitutionGroup.

Renamed discoverable relationship set to dimensional relationship set.

Solved some ambiguity wording.

Added normative and non-normative in titles.

20 October 2005Ignacio Hernández-Ros

Editorial changes to format errors and first errors revision.

Changed XML Schema errors to be reported as dimensional errors or XML Schema errors.

Added marks to definitions to be able to reference them in the text or tables of content.

Changed definition of aggregator-contributors arcs.

Changed definition of d-equal facts.

Added schema validation impact on taxonomies and instances.

26 October 2005Ignacio Hernández-Ros

Changed back to have domain members items in the substitution group of xbrli:item.

memberItem will be evaluated in the generic linkbase.

30 October 2005Ignacio Hernández-Ros

Reinstated the xbrldte:PrimaryItemPolymorphismError constraint.

Removed comments about the generic linkbase.

Changed the "Domain" box in the Figure 1 into a "Member" box for clarity.

Added an error if primary items are not numeric and subject of an aggregator-contributor network.

Added an error if members of an aggregator-contributor base set were not usable.

Removed all errors defined that can be handled by XML Schema validation.

01 December 2005Ignacio Hernández-Ros

Added example 11 to explain which hypercubes affect a primary item during validation.

Amendment typedElement definition in xbrldi schema.

Changed schema file name to remove month and day.

Wording changes in dimension-default relationships.

Two errors added about source and target of a dimension-default arc.

Allowed undirected cycles in domain-member arcs.

Added an error to check the existence of the QName as an xbrli:item in the schema referenced in the QName.

Changed errors at instance document validation level.

Wording changed to move old errors to possible warnings that are now vendor specific.

15 December 2005Ignacio Hernández-Ros

Cosmetic changes

schema references within the text are now references to the normative schema in section D.

New Document property StatusShort to indicate IWD, PWD etc.

Updates LRR definitions.

Added error 8 to report invalid cycles in DRS.

Removed @summable attribute in notAll arcs.

Bug#210 definition of dimensional elements has been created and reference to section 1.3 removed.

Bug#211 solved prohibiting an hypercube or a dimension to be the source of an "all" or "notAll" relationship.

According to the resolution of Bug#215 the error xbrldte:TypedExplicitDomainWithImplicitDomainError has been removed.

Added chapter 2.8.2.3 to explain "parallel tuples" and aggregator-contribution relationships.

22 December 2005Ignacio Hernández-Ros

Removed aggregator-contributor definition and references.

Implies removal of xbrldt:summable attribute.

Fixed some LRR entries.

Updated [Def, 1] to avoid non abstract elements in the xbrldt:hypercubeItem or xbrldt:dimensionItem substitution group to be valid primary items.

Fixed explicit dimension definition according to Bug#215.

31 December 2005Ignacio Hernández-Ros

Incorporated editorial changes according to comments from Paul Warren.

31 January 2006Ignacio Hernández-Ros

Editorial changes to explain the DRS

Added the definition of consecutive dimensional arcs.

Eliminated the impossible error xbrldt:DRSUndirectedCycleError.

Fixed bug in example 12.

Changed the @xlink:href attribute on explicitMember and typedMember elements to new "dimension" attribute.

The simple link element is now a QName.

31 January 2006Ignacio Hernández-Ros

Editorial changes submitted during the public exposure period.

Added an example in the dimension-default relationship

24 February 2006Ignacio Hernández-Ros

Updated the xbrldi namespace due to the changes in the xbrldi schema.

Added a paragraph and a note to example 11.

20 March 2006Hugh Wallis

Editorial to reflect Candidate Recommendation

31 March 2006Ignacio Hernández-Ros

Removal of LRR references and LRR entries in the normative sections.

Wording added to better explain DRS.

14 April 2006Walter Hamscher

Text edits for syntax and typos.

25 April 2006Ignacio Hernández-Ros

Edited text in Example 4

Point 2.5.2.1.1 changed the paragraph to indicate that the schema pointed by the xbrldt:typedDomainRef MUST be part of the DTS.

The decision made by the Spec group on 2006-04-20 did not include any specific error message.

Some other minor editorial changes were made

26 April 2006Ignacio Hernández-Ros

Added a bullet to the point 2.5.2.1.1 to raise the error xbrldte:OutOfDTSSchemaError.

26 April 2006Hugh Wallis

Editorial to reflect Candidate Recommendation 3 status

04 May 2006Ignacio Hernández-Ros

Editorial changes in sections 3.1.4, 3.1.4.1 and 3.1.4.5 to improve readability.

New Definition 13 (dimension container) added for clarity.

Section 2.5.2.1 removed " MAY not be a taxonomy schema".

Corrected typo in the header of Example 19.

10 May 2006Ignacio Hernández-Ros

Removed section 2.7.

Labels are not mandatory for dimensional elements.

Wording changed in section 3.1.4.4 to correct some typos and make explicit reference to the dimensions value definition.

Point 2.5.3.3 xbrldt:usable=falsexbrldt:usable=true for the same element in different domain but same effective domain.

Added an introductory paragraph in section 2.5 to introduce the concepts defined below.

Added and reordered the definitions in the whole section 2.5

08 June 2006Ignacio Hernández-Ros

Correct some typos in Sections 2.2.2 and 3 and examples 5, 10, 12 and 19.

The schemas that define typed dimensions MUST be in the DTS so no further changes are required to this document.

15 June 2006Ignacio Hernández-Ros

Reworded of section 2.4,

Added definitions of source extended link and target extended link.

Redefined dimensional relationship set and moved to Section 2.1

Added a new reference to XDM.

Changed the definition of Consecutive arcs.

19 June 2006Ignacio Hernández-Ros

The definition of consecutive arcs has been reworded to consecutive relationships.

Removed reference to XDM because now it is not used

26 June 2006Ignacio Hernández-Ros

The copyright notice in the schemas has been updated according to the current situation of the XBRL consortium.

In section 3.2 the definition of s-equal2 operation makes explicit reference to the XPath compatibility mode is set to false.

Minor edits in sections 2.5.2, 2.4.2 and 2.1

20 July 2006Ignacio Hernández-Ros

Minor editorial change in the description about the changes made on 2006-06-08.

12 September 2006Ignacio Hernández-Ros

Corrected a typo in Example 4.

Editorial to reflect Recommendation status.

04 July 2009Walter Hamscher

Document cleanup for publication of Errata

20 November 2011Walter Hamscher

Edits for Proposed Edited Recommendation status.

25 January 2012Walter Hamscher

Edits for Recommendation status.

Appendix H Errata Corrections incorporated in this document

This appendix contains a list of the errata that have been incorporated into this document. This represents all those errata corrections that have been approved by the XBRL International Specification Maintenance Working Group (SWG) up to and including 25 January 2012. Hyperlinks to relevant e-mail threads may only be followed by those who have access to the relevant mailing lists. Access to internal XBRL mailing lists is restricted to members of XBRL International Inc.

NumberDateSectionsDetails
1.02 April 2008 Section 2.1

Last word of the paragraph where the DRS is defined said that " Figure 1 demonstrates a DTS" but in reality it demonstrates a "DRS"

2.02 April 2008 Section 2.3.1

Example 4 had "usable: false" in the CountriesDomain box but it should contain "abstract: true" as all other boxes in the example. "usable" is an attribute of a relationship.

3.02 April 2008 Section 2.4

Example 6 had relationships crossing the boundaries of the extended link where they are defined. The new graph represents more accurately how the targetRole works.

4.02 April 2008 Section 2.5.2

Added a reference to the sections in the XBRL spec that imposes the limits to the relationships in the definition linkbase.

5.02 April 2008 Section 3.1.4.3
Section 3.1.4.5.1

Example 19 changed to work in combination with the DRS defined in Example 10 and Example 22 Also, Example 22 has been changed to avoid cross extended link relationships.

6.02 April 2008 Section 3

Non normative note on Section 3 did not consider a primary item with no hypercubes.

7.02 April 2008 Section 2.4.3

Updated wording on Section 2.4.3 to avoid resolvability of standard roles like http://www.xbrl.org/2003/role/link.

8.02 April 2008 Section 2.4.3

Updated wording on Section 2.4.3.1 to make it more clear, superseding erratum 7.

9.02 April 2008 Section 3.1.4.4.3
Appendix A

Added a new error code to check if an instance document contains a typed dimension container with a value element that does not corresponds to the element pointed to by the typedDomainRef element.

10.02 April 2008 Section 2.6

Inheritance: changed "arc" for "relationship" in the first paragraph of Section 2.6. Added preservation of the @xbrldt:closed attribute. Removed a paragraph between Example 11 and Example 12 that did a bad job providing hints about how dimensional validators could find hypercubes related to a primary item in a DRS.

11.02 April 2008 Section 3.1.4

The definition name "dimension value" has been changed to "dimension content". In order to avoid conflicts with the XML sense of a "value".

12.06 July 2009

Updated affiliation of authors and contributors.

13.07 September 2009 Section 2.3.3

Updated wording to avoid any implication that default members are valid even though they do not appear in the segment and scenario elements, per 343.

14.30 March 2008 Section 2.4.3

Add [Def, 19] and clarify the conditions for [Dim Err, 8] xbrldte:DRSDirectedCycleError, per 344.

15.02 February 2009 Section 3.1.4.3

Correct typo in Example 18, per 337.

16.02 February 2009 Section 2.7.1.1

Clarify that defaults are associated with dimensions not domains, per 342.

17.21 July 2008 Section 1
Section 2
Section 3

Make Section 1 normative except for Section 1.3, remove other indications of "normative" sections and add paragraph indicating that all sections are normative unless otherwise indicated, per 327.

18.06 July 2009 Section 1
Section 1.3
Section 2.1
Section 2.2
Section 2.5
Section 2.5.3

Corrections of grammar and wording having no impact on semantics as suggested by Roland Hommes.

19.02 April 2008 Section 2.4

Change definitions of source base set and target base set, to source role and target role, and refer to relationships not arcs, per 367.

20.20 November 2011

Grammatical corrections throughout.

21.25 January 2012

Change to editor affiliation.