XBRL Dimensions 1.0
Public Working Draft, dated 2005-07-19
This version:
XDT-PWD-2005-07-19.rtf

is normative. All other versions and formats are non-normative.
Authors
Name	Contact	Affiliation	
Ignacio Hernández-Ros	ihr@xbrl.org	XBRL International Inc.	
Hugh Wallis	hughwallis@xbrl.org	XBRL International Inc.	
Contributors
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	
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 [DIM-REQ]. It is a modular extension to the XBRL 2.1, Specification [XBRL]. 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 [XBRL] 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 the XBRL 2.1, Specification [XBRL] 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.
Status
Circulation of this Public Working Draft is unrestricted. Publication was approved by the International Steering Committee of XBRL International on 2005-07-19. Recipients of this draft are invited to submit comments to the authors and contributors, and to submit notification of any relevant patent rights of which they are aware and to provide supporting documentation.
Table of Contents
1	Introduction
1.1	Background
1.1.1	Measure taxonomies
1.1.2	Dimensional taxonomies
1.1.3	Template taxonomies
1.2	Relationship to other work
1.3	Terminology
1.4	Document conventions
2	Dimensional Taxonomies
2.1	Architecture
2.2	Segments and scenarios
2.3	Implicit dimensions
2.3.1	Attribute dimensionURI
2.4	Hypercubes
2.4.1	Arc role http://xbrl.org/dim/arcrole/has-dimension
2.4.2	Validity of a context with respect to a dimension
2.4.3	Validity of a context with respect to a hypercube
2.4.4	The optional “closed” attribute on the has-dimension arc
2.5	Measures and Hypercubes
2.5.1	The “all” arc role http://xbrl.org/dim/arcrole/all
2.5.2	The “any” arc role http://xbrl.org/dim/arcrole/any
2.5.3	The “choice” arc role http://xbrl.org/dim/arcrole/choice
2.5.4	Negation of the measure-hypercube arcs
2.6	Discoverable relationship sets
2.6.1	Validation impact of discoverable relationship sets
2.7	Attribute group dimAttributes
2.8	Explicit dimensions
2.8.1	Arc role http://xbrl.org/dim/role/dimension-domain
2.8.2	Arc role http://xbrl.org/dim/role/domain-member
2.8.3	Element Member
2.8.4	Validation of contexts with respect to an explicit dimension
2.9	Validation of facts
2.10	Domain-member relations and inheritance
2.11	Element declarations and linkbase syntax
3	Aggregators
3.1.1	Arc role http://xbrl.org/int/dim/arcrole/aggregator-contributor
A	Errors (normative)
B	Requirements Reference (non-normative)
C	References (non-normative)
D	Schemas (normative)
xdt-2005-06-30.xsd (normative)
xdi-2005-06-30.xsd (normative)
E	Intellectual Property Status (non-normative)
F	Acknowledgements (non-normative)
G	Document History (non-normative)
H	Approval process (non-normative)
 
Table of Examples
Example 1.  Implicit dimension elements and their domains
Example 2.  Hypercube of the Team and Drink implicit dimensions in segments
Example 3.  Two dimensions referenced in the segment of a context
Example 4.  Two dimensions referenced in the scenario of a context
Example 5.  An invalid context containing two references to the same dimension
Example 6.  A context that is valid with respect to a hypercube
Example 7.   Three contexts that are not valid with respect to a hypercube
Example 8.  A closed hypercube
Example 9.  A measure with a single hypercube
Example 10.  A measure with hypercubes composed by conjunction (“all”)
Example 11.  A measure with hypercubes composed by disjunction (inclusive “or”)
Example 12.  A hypercube composed by exclusive disjunction (exclusive “or”)
Example 13.  A hypercube composed by conjunction with a negated hypercube
Example 14.  B is in the DRS of A although in a different base set
Example 15.  An explicit dimension element and its domain
Example 16.  A context that is valid with respect to a hypercube with two explicit dimensions
Example 17.  Two measures inheriting a hypercube
Example 18.  Facts not valid because they violate their hypercube constraints
Example 19.  Aggregator-Contributor relationship

Table of Figures
Figure 1.  Relationships to define constraints on the content of contexts
Figure 2.  Discovery relation between relationship A and relationship B
Figure 3.  Errors signalled by a validator when fact context is not valid with respect to the DRS of the hypercubes of its measure

1	Introduction
The architecture of XBRL as defined in the base XBRL 2.1, Specification [XBRL] defines a rich set of syntactic and semantic rules for specifying concepts that are members, or elements, of one dimension and relationships among them in what is termed a “taxonomy” (plural “taxonomies”). It also defines extensibility mechanisms for taxonomies and “Discoverable Taxonomy Sets” (or DTSs - see [XBRL] section 3.2). These rules employ XML Schemas [SCHEMA-1][SCHEMA‑2] to identify the various concepts involved and XLINK linkbases [XLINK] to define relationships between those concepts and between those concepts and other resources. It also defines a rich set of syntactic and semantic rules for how such DTSs are to be referenced and interpreted when used in conjunction with an XBRL instance.  XBRL also provides a mechanism for instance preparers to define other dimensional metadata that describe facts that are reported in the XBRL instance. This mechanism involves the notion of “contexts” (defined by the <context> element) and, within those contexts, the use of <segment> and/or <scenario> elements along with additional schemas that specify all dimensional metadata that is not otherwise given semantic meaning by the specification itself. Dimensions that ARE provided such semantic meaning by the specification itself are the “time” dimension, which leverages the sophisticated semantic mechanisms provided in XML Schema [SCHEMA-1], and, to a limited extent, “units” which may sometimes be viewed as dimensional and at other times as properties of individual facts depending on the application.
The contents of the <segment> and <scenario> elements are deliberately left open to permit users to fashion their own mechanisms for defining and referencing this dimensional metadata. It has, however, become apparent that, in practice, there is a need to formalise a consistent system for defining this dimensional metadata and a need to define a mechanism for specifying not only the names of such metadata elements but also their interrelationships. It has also become apparent that often the nature of such metadata and metadata relationships resembles very closely that which is already addressed by the XBRL taxonomy mechanism which is used for the “concepts” dimension.
For the purposes defined in the Dimensional Taxonomies Requirements [DIM-REQ], and in particular for explicit dimensions, this modular extension to the base XBRL 2.1, Specification [XBRL] defines such a formalisation of the syntax of the body of the <segment> and <scenario> elements. so as to refer to elements from what are termed “dimensional taxonomies”. Such dimensional taxonomies are syntactically identical to taxonomies that are defined in the base XBRL 2.1, Specification [XBRL] with certain restrictions that must be adhered to when they are to be used as dimensional taxonomies (see section 2). In addition certain additional semantics are defined with respect to a taxonomy when it is used as a dimensional taxonomy and referenced as such by an XBRL instance.
1.1	Background
As should be apparent from the requirements [DIM-REQ], dimensional metadata was not invented with XBRL.  XBRL standardizes the representation of only two dimensions: the time dimension and the entity dimension.  Many reporting purposes, both internal and external to organisations, require multiple dimensions. What the XBRL 2.1 specification did create was the principles for this specification to exist while defining two open elements in the context of XBRL instance documents: the segment and scenario elements.  The present specification defines three possible different roles that taxonomies can play in representing multidimensional information: measures, explicit dimensions, and templates. 
1.1.1	Measure taxonomies
A measure taxonomy is an XBRL taxonomy that has no dimensional definitions.  Requirement G16 [DIM-REQ] states “Taxonomy authors must be able to extend a base taxonomy that does not have dimensional information, to have dimensions, without changing the concepts in the base.”  This specification uses the term measure taxonomy for a schema‑rooted DTS that represents only a single dimension, the elements that define the members of which are instantiated in an XBRL Instance.  A financial taxonomy used for a variety of purposes including internal and external reporting may be extended with a variety of dimensional taxonomies appropriate to the reporting purpose.
1.1.2	Dimensional taxonomies
Implicit dimensional taxonomies as defined in requirement G03 [DIM-REQ] define syntactic constraints on the contents of segments and scenarios using no additional metadata other than what can be represented in XML Schema.
Explicit dimensional taxonomies are those in which the XBRL items form a discrete, countably finite partitioning of a set of members, which hereinafter is called a domain.   Examples include a taxonomy on the domain of geographic territories, or a taxonomy on a domain of product lines.  Inclusion relationships (requirement G09 [DIM-REQ]) are represented by domain‑member relationships.  A dimensional taxonomy can be recognised because it will have an item that is the root of an acyclic graph of domain‑member relationships.  Instances may use any number of dimensional taxonomies, with the members of their domains possibly appearing in a variety of combinations within XBRL segment and scenario elements.
1.1.3	Template taxonomies
The DTS of an instance using dimensional information contains domain‑member relationships among items in both measure taxonomies and explicit dimension taxonomies.  Since a measure taxonomy (by definition) has no dimensional information, there is an implication that the instance-rooted DTS must encompass domain‑member relationships in a linkbase that is not in the schema-rooted DTS of the measure taxonomy.  
A template taxonomy imports all dimensional taxonomies with the measures taxonomies and adds the dimensional structures that will be used in the XBRL instance. By convention, a taxonomy that imports measure and dimensional taxonomies and defines all the necessary dimensional information is called a template taxonomy.  In particular, a template defines hypercubes.  A hypercube describes the Cartesian product of the dimensions needed for a measure.  Each dimension in turn is defined over a domain.  Note that in this formulation, a hypercube of a measure does not include the measure itself.
•	Example: a topographic map is a 3-dimensional hypercube; it has thee dimensions, elevation, longitude and latitude, all of which are defined over the domain of real numbers.  The elevation can be represented as a measure, longitude and latitude being the two dimensions of a hypercube for that measure.
•	Example: A table in a financial statement showing revenue for products, by territory, is a 3-dimensional hypercube, with one measure (revenue) and two explicit dimensions (products and territory).  A loan report for a bank may be, in effect, an n‑dimensional hypercube with dimensions including loan size (a measure), borrower’s credit rating, loan maturity, borrower type, loan purpose, and other dimensions.
The main purpose of a template taxonomy is to define the structures of the hyper cubes and link the hyper cubes with the measures.
1.2	Relationship to other work
The specifications contained in this document pertain to XBRL as defined in the XBRL Specification [XBRL].  
Parts of this document may reiterate for expository clarity certain syntactic and semantic restrictions imposed by XBRL, but this document does not modify XBRL.  In the event of any conflicts between this document and XBRL, XBRL prevails.  This document does place additional restrictions beyond those prescribed by XBRL.
This document implements the business requirements agreed in the Domain and Specifications Working Groups of the XBRL consortium and documented in the [DIM-REQ] document.
1.3	Terminology
Terminology used in XBRL frequently overlaps with terminology from other fields.
The following terms are used as described in the table below:

