1 Introduction (non-normative)

The architecture of XBRL as defined in the base XBRL 2.1, Specification [XBRL] defines a rich set of syntactic and semantic rules for specifying concepts that are members, or elements, of one dimension and relationships among them in what is termed a “taxonomy” (plural “taxonomies”). It also defines extensibility mechanisms for taxonomies and “Discoverable Taxonomy Sets” (or DTSs - see [XBRL] section 3.2). These rules employ XML Schemas [SCHEMA-1][SCHEMA‑2] to identify the various concepts involved and XLINK linkbases [XLINK] to define relationships between those concepts and between those concepts and other resources. It also defines a rich set of syntactic and semantic rules for how such DTSs are to be referenced and interpreted when used in conjunction with an XBRL instance. XBRL also provides a mechanism for instance preparers to define other dimensional metadata that describe facts that are reported in the XBRL instance. This mechanism involves the notion of “contexts” (defined by the <context> element) and, within those contexts, the use of <segment> and/or <scenario> elements along with additional schemas that specify all dimensional metadata that is not otherwise given semantic meaning by the specification itself. Dimensions that ARE provided such semantic meaning by the specification itself are the “time” dimension, which leverages the sophisticated semantic mechanisms provided in XML Schema [SCHEMA-1], and, to a limited extent, “units” which may sometimes be viewed as dimensional and at other times as properties of individual facts depending on the application.

The contents of the <segment> and <scenario> elements are deliberately left open to permit users to fashion their own mechanisms for defining and referencing this dimensional metadata. It has, however, become apparent that, in practice, there is a need to formalise a consistent system for defining this dimensional metadata and a need to define a mechanism for specifying not only the names of such metadata elements but also their interrelationships. It has also become apparent that often the nature of such metadata and metadata relationships resembles very closely that which is already addressed by the XBRL taxonomy mechanism which is used for the “concepts” dimension.

For the purposes defined in the Dimensional Taxonomies Requirements [DIM-REQ] this modular extension to the base XBRL 2.1, Specification [XBRL] defines a formalisation of the syntax of the body of the <segment> and <scenario>. This specification defines the syntax and semantics of dimensional taxonomies, which in turn define the dimensions that may be used in an XBRL instance document. This specification also defines the additional rules to which an XBRL instance document must adhere in order to be an XDT compliant instance document.

Dimensional taxonomies are syntactically identical to taxonomies that are defined in the base XBRL 2.1, Specification [XBRL] with certain restrictions that must be adhered to when they are to be used as dimensional taxonomies (see section 2). In addition certain additional semantics are defined with respect to a taxonomy when it is used as a dimensional taxonomy and referenced as such by an XBRL instance.

1.1 Background (non-normative)

As should be apparent from the requirements [DIM-REQ], dimensional metadata was not invented with XBRL. XBRL standardizes the representation of only two dimensions: the time dimension and the entity dimension. Many reporting purposes, both internal and external to organisations, require multiple dimensions. What the XBRL 2.1 specification did create was the principles for this specification to exist while defining two open elements in the context of XBRL instance documents: the segment and scenario elements. The present specification defines three possible different roles that taxonomies can play in representing multidimensional information: primary taxonomies, domain members taxonomies, and templates taxonomies. This taxonomy role differentiation is only illustrative. It is possible for one taxonomy to play two or three of these roles simultaneously.

1.1.1 Primary taxonomies

A primary taxonomy is an XBRL taxonomy that has no dimensional declarations or arcs. Requirement G16 [DIM-REQ] states “Taxonomy authors must be able to extend a base taxonomy that does not have dimensional information, to have dimensions, without changing the concepts in the base.” This specification uses the term primary taxonomy for a DTS that represents only a single dimension, the elements that are instantiated in an XBRL instance. A financial taxonomy used for a variety of purposes including internal and external reporting may be extended with a variety of dimensional taxonomies appropriate to the reporting purpose.

1.1.2 Domain members taxonomies

Typed dimensional taxonomies as defined in requirement G03 [DIM-REQ] define syntactic constraints on the contents of segments and scenarios.

Explicit dimensional taxonomies are those in which the XBRL items form a discrete, countable finite partitioning of a set of members, which hereinafter is called a domain. Examples include a taxonomy on the domain of geographic territories, or a taxonomy on a domain of product lines. Inclusion relationships (requirement G09 [DIM-REQ]) are represented by domain‑member relationships. XBRL Instances may use any number of dimensional taxonomies, with the members of their domains possibly appearing in a variety of combinations within XBRL segment and scenario elements.

1.1.3 Template taxonomies

The DTS of an instance using dimensional information contains domain‑member relationships among items in both primary taxonomies and domain members taxonomies. Since a primary taxonomy MAY NOT have dimensional information, there is an implication that the instance-rooted DTS must encompass domain‑member relationships in a linkbase that is not in the schema-rooted DTS of the primary taxonomy.

A template taxonomy imports all domain members taxonomies with the primary taxonomies and adds the dimensional structures that will be used in the XBRL instance. By convention, a taxonomy that imports primary and domain members taxonomies and defines all the necessary dimensional information is called a template taxonomy. In particular, a template defines hypercubes. A hypercube describes the Cartesian product of zero or more dimensions. Each dimension in turn is defined over zero or more domains and domains are composed by members. Note that in this formulation, a hypercube of a primary item does not include the primary item itself.

· Example: a topographic map is a 3-dimensional hypercube; it has thee dimensions, elevation, longitude and latitude, all of which are defined over the domain of real numbers. The elevation can be represented as a primary item, longitude and latitude being the two dimensions of a hypercube for that primary item.

· Example: A table in a financial statement showing revenue for products, by territory, is a 3-dimensional hypercube, with one primary item (revenue) and two explicit dimensions (products and territory). 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 main purpose of a template taxonomy is to define the structures of the hypercubes and link the hypercubes with the primary items.

1.2 Relationship to other work (non-normative)

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

Parts of this document may reiterate for expository clarity certain syntactic and semantic restrictions imposed by XBRL, but this document does not modify XBRL. In the event of any conflicts between this document and XBRL, XBRL prevails. This document does place additional restrictions beyond those prescribed by XBRL.

This document implements the business requirements agreed in the Domain and Specifications Working Groups of the XBRL consortium and documented in the [DIM-REQ] document.

1.3 Terminology (non-normative)

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

The following terms are used as described in the table below:

Term	Meaning (Normative)
Arc, arcroleRef, base set, child, concept, context, duplicate item, descendant, DTS (discoverable taxonomy set), element, entity, fact, instance, item, linkbase, linkbaseRef, p‑equal, roleRef, taxonomy, taxonomy schema, u‑equal, XBRL instance.	As defined by XBRL [XBRL].
relationship	An arc defines a relationship between its source concepts and target concepts that is determined by its xlink:arcrole and other attributes.
source [concept(s)]	The concepts identified by the URI content of the href attributes of the locator-type elements in the same extended-type link element, which have the same label attribute content as the content of the “from” attribute of an arc.
target [concept(s)]	The concepts identified by the URI content of the href attributes of the locator-type elements in the same extended-type link element, which have the same label attribute content as the content of the “to” attribute of an arc.
must, must not, required, shall, shall not, should, should not, may, optional	See [RFC2119] for definitions of these and other terms. These include, in particular: should: Conforming documents and applications are encouraged to behave as described. must: Conformant documents and consuming applications are required to behave as described; otherwise they are in error.
XDT Compliant (XDT-compliant)	Describes an element, attribute, linkbase, schema, instance document or DTS satisfying all applicable mandatory (“must”) rules in this document. Any of such artefacts that violates or ignores a recommended (“should”) rule is inferior to one that obeys it and should not be emulated.
XBRL	Extensible Business Reporting Language (XBRL) 2.1 Recommendation [XBRL].
XBRL valid (XBRL-valid)	XML instances and schemas that satisfy the syntax requirements of XBRL.

Term	Meaning (non-normative)
Dimension	Each of the different aspects by which a fact may be characterised. A dimension has only one effective domain. A typical example of a dimension is the “product” dimension that identifies for a concept (Sales) the domain consisting of the possible products that its fact can be expressed about. Dimensions are abstract elements in the substitution group of xbrldt:dimensionItem.
Domain	A (possibly empty or possibly infinite) set of members. A typical example could be the Longitude and Latitude dimensions. The numbers from -180 to +180 are a domain. In this case, both dimensions have the same domain. (In real life longitude is in a domain from -90 to +90 and latitude is in a domain from -180 to +180, but we are assuming both are the same for demonstration purposes only)
Effective Domain	A dimension may have multiple dimension-domain relationships; the effective domain is the conjoint set of all related domains.
Domain Member	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.
Aggregator	A domain member that represents the result of operating with facts about other members of the same domain. Example: In the products domain, the member “TotalProducts” is the aggregator of all possible products.
Primary Item	An XBRL v2.1 item.
Primary Item Declaration	The declaration of XBRL v2.1 item in a taxonomy.
Primary Item Descendant	Any child, grand-child etc. of a Primary Item according to the domain-member relationship.
Primary Taxonomy	A primary taxonomy is a taxonomy that contains primary items.
Dimensional Taxonomy	A taxonomy whose schema-rooted DTS includes a definition linkbase with one or more dimensional relationships.
Template Taxonomy	A taxonomy that defines hypercubes and the relationships between the hypercubes and primary items.
Hypercube	A hypercube represents a set of dimensions. Hypercubes are abstract elements in the substitutionGroup of hypercubeItem that participate in has-hypercube relations and hypercube-dimension relations.
Empty Hypercube	A hypercube with no dimensions.
Hypercube Declaration	The declaration of a hypercube in a schema document. This is represented by an abstract element declaration in the xbrldt:hypercubeItem substitution group
Dimension Declaration	The declaration of a dimension in a schema document. This is represented by an abstract element declaration in the xbrldt:dimensionItem substitution group
Typed Dimension Element	Refers to the non XBRL element used in the segment or scenario of a context as the dimension identifier.
Dimensional relationship set	A set of relationships constructed by traversing (as described in section 2.4) relationships and items not only within base sets but across base sets, thus possibly including relationships from extended-type links with different roles, and relationships with different arc roles.
Base Set	As defined in 3.5.3.9.7.3 Networks of relationships in a DTS in the [XBRL] specification.
Dimensional Processor	A dimensional processor consumes XBRL dimensional instance documents or taxonomies, and checks the conformance of that input document according to the rules declared in this document.
Raise an error	The phrase “a dimensional processor MUST raise an error” is used to indicate when 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 signal its errors can be seen in http://www.w3.org/TR/xquery-operators/#func-error

