1.1.1 Primary taxonomies

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

1.1.2 Domain members taxonomies

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

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

1.1.3 Template taxonomies

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

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

• Example: a topographic map is a 3-dimensional hypercube; it has thee dimensions - , elevation, longitude and latitude - , all of which are defined over the domain of real numbers. The elevation can be represented as a Primary Item, with longitude and latitude being the two dimensions of a hypercube for that Primary Item.
• Example: A table in a financial statement showing revenue byfor products and by territory, is a 3- dimensional hypercube, with one Primary Item (revenue) and two explicit dimensions (products and territory).
• Example: A loan report for a bank may be, in effect, an n-dimensional hypercube with dimensions including loan size (a Primary Item), borrower's credit rating, loan maturity, borrower type, loan purpose, and other dimensions.

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

2.1.1 Consecutive relationships

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

1. The value of the @xlink:arcrole attribute on the arc that represents the initial relationship and the value of the @xlink:arcrole attribute on the arc that represents the following relationship MUST correspond to one of the ordered pairs of arcrole values listed in Table 2; and
2. The set of nodes pointed to by locators identified by the @xlink:to attribute of the arc that represents the initial relationship MUST be the same set of nodes pointed to by locators identified by the @xlink:from attribute of the arc representing the following relationship.

2.2.1 Constraints on hypercube declarations

• A dimensional processor MUST raise an error xbrldte:HypercubeElementIsNotAbstractError if an element that is in the substitution group of the xbrldt:hypercubeItem element is not abstract.

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

The hypercube-dimension relationship has a hypercube declaration [Def, 4] as its source and a dimension declaration [Def, 7] as its target.

The order of the hypercube-dimension relationship for taxonomy representation purposes in taxonomy editing tools is defined by the value of the @order attribute on the arc defining the relationship.

The hypercube-dimension relationship role MUST NOT have any directed or undirected cycles.

It is declared as follows:

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

2.3.1 The "all" and "notAll" arc roles

Relationships in the dimensional relationship set [Def, 3] of an http://xbrl.org/int/dim/arcrole/all relationship are relevant to instance validation. The source and target are primary item declarations and hypercube declarations [Def, 4], respectively.

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

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

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.

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

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

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

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

2.3.2 The required @xbrldt:contextElement attribute on has-hypercube arcs

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

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

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

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

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

[Def, 20] The instantiation of a primary item declaration [Def, 1] as a fact in an instance document is dimensionally valid with respect to a hypercube when:

• For every dimension of the hypercube for which the primary item has a has-hypercube relationship, either:
  1. The has-hypercube relationship has xbrldt:contextElement="segment" and the segment dimensional container [Def, 16] of the fact's context has a dimension value [Def, 15] for that dimension, or
  2. The has-hypercube relationship has xbrldt:contextElement="scenario" and the scenario dimensional container [Def, 16] of the fact's context has a dimension value [Def, 15] for that dimension, or
  3. The dimension has default value [Def, 17].

[Def, 21] The instantiation of a primary item declaration [Def, 1] as a fact in an instance document is dimensionally valid 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 fact is dimensionally valid with respect to the hypercube [Def, 20] and
• For every dimension value [Def, 15] in the segment dimensional container [Def, 16] of the fact's context, the dimension of that value is a dimension of the closed hypercube, and
• For every dimension value [Def, 15] in the scenario dimensional container [Def, 16] of the fact’s context, the dimension of that value is a dimension of the closed hypercube.

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.4.1 Taxonomy validation impact of splitting dimensional relationship sets

Splitting dimensional relationship sets [Def, 3] into multiple roles base sets impacts the validity of XBRL taxonomies. ; cConsecutive relationships [Def, 2] having the same arcrole MUST NOT violate the cyclesAllowed constraint that would normally apply within in a base set. All other taxonomy validation rules are unaffected by base sets.

The @xbrldt:targetRole attribute itself MUST contain a declared role.

2.4.2 Instance validation impact of splitting dimensional relationship sets

Splitting dimensional relationship sets [Def, 3] into multiple roles base sets does not impact the validity of XBRL instances according to this specification. The rules in Section 3.1 below have the same meaning irrespective of whether the dimensional relationship set [Def, 3] is defined in one rolebase set or in multiple rolesbase sets.

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

