Status

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

Abstract

This specification allows XBRL taxonomy authors to define and restrict dimensional information that instance
authors may use in the <segment> and <scenario> elements of the <context>
element of XBRL instance documents. It satisfies XBRL International’s dimensional taxonomy requirements [Dimensions Requirements]. It is a modular extension to [XBRL 2.1]. It provides a generalised mechanism to
define dimensional metadata and to reference it in XBRL instances. Its architecture is such that any XBRL
artefacts (instances and their Discoverable Taxonomy Sets) that conform to this specification also conform to
the base specification and may be processed without error by any processor that is capable of correctly
processing XBRL artefacts, even if those processors are unaware of this modular extension. It is also designed
in such a way that it makes maximum use of components of [XBRL 2.1] in its components so as to require
a minimum amount of retooling of applications in order to be implemented. Accordingly certain compromises have,
of necessity, been made in the design that would not have been made if 100% compatibility with the base
specification had not been a requirement.

1 Introduction (non-normative)

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

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

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

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

All parts of this document not explicitly identified as non-normative are
normative. In the event of any conflict or apparent conflict between the English language text of this document
and/or schema fragments included in the main body of this document and the normative schemas contained herein,
the more restrictive interpretation that is possible from the information provided by the English language text
and that provided by the normative schemas SHALL prevail. The schema fragments incorporated into the body of the
text are non-normative and are generally indicated as such by means of shading ( Section 1.4). The normative schemas do not necessarily always provide the most
restrictive interpretation, either because it is not possible to express certain limitations using the syntax of
XML Schema or because, as at the time of publication of this specification, some commonly available commercial
implementations of XML Schema do not implement otherwise necessary features correctly or fully. The schemas and
other documents published separately and contemporaneously with the specification are non-normative and are
provided for the convenience of users of this specification.

1.1 Background (non-normative)

As should be apparent from the requirements [Dimensions Requirements], dimensional metadata was not invented
with XBRL. [XBRL 2.1] standardises the representation of only two dimensions: the time dimension and
the entity dimension. Many reporting purposes, both internal and external to organisations, require multiple
dimensions. What [XBRL 2.1] did create was the principles for this specification to exist while
defining two open elements in the <context> of XBRL instance documents: the <segment>
and <scenario> elements. This specification defines the syntax of elements that MAY
occur in the <segment> and <scenario> elements and defines standard arcs that
define the valid content of those elements. That content should be validated by dimensional XBRL processors
and standard errors are raised if the XBRL instance is not conformant with the multidimensional model defined
in the taxonomy. This specification uses three possible different roles that taxonomies can play in
representing multidimensional information: primary taxonomies, domain member taxonomies, and template
taxonomies. This taxonomy role differentiation is only illustrative. Because the multidimensional information
is represented by arcs and XBRL concepts and there is no way in XBRL to specify the role of a taxonomy, it is
possible for one taxonomy to play two or all of these roles simultaneously. The differentiation in this
specification provides an architectural framework to projects that incorporate multidimensional information
into existing taxonomies.

1.1.1 Primary taxonomies

A primary taxonomy is the DTS of an XBRL taxonomy that has no dimensional elements and no arcs defined in
this specification. Requirement G16 states "Taxonomy authors MUST be able to extend
a base taxonomy that does not have dimensional information, to have dimensions, without changing the
concepts in the base." This specification uses the term primary taxonomy for a DTS of elements that
MAY be instantiated in an XBRL instance. For example, a taxonomy used for external
financial reporting MAY be extended with a variety of dimensional taxonomies
appropriate to the reporting purpose.

1.1.2 Domain members taxonomies

Typed dimensional taxonomies as defined in Requirement G03 define syntactic
constraints on the contents of segments and scenarios.

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

1.1.3 Template taxonomies

The DTS of an instance using dimensional information MAY contain
domain-member relationships among items in both primary taxonomies and domain members
taxonomies. Since a primary taxonomy typically does not have dimensional information, thisthat implies that
the instance-rooted DTS MUST contain domain-member relationships in a
linkbase that is not in the schema-rooted DTS of the primary taxonomy.

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

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

Example: A table in a financial statement showing revenue byfor products and by territory, is a 3- dimensional hypercube, with one Primary Item (revenue) and two explicit dimensions (products and territory).