1.4 Document conventions (non-normative)

The following highlighting is used to present normative technical material in this document:

The following formatting is used for non-normative examples in this document:

The following formatting is used for non-normative counterexamples (examples of poor, discouraged or disallowed usage) in this document:

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:

Prefix	Namespace URI
xbrldt	http://xbrl.org/2005/xbrldt
xbrldi	http://xbrl.org/2005/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

2 Dimensional Taxonomies (normative)

2.1 Architecture (normative)

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

Dimensional taxonomies are distinguished by the use of several arc roles published in the Link Role Registry [LRR]. These arc roles and associated attribute declarations are in the appinfo section of an XML schema. The namespace of the schema file, 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.

Figure 1. Relationships to define constraints on the content and meaning of contexts

Figure 1 schematically shows the various relationships and the type of elements at their source and target, and the purpose that these elements serve either as primary items, explicit domain members, or as the root item that represents an entire dimension (typed or explicit). These relationships need not all be within the same extended-type link element; the xbrldt:targetRole attribute is used to connect the different pieces from Primary Items to Members across multiple extended-type link elements. The notation {all, notAll} means that there are two possible relationships. Additional attributes on the arc (xbrldt:closed, xbrldt:summable, xbrldt:usable, xbrldt:typedDomainRef and xbrldt:contextElement) and their types are shown on the arcs where they may appear.

Only XBRL items defined in the substitution group of xbrli:item may be used as an explicit dimension member.

The following sections in this chapter each define a syntax component and its consequences for validation (its semantics) with positive and negative examples. The rules of syntax that apply to dimensional schemas, linkbases and instances are stated individually within each section.

2.1.1 Segments and scenarios

The XBRL segment and scenario elements are containers having the same content model; it allows one or more elements, whose namespace must be something other than http://www.xbrl.org/2003/instance:

</sequence>

2.1.1.1 Segment and scenario elements of a context of a primary item may contain any elements allowed by their XBRL content models, unless otherwise constrained by dimensional relationships.

The mere presence of dimensional relationships and items does not by itself change the validation behaviour of an XBRL processor.

2.2 Hypercubes (normative)

[Def, 1] A hypercube declaration is an abstract item [IHR1] 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, 2], and ordered according to the order of these relationships.

2.2.1 Constraints on hypercube declarations

1. A dimensional processor MUST raise an error [Dim Err, 1] xbrldte:HypercubeElementIsNotAbstract if an element that is in the substitution group of xbrldt:hypercubeItem is not abstract.

2.2.2 Arc role http://xbrl.org/int/dim/arcrole/hypercube-dimension

The hypercube-dimension relationship has a hypercube declaration [Def, 1] as its source and a dimension declaration [Def, 3] 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 cycles.

This arc role is defined as follows in the LRR:

<roleURI>http://xbrl.org/int/dim/arcrole/hypercube-dimension</roleURI>

<authoritativeHref

>http://www.xbrl.org/2005/xbrldt-2005-09-09.xsd#hypercube-dimension</authoritativeHref>

<requirement xml:lang="en">A hypercube may have one or more dimensions.

</requirement>

</definition>

<conformanceSuiteURI>http://www.xbrl.org/conf/dim/tests.xml

</conformanceSuiteURI>

<validation xml:lang="en">The presence of an hypercube-dimension arc role indicates how part of a context is to be validated.

</validation>

<attribute namespaceURI="http://xbrl.org/2005/xbrldt" use="optional">summable</attribute>

<attribute namespaceURI="http://xbrl.org/2005/xbrldt" use="optional">targetRole</attribute>

</attributes>

<sourceAbstract>required</sourceAbstract>

<targetAbstract>required</targetAbstract>

</arcrole>

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[IHR2] </usedOn>

</arcroleType>

Example 1 shows a hypercube consisting of two typed dimensions, Team and Drink. This example shows a hypercube describing the occurrence of Team and Drink elements in either the segment or scenario element of a context.

Example 1. Hypercube of the Team and Drink typed dimensions

2.2.2.1 Constraints on hypercube-dimension arcs

1. The source of a hypercube-dimension relationship MUST be a hypercube declaration [Def, 1]. A dimensional processor must raise an error [Dim Err, 2] xbrldte:HypercubeDimensionSourceError if this rule is violated.

2. The target of a hypercube-dimension relationship must be a dimension declaration [Def, 3]. A dimensional processor must raise an error [Dim Err, 3] xbrldte:HypercubeDimensionTargetError if this rule is violated.

2.3 Primary item declarations and hypercubes (normative)

To constrain the set of contexts that may appear on primary items, a primary item declaration may be associated with zero or more hypercubes.

This specification defines no additional constraints on primary items whose corresponding primary item declaration is not associated with any hypercubes in the applicable DTS.

A set of hypercubes may be composed via conjunction of “all” and “notAll” compositors. The relationship between a compositor and its operands is represented by XLink arcs with distinct arc roles to define the different operators.

There are two arc roles collectively known as has‑hypercube relationships; 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, 2] 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, 1], respectively.

The negated version of the “all” relationship is the “notAll” relationship defined as http://xbrl.org/int/dim/arcrole/notAll

A context is dimensionally valid with respect to a conjunction of hypercubes only if it is valid with respect to all of the conjoined hypercubes individually. A negated hypercube “notAll” is valid if the non negated version of the same hypercube definition is invalid. The conjunction of a single hypercube is the hypercube itself (Example below).

Example 2. A primary item declaration with a single hypercube

The primary item declaration p_FluidCapacity is associated with a hypercube. A context will be dimensionally valid with respect to this primary item only if it has a Team and a Drink reference.

Example 3. A primary item declaration with two hypercubes composed by conjunction “all” and “notAll”

The primary item declaration p_FluidCapacity is associated with the composition of two hypercubes in the same base set. A context will be valid with respect to the primary item only if its segment has a City reference in its scenario that is a member of the hc_CityHypercubeAll and not a member of hc_CityHypercubeExcluded.

The all arc role has the following LRR declaration.

<roleURI>http://xbrl.org/int/dim/arcrole/all<roleURI>

<authoritativeHref

>http://www.xbrl.org/2005/xbrldt-2005-09-09.xsd#all</authoritativeHref>

<requirement xml:lang="en">Hypercubes may be defined by intersection.

</requirement>

</definition>

<conformanceSuiteURI>http://www.xbrl.org/conf/dim/tests.xml

</conformanceSuiteURI>

<validation xml:lang="en">The presence of an “all” arc role indicates how part of a context is to be validated.

</validation>

<attribute namespaceURI="http://xbrl.org/2005/xbrldt" use="required">contextElement</attribute>

<attribute namespaceURI="http://xbrl.org/2005/xbrldt" use="optional">closed</attribute>

<attribute namespaceURI="http://xbrl.org/2005/xbrldt" use="optional">summable</attribute>

<attribute namespaceURI="http://xbrl.org/2005/xbrldt" use="optional">targetRole</attribute>

</attributes>

<sourceAbstract>optional</sourceAbstract>

<targetAbstract>required</targetAbstract>

</arcrole>

It is declared as follows:

<arcroleType

id="all"

cyclesAllowed="undirected"

arcroleURI="http://xbrl.org/int/dim/arcrole/all">

<definition>Source (a primary item declaration) requires the target (hypercube) to appear in the context of the primary item.

</definition>

<usedOn>definitionArc</usedOn>

</arcroleType>

The notAll arc role has the following LRR declaration.

<roleURI>http://xbrl.org/int/dim/arcrole/notAll<roleURI>

<authoritativeHref

>http://www.xbrl.org/2005/xbrldt-2005-09-09.xsd#notAll</authoritativeHref>

<requirement xml:lang="en">Hypercubes may be defined by intersection.

</requirement>

</definition>

<conformanceSuiteURI>http://www.xbrl.org/conf/dim/tests.xml

</conformanceSuiteURI>

<validation xml:lang="en">The presence of a “notAll” arc role indicates how part of a context is to be validated.

</validation>

<attribute namespaceURI="http://xbrl.org/2005/xbrldt" use="required">contextElement</attribute>

<attribute namespaceURI="http://xbrl.org/2005/xbrldt" use="optional">closed</attribute>

<attribute namespaceURI="http://xbrl.org/2005/xbrldt" use="optional">summable</attribute>

<attribute namespaceURI="http://xbrl.org/2005/xbrldt" use="optional">targetRole</attribute>

</attributes>

<sourceAbstract>optional</sourceAbstract>

<targetAbstract>required</targetAbstract>

</arcrole>

It is declared as follows:

<arcroleType

id="notAll"

cyclesAllowed="undirected"

arcroleURI="http://xbrl.org/int/dim/arcrole/notAll">

<definition>Source (a primary item declaration) requires the target (hypercube) to appear in the context of the primary item.

</definition>

<usedOn>definitionArc</usedOn>

</arcroleType>

Example 4. A primary item with domain members, a negated hypercube limits the values for the country dimension of p_CostOfSales removing m_India from the domain

The primary item declaration p_GrossProfit has two children in the domain-member network. The valid members in the country dimension are AllCountries for p_GrossProfit and p_Sales but p_CostOfSales has fewer possibilities in the country dimension.

2.3.1.1 Constraints on “all” or “notAll” arcs

1. A dimensional processor MUST raise an error [Dim Err, 4] xbrldte:HasHypercubeSourceError if the source of an “all” or “notAll” relationship is not a primary item declaration.

2. A dimensional processor MUST raise an error [Dim Err, 5] xbrldte:HasHypercubeTargetError if the target of an “all” or “notAll” relationship is not a hypercube declaration [Def, 1].

3. A has-hypercube arc MUST have an xbrldt:contextElement attribute. A dimensional processor MUST raise an error [Dim Err, 6] xbrldte:HasHypercubeMissingContextElementAttribute 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.

</restriction>

</simpleType>

2.3.2.1 Constraints on the value of the xbrldt:contextElement attribute

1. Every xbrldt:contextElement attribute must have one of the values segment or scenario. A dimensional processor MAY raise any XML Schema error or [Dim Err, 7] xbrldte:InvalidContextElementAttribute if this rule is violated.

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

A context is dimensionally valid with respect to a closed hypercube when no other XML elements appear in a segment or scenario except those appearing in the closed hypercube.

Example 5. Two closed hypercubes