Term	Meaning (Normative)	
Arc, arcroleRef, base set, child, concept, context, duplicate item, descendant, DTS (discoverable taxonomy set), element, entity, fact, instance, item, linkbase, linkbaseRef, p‑equal, roleRef, taxonomy, taxonomy schema, u‑equal, XBRL instance.	As defined by XBRL [XBRL].	
relationship	An arc defines a relationship between its source concepts and target concepts that is determined by its xlink:arcrole and other attributes.	
source [concept(s)]	The concepts identified by the URI content of the href attributes of the locator-type elements in the same extended-type link element, which have the same label attribute content as the content of the “from” attribute of an arc.	
target [concept(s)]	The concepts identified by the URI content of the href attributes of the locator-type elements in the same extended-type link element, which have the same label attribute content as the content of the “to” attribute of an arc.	
must, must not, required, shall, shall not, should, should not, may, optional
	See [RFC2119] for definitions of these and other terms.  These include, in particular:
should: Conforming documents and applications are encouraged to behave as described.

must: Conformant documents and consuming applications are required to behave as described; otherwise they are in error.	
XDT Compliant (XDT-compliant)	Describes an element, attribute, linkbase, schema or DTS satisfying all applicable mandatory (“must”) rules in this document.   Any of such artefacts that violates or ignores a recommended (“should”) rule is inferior to one that obeys it and should not be emulated.	
XBRL	Extensible Business Reporting Language (XBRL) 2.1 Recommendation [XBRL].	
XBRL valid (XBRL-valid)	XML instances and schemas that satisfy the syntax requirements of XBRL.	

Term	Meaning (non-normative)	
Dimension	Each of the different aspects by which a fact may be characterised. A dimension has a domain.  A typical example of a dimension is the “product” dimension that identifies for a concept (Sales) the domain consisting of the possible products that its fact can be expressed about.	
Domain	A (possibly empty or possibly infinite) set of members.	
Domain Member	Each one of the possibilities in the domain of a Dimension.
Example: In the “Products Dimension” each one of the products in its domain is a Dimension Member.	
Explicit Dimension	Occurs when the domain explicitly names its members.	
Implicit Dimension	Occurs when the number of members is impractically large to enumerate explicitly.	
Empty Dimension	An Explicit Dimension with no domain.	
Aggregator	A dimension member that represents the result of summing facts about other members of the same dimension.
Example: In the products dimension, the member “TotalProducts” is the aggregator of all possible products.	
Measure	A measure is an item whose facts have contexts that contain dimensions.	
Measure Taxonomy	A measure taxonomy is an XBRL taxonomy with items that can contain dimensional information	
Dimensional Taxonomy	A taxonomy whose schema-rooted DTS includes a definition linkbase with one or more dimensional relationships.	
Template Taxonomy	A taxonomy that defines hypercubes and the relationships between the hypercubes and the facts from the measure.	
Hypercube	A hypercube is a combination of dimension members. The hypercube is defined by dimension-domain relations.	
Empty Hypercube	A hypercube with no dimensions.	
Dimensional Element	Refers to any non-measure element declaration used to represent hypercubes, explicit dimensions, implicit dimensions, domains and domain members.	
Discoverable relationship set	A set of relationships constructed by traversing relationships and items not only within base sets but across base sets, thus possibly including relationships from extended-type links with different roles, and relationships with different arc roles.	
1.4	Document conventions
The following highlighting is used to present normative technical material in this document:

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

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

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