The purpose of a template taxonomy is to define the structures of the hypercubes and link the hypercubes with the Primary Item.

1.2 Relationship to other work

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

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

This document implements the business requirements agreed in the Domain Working Group of the XBRL consortium
and documented in the [Dimensions Requirements] document.

1.3 Terminology (non-normative)

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

An arc defines a relationship between its source concepts and target concepts that is determined by
its @xlink:arcrole and other attributes.

source [concept(s)]

The concepts identified by the URI content of the @href attributes of the locator-type
elements in the same extended-type link element, which have the same label attribute content as the
content of the @from attribute of an arc.

target [concept(s)]

The concepts identified by the URI content of the @href attributes of the locator-type
elements in the same extended-type link element, which have the same label attribute content as the
content of the @to attribute of an arc.

MUST , MUST NOT , REQUIRED, SHALL, SHALL
NOT, SHOULD , SHOULD NOT , RECOMMENDED, MAY
, and OPTIONAL

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.

XML instances and schemas that satisfy the syntax requirements of [XBRL 2.1].

Dimension

Each of the different aspects by which a fact MAY be characterised. A dimension
has only one effective domain. A typical example of a
dimension is the "product" dimension that identifies for a concept (Sales) the domain consisting of the
possible products that its fact can be expressed about. Dimensions are abstract elements in the
substitution group of xbrldt:dimensionItem.

Domain

A (possibly empty or possibly infinite) set of members. A typical example could be the Longitude and
Latitude dimensions. The numbers from -180 to +180 are a domain. In this case, both dimensions have the
same domain. (In real life longitude is in a domain from -90 to +90 and latitude is in a domain from
-180 to +180, but we are assuming both are the same for demonstration purposes only).

A dimension which MAY have multiple dimension-domain relationships; the
effective domain is the conjoint set of all related domains.

Domain Member / Valid Member

Each one of the possibilities in the domain of a Dimension. Explicit domains are defined by
domain-member relations. Example: In the "Products Dimension" an explicit domain can be created with
each one of the products as a domain-member. Domain member items are in the substitution group of
xbrli:item.

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.

A set of relationships constructed by traversing relationships (as described in Section 2.4) not only within base sets but
across base sets, thus possibly including relationships from extended-type links with different roles,
and relationships with different arc roles.

Base Set

As defined in 3.5.3.9.7.3 Networks of relationships in a DTS in [XBRL 2.1].

Dimensional Processor

A processor that consumes XBRL dimensional instance documents or taxonomies and checks the
conformance of that input document according to the rules declared in this document.

Raise an Error

The phrase "a dimensional processor MUST raise an error" means that a
dimensional processor MUST signal something to the consuming application that is
calling the validation process. The specific type of signal is application dependent. An example of how
[XPATH 2.0] signals its errors can be seen in
http://www.w3.org/TR/xquery-operators/#func-error .

1.4 Document conventions

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

The following highlighting is used to present non-normative examples in this document:

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

Non-normative editorial comments are denoted as follows and removed from final recommendations:

1.5 Namespaces (normative)

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

Table 1: Namespaces and namespace prefixes

Prefix

Namespace URI

xbrldt

http://xbrl.org/2005/xbrldt

xbrldi

http://xbrl.org/2006/xbrldi

xbrldte

http://xbrl.org/2005/xbrldt/errors

xbrldie

http://xbrl.org/2005/xbrldi/errors

xbrli

http://www.xbrl.org/2003/instance

xs

http://www.w3.org/2001/XMLSchema

xlink

http://www.w3.org/1999/xlink

link

http://www.xbrl.org/2003/linkbase

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

2 Dimensional Taxonomies (normative)

2.1 Architecture (normative)

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

Dimensional taxonomies are distinguished by the use of several arc roles. These arc roles and their associated attribute declarations are in the
appinfo section of an XML schema.

The namespace of the schema is http://xbrl.org/2005/xbrldt. The prefix xbrldt is
used in this document to refer to elements and attributes defined in that schema.

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

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

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

[Def, 1] Primary item declarations are elements defined in XBRL taxonomies that are in the xbrli:item
substitution group and are not in the xbrldt:hypercubeItem or xbrldt:dimensionItem
substitution group.

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