The arcs with xbrldt:closed="true" mean that a context is valid with respect to the target hypercube if it has a Team and Drink and nothing else in the segment element, and nothing at all in the scenario element. Note that hc_Team_x_Drink has segment in its xbrldt:contextElement attribute and hc_Empty has scenario in its xbrldt:contextElement attribute.

2.3.3.1 Constraints on the value of the xbrldt:closed attribute

1. The closed attribute, if present, MUST have a Boolean value. A dimensional processor may raise any XML Schema error or [Dim Err, 8] xbrldte:ClosedAttributeInvalid if this rule is violated.

2.3.4 The optional “xbrldt:summable” attribute

The Boolean attribute xbrldt:summable may appear on hypercube-dimension arcs and on has-hypercube arcs {all, notAll}. Its semantics are defined in section 2.8 below, “Aggregators”.

When one dimension is summable then there must be an xbrldt:summable attribute whose value is true in the has-hypercube arc {all, notAll} and one xbrldt:summable attribute whose value is true in each one of the hypercube dimensions in which the primary item is summable.

The default value of the xbrldt:summable attribute is false.

<xs:attribute name="summable" type="xs:boolean" default="xs:false" />

2.3.4.1 Constraints on the value of the xbrldt:summable attribute

1. The value of the xbrldt:summable attribute MUST be Boolean. A dimensional processor may raise any XML Schema error or [Dim Err, 9] xbrldte:SummableAttributeInvalid if the value of the xbrldt:summable attribute is not Boolean.

2.4 Dimensional relationship sets (normative)

Taxonomy authors are able to partition relationships into distinct base sets using the xlink:role attribute on extended-type link elements. Applications that are aware of the names and meanings of the partitions may use different sets of relationships at different times for processing.

But it is more than a useful feature; in the case of summation‑item relationships in the calculation linkbase, partitioning is essential to ensure that incompatible summations are not commingled. Taxonomy authors may specify distinct base sets of dimensional relationships that a validating process would apply separately. To forbid this would violate P2 (Consistency, Appendix B).

Furthermore, a set of primary item declarations may have hypercubes in common among the targets of their has‑hypercube relationships; hypercube declarations in turn may have typed dimensions in common among the targets of their hypercube-dimension relationships. In sections 2.5.2 and 2.5.3 below, additional relationships will also introduce tangled graphs, with some items as the source of separate and distinct sets of relationships to define different dimensions. If all the dimensional relationships used together in a validation were forced to be in the same base set, there would be redundancy among dimensional relationships, violating P4 (Irredundancy, Appendix B).

Example 6. When the same dimension must have different domain members, partitioning among different extended link roles and a mechanism to indicate the extended link flow must be implemented. xbrldt:targetRole is used for this purpose.

The RegionDim dimension must have different members when is part of hc_ExcludeRegions cube and when is part of the hc_AllRegions cube.

The optional xbrldt:targetRole attribute on an arc allows a taxonomy author to group arcs with different arc roles and different base sets into dimensional relationships sets. As declared in their LRR entries, 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 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, 2] The dimensional relationship set (DRS) of a relationship consists of all relationships in the transitive closure of the discovery relation defined in Figure 2 below.

In Figure 2, role(arc) denotes the contents of the xlink:role attribute of the relationship’s base set; targetRole(arc) denotes the contents of the targetRole attribute on the arc itself.

Failing to put the xbrldt:targetRole on the arc when the next arc (according to the architectural structure defined in Figure 1) exists in a different extended-type link element causes the construction to be unconnected. The result is that empty hypercubes and empty dimensions are created.

The usage of the xbrldt:targetRole attribute is optional. But if it is present in an arc the discovery of additional related arcs in the current base set is considered finished and the processing continues in the new extended role indicated.

Figure 2. Discovery relation between relationship A and relationship B

Arc role of Relationship A	Arc role of Relationship B with a source among the targets of Relationship A
Arc role of Relationship A	all, notAll	hypercube-dimension	dimension‑domain	domain‑member
all, notAll	False	role(B) Î {role(A), targetRole(A)}	False	False
hypercube-dimension	False	False	role(B) Î {role(A), targetRole(A)}	False
dimension‑domain	False	False	False	role(B) Î {role(A), targetRole(A)}
domain‑member	False	False	False	role(B) Î {role(A), targetRole(A)}

Example 7. The arc in base set link2 is in the DRS of the arc in base set link1

<definitionLink

xlink:type="extended" xlink:role="http://example.com/role/link1" id="link1">

<loc xlink:type="locator"

xlink:href="m-2005-07-23.xsd#m_AllRegions"

xlink:label="AllRegions"/>

<loc xlink:type="locator"

xlink:href="m-2005-07-23.xsd#m_SouthAmerica"

xlink:label="SouthAmerica"/>

<definitionArc xlink:type="arc"

xbrldt:targetRole="http://example.com/role/link2"

xlink:arcrole="http://xbrl.org/int/dim/arcrole/domain-member"

xlink:from="AllRegions" xlink:to="SouthAmerica" order="1.0"/>

</definitionLink>

<definitionLink xlink:type="extended"

xlink:role="http://example.com/role/link2" id="link2">

<loc xlink:type="locator"

xlink:href="m-2005-07-23.xsd#m_SouthAmerica" xlink:label="SouthAmerica"/>

<loc xlink:type="locator"

xlink:href="m-2005-07-23.xsd#m_Argentina" xlink:label="Argentina"/>

<definitionArc xlink:type="arc"

xlink:arcrole="http://xbrl.org/int/dim/arcrole/domain-member"

xlink:from="SouthAmerica" xlink:to="Argentina" order="1.0"/>

</definitionLink>

2.4.1 Taxonomy validation impact of dimensional relationship sets

For the most part, dimensional relationship sets do not impact dimensional validity of XBRL taxonomies. 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 dimensional relationship sets

Dimensional relationship sets do impact dimensional validity of XBRL instances. In section 3.1 below, “Validation of primary items,” validation is defined with respect to the set of relationships in the DRS; the relevant DRS is defined in section 2.3 above, “Primary item declarations and hypercubes.”

2.4.3 Constraints on the value of a xbrldt:targetRole attribute

1. A dimensional processor must raise an error [Dim Err, 10] xbrldte:TargetRoleNotResolved if the URI content of an xbrldt:targetRole attribute cannot be resolved via a roleRef element (3.5.2.4 [XBRL]) to a roleType element (5.1.3 [XBRL]).

2. A dimensional processor MUST check the cycles in a DRS according to the value of the cyclesAllowed attribute in the arc definition in the xbrldt schema as if all the arcs were created in the same extended link role. A dimensional processor MUST raise any error defined in the section 5.1.4.3 of the [XBRL] specification

3. The content of the xbrldt:targetRole attribute MUST be a valid URI. A dimensional processor MAY raise any XML Schema error or [Dim Err, 11] xbrldte:TargetRoleAttributeInvalidURI if the content of xbrldt:targetRole is not a valid URI.

2.5 Dimensions (normative)

[Def, 3] A dimension declaration is an abstract item [IHR3] declaration in the xbrldt:dimensionItem substitution group. A dimension is each of the different aspects by which a fact may be characterised.

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 simple links elements in the context of XBRL instances. The value of those simple links MAY be a QName for explicit dimensions or a complex type XML element for typed dimensions.

2.5.1 Constraints on the dimension declaration

1. A dimensional processor MUST raise an error [Dim Err, 12] xbrldte:DimensionElementIsNotAbstract if an element that is in the substitution group of xbrldt:dimensionItem is not abstract.

2.5.2 Typed dimensions

[Def, 4] a typed dimension is a dimension declaration [Def, 3] those domain of members is defined in another XML element.

A typed dimension has 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 a typed dimension value is the child of an xbrldi:typedMember element that has an xlink:href 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="xbrli: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 xlink:type="simple" xlink:href="tax.xsd#tax_dCustomer"> <cust>12345</cust> </xbrldi:typedMember> <xbrldi:typedMember xlink:type="simple" xlink:href="tax.xsd#tax_dCustomer"> <cust>01742</cust> </xbrldi:typedMember>
<element name="dPhone" id="tax_dPhone" substitutionGroup="xbrli: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 xlink:type="simple" xlink:href="tax.xsd#tax_dPhone"> <phone> <country>7</country> <city>7</city> <number>5555555</number> </phone> </xbrldi:typedMember> <xbrldi:typedMember xlink:type="simple" xlink:href="tax.xsd#tax_dPhone"> <phone xsi:nil="true"/> </xbrldi:typedMember>

Dimension item declaration in tax.xsd

Domain declaration in schema.xsd

Domain members in instance.xbrl

<element

name="dCustomer"

id="tax_dCustomer"

substitutionGroup="xbrli:dimensionItem"

type="xbrli:stringItemType"

abstract="true"

xbrli:periodType="duration"

xbrldt:typedDomainRef="schema.xsd#id_cust"

</restriction>

</simpleType>

</element>

<xbrldi:typedMember xlink:type="simple" xlink:href="tax.xsd#tax_dCustomer">

</xbrldi:typedMember>

<xbrldi:typedMember

xlink:type="simple" xlink:href="tax.xsd#tax_dCustomer">

</xbrldi:typedMember>

<element

name="dPhone"

id="tax_dPhone"

substitutionGroup="xbrli:dimensionItem"

type="xbrli:stringItemType"

abstract="true"

xbrli:periodType="duration"

xbrldt:typedDomainRef="schema.xsd#id_phone"

</sequence>

</complexType>

</element>

Elements valid for the domain type, such as:

<xbrldi:typedMember xlink:type="simple" xlink:href="tax.xsd#tax_dPhone">

<phone>

</phone>

</xbrldi:typedMember>

<xbrldi:typedMember xlink:type="simple" xlink:href="tax.xsd#tax_dPhone">

</xbrldi:typedMember>

The separation of the dimension item from the element actually appearing in the instance is necessary because relationships in the definition linkbase may only have a target in the xbrli:item or xbrli:tuple substitution group, but such a restriction on the domain itself would be neither necessary nor desirable.

2.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 this typed dimension.

The value of the xbrldt:typedDomainRef attribute MUST be an IRI reference as defined in [RFC3987]. By design, all URIs (Uniform Resource Identifiers) as defined in [RFC3986] are also IRIs. The IRIs MUST have a fragment identifier.

[RFC3987], section 3.1 describes a procedure for escaping characters found in IRIs into a form representable in the xbrldt:typedDomainRef attribute.

The URI referenced in the xbrldt:typedDomainRef attribute has type anyURI. If the URI reference is relative, its absolute version MUST be computed by the method of [XML Base] before use.