1. If the value, V, of the @xbrldt:targetRole attribute on a definitionArc is not the standard extended link role (http://www.xbrl.org/2003/role/link), the ancestor linkbase element of the definitionArc element MUST have a child roleRef element (3.5.2.4 [XBRL 2.1]) with V as the value of its @roleURI attribute (5.1.3 [XBRL 2.1]). A dimensional processor MUST raise an error xbrldte:TargetRoleNotResolvedError if this constraint is not satisfied the URI content of an @xbrldt:targetRole attribute cannot be resolved via a link:roleRef element as defined in section (3.5.2.4 [XBRL 2.1]) of the [XBRL 2.1] specficiation. to a link:roleType element (5.1.3 [XBRL 2.1]).
2. [Def, 19] A consecutive relationship set is the set of relationships starting at an all or notAll relationship, and following all subsequent consecutive relationships [Def, 2]. A dimensional processor MUST check the cycles in two arcs that represents a consecutive relationship connected with an @xbrldt:targetRole attribute according to the value of the @cyclesAllowed attribute in the arc definition in the xbrldt schema as if the two arcs that represent the consecutive relationship [Def, 2] were created in the same extended-type link element. A dimensional processor MUST raise an error xbrldte:DRSDirectedCycleError for each consecutive relationship set [Def, 19] that contains a if invalid directed cycles are found.
3. According to the xbrldt XML Schema, the content of the @xbrldt:targetRole attribute MUST be a valid URI.

2.5.1 Constraints on the dimension declaration

1. A dimensional processor MUST raise an error xbrldte:DimensionElementIsNotAbstractError if an element that is in the substitution group of xbrldt:dimensionItem is not abstract.

2.5.2 Typed dimensions

[Def, 9] A typed dimension is a dimension declaration [Def, 7] whose domain of members [Def, 8] is defined in another XML element referenced in the @xbrldt:typedDomainRef attribute.

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

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

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

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.3 Explicit dimensions

[Def, 10] An explicit dimension is a dimension declaration [Def, 7] that has no @xbrldt:typedDomainRef attribute and has dimension-domain arcs to zero or more domain member declarations [Def, 11] whose QNames comprise the dimension domain [Def, 8] .

[Def, 11] A domain member declaration is an element defined in a taxonomy in the xbrli:item substitution group and not in the xbrldt:hypercubeItem or xbrldt:dimensionItem substitution groups.

[Def, 12] A domain of valid members of an explicit dimension is the set of QNames of all usable elements (see Section 2.5.3.3 below) in the dimensional relationship set [Def, 3] for the domain-member relation rooted at one domain member [Def, 11]. This is the effective domain [Def, 14] without the elements that are marked as not usable.

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

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

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

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.

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:

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

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

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

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

3.1.1 Constraints on the validity of primary items

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

3.1.2 Mutual validity of hypercubes in a base set

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

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

3.1.3 Individual validity of hypercubes

All dimensions in a hypercube MUST be validated according to rules defined in Section 3.1.4.

Note 1: Invalid because the hypercube is closed and Dim3 is not expected.

Note 2: This hypercube is open, so Dim3 is allowed.

3.1.4 Validity of dimensions

[Def, 15] The dimension value is defined as the QName that is the content value of the explicit dimension container [Def, 16] for explicit dimensions or the XML fragment that is the first child element content of the typed dimension container [Def, 16] for typed dimensions. A dimension value [Def, 15] exists for one specific dimension in one of the two possible <context> containers: <segment> or <scenario> . The Ddefault values are also possible dimension values but they are not enclosed in dimension containers [Def, 16] .

[Def, 16] The dimension container is the element xbrldi:typedMember for typed dimensions or the element xbrldi:explicitMember for explicit dimensions.

A dimension value  MUST be valid according to its Domain. Validation of typed dimensions and explicit dimensions is defined in Section 3.1.4.4 below and Section 3.1.4.5 below respectively.

3.1.4.3 Examples of context and their dimension validity

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

<context id="c3">

<entity>

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

<segment>

<xbrldi:typedMember dimension="tax:Team">

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

</xbrldi:typedMember>

</segment>

</entity>

<period>

<forever/>

</period>

<scenario>

<xbrldi:typedMember dimension="tax:Team">

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

</xbrldi:typedMember>

</scenario>

</context>

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

<context id="c4">

<entity>

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

<segment>

<xbrldi:typedMember dimension="tax:TeamDim">

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

</xbrldi:typedMember>

<xbrldi:typedMember dimension="tax:DrinkDim">

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

</xbrldi:typedMember>

</segment>

</entity>

<period>

<forever/>

</period>

</context>

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

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

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

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

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

<unit id="eur"> <measure>iso4217:EUR</measure> </unit> <context id="c19"> <entity> <identifier scheme="http://nic.net">example.com</identifier> <segment> <xbrldi:explicitMember dimension="p:ProductDim">p:m_RedWine</xbrldi:explicitMember> <xbrldi:explicitMember dimension="p:RegionDim">p:m_Barbados</xbrldi:explicitMember> </segment> </entity> <period> <forever/> </period> </context> <p:p_GrossProfit contextRef="c19" unitRef="eur" decimals="INF">10000</p:p_GrossProfit> <p:p_CostOfGoods contextRef="c19" unitRef="eur" decimals="INF">50000</p:p_CostOfGoods> <p:p_Sales contextRef="c19" unitRef="eur" decimals="INF">60000</p:p_Sales>

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

3.1.4.5 Explicit dimensions

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

3.1.4.5.1 The xbrldi:explicitMember element

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

<element name="explicitMember">

<annotation>

<documentation xml:lang="en">This element contains the QName of an item that is a member of an explicit dimension. </documentation>

</annotation>

<complexType>

<simpleContent>

<extension base="QName">

<attribute name="dimension" type="QName" use="required"/>

</extension>

</simpleContent>

</complexType>

</element>

<element name="explicitMember">

<annotation>

<documentation xml:lang="en">This element contains the QName of an item that is a member of an explicit dimension. </documentation>

</annotation>

<complexType>

<simpleContent>

<extension base="QName">

<attribute name="dimension" type="QName" use="required"/>

</extension>

</simpleContent>

</complexType>

</element>

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

<context id="c16">

<entity>

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

<segment>

<xbrldi:explicitMember dimension="tax:RegionDim">r:m_Iberia</xbrldi:explicitMember>

<xbrldi:explicitMember dimension="tax:ProductDim">p:m_RedWine</xbrldi:explicitMember>

</segment>

</entity>

<period>

<forever/>

</period>

</context>

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

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

3.1.4.5.3 Constraints on the content of the xbrldi:explicitMember elements

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