[Def, 2] Consecutive relationships are two relationships connected together according to the rules specified in
Section 2.1.1.

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

2.1.1 Consecutive relationships

Two relationships MAY be consecutive. A pair of consecutive relationships consists of an initial
relationship and a following relationship. For two relationships to be consecutive:

The value of the @xlink:arcrole attribute on the arc that represents the initial
relationship and the value of the @xlink:arcrole attribute on the arc that represents the
following relationship MUST correspond to one of the ordered pairs of arcrole values
listed in Table 2; and

The set of nodes pointed to by locators identified by the @xlink:to attribute of the arc
that represents the initial relationship MUST be the same set of nodes pointed to by
locators identified by the @xlink:from attribute of the arc representing the following
relationship.

Table 2: arcrole values for potentially consecutive relationships

Initial arc

Following arc

all

hypercube-dimension

notAll

hypercube-dimension

hypercube-dimension

dimension-domain

dimension-domain

domain-member

domain-member

domain-member

2.2 Hypercubes (normative)

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

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

The source of a hypercube-dimension arc MUST be a hypercube declaration [Def, 4] . A dimensional processor MUST raise an
error xbrldte:HypercubeDimensionSourceError if this rule is violated.

The target of a hypercube-dimension arc MUST be a dimension declaration [Def, 7]. A dimensional processor MUST raise an
error xbrldte:HypercubeDimensionTargetError if this rule is violated.

2.3 Primary item declarations and hypercubes (normative)

To constrain the set of <context> s that MAY appear on Primary Items, a primary item
declaration MAY be associated with zero or more hypercubes.

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

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

There are two arc roles collectively known as has-hypercube relationships; they are:

http://xbrl.org/int/dim/arcrole/all,

http://xbrl.org/int/dim/arcrole/notAll.

These relationships MAY be in different base sets. When has-hypercube relationships are
in different base sets, a Primary Item that is dimensionally valid
in any base set is dimensionally valid.

These relationships allow prohibition, overriding, and augmentation in extension taxonomies.

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

The instantiation of a primary item declaration [Def,
1] in an instance document is dimensionally valid with respect to a conjunction of
hypercubes only if it is valid with respect to all of the conjoined hypercubes individually. A negated
hypercube notAll is valid if the non negated version of the same hypercube definition is
invalid. The conjunction of a single hypercube is the hypercube itself Example 2.

Example 2: A primary item declaration with a single hypercube

The primary item
declarationp_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
declarationp_FluidCapacity is associated with the composition of two
hypercubes in the same base set. A <context> will be valid with respect to the Primary Item only if it has a City reference in its
<segment> that is a member of the hc_CityHypercubeAll and not a member of
hc_CityHypercubeExcluded.

The http://xbrl.org/int/dim/arcrole/all arc role is declared as follows:

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

<usedOn>definitionArc</usedOn>

</arcroleType>

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

The primary item
declarationp_GrossProfit has two children in the domain-member network.
The valid members in the hc_CountriesDim dimension are {CountriesDomain | m_Argentina |
m_France | m_India | m_Spain} for p_GrossProfit and p_Sales but
p_CostOfSales has only {CountriesDomain | m_Argentina | m_France | m_Spain}
possibilities in the country dimension (m_India has been removed from the domain).

Every has-hypercube arc MUST have an @xbrldt:contextElement
attribute.

<xs:simpleTypename="contextElementType">

<xs:restrictionbase="xs:token">

<xs:enumerationvalue="segment"/>

<xs:enumerationvalue="scenario"/>

</xs:restriction>

</xs:simpleType>

<xs:attributename="contextElement"type="xbrldt:contextElementType"/>

2.3.2.1 Constraints on the value of the @xbrldt:contextElement attribute

According to the xbrldt XML Schema, the @xbrldt:contextElement attribute
MUST have one of the values segment or scenario.

2.3.3 The optional @xbrldt:closed attribute on has-hypercube arcs

The optional Boolean attribute @xbrldt:closed MAY appear on
has-hypercube arcs.

<xs:attributename="closed"type="xs:boolean"default="false"/>