<xs:attribute name="typedDomainRef" type="xs:anyURI"/>

The schema pointed in the xbrldt:typedDomainRef MAY not be a taxonomy schema and MAY not be part of the DTS.

2.5.2.1.1 Constraints on the xbrldt:typedDomainRef attribute

1. A dimensional processor MUST raise an error [Dim Err, 13] xbrldte:TypedDomainRefError if the xbrldt:typedDomainRef attribute appears on an XML Schema element declaration that is not a dimension declaration [Def, 3].

2. A dimensional processor MUST raise an error [Dim Err, 14] xbrldte:TypedDimensionError if the xbrldt:typedDomainRef attribute locates (with xml:base and following definition in section 3.2 of [XPTR]) something that is not an XML Schema element declaration, or a declaration that is not an element declaration, or is an abstract element declaration.

3. A dimensional processor MUST raise an error [Dim Err, 15] xbrldte:TypedDimensionURIError if the xbrldt:typedDomainRef attribute does not contain a fragment identifier.

4. A dimensional processor MAY raise any XML Schema error or [Dim Err, 15] xbrldte:TypedDimensionURIError if the xbrldt:typedDomainRef attribute is not a valid URI according to XML Schema validation rules.

2.5.3 Explicit dimensions

[Def, 5] An explicit dimension declaration is a dimension declaration [Def, 3] that has dimension-domain arcs to zero or more head of domain member declarations [Def, 6] whose QNames compound the dimension domain [Def, 7].

[Def, 6] A domain member declaration is one element defined in a taxonomy in the substitution group of xbrli:item.

[Def, 7] A domain of members is the QNames of all elements in the dimensional relationship set [Def, 2] for the domain-member relation rooted at one domain member [Def, 6].

The items therefore inherit all the features of XBRL items, such as labels in multiple languages, presentation ordering, references, and extensibility of relations through prohibition, overrides, and augmentation. The members of the domain may also be arranged into a relationship domain‑member that satisfies the requirements for an inclusion relationship [DIM-REQ].

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.

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

abstract="true"

substitutionGroup="xbrli:item"

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, 5] as its source and any domain member declaration [Def, 6] 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.

This element is subject of the xbrldt:usable attribute as stated in 2.5.3.3 below.

[Def, 8] The effective domain of a dimension is the union of all dimension-domain arcs that exist for a particular dimension in the dimensional relationship set [Def, 2].

This arc role is defined as follows in the LRR:

<roleURI>http://xbrl.org/int/dim/arcrole/dimension-domain</roleURI>

<authoritativeHref

>http://www.xbrl.org/2005/xbrldt-2005-09-09.xsd#dimension-domain</authoritativeHref>

<requirement xml:lang="en">An explicit dimension has one domain.

</requirement>

</definition>

<conformanceSuiteURI>http://www.xbrl.org/conf/dim/tests.xml</conformanceSuiteURI>

<validation xml:lang="en">The presence of a dimension-domain arc role indicates how part of a context is to be validated.

</validation>

<attribute namespaceURI="http://xbrl.org/2005/xbrldt"

use="optional">usable</attribute>

<attribute namespaceURI="http://xbrl.org/2005/xbrldt" use="optional">targetRole</attribute>

</attributes>

<sourceAbstract>required</sourceAbstract>

<targetAbstract>optional</targetAbstract>

</arcrole>

It is declared as follows:

<arcroleType

id="dimension-domain"

cyclesAllowed="none"

arcroleURI="http://xbrl.org/int/dim/arcrole/dimension-domain">

<definition>Source (a dimension) has only the target (a domain) as its domain. </definition>

<usedOn>definitionArc</usedOn>

</arcroleType>

2.5.3.1.1 Constraints on the dimension-domain arcs

1. A dimensional processor must raise an error [Dim Err, 16] xbrldte:DimensionDomainSourceError if the source of the relationship is not a explicit dimension declaration [Def, 5].

2. A dimensional processor must raise an error [Dim Err, 17] xbrldte:DimensionDomainTargetError if the target of the relationship is not a domain member declaration [Def, 6].

3. A dimensional processor MUST raise an error [Dim Err, 18] xbrldte:TypedExplicitDomainConflict if the source of a dimension-domain relationship has an xbrldt:typedDomainRef attribute.

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.

The base set of a domain-member relationship must not have any kind of cycles.

This arc role is defined as follows in the LRR:

<roleURI>http://xbrl.org/int/dim/arcrole/domain-member</roleURI>

<authoritativeHref

>http://www.xbrl.org/2005/xbrldt-2005-09-09.xsd#domain-member</authoritativeHref>

<requirement xml:lang="en">An explicit dimension has one domain.

</requirement>

<definition xml:lang="en">Source (a domain) contains the target (a member).

</definition>

<conformanceSuiteURI>http://www.xbrl.org/conf/dim/tests.xml</conformanceSuiteURI>

<validation xml:lang="en">The presence of a domain-member arc role indicates how part of a context is to be validated.

</validation>

<attribute namespaceURI="http://xbrl.org/2005/xbrldt" use="optional">usable</attribute>

<attribute namespaceURI="http://xbrl.org/2005/xbrldt" use="optional">targetRole</attribute>

</attributes>

<sourceAbstract>optional</sourceAbstract>

<targetAbstract>optional</targetAbstract>

</arcrole>

It is declared as follows:

<arcroleType

id="domain-member"

cyclesAllowed="none"

arcroleURI="http://xbrl.org/int/dim/arcrole/domain-member">

<definition>Source (a domain) contains the target (a member).

</definition>

<usedOn>definitionArc[IHR4] </usedOn>

</arcroleType>

2.5.3.2.1 Constraints on the domain-member arcs

1. A dimensional processor must raise an error [Dim Err, 19] xbrldte:DomainMemberSourceError if the source of a domain-member arc is not a primary item declaration.

2. A dimensional processor must raise an error [Dim Err, 20] xbrldte:DomainMemberTargetError if the target of a domain-member arc is not a primary item declaration.

2.5.3.3 The optional xbrldt:usable attribute

The xbrldt:usable attribute is used to denote domain members which may not be used as values of a domain in an instance document. This allows nodes 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.

2.5.3.3.1 Constraints on the value of the xbrldt:usable attribute

1. The value of the xbrldt:usable attribute MUST be Boolean. A dimensional processor may raise any XML Schema error or [Dim Err, 21] xbrldte:UsableAttributeInvalid if the value of the xbrldt:usable attribute is not 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, and the target of the domain‑member relationship is not the source of any has‑hypercube relationships, the target of the domain‑member arc is said to inherit the has-hypercube relationship. 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 and xbrldt:summable attributes.

The example below shows two primary item declarations that have a common ancestor from which they inherit an all relation to a hypercube.

Example 10. Two primary item declarations inheriting a hypercube

Primary item declarations p_Sales and p_CostOfGoods are not the source of any has‑hypercube arc; they inherit the hypercube d_hcRegion_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 has‑hypercube relationships of its own may inherit any number of has‑hypercube relationships, from any number of distinct base sets.

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 the 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.

In the example 11 below there is another example of this particular use case:

Example 11. 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	Nothing – This dimension MUST not appear in the context	C	Inherited from parent is cube1, but cube2 with notAll excludes all elements from the product dimension and A,B from the regions dimension
p_ImportedGoods	1,2,3	A	Inherited from parent p_CostOfGoods but cube3 removes B and C from the allowed combinations in the Region Dimension

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

2.7 Element declarations and linkbase syntax (normative)

Typed dimensions, explicit dimensions, domains and hypercubes are all represented using element declarations. These element declarations which are the targets of has-hypercube, hypercube-dimension, dimension-domain and domain-member relationships are collectively called dimensional elements as defined in section 1.3 above.

There may be any number of standard labels of a dimensional element in the base set in the schema-rooted DTS of the schema where the element is defined. Dimensional elements may have multiple labels, but they must either be in different base sets, have different value of the xml:lang attribute or have different value in its xlink:role attribute. Therefore, extension taxonomies may provide multiple labels even with the same value of the xml:lang attribute.

2.7.1.1 Constraints on labels on dimensional elements

1. There must be at least one standard label of a dimensional element for any given language and base set in the schema-rooted DTS of the schema where the element is defined. A dimensional processor must raise an error [Dim Err, 22] xbrldte:NoStandardLabel if a dimensional element has no standard label in any language in the schema-rooted DTS of the schema where the element is defined.

2.8 Aggregators (normative)

Explicit dimensions can optionally contain aggregation relationships that define how facts reported within a dimension are related numerically.

2.8.1 Summable primary items

A primary item declaration is summable across one dimension domain and the aggregation value MUST be calculated and compared with reported value by a dimensional processor when both the has‑hypercube and hypercube-dimension arcs that link the primary item to the dimension domain have an attribute xbrldt:summable whose value is true and the member of the domain participates in an aggregator-contributor relationship.

The default value for the xbrldt:summable attribute is false.

When the xbrldt:summable attribute has the value of false or it does not appear in the hypercube-dimension arc all the xbrldt:summable attributes in hypercube-dimension arcs MUST be ignored and no computation is required.

When the xbrldt:summable attribute has the value of true in the has-hypercube arc but false in the has-dimension arc the computation defined for that dimension MUST be ignored.

In theory, whether a primary item is summable or not should be independent of any particular hypercube. However, annotating the primary item declaration directly without using dimensional relationships would violate requirement G16 (see Appendix B below).

2.8.2 Arc role http://xbrl.org/int/dim/arcrole/aggregator-contributor

The relationship aggregator-contributor is a binary relationship defined over pairs of domain members.

The source of a domain‑member relationship is an aggregator of the target, which is its contributor.

This arc role is defined as follows in the LRR:

<roleURI>http://xbrl.org/int/dim/arcrole/aggregator-contributor</roleURI>

<authoritativeHref

>http://www.xbrl.org/2005/xbrldt-2005-09-09.xsd#aggregator-contributor</authoritativeHref>

<requirement xml:lang="en">The values of a primary items can be calculated across a dimension domains

</requirement>

<definition xml:lang="en">Source (a domain member) is the aggregator of the target (another domain-member).

</definition>

<conformanceSuiteURI>http://www.xbrl.org/conf/dim/tests.xml</conformanceSuiteURI>

<validation xml:lang="en">The presence of an aggregator-contributor arc role indicates how primary items in an instance are to be aggregated.

</validation>

<attribute namespaceURI="http://www.xbrl.org/2003/linkbase" use="optional">weight</attribute>

</attributes>

<sourceAbstract>optional</sourceAbstract>