2	
Dimensional Taxonomies 
2.1	Architecture
In XBRL Instances, certain elements that are defined by this specification are distinguished by the use of elements in the namespace http://xbrl.org/2005/xdi which is conventionally prefixed “xdi”; these elements appear within the scenario and segment elements only.  XBRL instances are validated according to the syntax constraints implied by the implicit dimensions (which require XML Schema validation and nothing more) and by the explicit dimensions (which require description of each member element and relationships among the members using linkbases).
Dimensional taxonomies are distinguished by the use of several arc roles published in the Link Role Registry [LRR].  These arc roles and associated attribute definitions are defined in the appinfo section of an XML schema containing no element definitions (the namespace of the schema file, were it to have elements, would be http://xbrl.org/2005/xdt).  
This document describes all the arc roles in detail.  Some of the arc roles require that their source or target be abstract, not abstract, numeric, string, or other types.  These abstract elements function for the definition of the dimensional taxonomies in a way that is similar to the way that abstract elements function in the presentation linkbases (see [XBRL] section 5.2.4.2 and Example 48); they never appear in instances, but serve to organize relationships.
Figure 1.  Relationships to define constraints on the content of contexts

Figure 1 schematically shows the various relationships and the type of elements at their source and target, and the purpose that these elements serve either as measures, explicit dimension members, or as the root item that represents an entire dimension (implicit or explicit).  These relationships need not all be within the same extended-type link.  The notation {any, all, choice} means that there are three possible relationships.  Additional attributes on the arc (i.e., negation and elt) and their types are shown on the arcs where they may appear.
Structured content in XML may be used in the contexts with implicit dimensions.   
Any XBRL item defined in a taxonomy may be used as an explicit dimension member.
Each of the sections in this chapter defines a syntax component and its consequences for validation (its semantics) with positive and negative examples.  The rules of syntax that apply to dimensional schemas, linkbases and instances are stated individually within each section.
2.2	Segments and scenarios
The XBRL segment and scenario elements are containers having the same content model; it allows one or more elements, whose namespace must be something other than http://www.xbrl.org/2003/instance : 
    <sequence>
      <any namespace="##other" processContents="lax" maxOccurs="unbounded"/>
    </sequence>	
2.2.1.1	Segment and scenario elements of a context of a measure may contain any elements allowed by their XBRL content models, unless otherwise constrained by dimensional relationships.
The mere presence of dimensional relationships and items does not by itself change the validation behaviour of an XBRL processor.
2.3	Implicit dimensions
An implicit dimension is represented by an abstract item (as defined by 5.1.1.3 [XBRL]), that is the target of a definition relationship having the arc role http://xbrl.org/dim/arcrole/has-dimension, and that has nonempty content for the attribute dimensionURI.  The dimensionURI attribute contains the URI of the definition of an element that defines the domain of the dimension.
The xbrli:balance, xbrli:periodType and nillable attributes of an implicit dimension item have no significance.
In any valid DTS there is a one-to-one relationship between dimension items (that are abstract) and dimension elements (that may appear in segment and scenario elements).
The domain of an implicit dimension contains all XML elements allowed by the type of the element referenced by dimensionURI.  The implicit dimension element may have nillable="true" in which case the domain contains that element with nil="true".
Example 1.  Implicit dimension elements and their domains
Dimension item	Dimension	Domain members	
<element
name="dCustomer"
substitutionGroup="xbrli:item"
abstract="true"
xbrli:periodType="duration"
xdt:dimensionURI=="#id_phone"
/>	<element name="cust">
<simpleType>
  <restriction base="string">
      <pattern value="[0-9][0-9][0-9][0-9][0-9]"/>
    </restriction>
  </simpleType>
</element>	<cust>12345</cust> <cust>01742</cust>	
<element 
name="dPhone" 
substitutionGroup="xbrli:item" 
abstract="true"
xbrli:periodType="duration"
xdt:dimensionURI="#id_phone"
/>

	<element name="phone" id="id_phone" xsi:nillable="true">
  <complexType name="phone" id="id_phone">
    <sequence>
      <element name="country" type="integer"/>
      <element name="city" type="integer"/>
      <element name="number" type="integer"/>
    </sequence>
  </complexType>
</element>	Elements valid for the domain type, such as: 

<phone> <country>7</country> <city>7</city> <number>5555555</number> </phone>

<phone xsi:nil="true"/>	

The separation of the dimension item from the element actually appearing in the instance is necessary because relationships in the definition linkbase may only have a target in the xbrli:item or xbrli:tuple substitution group, but such a restriction on the domain itself would be neither necessary nor desirable.
2.3.1	Attribute dimensionURI
The dimensionURI attribute has type anyURI.  Resolution of the URI is subject to the presence of an xml:base attribute.
  <xs:attribute name="dimensionURI" type="xs:anyURI"/>	
2.3.1.1	If the dimensionURI attribute appears in an element declaration, the element must be an abstract item.
A validator must signal xde:DimensionURIError if the dimensionURI attribute appears on an XML Schema element definition that is not in a substitution group of xbrli:item with abstract="true".
2.3.1.2	When present, the dimensionURI attribute must locate the definition of a non-abstract element.
A validator must signal xde:ImplicitDimensionError if the dimensionURI attribute locates something that is not an XML Schema element definition, or a definition that is not an element definition, or is not abstract.
2.3.1.3	Distinct items in a DTS having dimensionURI attributes must not refer to the same dimension element.
A validator must signal xde:DuplicateImplicitDimension if a dimensionURI attribute locates the same element as another dimensionURI attribute in the same DTS.  This rule does not prevent several dimensions from having the same domain but it does allow the appearance of a dimension element in a context to be unambiguously resolved to a dimension item.
2.4	Hypercubes
A hypercube is an abstract item that names a sequence of dimensions.  A hypercube is the Cartesian product of a sequence of dimensions.  The hypercube item names, and holds relationships to, the dimension items that constrain the syntax of contexts.   One of these relationships is the has‑dimension arc role.
2.4.1	Arc role http://xbrl.org/dim/arcrole/has-dimension
The has-dimension relationship has a hypercube item as its source and a dimension item as its target.  
A hypercube is the Cartesian product of one or more dimensions.  A hypercube and a set of has-dimension relationships in a base set associate the hypercube with the dimensions in that base set.
The order attribute indicates the order in which the dimensions are sequenced to produce a Cartesian product.
The has-dimension relationship role must not have any directed cycles.  A validator must signal error xdte:HasDimensionDirectedCycle if this occurs.
A validator must signal xdte:HasDimensionSourceError if the source of the relationship is not an abstract element in the substitution group of xbrli:item.
A validator must signal xdte:HasDimensionTargetError if the target of the relationship is not an abstract element in the substitution group of xbrli:item.
This arc role is defined as follows in the LRR:
<arcrole>
<link:arcroleRef 
  xlink:type="simple" 
  arcroleURI="http://xbrl.org/dim/arcrole/has-dimension" 
  xlink:href="http://www.xbrl.org/2005/xdt-2005-06-30.xsd#has-dimension"/>
<status>IWD</status>
<versionDate>2005-07-19</versionDate>
<requirement xml:lang="en">A hypercube may have one or more dimensions.
</requirement>
<versionOfXBRL>2.1</versionOfXBRL>
<minimumEditionDate>2004-11-14</minimumEditionDate>
<impactsTaxonomyValidation>true</impactsTaxonomyValidation>
<impactsInstanceValidation>true</impactsInstanceValidation>
<conformanceSuiteURI>http://www.xbrl.org/conf/dim/tests.xml
</conformanceSuiteURI>
<validation xml:lang="en">The presence of an has-dimension arc role indicates how part of a context is to be validated.
</validation>
  <attributes>
  <attribute 
  namespaceURI="http://www.xbrl.org/2003/instance" use="required">elt</attribute>
  <attribute>
  namespaceURI="http://www.xbrl.org/2003/instance" use="optional">closed</attribute>
</attributes>
<sourceAbstract>required</sourceAbstract>
<targetAbstract>required</targetAbstract>
</arcrole>	
It is declared as follows:
<arcroleType 
  id="has-dimension" 
  cyclesAllowed="none" 
  arcroleURI="http://xbrl.org/dim/arcrole/has-dimension">
  <definition>Source (a hypercube) contains the target (a dimension) among others.
  </definition>
  <usedOn>definitionArc</usedOn>
</arcroleType>	
Example 1 shows a hypercube consisting of two implicit dimensions, Team and Drink.  This example shows a hypercube describing the occurrence of Team and Drink elements in the segment element of a context.  The dimensionURI attributes are present but not relevant in the example.
Example 2.  Hypercube of the Team and Drink implicit dimensions in segments
	
2.4.1.1	A base set must not contain more than one has-dimension relationship between any pair of hypercube and implicit dimension elements.
Dimensions must be represented by distinct dimension items.  A validator must ensure that no hypercube has a repeated dimension.  Violation of this rule must signal xdte:RepeatedDimensionInHypercube.  Note that this is not guaranteed by XBRL itself which ensures only that there are no repeated arcs within an extended-type link.
2.4.2	Validity of a context with respect to a dimension
An implicit dimension is referenced in the segment of a context when the context contains an xbrli:segment element containing an element whose definition is referred to by a dimensionURI attribute.
Example 3.  Two dimensions referenced in the segment of a context
  <context id="c1">
    <entity>
      <identifier scheme="http://nic.net">example.com</identifier>
      <segment>
        <d:Team>Lakers</d:Team>
        <d:Drink>Coors</d:Drink>
      </segment>
    </entity>
    <period><forever/></period>
  </context>	
•	An implicit dimension is referenced in the scenario of a context when the context contains an xbrli:scenario element containing an element whose definition is referred to by a dimensionURI attribute.
Example 4.  Two dimensions referenced in the scenario of a context
  <context id="c2">
    <entity>
      <identifier scheme="http://nic.net">example.com</identifier>
    </entity>
    <period><forever/></period>
    <scenario>
      <d:Team>Celtics</d:Team>
      <d:Drink>Sam Adams</d:Drink>
    </scenario>
  </context>	
Not all of the elements appearing in segment or scenario are necessarily dimension elements; see section 2.4.4 below (The optional “closed” attribute on the has-dimension arc).
2.4.2.1	A context must not contain more than one element whose dimensionURI attribute resolves to the same elements.
A validator must signal xdie:RepeatedDimensionInInstance when a context references a dimension more than once, whether those references occur in the segment or scenario elements.
Example 5.  An invalid context containing two references to the same dimension
  <context id="c3">
    <entity>
      <identifier scheme="http://nic.net">example.com</identifier>
      <segment>
        <d:Team>Rams</d:Team>
      </segment>
    </entity>
    <period><forever/></period>
    <scenario>
      <d:Team>Lakers</d:Team>
    </scenario>
  </context>	
2.4.3	Validity of a context with respect to a hypercube
A context element in an XBRL instance is valid in a discoverable relationship set with respect to a hypercube if, for every simple dimension item that is the target of a has‑dimension relationship (in that discoverable relationship set) whose source is the hypercube, the dimension element that the target item’s dimensionURI attribute refers to appears in the particular descendant element named by the elt attributes.  Additional conditions apply to explicit dimension items, as discussed below.
An elt attribute must have one of the values segment or scenario.  
  <simpleType name="eltType">
    <restriction base="token">
      <enumeration value="segment"/>
      <enumeration value="scenario"/>
    </restriction>
  </simpleType>
  <attribute name="elt" type="xdt:eltType"/>	
Being invalid with respect to a hypercube does not, by itself, mean the context is invalid; that depends also on the relationship between the context, its facts, the measures, and the hypercube.
Discoverable relationship sets are defined in section 2.6 below; in the examples below, the discoverable relationship set happens to be equivalent to the base set of the has‑dimension relationships.  
Example 6.  A context that is valid with respect to a hypercube
	
  <context id="c3">
    <entity>
      <identifier scheme="http://nic.net">example.com</identifier>
      <segment>
        <d:Team>Rams</d:Team>
        <d:Drink>Coors</d:Drink>
      </segment>
    </entity>
    <period><forever/></period>
  </context>	
Example 7.   Three contexts that are not valid with respect to a hypercube
	
  <context id="c2">
    <entity>
      <identifier scheme="http://nic.net">example.com</identifier>
      <segment>
        <d:Team>Rams</d:Team>
      </segment>
    </entity>
    <period><forever/></period>
  </context>	Missing a reference to the Drink dimension.	
  <context id="c3">
    <entity>
      <identifier scheme="http://nic.net">example.com</identifier>
      <segment>
        <d:Team>Rams</d:Team>
      </segment>
    </entity>
    <period><forever/></period>
    <scenario>
      <d:Drink>Coors</d:Drink>
    </scenario>
  </context>	The Drink dimension must be referenced in the segment element.	
  <context id="c1">
    <entity>
      <identifier scheme="http://nic.net">example.com</identifier>
      <segment>
         <d:Drink>Coors</d:Drink>
      </segment>
    </entity>
    <period><forever/></period>
  </context>	Missing a reference to the Team dimension.	
2.4.4	The optional “closed” attribute on the has-dimension arc
The optional Boolean attribute closed may appear on has-dimension arcs.  If closed="true" on a has-dimension arc with elt="segment", the hypercube is said to be closed with respect to the segment element in that base set.  If closed="true" on a has-dimension arc with elt="scenario", the hypercube is said to be closed with respect to the scenario element in that base set.  
  <xs:attribute name="closed" type="xs:boolean"/>	
A context is valid with respect to a closed hypercube when the only elements appearing in the segment or scenario elements are those referenced in the segment or scenario (respectively) of the context.  For this purpose, a has-dimension relationship may have a target dimension that is an explicit dimension having no domain (an empty dimension).
Example 8.  A closed hypercube
	
The arcs with closed="true" mean that a context is valid with respect to this hypercube if it has a Team and Drink reference and nothing else in the segment element, and nothing at all in the scenario element.  Only one of the has-dimension arcs with the same value for the elt attribute needs to have closed="true".	
2.5	Measures and Hypercubes
To constrain the set of contexts that may appear on the facts of a given measure, a measure is associated with zero or more hypercubes.  
A measure associated with no hypercubes has no constraint on the contexts in which its facts appear.
A nonempty set of hypercubes may be composed via conjunction (“all”), exclusive disjunction (“choice”), inclusive disjunction (“any”).  These operators are conceptually no different from the similarly named compositors of XML Schema.  They also have a similar semantics with respect to validating instances.  However, the relationship between a compositor and its operands in XML Schema is represented by the XML node parent-child relationship, while in XBRL Dimensional Taxonomies the relationship between a compositor and its operands is represented by XLink arcs with distinct arc roles.  The use of arcs opens the possibility of using prohibition, overriding, and augmentation in extension taxonomies.
There are three arc roles collectively known as the measure‑hypercube relationships; they are:
•	http://xbrl.org/dim/arcrole/all, 
•	http://xbrl.org/dim/arcrole/any, and
•	http://xbrl.org/dim/arcrole/choice. 
The three composition operators are subject to negation via the “polarity” attribute on their corresponding arcs.  This feature is unlike XML Schema.
2.5.1	The “all” arc role http://xbrl.org/dim/arcrole/all
Only relationships in the discoverable relationship set are relevant to instance validation with the arc role http://xbrl.org/dim/arcrole/all.  A context is valid with respect to a conjunction of hypercubes only if it is valid with respect to all of the conjoined hypercubes individually.  The conjunction of a single hypercube is the hypercube itself (Example 9).
Example 9.  A measure with a single hypercube
	
The measure m_FluidCapacity is associated with a hypercube.  A context will be valid with respect to this measure only if it has a Team and a Drink reference.	
Example 10.  A measure with hypercubes composed by conjunction (“all”)
	
The measure m_FluidCapacity is associated with the composition of two hypercubes.  A context will be valid with respect to this measure only if it has a Team, Drink, and a City reference.  hcCity is a legal, but degenerate hypercube consisting of only a single dimension.	

A validator must signal xdte:MeasureHypercubeSourceError if the source of the relationship is an abstract element or not in the substitution group of xbrli:item.
A validator must signal xdte:MeasureHypercubeTargetError if the target of the relationship is not abstract element or not in the substitution group of xbrli:item.
The all arc role has the following LRR definition.  
<arcrole>
<link:arcroleRef 
  xlink:type="simple" 
  arcroleURI="http://xbrl.org/dim/arcrole/all" 
  xlink:href="http://www.xbrl.org/2005/xdt-2005-06-30.xsd#all "/>
<status>IWD</status>
<versionDate>2005-07-19</versionDate>
<requirement xml:lang="en">Hypercubes may be defined by intersection.
</requirement>
<versionOfXBRL>2.1</versionOfXBRL>
<minimumEditionDate>2004-11-14</minimumEditionDate>
<impactsTaxonomyValidation>true</impactsTaxonomyValidation>
<impactsInstanceValidation>true</impactsInstanceValidation>
<conformanceSuiteURI>http://www.xbrl.org/conf/dim/tests.xml
</conformanceSuiteURI>
<validation xml:lang="en">The presence of an “all” arc role indicates how part of a context is to be validated.
</validation>
  <attributes>
  <attribute namespaceURI="http://www.xbrl.org/2003/instance" use="optional">polarity</attribute>
</attributes>
<sourceAbstract>prohibited</sourceAbstract>
<targetAbstract>required</targetAbstract>
</arcrole>	
It is declared as follows:
<arcroleType 
  id="all" 
  cyclesAllowed="none" 
  arcroleURI="http://xbrl.org/dim/arcrole/all">
  <definition>Source (a measure) requires the target (hypercube) to appear in the context of the measure.
  </definition>
  <usedOn>definitionArc</usedOn>
</arcroleType>	
2.5.1.1	If a measure element is the source of an “all” relationship in a base set, then it must not be the source of a “choice” arc role in that same base set.
2.5.1.2	If a measure is the source of an “all” relationship in a base set, then it must not be the source of an “any” arc role in that same base set.
The validator must signal error xdte:MeasureHypercubeOperatorInconsistency if either rule is violated.
2.5.2	The “any” arc role http://xbrl.org/dim/arcrole/any
Relationships in the discoverable relationship set of an http://xbrl.org/dim/arcrole/any relationship are relevant to instance validation.
A context is valid with respect to an inclusive disjunction of hypercubes if it is valid with respect to one of the disjoined hypercubes.  
Example 11.  A measure with hypercubes composed by disjunction (inclusive “or”)
	
The measure m_FluidCapacity is associated with two disjoined hypercubes.  A context is valid with respect to this hypercube if it has either a City, or a Team and Drink.	
A validator must signal xdte:MeasureHypercubeSourceError if the source of a relationship is an abstract element or not in the substitution group of xbrli:item.
A validator must signal xdte:MeasureHypercubeTargetError if the target of a relationship is not an abstract element or not in the substitution group of xbrli:item.
The any arc role has the following LRR definition.
<arcrole>
<link:arcroleRef 
  xlink:type="simple" 
  arcroleURI="http://xbrl.org/dim/arcrole/any" 
  xlink:href="http://www.xbrl.org/2005/xdt-2005-06-30.xsd#any"/>
<status>IWD</status>
<versionDate>2005-07-19</versionDate>
<requirement xml:lang="en">Hypercubes may be defined by inclusive union.
</requirement>
<versionOfXBRL>2.1</versionOfXBRL>
<minimumEditionDate>2004-11-14</minimumEditionDate>
<impactsTaxonomyValidation>true</impactsTaxonomyValidation>
<impactsInstanceValidation>true</impactsInstanceValidation>
<conformanceSuiteURI>http://www.xbrl.org/conf/dim/tests.xml
</conformanceSuiteURI>
<validation xml:lang="en">The presence of an "any" arc role indicates how part of a context is to be validated.
</validation>
  <attributes>
  <attribute namespaceURI="http://www.xbrl.org/2003/instance" use="optional">polarity</attribute>
</attributes>
<sourceAbstract>prohibited</sourceAbstract>
<targetAbstract>required</targetAbstract>
</arcrole>	
It is declared as follows:
<arcroleType 
  id="any" 
  cyclesAllowed="none" 
  arcroleURI="http://xbrl.org/dim/arcrole/any">
  <definition>Source (a measure) allows the target (hypercube) to appear in the context of the measure.
  </definition>
  <usedOn>definitionArc</usedOn>
</arcroleType>	
2.5.2.1	If a measure is the source of an “any” arc role in a base set, then it must not be the source of an “all” relationship in that same base set.
2.5.2.2	If a hypercube is the source of an “any” arc role in a base set, then it must not be the source of a “choice” relationship in that same base set.
The validator must signal error xdte:MeasureHypercubeOperatorInconsistency if either rule is violated.
2.5.3	The “choice” arc role http://xbrl.org/dim/arcrole/choice
Relationships in the discoverable relationship set of an http://xbrl.org/dim/arcrole/choice relationship are relevant to instance validation.  The source and target are measure and hypercube elements, respectively. 
A context is valid with respect to an exclusive disjunction of hypercubes if it is valid with respect to one of the disjoined hypercubes and not valid with respect to the others.
Example 12.  A hypercube composed by exclusive disjunction (exclusive “or”)
	
The measure m_FluidCapacity is associated with two hypercubes.  A context is valid with respect to this exclusive disjunction of hypercubes if it has either a Team and Drink (as defined before) or a City, but not both.	
A validator must signal xdte:MeasureHypercubeSourceError if the source of the relationship is an abstract element or not in the substitution group of xbrli:item.
A validator must signal xdte:MeasureHypercubeTargetError if the target of the relationship is an abstract element or not in the substitution group of xbrli:item.
The choice arc role has the following LRR definition.
<arcrole>
<link:arcroleRef 
  xlink:type="simple" 
  arcroleURI="http://xbrl.org/dim/arcrole/choice" 
  xlink:href="http://www.xbrl.org/2005/xdt-2005-06-30.xsd#choice"/>
<status>IWD</status>
<versionDate>2005-07-19</versionDate>
<requirement xml:lang="en">Hypercubes may be defined by exclusive union.
</requirement>
<versionOfXBRL>2.1</versionOfXBRL>
<minimumEditionDate>2004-11-14</minimumEditionDate>
<impactsTaxonomyValidation>true</impactsTaxonomyValidation>
<impactsInstanceValidation>true</impactsInstanceValidation>
<conformanceSuiteURI>http://www.xbrl.org/conf/dim/tests.xml
</conformanceSuiteURI>
<validation xml:lang="en">The presence of a "choice" arc role indicates how part of a context is to be validated.
</validation>
  <attributes>
  <attribute namespaceURI="http://www.xbrl.org/2003/instance" use="optional">polarity</attribute>
</attributes>
<sourceAbstract>prohibited</sourceAbstract>
<targetAbstract>required</targetAbstract>
</arcrole>	
It is declared as follows:
<arcroleType 
  id="choice" 
  cyclesAllowed="none" 
  arcroleURI="http://xbrl.org/dim/arcrole/choice">
  <definition>Source (a measure) allows the target (hypercube) as one of a set of mutually exclusive alternatives.
  </definition>
  <usedOn>definitionArc</usedOn>
</arcroleType>	
2.5.3.1	If a measure is the source of a “choice” relationship in a base set, then it must not be the source of an “all” relationship in that same base set.
The validator must signal error xdte:MeasureHypercubeOperatorInconsistency if this rule is violated.
2.5.3.2	If a measure is the source of a “choice” relationship in a base set, then it must not be the source of an “any” relationship in that same base set.
The validator must signal error xdte:MeasureHypercubeOperatorInconsistency if this rule is violated.
2.5.4	Negation of the measure-hypercube arcs
Measure-hypercube arcs also have an optional attribute polarity.  The value of polarity is a Boolean and its default value is true.
  <xs:attribute name="polarity" type="xs:boolean" default="true"/>	
A hypercube that is the target of an arc with polarity="false" is a negated hypercube.  
A context is valid with respect to a negated hypercube if it is invalid with respect to the underlying hypercube.  
A context is invalid with respect to a negated hypercube if it is valid with respect to the underlying hypercube.
Example 13.  A hypercube composed by conjunction with a negated hypercube
	
The measure m_FluidCapacity has two conjoined hypercubes.  A context is valid with respect to this measure if it has a Team and Drink but does NOT have a City.	
Note: Having a negation relationship means that DeMorgan’s Law could be applied to make one of the any, all or choice relationships unnecessary.  However, this would require more deeply nested structures, such as hypercubes inside of hypercubes, violating P3 (Simplicity, Appendix B).  A design choice has been made to retain all three relationships and their negations, and have a single layer of hypercubes and a single layer of (conjoined) dimensions within each hypercube.
2.6	Discoverable relationship sets
Taxonomy authors are able to partition relationships into distinct base sets using the xlink:role attribute on extended-type link elements.  Applications that are aware of the names and meanings of the partitions may use different sets of relationships at different times for processing.  
But it is more than a useful feature; in the case of summation‑item relationships in the calculation linkbase, partitioning is essential to ensure that incompatible summations are not commingled.  Taxonomy authors may specify distinct base sets of dimensional relationships that a validating process would use together.  To forbid this would violate P2 (Consistency, Appendix B).
However, a set of measures may have hypercubes in common among the targets of their measure‑hypercube relationships; hypercube elements in turn may have implicit dimensions in common among the targets of their has‑dimension relationships.  Furthermore, in sections 2.7 through 2.9 below, additional relationships will also introduce tangled graphs, with some items as the source of separate and distinct sets of relationships to define different dimensions.  If all the dimensional relationships used together in a validation were forced to be in the same base set, there would be redundancy among dimensional arcs, violating P4 (Irredundancy, Appendix B).
The optional targetRole attribute on an arc allows a taxonomy author to specify the base sets of relationships that a validating processor must use together.  As declared in their LRR entries, the targetRole attribute may appear on definition arcs having the following arc roles: all, any, choice, has‑dimension, dimension‑domain and domain‑member.  The targetRole attribute has type anyURI.  Resolution of the URI is not subject to the presence of an xml:base attribute.  
  <xs:attribute name="targetRole" type="xs:anyURI"/>	
The discoverable relationship set (DRS) of a relationship consists of all relationships in the transitive closure of the discovery relation defined in Figure 2 below.  In Figure 2, role(arc) denotes the contents of the xlink:role attribute of the relationship’s base set; targetRole(arc) denotes the contents of the targetRole attribute on the arc itself.
Figure 2.  Discovery relation between relationship A and relationship B 
Arc role of Relationship A	Arc role of Relationship B with a source among the targets of Relationship A	
	domain‑member	all, any, choice	has‑dimension	dimension‑domain	
domain‑member	role(B)  {role(A), targetRole(A)}	False	False	False	
all, any, choice	False	False*	role(B)  {role(A), targetRole(A)}	False	
has‑dimension	False	False	False	role(B)  {role(A), targetRole(A)}	
dimension‑domain	role(B)  {role(A), targetRole(A)}	False	False	False	
*If the all, any and choice operators could be nested, this cell would not be False. 
Example 14.  B is in the DRS of A although in a different base set
	
<linkbase ...>
 <definitionLink xlink:role="http://www.xbrl.org/2003/role/link">
   <loc xlink:type="locator" xlink:href="tax1.xsd#first" xlink:label="lbl_1"/>
   <loc xlink:type="locator" xlink:href="tax1.xsd#second" xlink:label="lbl_2"
        />
   <definitionArc xlink:type="arc" id="arc_A"
        xlink:arcrole="http://xbrl.org/dim/role/domain-member"
	 targetRole="http://www.example.com/extended/role"
        xlink:from="lbl_1" xlink:to="lbl_2" />
 </definitionLink>
 <definitionLink xlink:role="http://www.example.com/extended/role">
   <loc xlink:type="locator" xlink:href="tax1.xsd#second" xlink:label="lbl_1"/>
   <loc xlink:type="locator" xlink:href="tax1.xsd#third" xlink:label="lbl_2"/>
   <definitionArc xlink:type="arc" id="arc_B"
        xlink:arcrole="http://xbrl.org/dim/role/domain-member"
        xlink:from="lbl_1" xlink:to="lbl_2" />
 </definitionLink>
</linkbase>	
2.6.1	Validation impact of discoverable relationship sets
Discoverable relationship sets do not impact validation of XBRL taxonomies.  That is because each arc role either has a “False” value along the diagonal in Figure 2 above, or else, as with domain‑member, has cyclesAllowed="any".  All other taxonomy validation rules are unaffected by base sets.
Discoverable arc sets do impact validation of XBRL instances.  In section 2.4.3 above, “Validity of a context with respect to a hypercube,” validation is defined with respect to the set of relationships in the DRS; the relevant DRS is defined in section 2.5 above, “Measures and Hypercubes.”
2.7	Attribute group dimAttributes 
Contexts may reference explicit dimension members using an XLink simple-type link with these attributes:
  <xs:attributeGroup name="dimAttributes">
    <xs:attributeGroup ref="xlink:simpleType"/>
    <xs:attribute ref="xlink:href" use="required"/>
    <xs:attribute ref="xlink:arcrole" use="optional"/>
    <xs:attribute ref="xlink:role" use="optional"/>
    <xs:attribute ref="xlink:title" use="optional"/>
    <xs:attribute ref="xlink:show" use="optional"/>
    <xs:attribute ref="xlink:actuate" use="optional"/>
    <xs:anyAttribute namespace="##targetNamespace" processContents="lax"/>
  </xs:attributeGroup>	
2.7.1.1	The required xlink:type attribute 
The xlink:type attribute MUST occur and MUST have the fixed content “simple”.
2.7.1.2	The required xlink:href attribute
The xlink:href attribute MUST occur and must be a URI that resolves to an XML Schema root element. If the URI reference is relative, its absolute version MUST be determined as specified in [XML Base] before use. For details on the allowable forms of XPointer [XPTR] syntax in the URI see [XBRL] section 3.5.4.
2.7.1.3	The optional xml:base attribute on Member elements
The xml:base attribute MAY occur and participate in the resolution of relative URIs specified in xlink:href attributes [XML Base].
2.7.1.4	The optional xlink:title attribute on Member elements 
The xlink:title attribute MAY occur.  Processors MAY use the contents of this attribute as a convenient way to identify to a user the dimension to which the reference element points, without having to traverse the link.
2.8	Explicit dimensions
The domain of an explicit dimension consists of the QNames of items in a taxonomy.  The items therefore inherit all the features of XBRL items, such as labels in multiple languages, presentation ordering, references, and extensibility of relations through prohibition, overrides, and augmentation.  The members of the domain may also be arranged into a relationship domain‑member that satisfies the requirements for an inclusion relationship [DIM-REQ].
An explicit dimension is represented by an abstract element in the substitution group of xbrli:item that is numeric (as defined in section 5.1.1.3 in [XBRL]), and which is the target of a definition relationship with arc role http://xbrl.org/dim/arcrole/has-dimension.  The xbrli:balance, xbrli:periodType and nillable attributes of an explicit dimension declaration have no significance.
The domain of an explicit dimension is represented by the target item of a dimension‑domain relationship whose source is the explicit dimension element.  The domain contains the QNames of all items in the transitive closure of the domain‑member relation rooted at the domain item.
Example 15.  An explicit dimension element and its domain
Dimension	Domain	Domain members	
<element 
name="ContinentDim" 
id="my_ContinentDim"
substitutionGroup="xbrli:item"
abstract="true"
xbrli:periodType="duration"/>

	<element
name="Continent"
id="geo_Continent"
substitutionGroup="xbrli:item"
xbrli:periodType="duration"/>

<element
name="SouthAmerica"
id="geo_SouthAmerica"
substitutionGroup="xbrli:item"
  xbrli:periodType="duration"/>	QNames (assuming that the namespace prefix of the targetNamespace is geo and there is a domain‑member arc from Continent to SouthAmerica):

geo:Continent
geo:SouthAmerica	
2.8.1	Arc role http://xbrl.org/dim/role/dimension-domain
A dimension‑domain relationship has an explicit dimension item as its source and any item as its target.  It binds a dimension to a domain.
A validator must signal xdte:DimensionDomainDirectedCycle if there is a directed cycle of dimension‑domain relationships in any base set.
A validator must signal xdte:DimensionDomainSourceError if the source of the relationship is not an abstract element in the substitution group of xbrli:item.
A validator must signal xdte:DimensionDomainTargetError if the target of the relationship is not in the substitution group of xbrli:item.
This arc role is defined as follows in the LRR:
<arcrole>
<link:arcroleRef 
  xlink:type="simple" 
  arcroleURI="http://xbrl.org/dim/role/dimension-domain" 
  xlink:href="http://www.xbrl.org/2005/xdt-2005-06-30.xsd#dimension-domain"/>
<status>IWD</status>
<versionDate>2005-07-19</versionDate>
<requirement xml:lang="en">An explicit dimension has one domain.
</requirement>
<versionOfXBRL>2.1</versionOfXBRL>
<minimumEditionDate>2004-11-14</minimumEditionDate>
<impactsTaxonomyValidation>true</impactsTaxonomyValidation>
<impactsInstanceValidation>true</impactsInstanceValidation>
<conformanceSuiteURI>http://www.xbrl.org/conf/dim/tests.xml</conformanceSuiteURI>
<validation xml:lang="en">The presence of a dimension-domain arc role indicates how part of a context is to be validated.
</validation>
  <attributes/>
<sourceAbstract>required</sourceAbstract>
<targetAbstract>optional</targetAbstract>
</arcrole>	
It is declared as follows:
<arcroleType 
  id="dimension-domain" 
  cyclesAllowed="none" 
  arcroleURI="http://xbrl.org/dim/role/dimension-domain">
  <definition>Source (a dimension) has only the target (a domain) as its domain.  </definition>
  <usedOn>definitionArc</usedOn>
</arcroleType>	
2.8.1.1	An explicit dimension item must not be the source of more than one dimension-domain relationship in a given base set.
A validator must signal xdte:DimensionDomainMultipleDomains if this rule is violated.
2.8.2	Arc role http://xbrl.org/dim/role/domain-member
A domain-member relationship binds a dimension to a domain.  The purpose of this relationship is to create sets of explicit dimension members. 
The base set of a domain-member relationship may have any kind of cycles.
A validator must signal xdte:DomainMemberSourceError if the source of the relationship is not in the substitution group of xbrli:item.
A validator must signal xdte:DomainMemberTargetError if the target of the relationship is not in the substitution group of xbrli:item or is abstract.
This arc role is defined as follows in the LRR:
<arcrole>
<link:arcroleRef 
  xlink:type="simple" 
  arcroleURI="http://xbrl.org/dim/role/domain-member" 
  xlink:href="http://www.xbrl.org/2005/xdt-2005-06-30.xsd#ddomain-member"/>
<status>IWD</status>
<versionDate>2005-07-19</versionDate>
<requirement xml:lang="en">An explicit dimension has one domain.
</requirement>
<versionOfXBRL>2.1</versionOfXBRL>
<minimumEditionDate>2004-11-14</minimumEditionDate>
<impactsTaxonomyValidation>true</impactsTaxonomyValidation>
<impactsInstanceValidation>true</impactsInstanceValidation>
<conformanceSuiteURI>http://www.xbrl.org/conf/dim/tests.xml</conformanceSuiteURI>
<validation xml:lang="en">The presence of a domain-member arc role indicates how part of a context is to be validated.
</validation>
  <attributes/>
<sourceAbstract>optional</sourceAbstract>
<targetAbstract>prohibited</targetAbstract>
</arcrole>	
It is declared as follows:
<arcroleType 
  id="domain-member" 
  cyclesAllowed="none" 
  arcroleURI="http://xbrl.org/dim/role/domain-member">
  <definition>Source (a domain) contains the target (a member).
  </definition>
  <usedOn>definitionArc</usedOn>
</arcroleType>	
2.8.3	Element Member
The xdt:Member element is a simple-type link whose content is a member of the domain of the dimension to which its xlink:href attribute refers.
<element name="Member">
<annotation><documentation xml:lang="en"> A simple-type link containing the QName of an item that is a member of an explicit dimension.</documentation></annotation>
  <complexType>
    <simpleContent>
      <extension base="QName">
        <attributeGroup ref="xdi:dimAttributes"/>
      </extension>
    </simpleContent>
  </complexType>
</element>	
A validator must signal xdie:MemberNotExplicitDimension if the content of the xlink:href attribute resolves (with xml:base) to anything other than an abstract numeric item definition that is either the source of a dimension-domain relationship or the target of a has-dimension arc.
2.8.4	Validation of contexts with respect to an explicit dimension
A segment or scenario element in an XBRL instance is valid in a DRS with respect to an explicit dimension if the dimension appears in the relevant descendant element named by the elt attribute of the has-dimension arc and the content of the xdt:Member element is a member of the domain of the dimension.
Example 16.  A context that is valid with respect to a hypercube with two explicit dimensions
	
<context id="c90">
  <entity>
    <identifier scheme="http://nic.net>example.com</identifier>
      <segment>
        <xdi:Member xlink:type="simple"
		     xlink:href="t‑company.xsd#t_SalesRegion"      
         >d:AllRegions</xdi:Member>
        <xdi:Member xlink:type="simple"
		     xlink:href="t-company.xsd#t_Product"
	  >d:RedWine</xdi:Member>
      </segment>
    </entity>
    <period><forever></period>
  </context>	
2.9	Validation of facts
An item in an instance must have a context and a measure.  That measure may have a set of hypercubes, relationships to them (any, all, or choice, possibly negated), and for each of those relationships must have a DRS.
Whether the item appears inside a tuple has no relevance to whether its measure and context are valid with respect to dimensional relationships.
Figure 3 shows the signals that a validator must raise depending on what the measure‑hypercube relationship is, whether the relationship is negated, what the dimension type is, and what caused the validation failure.
Figure 3.  Errors signalled by a validator when fact context is not valid with respect to the DRS of the hypercubes of its measure
Op	Polarity	Dim Type	Result	Error	
All	True	Implicit	Reference not found in segment (scenario)	xdie: ImplicitDimNotInSegment
(xdie: ImplicitDimNotInScenario)	
All	True	Implicit	invalid	xdie:ImplicitDimInvalidContent	
All	True	Explicit	xdi:Member not found in segment (scenario)	xdie:ExplicitDimNotInSegment
(xdie:ExplicitDimNotInScenario)	
All	True	Explicit	QName is not an item	xdie:ExplicitDimDomainInvalidContent	
All	True	Explicit	MemRef not found in domain	xdie:ExplicitDimDomainMemberNotFound	
All	False	Implicit	Reference found in segment (scenario)	xdie:ForbiddenImplicitDimInSegment
(xdie:ForbiddenImplicitDimInScenario)	
All	False	Explicit	xdi:Member found in segment (scenario)	xdie:ExplicitDimDomainMemberNotFound	
All	True	*	Reference not found in segment (scenario)	xdie:NoAllowedDimsPresentInSegment
(xdie:NoAllowedDimsPresentInScenario	
All	False	*	All references are found in segments and scenarios	xdie:AllDisallowedDimsPresent	
All	True	*	No references are found	xdie:NoneOfExclusiveDimsPresent	
Choice	True	*	More than one reference is found	xdie:MultipleExclusiveDimsPresent	
Choice	False	*	*	xdie:NotAllDimensionsCoincident	
The introduction of any, choice, and negation relationships weaken the specificity of the errors that can be raised.  These would typically fail validation depending only on whether dimension references were present at all; validity of the content would be a secondary consideration.
2.10	Domain-member relations and inheritance
A measure may be the source of a domain‑member relationship.  When a measure is the source of both a domain‑member relationship and a measure‑hypercube relationship, and the target of the domain‑member relationship is not the source of any measure‑hypercube relationships, the target of the domain‑member arc is said to inherit the measure-hypercube relationship.  Inheritance is transitive.  Inheritance preserves the base set and DRS of the original measure‑hypercube relationship.
Example 17 shows a simple example in which two measures have a common ancestor from which they inherit an all relation to a hypercube.
Example 17.  Two measures inheriting a hypercube
	Measures Sales and CostOfGoods are not the source of any measure-hypercube arc; they inherit the hypercube hcRegion_x_Product from the measure GrossProfit.	
Example 18.  Facts not valid because they violate their hypercube constraints
<GrossProfit contextRef="c92" unitRef="eur" decimals="INF"/>  
<CostOfGoods contextRef="c92" unitRef="eur" decimals="INF"/>  
<Sales contextRef="c92" unitRef="eur" decimals="INF"/>  

<context id="c92">
  <entity>
    <identifier scheme="http://nic.net>example.com</identifier>
      <segment>
        <xdi:Member xlink:type="simple"
		     xlink:href="t company.xsd#t_SalesRegion"      
         >r:Barbados</xdi:Member>
        <xdi:Member xlink:type="simple"
		     xlink:href="t-company.xsd#t_Product"
	  >p:RedWine</xdi:Member>
      </segment>
    </entity>
    <period><forever></period>
  </context>	r:Barbados is not a domain member in SalesRegion; hence the constraint is violated by all three facts even though only GrossProfit had an explicit “all” arc to hcRegion_x_Product.	

A measure having no measure‑hypercube relationships of its own may inherit any number of measure‑hypercube relationships, from any number of distinct base sets.  
If the resulting set of inherited measure-hypercube relationships would violate any of the syntax rules 0, 2.5.1.2, 0, 2.5.2.2, 2.5.3.1, or 2.5.3.2 above, then a validating processor must detect this and signal the same errors as specified for those rules.
The impact of the measure‑hypercube relationships on instance validation is unchanged merely because the relationships have been inherited.
2.11	Element declarations and linkbase syntax
Implicit dimensions, explicit dimensions, domains and hypercubes are all represented using elements in the substitution group of xbrli:item.  These elements which are the targets of measure-hypercube, domain-member, has-dimension, and dimension-domain relationships are collectively called dimensional elements as defined in section 1.3 above.
2.11.1.1	There must be exactly one standard label of a dimensional element for any given language and base set in the schema-rooted DTS of the schema where the element is defined.
A validator must signal xdte:NoStandardLabel if a dimensional element has no standard label in any language in the schema-rooted DTS of the schema where the element is defined.
A validator must signal xdte:TooManyStandardLabels if there is a language and base set for which a dimensional element has more than one standard label in the schema-rooted DTS of the schema where the element is defined.
There may be any number of standard labels of a dimensional element in the base set in the schema-rooted DTS of the schema where the element is defined.  Dimensional elements may have multiple labels, but they must either be in different base sets or have different values of the xml:lang attribute.  Therefore, extension taxonomies may provide multiple labels even with the same value of the xml:lang attribute.
3	Aggregators
The summation-item relationship of the calculation linkbase has no special meaning when its source and target elements are dimensional elements.  Calculations that bind and detect inconsistencies using the summation-item relationship do so irregardless of whether the facts in question appear in domain‑member relationships and irregardless of whether the fact contexts have references to domain members.  Because expansion of the meaning of the summation‑item relationship, and consequent change in the behaviour of validating processors would imply a change to the underlying specification, thus violating P5 (Priority, Appendix B), summation is defined instead in dimensional taxonomies using a new calculationArc arc role, aggregator‑contributor.
Summation in dimensional taxonomies is performed by projecting the aggregator-contributor relationship (within a base set) onto contexts, and thence onto facts, where inconsistencies may be detected via “cross context calculation”.
The relationship aggregator-contributor is an polymorphic binary relationship defined over pairs of domain members, pairs of contexts, and pairs of facts.  The relationship aggregator‑contributors is a polymorphic binary relationship defined over a domain member and set of members, a context and a set of context, and a fact and set of facts.
The source of the aggregator-contributor relationship is said to be an aggregator of the target, which is its contributor.  If the relationships are in the same base set then the set of contributing sources are the contributors.
When two contexts are identical except that one has the QName of an aggregator as the content of an xdi:Member element and the other has the QName of a contributor in its corresponding xdi:Member element, then that context is said to be an aggregator of the other context, which is its contributor.  All contexts for which their QName was among the contributors are the contributors of the aggregator.
When two p‑equal, u-equal (section 4.10 [XBRL]) facts in an instance have the same element name and the context of one is an aggregator of the context of the other, then the fact is said to be an aggregator of the other.  The facts whose contexts were contributors are contributors of the aggregator.
Example 19 below shows two aggregator-contributor relationships that can be derived from a valid set of facts, contexts, and aggregator-contributor relationship in a dimensional taxonomy; the Sales value in SouthAmerica is an aggregator of the Sales value in Argentina, when all other aspects of the context are held equal.
Example 19.  Aggregator-Contributor relationship
	
A fact that is the aggregator of one or more contributing facts must have a numeric value that is consistent with the sum of the numeric values.  The value is defined to be consistent if the rounded value of the summation item is equal to the total of the contributing values rounded to the precision or inferred precision of the aggregator.
Validating processors may signal xdie:InconsistentAggregation upon detecting an inconsistency thus defined.
Contexts are not aggregators of, and are not contributors to, contexts that differ along more than one dimension.
Inconsistency in calculations does not impact instance validation.  Therefore there is no impact on instance validation.
Duplicate facts within a set of contributors render the aggregator consistent.
Aggregator-contributor relationships cannot be defined for implicit dimensions.
3.1.1	Arc role http://xbrl.org/int/dim/arcrole/aggregator-contributor
A validator must signal xdte:AggregatorContributorCycleError if there is a directed or undirected cycle of aggregator‑contributor relationships in any base set.
A validator must signal xdte:AggregatorContributorSourceError if the source of the relationship is an abstract element or is not in the substitution group of xbrli:item.
A validator must signal xdte:AggregatorContributorTargetError if the target of the relationship is an abstract element or is not in the substitution group of xbrli:item.
This arc role is defined as follows in the LRR:
<arcrole>
<link:arcroleRef 
  xlink:type="simple" 
  arcroleURI="http://xbrl.org/int/dim/arcrole/aggregator-contributor" 
  xlink:href="http://www.xbrl.org/2005/xdt-2005-06-30.xsd#aggregator-contributor"/>
<status>IWD</status>
<versionDate>2005-07-19</versionDate>
<requirement xml:lang="en">Calculations may aggregate across contexts.
</requirement>
<versionOfXBRL>2.1</versionOfXBRL>
<minimumEditionDate>2004-11-14</minimumEditionDate>
<impactsTaxonomyValidation>true</impactsTaxonomyValidation>
<impactsInstanceValidation>true</impactsInstanceValidation>
<conformanceSuiteURI>http://www.xbrl.org/conf/dim/tests.xml</conformanceSuiteURI>
<validation xml:lang="en">The presence of an aggregator-contributor arc may be used to signal a calculation inconsistency.
</validation>
  <attributes/>
<sourceAbstract>prohibited</sourceAbstract>
<targetAbstract>prohibited</targetAbstract>
</arcrole>	
It is declared as follows:
<arcroleType 
  id="aggregator-contributor" 
  cyclesAllowed="none" 
  arcroleURI="http://xbrl.org/int/dim/arcrole/aggregator-contributor">
  <definition>Source (a member) is the aggregator of the target (a member).
  </definition>
  <usedOn>definitionArc</usedOn>
</arcroleType>	
A	
A	Errors (normative)
Validating Taxonomies
Taxonomy Error	Meaning	Ref.	
xdte:DimensionURIError	The dimensionURI attribute appears on an element definition that is not an abstract item.	2.3.1.1	
xdte:ImplicitDimensionError	The dimensionURI attribute does not locate an implicit dimension.	2.3.1.2	
xdte:DuplicateImplicitDimension	More than one dimensionURI attribute references an implicit dimension.	2.3.1.3	
xdte:HasDimensionDirectedCycle	There is a directed cycle in a base set of has‑dimension arcs.	2.4.1	
xdte:HasDimensionSourceError	The source of the has-dimension arc is not the correct type.	2.4.1	
xdte:HasDimensionTargetError	The target of the has-dimension arc is not the correct type.	2.4.1	
xdte:RepeatedDimensionInHypercube	The hypercube has a dimension repeated.	2.4.1.1	
xdte:MeasureHypercubeSourceError	The source of an all, any or choice arc is not the correct type.	2.5.1
2.5.2
2.5.3	
xdte:MeasureHypercubeTargetError	The target of an all, any or choice arc is not the correct type.	2.5.1
2.5.2
2.5.3	
xdte:MeasureHypercubeOperatorInconsistency	Not all of the measure-hypercube arcs with the same source have the same operator (any, all, choice).	0 2.5.1.2 0 2.5.2.2 2.5.3.1 2.5.3.2	
xdte:DimensionDomainDirectedCycle	There is a directed cycle in a base set of dimension-domain arcs.	2.8.1	
xdte:DimensionDomainSourceError	The source of a dimension-domain arc is not the correct type.	2.8.1	
xdte:DimensionDomainTargetError	The target of a dimension-domain arc is not the correct type.	2.8.1	
xdte:DimensionDomainMultipleDomains	A single dimension has more than one domain.	0	
xdte:DomainMemberSourceError	The source of a domain-member arc is not the correct type.	2.8.2	
xdte:DomainMemberTargetError	The target of a domain-member arc is not the correct type.	2.8.2	
xdte:NoStandardLabel	The dimensional element does not have a standard label in any language.	2.11.1.1	
xdte:TooManyStandardLabels	The dimensional element has more than one standard label of in a language in a base set.	2.11.1.1	
xdte:AggregatorContributorCycleError	There is a cycle in an aggregator‑contributor base set.	3.1.1	
xdte:AggregatorContributorSourceError	The source of an aggregator‑contributor arc is not the correct type.	3.1.1	
xdte:AggregatorContributorTargetError	The target of an aggregator‑contributor arc is not the correct type.	3.1.1	
Validating Instances
Instance Error	Meaning	Ref.	
xdie:MemberNotExplicitDimension	The Member element does not refer to an explicit dimension.	0	
xdie:ImplicitDimNotInSegment	Figure 3	2.9	
xdie:ImplicitDimNotInScenario	Figure 3	2.9	
xdie:ImplicitDimInvalidContent	Figure 3	2.9	
xdie:ExplicitDimNotInSegment	Figure 3	2.9	
xdie:ExplicitDimNotInScenario	Figure 3	2.9	
xdie:ExplicitDimDomainInvalidContent	Figure 3	2.9	
xdie:ExplicitDimDomainMemberNotFound	Figure 3	2.9	
xdie:ForbiddenImplicitDimInSegment	Figure 3	2.9	
xdie:ForbiddenImplicitDimInScenario	Figure 3	2.9	
xdie:ForbiddenExplicitDimInSegment	Figure 3	2.9	
xdie:ForbiddenExplicitDimInScenario	Figure 3	2.9	
xdie:NoAllowedDimsPresentAndValid	Figure 3	2.9	
xdie:AllDisallowedDimsPresent	Figure 3	2.9	
xdie:MultipleExclusiveDimslPresent	Figure 3	2.9	
xdie:NoneOfExclusiveDimsPresent	Figure 3	2.9	
xdie:NotAllDimensionsCoincident	Figure 3	2.9	
xdie:InconsistentAggregation	There is a calculation inconsistency between an aggregator and its contributors. 	3	

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 measures 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.3, Implicit dimensions; Section 2.8, Explicit dimensions; Section 2.10, Domain-member relations and inheritance; use of arc roles all, any, choice, has‑dimension, dimension‑domain, domain‑member arc roles.	
P3	Simplicity: The solution MUST NOT include features for which there is no documented need.	Satisfied.  No nested hypercubes, as explained in section 2.5.4, “Negation of the measure-hypercube arcs.”	
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.6, “Discoverable relationship sets.”  Association of implicit dimension items and dimensional elements has a unidirectional reference, section 2.3.1, “Attribute dimensionURI”.	
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.3.1, “Attribute dimensionURI”.	
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.2.1.1; Section 2.5, “Measures and Hypercubes;” and Section 2.9, “Validation of facts.”	
G02	One context may have multiple Dimensions.  The Dimensions may be implicit or explicit.	Satisfied.  Rule 2.2.1.1; Section 2.4, “Hypercubes.”	
G03	Taxonomy authors must be able to name Implicit Dimensions.	Satisfied.  Section 2.3, “Implicit 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.3, “Implicit dimensions.”	
G05	Taxonomy authors MUST be able to extend or restrict the members of Implicit Dimensions of a base taxonomy.	Satisfied. Section 2.3, “Implicit 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.8, “Explicit dimensions.”	
G07	Taxonomy authors must be able to define a suggested presentation ordering relation on Explicit Dimension Members.	Satisfied.  Section 2.8, “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.8, “Explicit dimensions;” explicit dimension members are non-abstract items that may have labels; rule 2.11.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.8.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.8, “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.5, “Measures and Hypercubes” and Section 2.9, “Validation of facts.”	
G12	Taxonomy authors must be able to use the same Explicit Dimension Members in any number of Explicit Dimensions.	Satisfied.  Sections 2.8.1 and 2.8.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 3, “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 3, “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 measure taxonomy, such as summation‑item relationships, are not used in dimensional taxonomies, guaranteeing separation.	
G17	The specification should minimise the number of elements required to express constraints on combinations of Concepts and Dimension Members. 	Satisfied.  Section 2.5, “Measures and Hypercubes” allows a minimum of one element per hypercube; section 2.6, “Discoverable relationship sets” allows a set of dimension or domain relationships to be used by any number of hypercubes or measures.	
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 the 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 Draft Candidate Recommendation 3	
	XBRL-LRR-CR3-2005-07-14.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-04-25	
	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/	
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.
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/ 
xdt-2005-06-30.xsd (normative)
<?xml version="1.0" encoding="US-ASCII"?>
<!-- (c) 2005 XBRL International. All Rights Reserved. http://www.XBRL.org/legal/ 
     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:xdt="http://xbrl.org/int/dim/xdt/2005-06-30" targetNamespace="http://xbrl.org/int/dim/xdt/2005-06-30" 
elementFormDefault="qualified" 
attributeFormDefault="unqualified">
  <xs:annotation>
    <xs:appinfo>
      <arcroleType arcroleURI="http://xbrl.org/int/dim/arcrole/has-dimension" cyclesAllowed="none" id="has-dimension">
        <definition>Source (a hypercube) contains the target (a dimension) among others.</definition>
        <usedOn>definitionArc</usedOn>
      </arcroleType>
      <arcroleType arcroleURI="http://xbrl.org/int/dim/arcrole/dimension-domain" cyclesAllowed="none" id="dimension-domain">
        <definition>Source (a dimension) has only the target (a domain) as its domain.</definition>
        <usedOn>definitionArc</usedOn>
      </arcroleType>
      <arcroleType arcroleURI="http://xbrl.org/int/dim/arcrole/domain-member" cyclesAllowed="none" id="domain-member">
        <definition>Source (a domain) contains the target (a member).</definition>
        <usedOn>definitionArc</usedOn>
      </arcroleType>
      <arcroleType arcroleURI="http://xbrl.org/int/dim/arcrole/aggregator-contributor" cyclesAllowed="none" id="aggregator-contributor">
        <definition>Source (a member) is the aggregator of the target (a member).</definition>
        <usedOn>definitionArc</usedOn>
      </arcroleType>
      <arcroleType arcroleURI="http://xbrl.org/int/dim/arcrole/any" cyclesAllowed="none" id="any">
        <definition>Source (a measure) allows the target (hypercube) as one of a set of inclusive alternatives.</definition>
        <usedOn>definitionArc</usedOn>
      </arcroleType>
      <arcroleType arcroleURI="http://xbrl.org/int/dim/arcrole/all" cyclesAllowed="none" id="all">
        <definition>Source (a measure) requires the target (hypercube) to appear in the context of the measure.</definition>
        <usedOn>definitionArc</usedOn>
      </arcroleType>
      <arcroleType arcroleURI="http://xbrl.org/int/dim/arcrole/choice" cyclesAllowed="none" id="choice">
        <definition>Source (a measure) allows the target (hypercube) as one of a set of mutually exclusive alternatives.</definition>
        <usedOn>definitionArc</usedOn>
      </arcroleType>
      <arcroleType arcroleURI="http://xbrl.org/int/dim/arcrole/closed" cyclesAllowed="any" id="closed">
        <definition>Source (a hypercube) does not allow additional elements in the segment or scenario of the context.</definition>
        <usedOn>definitionArc</usedOn>
      </arcroleType>
    </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="eltType">
    <xs:restriction base="xs:token">
      <xs:enumeration value="segment"/>
      <xs:enumeration value="scenario"/>
    </xs:restriction>
</xs:simpleType>
  <xs:attribute name="elt" type="xdt:eltType"/>
<xs:attribute name="dimensionURI" type="xs:anyURI"/>
  <xs:attribute name="closed" type="xs:boolean" default="false"/>
  <xs:attribute name="polarity" type="xs:boolean" default="true"/>
  <xs:attribute name="targetRole" type="xs:anyURI"/>
</xs:schema>
xdi-2005-06-30.xsd (normative)
<?xml version="1.0" encoding="US-ASCII"?>
<!-- (c) 2005 XBRL International. All Rights Reserved. http://www.XBRL.org/legal/ 
     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:xdi="http://xbrl.org/2005/xdi" 
targetNamespace="http://xbrl.org/2005/xdi" 
elementFormDefault="qualified" 
attributeFormDefault="unqualified">
  <annotation>
    <appinfo>
      <documentation xml:lang="en">This schema is used by XBRL instances that use dimensions to define legal segment and scenario element contents.</documentation>
    </appinfo>
  </annotation>
  <import namespace="http://www.w3.org/1999/xlink" schemaLocation="http://www.xbrl.org/2003/xlink-2003-12-31.xsd"/>
  <attributeGroup name="dimAttributes">
    <attributeGroup ref="xlink:simpleType"/>
    <attribute ref="xlink:href" use="required"/>
    <attribute ref="xlink:arcrole" use="optional"/>
    <attribute ref="xlink:role" use="optional"/>
    <attribute ref="xlink:title" use="optional"/>
    <attribute ref="xlink:show" use="optional"/>
    <attribute ref="xlink:actuate" use="optional"/>
    <anyAttribute namespace="##targetNamespace" processContents="lax"/>
  </attributeGroup>
  <element name="Member">
    <annotation>
      <documentation xml:lang="en">A simple-type link containing the QName of an item that is a member of an explicit dimension.
      </documentation>
    </annotation>
    <complexType>
      <simpleContent>
        <extension base="QName">
          <attributeGroup ref="xdi:dimAttributes"/>
        </extension>
      </simpleContent>
    </complexType>
  </element>
</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	
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		
5	Candidate Recommendation	ISC	Approve for Stage 6	Restart Stage 4		
6	Recommendation	SWG	Recommend for Stage 7	Restart Stage 4		
7	Recommendation	ISC	Publication	Restart stage 4