If the @xbrldt:closed attribute is specified with a true value on a
has-hypercube arc with the value <segment> for the
@xbrldt:contextElement attribute, the hypercube is closed with respect to the
<segment> element in that base set.

If the @xbrldt:closed attribute is specified with a true value on a
has-hypercube arc with the value scenario for the
@xbrldt:contextElement attribute, the hypercube is closed with respect to the
<scenario> element in that base set.

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

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

2.3.3.1 Constraints on the value of the @xbrldt:closed attribute

According to the xbrldt XML Schema, the @xbrldt:closed attribute, if
present, MUST have a Boolean value.

2.4 Partitioning of a Dimensional relationship set across multiple base-sets (normative)

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

However,But it is more than a useful feature. I; in the case of
summation-item relationships in the calculation linkbase, partitioning is essential to ensure
that incompatible summations are not commingled. Taxonomy authors MAY specify distinct
base sets of dimensional relationships that a validating process would apply separately. To forbid this would
violate Requirement P2.

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

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

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

The optional @xbrldt:targetRole attribute on an arc allows a taxonomy author to connect together
two arcs that represent a consecutive relationship [Def,
2] that exist in different rolesbase sets. As declared in this document, the
@xbrldt:targetRole attribute MAY appear on definition arcs having the
following arc roles: all, notAll, hypercube-dimension,
dimension-domain and domain-member. The @xbrldt:targetRole attribute has
the type anyURI. Resolution of the URI is
not subject to the presence of an @xml:base attribute and its value MUST be an
absolute URI.

<xs:attributename="targetRole"type="xs:anyURI"/>

[Def, 5] The source rolebase set is the content of the
@xlink:role attribute of the relationship's base set.
In Figure 2 it is identified as role(arc).

[Def, 6] The target rolebase set is the content of the
@targetRole attribute on the arc itself.
In Figure 2 it is identified as targetRole(arc).

Two arcs that represent a consecutive relationship [Def,
2] that exist in different extended-type link elements MUST be connected
together using the @xbrldt:targetRole attribute. Not doing so causes the construction to be
unconnected and results in, for example, empty hypercubes, dimensions and domains.

2.4.3 Constraints on the value of a @xbrldt:targetRole attribute