<targetAbstract>optional</targetAbstract>

</arcrole>

It is declared as follows:

<arcroleType

id="aggregator-contributor"

cyclesAllowed="none"

arcroleURI="http://xbrl.org/int/dim/arcrole/aggregator-contributor">

<definition> Source (a domain member) is the aggregator of thet target (another domain-member).

</definition>

<usedOn>calculationArc[PW5] </usedOn>

</arcroleType>

When two facts of the same primary item within an instance document have two contexts (one context each) and the two facts are u-equal and s-equal over the period dimension and s-equal over the identifier element and d-equal [Def, 10] for all other dimensions except for the value of the dimension in which the aggregator-contributor network is defined and s-equal for any other non dimensional information that appears in the segment or scenario, and one fact has a dimension value [Def, 9] for that dimension of an aggregator and the other has a dimension value [Def, 9] for the same dimension of a contributor, then that fact is said to be an aggregator of the other fact, which is its contributor.

The aggregator-contributor arc role is defined in this specification to be used in the calculationArc element defined in the section 5.2.5.2 of the [XBRL] Specification. All constrains defined in the section 5.2.5 about the calculationLink, locator elements in calculationLink elements, the calculationArc element and the weight attribute works exactly in the same way they work for summation-item arcs.

Subsequent errata corrections of the [XBRL] Specification in the chapter 5.2.5 MAY affect how the arc role “aggregator-contributor” works. In that case, subsequent errata corrections of this specification should be published.

Example 12. Aggregator-contributor relationship

This shows the aggregator-contributor relationship within two members of a domain and how this affects a particular dimensionally valid set of primary items, contexts, and dimensional relationships. The Sales value in SouthAmerica and the Sales value in NorthAmerica are aggregators of the Sales value in AllAmerica, in the dimensional relationship set of http://example.com/role/link, when all other aspects of the contexts are held equal.

The dimension member of a primary item that is the aggregator of one or more contributors must have a numeric value that is consistent with the sum of the numeric values. The value is defined to be consistent if the rounded value of the aggregator primary item is equal to the total of the contributing primary item values rounded to the precision or inferred precision of the aggregator.

Facts are not aggregators of, and are not contributors to, facts that differ along more than one dimension value [Def, 9].

Duplicate primary items within a set of contributors render the aggregator primary item consistent.

Aggregator-contributor relationships are not defined for typed dimensions.

Inconsistency in calculations does not impact instance validation.

2.8.2.1 Constraints on aggregator-contributor arcs

1. Source and target of the aggregator-contributor relationship MUST be members of the same effective domain [Def, 8]. A dimensional processor MUST raise an error [Dim Err, 23] xbrldte:AggregationMembersInDifferentDomains if this rule is violated.

2.8.2.2 Constraints on instance documents about the calculated aggregation value

1. Instance documents which do not obey the relationships described by the aggregator-contributor relationships are dimensionally inconsistent. A dimensional processor mUST raise an error [Ins Err, 1] xbrldie:InconsistentAggregation upon detecting an inconsistency thus defined.

2.9 Default values for dimensions (normative)

Dimensions are allowed to have default values.

The arc dimension-default specifies which element form the domain plays the role of the default member for that dimension.

The default values for dimensions are automatically inferred by dimensional XBRL dimensional processors and MUST not be reported in the context of the instance (see 3.1.3.1 below “Obtaining the dimension value for a dimension.”).

The automatic inference of default values for dimensions MAY be used in taxonomies to allow summation-item arcs between some specific facts reported by the default dimensions. For example: the Sales concept may have a products dimension; if the default member in the products dimension were the TotalProducts member then the concept Sales for TotalProducts can be used in summation-items arcs with other concepts that have no dimensions.

2.9.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 member who plays the role of the default member.

If there were multiple dimension-default arcs in the same base set from the same dimension to different members in the domain only the one with higher value in its priority attribute is considered the default value.

The dimension-default is not subject to the effect of the xbrldt:targetRole attribute. This arc MUST be defined in the same base set than the dimension-domain arc is defined.

This arc role is defined as follows in the LRR:

<roleURI>http://xbrl.org/int/dim/arcrole/dimension-default</roleURI>

<authoritativeHref

>http://www.xbrl.org/2005/xbrldt-2005-09-09.xsd#dimension-default</authoritativeHref>

<requirement xml:lang="en">A domain have a default member.

</requirement>

<definition xml:lang="en">Source (a dimension) default is the target (a member).

</definition>

<conformanceSuiteURI>http://www.xbrl.org/conf/dim/tests.xml</conformanceSuiteURI>

<validation xml:lang="en">The presence of a dimension-default arc role indicates how part of a context is to be validated.

</validation>

<sourceAbstract>required</sourceAbstract>

<targetAbstract>optional</targetAbstract>

</arcrole>

It is declared as follows:

<arcroleType

id="dimension-default"

cyclesAllowed="none"

arcroleURI="http://xbrl.org/int/dim/arcrole/dimension-default">

<definition>Source (a dimension) default is the target (a member).

</definition>

<usedOn>definitionArc[IHR6] </usedOn>

</arcroleType>

2.9.1.1 Constraints on dimension-default arcs

1. There MUST be no more than one default member with the same highest value in the priority attribute for a dimension. A dimensional processor MUST raise an error [Dim Err, 24] xbrldte:TooManyDefaultMembers if this rule is violated.

2.9.1.2 Constraints on instance documents about the values that are the default for a dimension

1. The default value of a dimension MUST NOT be reported in an instance. A dimensional processor MUST raise [Ins Err, 2] xbrldie:DefaultValueUsedInInstance when a default value is explicitly reported.

3 Dimensions in instance documents (normative)

Primary taxonomies define the concepts that will be used to represent the facts in a XBRL instance document.

One instance document whose DTS contains dimensional relationships according to this specification MUST be validated using the rules defined in this specification.

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. 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 there is at least one base set with a valid combination of hypercubes.

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 item that contains hypercubes in the DTS of the instance document MUST be valid according to the at least one of the base sets in which hypercubes are defined.

A primary item in an instance has a context and a primary item declaration. A primary item declaration is the root of a base set when the base set contains at least one has‑hypercube relation (all, notAll) whose source is that primary item.

When a primary item declaration is the root of a base set, it is also the root of the dimensional relationship set of that base set.

A dimensionally valid primary item must be either the source of no dimensional relationship sets, or the root of a DRS in which its context is dimensionally valid.

Example 13. Primary item at the root of a dimensional relationship set

Primary item declaration p_Sales is the root of the dimensional relationship set that includes, among others, all arcs in base set http://example.com/role/link3.

Whether a primary item appears inside a tuple has no relevance to whether its primary item declaration 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 Mutual validity of hypercubes in a base set

The 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 shows the errors that a dimensional processor MUST raise when a primary item is not valid according to their 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	Context evaluation Result	Error
1	All	Valid	True	No error
1	notAll	Invalid	True	No error
2	All notAll	Valid Invalid	True	No error
1	All	Invalid	False	xbrldie:InvalidDimensionCombiantionForAllOperation
1	notAll	Valid	False	xbrldie:InvalidDimensionCombiantionForAllOperation
2	All notAll	Valid Valid	False	xbrldie:InvalidDimensionCombiantionForAllOperation

3.1.1.1 Constraints on the validity of a primary item according to the “all” and “notAll” operations

1. A dimensional processor MUST raise an error [Ins Err, 3] xbrldie:InvalidDimensionCombiantionForAllOperation if the result of the multiple hypercubes operation is false.

3.1.2 Validity of hypercubes

Figure 4. Hypercube validity table

Closed	Empty	Dimensions	Instance dimensional data Dimension values	Dimension validity	Result	Error
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	(1)
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[1]	N/A	Invalid	(1)
No	No	Dim1 and Dim2	Dimension value found for Dim1 and Dim2 and Dim3[2]	Dim1 OK and Dim2 OK and Dim3 N/A	Valid
Yes/No	No	Dim1	Dimension value not found for Dim1	N/A	Invalid	(2)
Yes/No	No	Dim1	Dimension value found for Dim1	Dim1 NOT OK	Invalid	(3)

All dimensions in a hypercube MUST be validated according to rules defined in 3.1.3 (“Validity of dimensions”).

3.1.2.1 Constraints on the individual validity of hypercubes

1. If a closed hypercube contains any unexpected dimension value a dimensional processor MUST raise [Ins Err, 4] xbrldie:ClosedHypercubeContainsExtraDataError. This error is referenced as (1) in Figure 4 below.

2. If the value of the xbrldt:contextElement attribute in the has-hypercube arc is segment and there is no value in the segment for the dimension a dimensional processor must raise an error [Ins Err, 5] xbrldie:HypercubeMissingDimensionInSegmentError. This error is referenced as (2) in Figure 4 below.

3. If the value of the xbrldt:contextElement attribute in the has-hypercube arc is scenario and there is no value in the scenario for the dimension a dimensional processor must raise an error [Ins Err, 6] xbrldie:HypercubeMissingDimensionInScenarioError. This error is referenced as (2) in Figure 4 below.

4. No explicit error is defined in this section. A dimensional processor MUST raise the error raised by the dimension value validation in section 3.1.3 below. This error is referenced as (3) in Figure 4 below.

3.1.3 Validity of dimensions

[Def, 9] Dimension value is defined as the content of the dimension container for one specific dimension in one of the three possible dimension containers: segment, scenario or default values.

The dimension container is the content of the element xbrldi:typedMember for typed dimensions or the QName of the xbrldi:explicitMember for explicit dimensions or the QName of the default value of the dimension those xlink:href attribute value points to the id of the dimension in use.

A dimension value must be valid according to its domain. Validation of typed dimensions and explicit dimensions is defined in sections 3.1.3.4 below and 3.1.3.5 respectively.

3.1.3.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.

For explicit dimensions, if the value is not reported in the instance and the dimension has a default value the default value is considered as the value to be obtained.

3.1.3.2 Constraints about dimension values

1. A context must not contain more than one dimension value for every dimension. A validator must signal [Ins Err, 7] xbrldie:RepeatedDimensionInInstance when this rule is violated.

2. According to 2.9.1.2 above the default values cannot appear in the instance document and an error [Ins Err, 2] xbrldie:DefaultValueUsedInInstance must be raised if the default value is found.

3.1.3.3 Examples of context and their dimension validity

Example 14. Dimensionally invalid context containing two references to the same dimension

<identifier scheme="http://nic.net">example.com</identifier>

<xbrldi:typedMember xlink:type="simple" xlink:href="tax.xsd#dim_Team">

<d:Team>Rams</d:Team>

</xbrldi:typedMember>

</segment>

</entity>

<xbrldi:typedMember xlink:type="simple" xlink:href="tax.xsd#dim_Team">

<d:Team>Lakers</d:Team>

</xbrldi:typedMember>

</scenario>

</context>

Example 15. A segment that is valid with respect to a hypercube

<identifier scheme="http://nic.net">example.com</identifier>

<xbrldi:typedMember xlink:type="simple" xlink:href="tax.xsd#hc_TeamDim">

<d:Team>Rams</d:Team>

</xbrldi:typedMember>

<xbrldi:typedMember xlink:type="simple" xlink:href="tax.xsd#hc_DrinkDim">

<d:Drink>Coors</d:Drink>

</xbrldi:typedMember>

</segment>

</entity>

</context>

Example 16. Three segments not dimensionally valid with respect to a hypercube

<identifier scheme="http://nic.net">example.com</identifier>

<xbrldi:typedMember

xlink:type="simple" xlink:href="tax.xsd#hc_TeamDim">

<d:Team>Rams</d:Team>

</xbrldi:typedMember>

</segment>

</entity>

</context>

Missing a reference to the Drink dimension.

<identifier scheme="http://nic.net">example.com</identifier>

<xbrldi:typedMember

xlink:type="simple" xlink:href="tax.xsd#hc_DrinkDim">

<d:Drink>Coors</d:Drink>

</xbrldi:typedMember>

</segment>

</entity>

</context>

Missing a reference to the Team dimension.

Example 17. 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	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: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:hypercubeMissingInScenarioDimensionError 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 18. Primary items those are not dimensionally valid because they violate their hypercube constraints

<identifier scheme="http://nic.net">example.com</identifier>

<xbrldi:explicitMember xlink:type="simple"

xlink:href="hc-2005-07-23.xsd#hc_ProductDim"

>m:RedWine</xbrldi:explicitMember>

<xbrldi:explicitMember xlink:type="simple"

xlink:href="hc-2005-07-23.xsd#hc_RegionDim"

>m:Barbados</xbrldi:explicitMember>

</segment>

</entity>

</context>

<p:GrossProfit

contextRef="c19" unitRef="eur"

decimals="INF">10000</p:GrossProfit>

<p:CostOfGoods

contextRef="c19" unitRef="eur"

decimals="INF">50000</p:CostOfGoods>

<p:Sales contextRef="c19" unitRef="eur"

decimals="INF">60000</p:Sales>

r:Barbados is not a domain member in hc_RegionDim; hence the constraint is violated by all three facts even though only p_GrossProfit had an explicit “all” arc to hc_Product_x_Region.

3.1.3.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.

3.1.3.4.1 The xbrldi:typedMember element

The xbrldi:typedMember element is a complex-type link whose content MUST be one element whose schema declaration is located by the xbrldt:typedDomainRef attribute (see section 2.5.2.1 above).

<documentation xml:lang="en">A simple-type link; the content of a typed dimension is anyType.</documentation>

</annotation>

</extension>

</complexContent>

</complexType>

</element>

The content of the xlink:href attribute of an xbrldi:TypedElement element must resolve to a typed dimension within the DTS of the instance.

A typed dimension is valid if there is a dimension value for the dimension that is Valid XML according to the declaration referred in the xbrldt:typedDomainRef attribute.

Example 19. Two dimensions referenced in the segment of a context

<identifier scheme="http://nic.net">example.com</identifier>

<xbrldi:typedMember xlink:type="simple" xlink:href="tax.xsd#dim_Team">

<d:Team>Lakers</d:dTeam>

</xbrldi:typedMember>

<xbrldi:typedMember xlink:type="simple" xlink:href="tax.xsd#dim_Drink">

<d:Drink>Coors</d:Drink>

</xbrldi:typedMember>

</segment>

</entity>

</context>

Example 20. Two dimensions referenced in the scenario of a context

<identifier scheme="http://nic.net">example.com</identifier>

</entity>

<xbrldi:typedMember xlink:type="simple" xlink:href="tax.xsd#dim_Team">

<d:Team>Celtics</d:dTeam>

</xbrldi:typedMember>

<xbrldi:typedMember xlink:type="simple" xlink:href="tax.xsd#dim_Drink">

<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 2.3.2.1 above regarding the “closed” attribute.

3.1.3.4.2 Constraints about the xlink:href attribute in xbrldi:typedMember elements

1. The content of the xlink:href attribute of a xbrldi:typedMember element must resolve to an typed dimension within the DTS of the instance document. A dimensional processor must raise an error [Ins Err, 8] xbrldie:TypedMemberNotTypedDimension if the content of the xlink:href attribute of xbrldi:explicitMember resolves (with xml:base) to anything other than a typed dimension declaration.

2. Every instance of xbrldi:typedMember must have only one child element. A validator must signal [Ins Err, 9] xbrldie:TypedMemberMoreThanOneValue if this rule is violated.

3. The typed dimension value MUST be valid XML according to the XML Schema syntax of the element references in the xbrldt:typedDomainRef attribute. A dimensional processor MAY signal any XML Schema error or [Ins Err, 10] xbrldie:TypedMemberValueError if the content is not according to the XML schema validation rules.

3.1.3.5 Explicit dimensions

The members of an explicit dimension are the QNames of elements found in the dimension domain.

3.1.3.5.1 The xbrldi:explicitMember element

The xbrldi:explicitMember element is a simple-type link whose content must be the QName of a member of the domain in the explicit dimension domain of the dimension to which its xlink:href attribute refers.

<annotation><documentation xml:lang="en">A simple-type link containing the QName of an item that is a member of an explicit dimension.</documentation></annotation>

</extension>

</simpleContent>

</complexType>

</element>

The explicit dimension is valid if the dimension value (QName) is a member of the effective dimension domain.

Example 21. A context that is dimensionally valid with respect to a hypercube with two explicit dimensions

<identifier scheme="http://nic.net>example.com</identifier>

<xbrldi:explicitMember xlink:type="simple"

xlink:href="hc-2005-07-23.xsd#hc_RegionDim"

>r:m_Iberia</xbrldi:explicitMember>

<xbrldi:explicitMember xlink:type="simple"

xlink:href="hc-2005-07-23.xsd#hc_ProductDim"

>p:m_RedWine</xbrldi:explicitMember>

</segment>

</entity>

</context>

3.1.3.5.2 Constraints on the xlink:href attribute in xbrldi:explicitMember elements

1. The content of the xlink:href attribute of an xbrldi:explicitMember element must resolve to an explicit dimension within the DTS of the instance document. A dimensional processor must raise an error [Ins Err, 11] xbrldie:ExplicitMemberNotExplicitDimension if the content of the xlink:href attribute of xbrldi:explicitMember resolves (with xml:base) to anything other than an explicit dimension declaration.

3.1.3.6 Attribute group dimAttributes

Contexts may reference explicit dimension members using an XLink simple-type link with these attributes:

<xs:attributeGroup name="dimAttributes">

<xs:attributeGroup ref="xlink:simpleType"/>

<xs:attribute ref="xlink:href" use="required"/>

<xs:attribute ref="xlink:arcrole" use="optional"/>

<xs:attribute ref="xlink:role" use="optional"/>

<xs:attribute ref="xlink:title" use="optional"/>

<xs:attribute ref="xlink:show" use="optional"/>

<xs:attribute ref="xlink:actuate" use="optional"/>

<xs:anyAttribute namespace="##targetNamespace" processContents="lax"/>

</xs:attributeGroup>

3.1.3.7 The required xlink:type attribute on xbrldie:explicitMember and xbrldie:typedMember

The xlink:type attribute MUST occur and MUST have the fixed content “simple”.

3.1.3.8 The required xlink:href attribute on xbrldie:explicitMember and xbrldie:typedMember

The xlink:href attribute MUST occur and must be a URI that resolves to an XML Schema root element. If the URI reference is relative, its absolute version MUST be determined as specified in [XML Base] before use. For details on the allowable forms of XPointer [XPTR] syntax in the URI see [XBRL] section 3.5.4.

3.1.3.9 The optional xml:base attribute on xbrldi:explicitMember and xbrldi:typedMember elements

The xml:base attribute MAY occur and participate in the resolution of relative URIs specified in xlink:href attributes [XML Base].

3.1.3.10 The optional xlink:title attribute on xbrldi:explicitMember and xbrldi:typedMember elements

The xlink:title attribute MAY occur. Processors MAY use the contents of this attribute as a convenient way to identify to a user the dimension to which the reference element points, without having to traverse the link.

3.2 Definition of dimensionally equal facts (normative)

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

d-equal is an independent operation of c-equal, u-equal, s-equal defined in section 4.10 of the [XBRL] specification. d-equal is defined only for one fact and one dimension.

All dimensional information MUST keep a consistent order in the instance document in order to allow the summation-item relationships to work.

Two facts related to different contexts 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 and the white spaces that are between the dimensional elements.

Example 22. Multiple contexts and the result of the d-equal operation

Fact Sales in Context A

Fact Sales in Context B

d-equal( Sales, prodDim)

<xbrli:explicitMember

xlink:type="simple"

xlink:href="taxonomy.xsd#prodDim">p:product</xbrli:ExcplicitMember>

</segment>

<xbrli:explicitMember xlink:type="simple"

xlink:href="taxonomy.xsd#prodDim">p:product</xbrli:ExcplicitMember>

</segment>

Yes,

Note the spaces between elements are different.

<xbrli:explicitMember

xlink:type="simple"

xlink:href="taxonomy.xsd#prodDim">p:product</xbrli:ExcplicitMember>

<xbrli:explicitMember

xlink:type="simple"

xlink:href="taxonomy.xsd#dept_dim_ID">r:sales</xbrli:ExcplicitMember>

</segment>

<xbrli:explicitMember

xlink:type="simple"

xlink:href="taxonomy.xsd#dept_dim_ID">r:sales</xbrli:ExcplicitMember>

<xbrli:explicitMember

xlink:type="simple"

xlink:href="taxonomy.xsd#prodDim">p:product</xbrli:ExcplicitMember>

</segment>

Yes,

Note that the order of the two explicit elements is different.

<xbrli:explicitMember

xlink:type="simple"

xlink:href="taxonomy.xsd#prodDim">p:product</xbrli:ExcplicitMember>

</segment>

<xbrli:explicitMember

xlink:type="simple"

xlink:href="taxonomy.xsd#prodDim">p:product</xbrli:ExcplicitMember>