If the value, V, of the @xbrldt:targetRole
attribute on a definitionArc is not the standard extended link role
(http://www.xbrl.org/2003/role/link), the ancestor linkbase element of the
definitionArc element MUST have a child roleRef
element (3.5.2.4 [XBRL 2.1]) with V as the value of its @roleURI attribute (5.1.3
[XBRL 2.1]). A dimensional processor MUST raise an error
xbrldte:TargetRoleNotResolvedError if this
constraint is not satisfied the URI content of an @xbrldt:targetRole attribute
cannot be resolved via a link:roleRef element as defined in section (3.5.2.4 [XBRL 2.1]) of the [XBRL 2.1] specficiation. to a link:roleType element
(5.1.3 [XBRL 2.1]).

[Def, 19] A consecutive relationship set is the set of
relationships starting at an all or notAll relationship, and following all subsequent
consecutive relationships [Def, 2].
A dimensional processor MUST check the
cycles in two arcs that represents a consecutive
relationship connected with an @xbrldt:targetRole attribute
according to the value of the @cyclesAllowed attribute in the arc definition in the xbrldt
schema as if the two arcs that represent the consecutive
relationship [Def, 2] were created in the same extended-type link element. A dimensional processor MUST raise an error
xbrldte:DRSDirectedCycleError
for each
consecutive relationship set [Def, 19] that contains a if invalid directed cycles are found.

According to the xbrldt XML Schema, the content of the @xbrldt:targetRole attribute
MUST be a valid URI.

2.5 Dimensions (normative)

[Def, 7] A dimension declaration is an abstract item
declaration in the xbrldt:dimensionItem substitution group.

2.5.2 Typed dimensions

A typed dimension MUST have nonempty content for the attribute @xbrldt:typedDomainRef.

The @xbrldt:typedDomainRef is an @xlink:href to an element declaration in an XML
Schema that defines the dimension domain.

In the instance document below , a typed dimension value [Def, 15] below is the child of an
xbrldi:typedMember element that has a @dimension attribute whose value locates the
typed dimension element declaration.

The separation of the dimension item from the element actually appearing in the instance is necessary
because sections 5.2.6, 5.2.6.1 and 5.2.6.2 of the [XBRL 2.1] specification states that relationships in the definition linkbase MAY
only have a target in the xbrli:item or xbrli:tuple substitution group, but such a restriction on
the domain itself would be neither necessary nor desirable.

2.5.2.1 The @xbrldt:typedDomainRef attribute

The @xbrldt:typedDomainRef attribute is used in a Typed Dimension Element to locate the element in an XML Schema that defines the content of
the this typed dimension.

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

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

<xs:attributename="typedDomainRef"type="xs:anyURI"/>

The schema pointed to by the xbrldt:typedDomainRef MUST be part of the DTS.

2.5.2.1.1 Constraints on the @xbrldt:typedDomainRef attribute

A dimensional processor MUST raise an
error xbrldte:OutOfDTSSchemaError attribute points to a schema that is not included in
the taxonomy DTS.

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

A dimensional processor MUST raise an
error xbrldte:TypedDimensionError if the @xbrldt:typedDomainRef attribute
locates (with @xml:base and following definition in section 3.2 of [XPOINTER]) any of the following:

Nothing

Something that is not a global XML Schema element declaration

A global abstract element declaration.

A dimensional processor MUST raise an
error xbrldte:TypedDimensionURIError if the @xbrldt:typedDomainRef attribute
does not contain a fragment identifier.

According to the xbrldt XML Schema, the content of the @xbrldt:typedDomainRef attribute
MUST be a valid URI.

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

The domain of an explicit dimension is represented by the
target item of a dimension-domain relationship whose source is the explicit dimension element. The QName of the domain item is a valid member of the domain.

According to the architecture defined in Figure 1, Primary Items and explicit
dimension domain s members are both in the substitution group of xbrli:item.
A Primary Item defined in a taxonomy can play two different roles
in an instance document: it can could be used as a member of an explicit dimension in the
<context> of another item or it can be used as an item too. The QName of a primary item MUST NOT be a member of the domain of any
of its explicit dimensions.

A dimensional processor MUST
raise an error xbrldte:PrimaryItemPolymorphismError if there is a cycle in which the
Primary Item source of the hypercube is also a member
of the domain of valid members
[Def, 12].

2.5.3.2 Arc role http://xbrl.org/int/dim/arcrole/domain-member

A domain-member relationship binds a domain to a member of a domain. The purpose of this relationship is
to create sets of explicit domain members.

2.5.3.2.1 Constraints on the domain-member arcs

A dimensional processor MUST raise an
error xbrldte:DomainMemberSourceError if the source of a domain-member arc is not a
primary item declaration.

A dimensional processor MUST raise an
error xbrldte:DomainMemberTargetError if the target of a domain-member arc is not a
primary item declaration.

A dimensional processor MUST
raise an error xbrldte:PrimaryItemPolymorphismError if there is a cycle in which the
Primary Item source of the hypercube is also a member
of the domain of valid members
[Def, 12].

2.5.3.3 The optional @xbrldt:usable attribute

The @xbrldt:usable attribute is used to denote domain members that MUST NOT
not be used as values of a domain in an instance document. This allows members to be introduced
into the domain member hierarchy for the purpose of organising the hierarchy.

The @xbrldt:usable attribute MAY appear on
http://xbrl.org/int/dim/arcrole/dimension-domain arcs or on
http://xbrl.org/int/dim/arcrole/domain-member arcs.

The default value of the @xbrldt:usable attribute is true.

If an arc has an @xbrldt:usable attribute whose value is false, then its targets are excluded from the domain of valid members.

The exclusion does not affect subsequent children in the domain-member DRS rooted at the excluded
element.

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

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

2.6 Domain-member relations and inheritance (normative)

A primary item declaration MAY
be the source of a domain-member relationship. When a primary item declaration is the source of both a domain-member relationship and a
has-hypercube relationship, the target of the domain-member arc
relationship is said to inherit the has-hypercube relationship of the source element. Inheritance
is transitive. Inheritance preserves the base set and DRS of the original has-hypercube
relationship, as well as the values of its @xbrldt:contextElement attribute and @xbrldt:closed attribute.

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

A primary item declaration having no direct
has-hypercube relationships MAY inherit any number of has-hypercube
relationships , from its parents in the domain-member
network.

The impact of has-hypercube relationships on instance validation is unchanged merely because
the relationships have been inherited.

2.6.1 Processing of multiple has-hypercube arcs

In Example 6 above, the domain-member network created with elements from the
primary taxonomy MAY have multiple has-hypercube arcs at different levels of the tree.

As stated in chapter Section 3.1.2, "Mutual validity of hypercbues in a base set"
below , only
the hypercubes that are found within the same base set are considered together for validation.

Example 11: Inheritance and processing of multiple hypercubes.

Element under validation

Extended link

Hypercubes

p_PrimaryParent

link1

hc_One

p_FirstChild

link1

hc_One and hc_Two

p_SecondChild

link1

hc_One and hc_Two

p_ThirdChild

link1

hc_One and hc_Two

p_PrimaryParent

link2

None

p_FirstChild

link2

None

p_SecondChild

link2

hc_Three

p_ThirdChild

link2

hc_Three

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

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

Example 12: Multiple allAll hypercubes in a domain-member network

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

Element

Product Dimension

Region Dimension

Explanation

p_GrossProfit

1,2,3

A,B,C

Directly linked hypercube hc_Reg_x_Prod defined in cube1

p_Sales

1,2,3

A,B,C

Inherited from parent p_GrossProfit

p_CostOfGoods

1,2,3

C

Inherited from parent is cube1, but cube2 with notAll excludes combinations of A,B with all
members from the product dimension and keeps element C from the regions dimension combined with all
members in the product dimension

p_ImportedGoods

1,2,3

No combination is possible, a warning MAY be raised by dimensional
processors.

Inherited from parent p_CostOfGoods are only the combinations of the C region with
all members in the products domain. cube3 is incompatible because it only includes region A. Either
hypercube declared in (cube1 and not cube2) or hypercube declared in (cube3) will be invalid so the
hypercubes are not compatible and it is not possible to create a dimensionally valid instantiation
of p_ImportedGoods.

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

In the tx taxonomy only the GrossProfit primary concept has a products
dimension, and the default member in the products dimension is the p:TotalProducts
member. A calculation network exists in the primary taxonomy tx to represent that NetProfit =
GrossProfit – Taxes. The concept GrossProfit for
TotalProducts (the one with @contextRef = "ctx1") is dimensionally
valid (ProductDim = p:TotalProducts) and used in summation-items relationships
with Taxes and NetProfit.

2.7.1 Arc role http://xbrl.org/int/dim/arcrole/dimension-default

The dimension-default arc role identifies in its source a dimension element and in its target
the default member.

The default member indicated in the target of a dimension-default arc is global. If one dimension-default
arc exists in one extended link, then the default member is considered as defined in all the extended links
where the dimension is used and the domain contains the domain member indicated in the target of the arc.

The dimension-default relationship is not subject to the effect of the
@xbrldt:targetRole attribute.

The existence of a dimension-default arc does not add the target item to any of the domains
of the source dimension.

The http://xbrl.org/int/dim/arcrole/dimension-default arc role is declared as follows:

A dimension MUST NOT have more than one
default member. There MUST be no more than one default
member in a domain. A dimensional processor MUST raise an
error xbrldte:TooManyDefaultMembersError if this rule is violated.

2.7.1.2 Constraints on instance documents about the member that is the default for a dimension

The default member of a dimension MUST NOT appear in a <context> .
A dimensional processor MUST
raise an error
xbrldie:DefaultValueUsedInInstanceError when a default member appears.

3 Dimensions in instance documents (normative)

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

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

NON NORMATIVE NOTE: The validation of the instance document must be made item by item. A dimensional processor
must find the hypercubes related to an item in the document DTS and must validate the hypercubes one by one. One
hypercube is valid if all its dimensions are valid. A dimension is valid if in the <context> there is
a member of its domain or if the dimension contains a default member. The result of the hypercubes validation
must be combined for those hypercubes that coexist in the same base set using the specified operator "all",
"notAll". One Primary Item is valid if it is not associated with any hypercube or if there is at least one extended link role in which the primary item is associated to a base set with a valid combination of hypercubes whose combined validation result is valid.

The following sections describe in more detail the rules that apply to the validation of every dimensional
component.

3.1 Validation of primary items (normative)

Every primary item [Def, 1] that has hypercubes in
the DTS of the instance document MUST be valid according to at least one of the base sets
in which its hypercubes are defined.

Primary Items are dimensionally valid if the hypercubes found in at
least one base set are mutually valid.

3.1.1 Constraints on the validity of primary items

A Primary Item is dimensionally valid if the hypercubes
found in at least one base set are mutually valid. See Section 3.1.2. A dimensional processor MUST raise
an error xbrldie:PrimaryItemDimensionallyInvalidError if the hypercube combinations found
in all base sets are invalid.

3.1.2 Mutual validity of hypercubes in a base set

A Primary Item is valid according to the hypercubes defined in
a base set if the operation that joins all the hypercubes is satisfied.

Figure 3 below shows the warnings that a
dimensional processor MAY raise when a primary item is not valid according to its
hypercubes and the operation that combines multiple hypercubes within the same base set.

Figure 3: Combination of multiple hypercubes and the result operation.

Nº of cubes

Operator

Hypercube(s) evaluation

Primary Item eval. Result

Warning

1

all

Valid

Valid

No error

1

notAll

Invalid

Valid

No error

2

all notAll

Valid Invalid

Valid

No error

1

all

Invalid

Invalid

There is just one hypercube and is invalid for the all operation

1

notAll

Valid

Invalid

There is just one hypercube and is valid for the notAll operation

2

all notAll

Valid Valid

Invalid

There are multiple hypercubes defined in a base set and the result of the combination invalid

3.1.3.1 Constraints on the individual validity of hypercubes

There MUST be a dimension value
in the container indicated in the value of the @xbrldt:contextElement attribute in the
has-hypercube arc. If there is no value for the dimension in the indicated container the
hypercube is invalid.

All dimensions defined in the hypercube MUST be valid according to the rules
defined in Section 3.1.4 "Validity of dimensions" below. If one dimension is invalid the hypercube is invalid.

The dimension value [Def, 15] for explicit dimensions is the QName that is the content of the
xbrldi:explicitMember element whose @dimension attribute value is the QName of
the dimension in use or the QName of the default member if the value is not reported in the instance and
the dimension has a default member.

[Def, 17] The default value is the QName of the default
member.

3.1.4.2 Constraints about dimension values

A <context> MUST NOT contain more than one dimension value [Def, 15] for each dimension. A validator MUST signal
an error
xbrldie:RepeatedDimensionInInstanceError when this rule is violated.

Assuming the context is using the DRS defined in
Example 10 and Example 20.
p:m_Barbados is not a domain member of in hc_RegionDim;
hence the constraint is violated by all three facts even though only p_SalesGrossProfit had an explicit "all" arc to hc_Product_x_Region.

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

3.1.4.4.2 Constraints about the @dimension attribute in xbrldi:typedMember elements

The content of the @dimension attribute of an xbrldi:typedMember element
MUST be the QName of a typed dimension
declaration [Def, 9] defined in a schema within the DTS of the instance document. A dimensional processor MUST
raise an error xbrldie:TypedMemberNotTypedDimensionError if the element whose QName
appears in the @dimension attribute of xbrldi:typedMember resolves to
anything other than a typed dimension declaration [Def,
9].

3.1.4.4.3 Constraints on the content of xbrldi:typedMember elements

According to the xbrldi XML Schema, every instance of
xbrldi:typedMember MUST have only one child element.

The typed dimension value [Def, 15] MUST be XML valid according to the XML Schema declaration of the element
referenced in the @xbrldt:typedDomainRef attribute.

The typed
dimension content [Def, 15] MUST be an instantiation of the element pointed to by the
@xbrldt:typedDomainRef of the typed dimension indicated in the @dimension
attribute of the xbrldi:typedMember element. A dimensional processor MUST
raise an error xbrldie:IllegalTypedDimensionContentError if this rule is
violated.

3.1.4.5.2 Constraints on the @dimension attribute in xbrldi:explicitMember
elements

The content of the @dimension attribute of an xbrldi:explicitMember
element MUST be the QName of an explicit
dimension element defined in a schema within the DTS of the instance document. A dimensional processor MUST
raise an error xbrldie:ExplicitMemberNotExplicitDimensionError if the
element whose QName appears in the @dimension attribute of
xbrldi:explicitMember resolves to anything other than an explicit dimension declaration [Def, 10].

3.1.4.5.3 Constraints on the content of the xbrldi:explicitMember elements

The content of the xbrldi:explicitMember element MUST be a
QName whose global element definition can be found in the taxonomy schema referenced by the namespace
of the QName. A dimensional processor
MUST raise ean error xbrldie:ExplicitMemberUndefinedQNameError if
this rule is violated.

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

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

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

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

Appendix A Errors

A.1 Validating Taxonomies

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

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

A.2 Validating Instances

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

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

Irredundancy: The solution SHOULD NOT require instances, schemas or linkbases
to encode the same information in multiple places.

Satisfied. Use of base sets in validation to avoid redundancy explained in
Section 2.4,
"Partitioning of a Dimensional relationship set"
Association of typed dimension
items and dimensional elements has a unidirectional reference, Section 2.5.2.1, "The xbrldt:typedDomainRef".

Taxonomy authors MUST be able to define the valid combinations of Dimensions
and Dimension members that MUST NOT , MAY or MUST
occur in the <segment> s and <scenario> s of the <context> s of
the facts of any concept, and whether other elements MAY or MUST NOT
appear in <segment> s and <scenario> s.

The specification SHOULD minimise the number of elements required to express
constraints on combinations of Concepts and Dimension Members.

Satisfied. Section 2.3,
"Primary item declarations and hypercubes"
allows a minimum of one element per hypercube;
Section 2.4,
"Partitioning of a Dimensional relationship set,"
allows a set of dimension or domain relationships to be used by any number of hypercubes or primary item declarations.

Appendix D Schemas (normative)

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

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

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

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

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

Appendix E Intellectual property status (non-normative)

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

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

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

Appendix F Acknowledgements (non-normative)

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

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

19 July 2005

Hugh Wallis

Editorial updates to indicate Public Working Draft status.

23 July 2005

Walter Hamscher

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

24 July 2005

Walter Hamscher

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

26 July 2005

Ignacio Hernández-Ros

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

28 July 2005

Ignacio Hernández-Ros

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

01 August 2005

Ignacio Hernández-Ros

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

04 August 2005

Ignacio Hernández-Ros

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

12 August 2005

Ignacio Hernández-Ros

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

19 August 2005

Ignacio Hernández-Ros

Rebuilding of Example 19.

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

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

New example 15 created to demonstrate Empty Dimensions

Changed most of the wording in the terms definitions

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

26 August 2005

Ignacio Hernández-Ros

Prefixed changes from xdt to xbrldt and xdi to xbrldi.

Namespaces changed accordingly.

Changed arcrole has-dimension to hypercube-dimension.

Changed attribute @dimensionURI to @implicitDimensionRef.

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

Wording changes to clarify some parts of the document.

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

Changed the examples.

07 September 2005

Ignacio Hernández-Ros

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

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

Removed the overloading of the abstract attribute.

Changed the @implicitDimensionRef attribute to @implicitDomainRef.

Added the ImplicitMember in the instances.

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

Removed the chapter 2.10 about the priority of hypercubes operations.

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

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

New schemas updated.

Updated the error tables.

09 September 2005

Walter Hamscher

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

Updated LRR entries to 2005-08-11 CR3.

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

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

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

Re-sorted the instance error table.

12 September 2005

Ignacio Hernández-Ros

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

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

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

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

Minor edits in sections 2.5.2, 2.4.2 and 2.1

20 July 2006

Ignacio Hernández-Ros

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

12 September 2006

Ignacio Hernández-Ros

Corrected a typo in Example 4.

Editorial to reflect Recommendation status.

04 July 2009

Walter Hamscher

Document cleanup for publication of Errata

20 November 2011

Walter Hamscher

Edits for Proposed Edited Recommendation status.

Appendix H Errata Corrections incorporated in this document

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

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