</scenario>

No,

Dimensions MUST be reported in the specified container

A Errors [IHR7] (normative)

Validating Taxonomies

Statutes

[Dim Err, 1] xbrldte:HypercubeElementIsNotAbstract.............................................................. 8

[Dim Err, 10] xbrldte:TargetRoleNotResolved......................................................................... 18

[Dim Err, 11] xbrldte:TargetRoleAttributeInvalidURI............................................................... 18

[Dim Err, 12] xbrldte:DimensionElementIsNotAbstract........................................................... 18

[Dim Err, 13] xbrldte:TypedDomainRefError........................................................................... 20

[Dim Err, 14] xbrldte:TypedDimensionError............................................................................ 20

[Dim Err, 15] xbrldte:TypedDimensionURIError...................................................................... 20

[Dim Err, 16] xbrldte:DimensionDomainSourceError............................................................... 21

[Dim Err, 17] xbrldte:DimensionDomainTargetError............................................................... 21

[Dim Err, 18] xbrldte:TypedExplicitDomainConflict.................................................................. 22

[Dim Err, 19] xbrldte:DomainMemberSourceError................................................................... 22

[Dim Err, 2] xbrldte:HypercubeDimensionSourceError............................................................ 10

[Dim Err, 20] xbrldte:DomainMemberTargetError................................................................... 22

[Dim Err, 21] xbrldte:UsableAttributeInvalid.......................................................................... 23

[Dim Err, 22] xbrldte:NoStandardLabel.................................................................................. 25

[Dim Err, 23] xbrldte:AggregationMembersInDifferentDomains.............................................. 28

[Dim Err, 24] xbrldte:TooManyDefaultMembers...................................................................... 29

[Dim Err, 3] xbrldte:HypercubeDimensionTargetError............................................................ 10

[Dim Err, 4] xbrldte:HasHypercubeSourceError...................................................................... 13

[Dim Err, 5] xbrldte:HasHypercubeTargetError....................................................................... 13

[Dim Err, 6] xbrldte:HasHypercubeMissingContextElementAttribute...................................... 13

[Dim Err, 7] xbrldte:InvalidContextElementAttribute.............................................................. 14

[Dim Err, 8] xbrldte:ClosedAttributeInvalid............................................................................ 14

[Dim Err, 9] xbrldte:SummableAttributeInvalid....................................................................... 15

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

Taxonomy Error	Meaning	Ref.
[Dim Err, 1] xbrldte:HypercubeElementIsNotAbstract	Hypercube element MUST be abstract	2.2
[Dim Err, 2] xbrldte:HypercubeDimensionSourceError	The source of the hypercube-dimension arc is not the correct type.	2.2.2.1
[Dim Err, 3] xbrldte:HypercubeDimensionTargetError	The target of the hypercube-dimension arc is not the correct type.	2.2.2.1
[Dim Err, 4] xbrldte:HasHypercubeSourceError	The source of an all, notAll arc is not the correct type.	2.3.1.1
[Dim Err, 5] xbrldte:HasHypercubeTargetError	The target of an all, notAll arc is not the correct type.	2.3.1.1
[Dim Err, 6] xbrldte:HasHypercubeMissingContextElementAttribute	The all, notAll arc does not have an xbrldt:contextElement attribute.	2.3.1.1
[Dim Err, 7] xbrldte:InvalidContextElementAttribute	The xbrldt:contextElement attribute is present and has a value other than segment or scenario.	2.3.2.1
[Dim Err, 8] xbrldte:ClosedAttributeInvalid	The xbrldt:closed attribute is present but its value is not a Boolean.	2.3.3.1
[Dim Err, 9] xbrldte:SummableAttributeInvalid	The xbrldt:summable attribute is present but its value is not a Boolean.	2.3.4.1
[Dim Err, 10] xbrldte:TargetRoleNotResolved	The URI content of a xbrldt:targetRole attribute cannot be resolved via a roleRef to a roleType.	2.4.3
[Dim Err, 11] xbrldte:TargetRoleAttributeInvalidURI	The xbrldt:targetRole attribute is present but its value is not a URI.	2.4.3
[Dim Err, 12] xbrldte:DimensionElementIsNotAbstract	Dimension elements MUST be abstract	2.5
[Dim Err, 13] xbrldte:TypedDomainRefError	The xbrldt:typedDomainRef attribute appears on an element declaration that is not an abstract item.	2.5.2.1.1
[Dim Err, 14] xbrldte:TypedDimensionError	The xbrldt:typedDomainRef attribute does not locate a typed dimension.	2.5.2.1.1
[Dim Err, 15] xbrldte:TypedDimensionURIError	The xbrldt:typedDomainRef attribute contains an invalid URI or does not contain a fragment identifier	2.5.2.1.1
[Dim Err, 16] xbrldte:DimensionDomainSourceError	The source of a dimension-domain arc is not the correct type.	2.5.3.1.1
[Dim Err, 17] xbrldte:DimensionDomainTargetError	The target of a dimension-domain arc is not the correct type.	2.5.3.1.1
[Dim Err, 18] xbrldte:TypedExplicitDomainConflict	The element that is the source of an explicit domain contains an attribute that points to n typed domain declaration.	2.5.3.1.1
[Dim Err, 19] xbrldte:DomainMemberSourceError	The source of a domain-member arc is not the correct type.	2.5.3.2.1
[Dim Err, 20] xbrldte:DomainMemberTargetError	The target of a domain-member arc is not the correct type.	2.5.3.2.1
[Dim Err, 21] xbrldte:UsableAttributeInvalid	Attribute xbrldt:usable is not a Boolean.	2.5.3.3.1
[Dim Err, 22] xbrldte:NoStandardLabel	The dimensional element does not have a standard label in any language.	2.7.1.1
[Dim Err, 23] xbrldte:AggregationMembersInDifferentDomains	All items in an aggregator-contributor base set MUST be members of the same effective domain.	2.8.2.1
[Dim Err, 24] xbrldte:TooManyDefaultMembers	The dimension has two or more members in its domain that MAY play the role of the default member.	2.9.1.1

Validating Instances

Other Authorities

[Ins Err, 1] xbrldie:InconsistentAggregation.......................................................................... 28

[Ins Err, 10] xbrldie:TypedMemberValueError........................................................................ 35

[Ins Err, 11] xbrldie:ExplicitMemberNotExplicitDimension....................................................... 37

[Ins Err, 2] xbrldie:DefaultValueUsedInInstance.................................................................... 29

[Ins Err, 3] xbrldie:InvalidDimensionCombiantionForAllOperation.......................................... 31

[Ins Err, 4] xbrldie:ClosedHypercubeContainsExtraDataError................................................ 31

[Ins Err, 5] xbrldie:HypercubeMissingDimensionInSegmentError........................................... 31

[Ins Err, 6] xbrldie:HypercubeMissingDimensionInScenarioError............................................ 31

[Ins Err, 7] xbrldie:RepeatedDimensionInInstance................................................................ 32

[Ins Err, 8] xbrldie:TypedMemberNotTypedDimension........................................................... 35

[Ins Err, 9] xbrldie:TypedMemberMoreThanOneValue............................................................ 35

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

Instance Error	Meaning	Ref.
[Ins Err, 1] xbrldie:InconsistentAggregation	There is a calculation inconsistency between an aggregator and its contributors.	2.8.2.2
[Ins Err, 2] xbrldie:DefaultValueUsedInInstance	Default values of dimension MUST not be reported in instances.	2.9.1.2
[Ins Err, 3] xbrldie:InvalidDimensionCombiantionForAllOperation	The context is not valid for the “all” operation, one of the hypercubes is not valid.	3.1.1.1
[Ins Err, 4] xbrldie:ClosedHypercubeContainsExtraDataError	A closed hypercube contains unexpected dimension values	3.1.2.1
[Ins Err, 5] xbrldie:HypercubeMissingDimensionInSegmentError	There is no value in the segment for the required dimension	3.1.2.1
[Ins Err, 6] xbrldie:HypercubeMissingDimensionInScenarioError	There is no value in the scenario for the required dimension	3.1.2.1
[Ins Err, 7] xbrldie:RepeatedDimensionInInstance	it is not allowed to report a value for the same dimension more then once.	3.1.3.2
[Ins Err, 8] xbrldie:TypedMemberNotTypedDimension	The xbrldi:typedMember element does not refer to a typed dimension.	3.1.3.4.2
[Ins Err, 9] xbrldie:TypedMemberMoreThanOneValue	The xbrldi:typedMember element in the instance contains more than one child element	3.1.3.4.2
[Ins Err, 10] xbrldie:TypedMemberValueError	The dimension value is invalid XML according to the container definition	3.1.3.4.2
[Ins Err, 11] xbrldie:ExplicitMemberNotExplicitDimension	The xbrldi:ExplicitMember element does not refer to an explicit dimension.	3.1.3.5.2

B Requirements Reference (non-normative)

This section cross references to the dimensional taxonomy requirements [DIM-REQ].

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 items 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 XML Schema is not adequate.	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 arc roles.
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, “Dimensional relationship sets.” 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 the XBRL 2.1 specification.	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 segments and scenarios of the contexts of the facts of any concept, and whether other elements MAY or MUST NOT appear in segments and scenarios.	Satisfied. Rule 2.1.1.1; 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. Rule 2.1.1.1; 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; rule 2.7.1.1 requires a label in one language.
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 contexts 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. Sections 2.5.3.1 and 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.	Satisfied. Section 2.8, “Aggregators” defines the aggregator‑contributor relationship.
G14	Taxonomy authors must be able to limit summations over Explicit Dimension Members to apply only to certain concepts.	Satisfied. Section 2.8, “Aggregators” shows that the aggregator‑contributor relationship is distinct from the domain‑member relationship.
G15	Taxonomy authors must be able to define an equivalence relationship on Explicit Dimension Members within the same Explicit Dimension.	Not satisfied.
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. The “summable” property is represented as an attribute of a primary item’s relationship to hypercubes, although in principle it is universal and could be represented in the base taxonomy.
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, “Dimensional relationship sets” 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.	To be satisfied.

C References (non-normative)

[DIM-REQ]	Ignacio Hernández-Ros, Walter Hamscher, David vun Kannon, Hugh Wallis
	Dimensional Taxonomies Requirements Public Working Draft
	DIM-REQ-PWD-2005-06-21.rtf

[LRR]	Walter Hamscher, Hugh Wallis
	Linkbase Role Registry 1.0 Candidate Recommendation 3
	XBRL-LRR-CR3-2005-08-11.rtf

[RFC2119]	Scott Bradner
	Key words for use in RFCs to Indicate Requirement Levels, March 1997
	http://www.ietf.org/rfc/rfc2119.txt

[SCHEMA-0]	World Wide Web Consortium.
	XML Schema Part 0: Primer.
	http://www.w3.org/TR/xmlschema-0/

[SCHEMA-1]	World Wide Web Consortium.
	XML Schema Part 1: Structures.
	http://www.w3.org/TR/xmlschema-1/

[SCHEMA‑2]	World Wide Web Consortium.
	XML Schema Part 2: Datatypes.
	http://www.w3.org/TR/xmlschema-2/

[XBRL]	Phillip Engel, Walter Hamscher, Geoff Shuetrim, David vun Kannon, Hugh Wallis.
	Extensible Business Reporting Language (XBRL) 2.1 Recommendation with corrected errata to 2005-11-07
	http://www.xbrl.org/SpecRecommendations/

[XLINK]	Steve DeRose, Eve Maler, David Orchard
	XML Linking Language (XLink) Version 1.0.
	http://www.w3.org/TR/xlink/

[XML Base]	Jonathan Marsh
	XML Base.
	http://www.w3.org/TR/xmlbase/

[XPTR]	Paul Grosso, Eve Maler, Jonathan Marsh, and Norman Walsh, editors
	XML Pointer Language (XPointer Framework) V1.0.
	http://www.w3.org/TR/xptr-framework/

[RFC3987]	Martin Dürst, Michel Suignard
	Internationalized Resource Identifiers, January 2005
	http://www.ietf.org/rfc/rfc3987.txt

[RFC3986]	Tim Berners-Lee, Roy T. Fielding, Larry Masinter
	URI Generic Syntax, January 2005
	http://www.ietf.org/rfc/rfc3986.txt

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-11-07.xsd schema and MUST be schema valid according to the schema validation rules defined in [SCHEMA-1] [SCHEMA‑2]. Any XML Schema validation error MAY stop dimensional processors from continuing to validate dimensional relationships.

XBRL instances using the elements defined in xbrldi-2005-11-07.xsd MUST be XML Schema valid according to validation rules defined in [SCHEMA-1] [SCHEMA‑2]. 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 directory http://www.xbrl.org/2005/

xbrldt-2005-11-07.xsd (normative)

<?xml version="1.0" encoding="utf-8"?>

This document 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. XBRL is a

registered trademark of AICPA licensed exclusively to XBRL International. -->

<xs:schema

xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xbrli="http://www.xbrl.org/2003/instance"

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

xmlns:xlink="http://www.w3.org/1999/xlink"

xmlns:xl="http://www.xbrl.org/2003/XLink"

xmlns:xbrldt="http://xbrl.org/2005/xbrldt" targetNamespace="http://xbrl.org/2005/xbrldt"

elementFormDefault="qualified"

attributeFormDefault="unqualified">

<xs:annotation>

<xs:appinfo>

<definition>Source (a hypercube) contains the target (a dimension) among others.</definition>

<usedOn>definitionArc</usedOn>

</arcroleType>

<definition>Source (a dimension) has only the target (a domain) as its domain.</definition>

<usedOn>definitionArc</usedOn>

</arcroleType>

<definition>Source (a domain) contains the target (a member).</definition>

<usedOn>definitionArc</usedOn>

</arcroleType>

<definition>Source (a member) is the aggregator of the target (a member).</definition>

<usedOn>calculationArc</usedOn>

</arcroleType>

<definition>Source (a primary item declaration) requires the target (hypercube) to appear in the context of the primary item.</definition>

<usedOn>definitionArc</usedOn>

</arcroleType>

<definition>Source (a primary item declaration) requires the target (hypercube) to appear in the context of the primary item.</definition>

<usedOn>definitionArc</usedOn>

</arcroleType>

<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="summable" 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" abstract="true" substitutionGroup="xbrli:item" type="xbrli:stringItemType" xbrli:periodType="duration" id="xbrldt_hypercubeItem"/>

<xs:element name="dimensionItem" abstract="true" substitutionGroup="xbrli:item" type="xbrli:stringItemType" xbrli:periodType="duration" id="xbrldt_dimensionItem"/>

</xs:schema>

xbrldi-2005-11-07.xsd (normative)

<?xml version="1.0" encoding="utf-8"?>

This document 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. XBRL is a

registered trademark of AICPA licensed exclusively to XBRL International. -->

<schema xmlns="http://www.w3.org/2001/XMLSchema" xmlns:link="http://www.xbrl.org/2003/linkbase" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xbrli="http://www.xbrl.org/2003/instance" xmlns:xl="http://www.xbrl.org/2003/XLink"

xmlns:xbrldi="http://xbrl.org/2005/xbrldi"

targetNamespace="http://xbrl.org/2005/xbrldi"

elementFormDefault="qualified"

attributeFormDefault="unqualified">

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

</attributeGroup>

<documentation xml:lang="en">A simple-type link containing the QName of an item that is a member of an explicit dimension.

</documentation>

</annotation>

</extension>

</simpleContent>

</complexType>

</element>

<documentation xml:lang="en">A simple-type link consisting of anyType.

</documentation>

</annotation>

</extension>

</complexContent>

</complexType>

</element>

</schema>

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

F Acknowledgements (non-normative)

This document could not have been written without the contributions of many people. The participants in the XBRL Specification Working Group, public commentators, and personal advisors have all played a significant role. The XBRL International Specification Working Group is chaired by Paul Warren (DecisionSoft) and vice chaired by Cliff Binstock (UBmatrix). Reviewers and commentators included Herm Fischer (UBmatrix), Masatomo Goto (Fujitsu), Geoff Shuetrim (KPMG) and Chris Simmons (DecisionSoft).

G Document History (non-normative)

Date	Editor	Summary
2004-10-15	Hamscher	First skeletal draft created.
2004-10-17	Wallis	Rules of syntax, semantics, examples, and schema created.
2005-02-11	IHR	Added dimensions definition in a separate file
2005-06-06	IHR	Created a new version adapted to Test cases
2005-06-15	Hamscher	Edits to bring implicit and explicit dimensions into similar syntax.
2005-07-04	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.
2005-07-11	Hamscher	Combined the two variants of implicit dimensions and allowed XML Schema level validation of reference contents. Added the aggregator-contributor calculation arc role.
2005-07-12	Hamscher	Fixed typographical errors in schemas.
2005-07-13	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.
2005-07-14	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.
2005-07-14a	Hamscher	Allow implicit dimensions to have any type. Correct namespace and locations in LRR entries.
2005-07-19	Wallis	Editorial updates to indicate Public Working Draft status
2005-07-23	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.
2005-07-24	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’.
2005-07-26	IHR	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.
2005-07-28	IHR	Changed summable attribute and example related to it. Changed also the Figure 1 with the overall structure of the dimensional elements.
2005-08-01	IHR	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
2005-08-04	IHR	Added namespace definitions for instance errors and taxonomy errors. Each time an element is mentioned to be in substitutionGroup of xbrli:item I’ve added the text “in his head” to allow inheritance of element attributes if needed in the taxonomy design.
2005-08-12	IHR	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.
2005-08-19	IHR	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.
2005-08-26	IHR	Lot of changes this week; 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.
2005-09-07	IHR	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. Still TO DO: syntax of the Aggregator-Contributor networks and ordering of the dimensions in a context. Definition of d-equal MAY skip the definition of the dimensions order in a context.
2005-09-09	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.
2005-09-12	IHR	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 Hamscher.
2005-09-15	IHR	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.
2005-09-26	IHR	Renamed Implicit dimension to Typed dimensions. Added default values for dimensions, reviewed the aggregators section, removed references to dimensions ordering.
2005-09-27	IHR	Updated LRR definitions, changed first letter to lowercase in typedMember, explicitMember, dimensionItem and hypercubeItem.
2005-10-07	IHR	Incorporated comments from Paul Warren. A new structure of the document has been created and there are a lot of changes everywhere.
2005-10-18	IHR	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.
2005-10-20	IHR	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.
2005-10-26	IHR	Changed back to have domain members items in the substitution group of xbrli:item. memberItem will be evaluated in the generic linkbase.
2005-11-07	Wallis	Editorial to reflect Public Working Draft status

WcH: Outstanding point is concern about Requirement G18 functions. What are the semantics of primary item declarations that have no hypercubes, above and beyond validation. Example would be two primary items with the same context, but one has a hypercube defined and the other does not. They both validate. Should they be displayed, aggregated, etc., the same?

H Approval process (non-normative)

This section will be removed from the final recommendation. SWG = Specification Working Group; ISC = International Steering Committee.

For this document, a necessary condition for advancing from stage 5 (Candidate Recommendation) to stage 6 (Recommendation) shall be the concurrent approval of compliant sample dimensional taxonomies and instances and a conformance suite that has been exercised successfully by two vendors.

	Stage	Party responsible for decision	Next step	Revisions needed	Target date for stage completion
1	Internal WD	SWG	Recommend for Stage 2	Stay in Stage 1	2005-07-14
2	Internal WD pending publication	ISC	Approve for Stage 3	Return to Stage 1	2005-07-19
3	Public WD under 45 day review	WD Editors	Minor revisions – to Stage 4	Major revisions – Restart Stage 1	2005-09-01
4	Draft Candidate Recommendation	SWG	Recommend for Stage 5	Restart Stage 3	2005-12-31
5	Candidate Recommendation	ISC	Approve for Stage 6	Restart Stage 4	2006-01-21
6	Recommendation	SWG	Recommend for Stage 7	Restart Stage 4	2006-05-15
7	Recommendation	ISC	Publication	Restart stage 4

[1] Invalid because the hypercube is closed and Dim3 is not expected.

[2] This hypercube is open, so Dim3 is allowed and not used.

Name	Contact	Affiliation
Ignacio Hernández-Ros	ihr@xbrl.org	XBRL International Inc.
Hugh Wallis	hughwallis@xbrl.org	XBRL International Inc.

Name	Contact	Affiliation
David vun Kannon	david.k.vun.kannon@us.pwc.com	PricewaterhouseCoopers
Walter Hamscher	walter@hamscher.com	Standard Advantage / Consultant to PricewaterhouseCoopers
Charles Hoffman	charleshoffman@olywa.net	UBmatrix
Cliff Binstock	cliff.binstock@ubmatrix.com	UBmatrix
Paul Warren	pdw@decisionsoft.com	DecisionSoft