Dimensional Taxonomies Requirements
Public Working Draft dated 2005-06-21
This version:
	DIM-REQ-PWD-2005-06-21.rtf

is normative. All other versions and formats are non-normative.
Author
Ignacio Hernández-Ros	ihr@xbrl.org	XBRL International	
Contributors
Walter Hamscher	walter@hamscher.com	Standard Advantage / PricewaterhouseCoopers	
David vun Kannon	dvunkannon@kpmg.com	KPMG LLP	
Hugh Wallis	hugh@xbrl.org	XBRL International	
Abstract
This document describes the business requirements for 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.
Status
Circulation of this Public Working Draft is unlimited  It was approved for publication by the International Steering Committee on 2005-06-21. Recipients of this draft are invited to submit comments to the editors and authors, and to submit notification of any relevant patent rights of which they are aware and to provide supporting documentation.

Table of Contents
1.	Terminology and Formatting
2.	Design Principles
3.	Functional Requirements
4.	Technical requirements
A.	References (non-normative)
B.	Intellectual Property Status (non-normative)
C.	Acknowledgements (non-normative)
D.	Document History (non-normative)
E.	Errata corrections incorporated in this document
F.	Approval process (non‑normative)

1.	Terminology and Formatting
Terminology used in XBRL frequently overlaps with terminology from other fields.  The terminology used in this document is summarised in Table 1.
Table 1
abstract element, bind, concept, concrete element, context, Discoverable Taxonomy Set (DTS), duplicate items, duplicate tuples, element, entity, equal, essence concept, fact, instance, item, least common ancestor, linkbase, period, taxonomy, tuple, unit, taxonomy schema, child, parent, sibling, grandparent, uncle, ancestor, XBRL instance, c-equal, p-equal, s-equal, u-equal, v-equal, x-equal, minimally conforming XBRL processor, fully conforming XBRL processor.	As defined in [XBRL].	
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	
Conforming documents and consuming applications are required to behave as described; otherwise they are in error.	

Dimension	Each one of the different aspects by which a fact may be characterised. A dimension is a (possibly empty or possibly infinite) set of members. A typical example of a dimension is the “product” dimension that identifies for a concept (Sales) each one of the possible products that its fact can be expressed about.	
Dimension Member	Each one of the possibilities we can choose from the whole Dimension set.
Example: In the “Products Dimension” each one of the products is a Dimension Member.	
Explicit Dimension	Occurs when all the members are named.	
Implicit Dimension	Occurs when the members are unknown or when the number of members is impractically large to enumerate explicitly.	
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 XBRL fact whose context contains dimensions.	
The following highlighting is used for non-normative examples in this document:
	
Non-normative editorial comments to be removed from final recommendations are denoted as follows:
IHR: This highlighting indicates editorial comments about the current draft, prefixed by the editor’s initials.
Italics are used for rhetorical emphasis only and do not convey any special normative meaning.
2.	Design Principles
Id	Principle	Meaning 	
P1	Flexibility	The solution must be applicable to multiple environments in which dimensions are a good solution, such as:
Internal Reporting
XBRL-GL Taxonomy
Regulator-specific reporting. 	
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.	
P3	Simplicity	The solution must not include features for which there is no documented need.	
P4	Irredundancy	The solution should not require instances, schemas or linkbases to encode the same information in multiple places.	
P5	Priority	An implementation of these requirements must not violate the most current edition of the XBRL 2.1 specification.	
3.	Functional Requirements
Id	Text	
G01	Instance authors must be able to create contexts with Dimensions. Taxonomy authors must be able to define the valid combinations of Dimensions that may or must occur in the contexts of the facts of any concept.  Instances with facts or contexts violating the validity constraints are invalid. 
Example: A taxonomy requires that the context of every Sales fact must have a product and region dimension and may have others.
Example: A taxonomy requires that the context of every Asset fact must have a region dimension but no other dimensions.	

IHR: Required by COREP.  Validation is not yet implemented.	
G02	One context may have multiple Dimensions.  The Dimensions may be implicit or explicit.
Example: Context is “Fiscal 2005 for Example.com” 
Dimension1: Country 
Dimension2: Product
Dimension3: Customer Code	

G03	Taxonomy authors must be able to name Implicit Dimensions.
Example: Having the “Client Code” as a dimension for contexts of “Sales” facts when the list of clients has one million members.
IHR: COREP requirement.	
G04	Taxonomy authors must be able to name Implicit Dimensions and define constraints on valid members, while allowing instance authors to enumerate the members.
Example: Taxonomy author defines the concepts “Sales” and “Number of clients” and the Dimension “client segmentation” with qualifiers to the dimension is “lower bound revenue” and “upper bound revenue”.  The Instance author defines three Dimension Members with the lower bounds and upper bounds shown in the table below.	

Lower bound	
Upper bound	
Nº of clients	
Sales	

0€	
1,000€	
1,000	
100,000€	

1,001€	
100,000€	
10	
1,000,000€	

100,001€	
Infinity	
4	
10,000,000€	

IHR: COREP requirement, implementation is not satisfactory.
WcH: Could be implemented in most cases using Schema structures.	
G05	Taxonomy authors must be able to extend or restrict the members of Implicit Dimensions of a base taxonomy.
WcH: COREP requirement.  Could be implemented in most situations using Schema constructs, particularly substitution groups.	
G06	Taxonomy authors must be able to define Explicit Dimensions.   An Explicit Dimension has a discrete list of valid Explicit Dimension Members.
WcH: COREP Requirement.  Implemented via dimension-member.	
G07	Taxonomy authors must be able to define a suggested presentation ordering relation on Explicit Dimension Members.
WcH: COREP Requirement.  Implemented via order attribute on definition arcs.	
G08	Taxonomy authors must be able to define suggested labels to be associated with Explicit Dimension Members in different situations and in different languages.
WcH: COREP Requirement.  Implemented via label linkbases.	
G09	Taxonomy authors must be able to define an inclusion relationship on Dimension Members.  The inclusion relationship must be transitive, irreflexive, and antisymmetric.  Dimensions that violate the inclusion relationship constraints are invalid.
Examples: 
World1
America Continent 
Asia Continent 
Africa Continent 
Europe Continent 
France Country
UK Country
… 25 Countries
… 7 continents 
	
World2
EMEA
…
APAC
…
OTHER	

IHR: COREP Requirement.  Implemented as ‘dimension-member’ arcs.	
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.
WcH: COREP requirement.  Implemented in COREP.	
G11	Taxonomy authors must be able to define Dimension Member combinations among Explicit Dimensions that are valid or invalid in contexts of specific concepts.
Example: The product Hot Pepsi cannot be sold in Spain.  For any fact of the concept “Sales” the combination of Dimension member “Hot Pepsi” in the Products Dimension and Dimension member “Spain” in the Locations dimension is invalid.	

IHR: COREP requirement.  Not properly implemented yet.	
G12	Taxonomy authors must be able to use the same Explicit Dimension Members in any number of Explicit Dimensions.  Instance authors must distinguish which Explicit Dimension the Dimension Member is being used in a given context.
Example: Members of the “Country” Dimension are members of the “Country of Sales” and “Country of Support” Dimensions.	

IHR: Requirement of COREP.   Implemented in the taxonomies.	
G13	Taxonomy authors must be able to define summations over Explicit Dimension Members. 
The summation relationship is irreflexive, intransitive and antisymmetric.  Dimensions that violate this constraint are invalid.
 All facts of the same concept and whose contexts differ only in an Explicit Dimension (where Dimension Members have summations defined) may bind for calculation.  Instance validators must detect calculation inconsistencies thus defined. 
Example:  Iberia is the sum of Spain and Portugal with respect to the Sales concept.  The following set of facts in an instance would be inconsistent.
Concept	
Content	
Unit	
Context	
Dimension Member	

Sales	
400	
EUR	
C1	
Iberia	

Sales	
400	
EUR	
C2	
Spain	

Sales	
200	
EUR	
C3	
Portugal	

WcH:  The definition here is meant to be a minimal extension of the summation‑item relationship, in the sense that if there are summation‑item arcs from Iberia to Spain and from Iberia to Portugal, then the relationships are projected onto the ‘Sales’ concept as if there were a single context with facts of three concepts Sales[country=Iberia], Sales[country=Spain] and Sales[country=Portugal].
Example:  Iberia is the sum of Spain and Portugal with respect to the Sales concept.  The following set of facts in an instance would be inconsistent.
Concept	
Content	
Unit	
Context	
Dimension Member	
Dimension Member	

Sales	
400	
EUR	
C1	
Iberia	
Forecast	

Sales	
400	
EUR	
C2	
Spain	
Forecast	

Sales	
200	
EUR	
C3	
Portugal	
Forecast	

Detection of inconsistencies in summations over multiple dimensions is not required.
Example:  Iberia is the sum of Spain and Portugal with respect to the Sales concept.  The following set of facts in an instance is consistent.
Concept	
Content	
Unit	
Context	
Dimension Member	
Dimension Member	

Sales	
600	
EUR	
C1	
Iberia	
Forecast	

Sales	
400	
EUR	
C2	
Spain	
Forecast	

Sales	
200	
EUR	
C3	
Portugal	
Actual	

IHR: Requirement of COREP.  Inconsistency detection not implemented.	
G14	Taxonomy authors must be able to limit summations over Explicit Dimension Members to apply only to certain concepts.
Example:  Iberia is the sum of Spain and Portugal, but not with respect to the Volume concept.  The following set of facts in an instance would be consistent.
Concept	
Content	
Unit	
Context	
Dimension Member	

Volume	
400	
EUR	
C1	
Iberia	

Volume	
400	
EUR	
C2	
Spain	

Volume	
200	
EUR	
C3	
Portugal	

IHR: Requirement of COREP.	
G15	Taxonomy authors must be able to define an equivalence relationship on Explicit Dimension Members within the same Explicit Dimension.  The equivalence relationship is transitive, reflexive, and symmetric.  Dimensions that violate this constraint are invalid.
Instances that would be invalid if all Explicit Dimension Members were canonicalised within their equivalence class are invalid.
Instances that would be inconsistent if all Explicit Dimension Members were canonicalised within their equivalence class are invalid.
WcH: This requirement could be eliminated by restructuring relationships in COREP.	
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.
IHR: Required by COREP, and implemented. 	
G17	The specification should minimise the number of elements required to express constraints on combinations of Concepts and Dimension Members. 
IHR: Required by COREP, and implemented via transitivity of inclusion with respect to the “not-allowed” arc role.	
G18	Formula linkbase authors MUST be able to select concepts that are reported in multiple dimensions.	
4.	Technical requirements
T1	The specification must include a conformance suite and the requirement that there be two independent implementations correctly processing that conformance suite.	
A.	References (non-normative)
[COREP]	Common Solvency Ratio Reporting Taxonomy Project 	
	Commission of European Banking Supervisors (http://www.c-ebs.org) 	
	http://www.corep.info 	
		
[RFC2119]	Scott Bradner	
	Key words for use in RFCs to Indicate Requirement Levels, March 1997	
	http://www.ietf.org/rfc/rfc2119.txt	
		
[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/ 	
		
[XF]	Chris Simmons (editor).	
	XBRL Functions 1.0, Internal Working Draft.	
	XF-IWD-2005-04-22.htm 	
B.	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).
C.	Acknowledgements (non-normative)
The participants in the XBRL International Specification Working Group contributed to this document.  The XBRL International Specification Working Group is chaired by Paul Warren (DecisionSoft Ltd.) and vice chaired by Cliff Binstock (UBmatrix).  We also thank the following people for their comments and suggestions: Mark Goodhand (DecisionSoft), Charles Hoffman (UBmatrix). 
D.	Document History (non-normative)
Date	Editor	Summary	
2004-05-01	Hernandez‑Ros	First draft of document prepared.	
2004-05-04	Hernandez‑Ros	Second draft incorporating comments.	
2005-05-05	Hamscher	Editorial and formatting.	
2005-05-18	Hernandez-Ros	Third draft incorporating comments.	
2005-05-19	Hamscher	Reordered the requirements to reflect and distinguish the different types of syntactic and semantic constraints needed; rewrote requirements to define functionality available to different users and requirements of Dimension enabled validators; added requirement for an equivalence relationship; narrowed the scope of the calculation inconsistency detection requirement.	
2005-06-10	Wallis	Editorial to reflect Public Working Draft status	
E.	Errata corrections incorporated in this document
This appendix contains a list of the errata that have been incorporated into this document. This represents all those errata corrections that have been approved by the XBRL International Specification Working Group up to and including 2005-04-25.  Hyperlinks to relevant e-mail threads may only be followed by those who have access to the relevant mailing lists. Access to internal XBRL mailing lists is restricted to members of XBRL International Inc.
Erratum number	Brief description and link(s) to relevant discussion thread(s)	Affected section(s)	Date Correction Approved by the DWG	
There are no errata at this time for this Public Working Draft.
A.	
F.	Approval process (non‑normative)
This section will be removed from the final recommendation.  
WG = XBRL International Specification Working Group; ISC = International Steering Committee.
	Stage
(* - Current)	Party responsible for decision	Decision	Revisions needed	Target date for decision	
1	Internal WD	WG 	Recommend for Stage 2	Stay in Stage 1	2005-05-19	
2	Internal WD pending publication	ISC	Approve for Stage 3	Return to Stage 1	2005-06-21	
3	* Public WD	WD Editors	Minor revisions – to Stage 4	Major revisions, Restart Stage 1	2005-08-05	
4	Draft Candidate Recommendation 	WG	Recommend for Stage 5	Restart Stage 3	2005-08-16	
5	Candidate Recommendation 	ISC	Approve for Stage 6	Restart Stage 4	2005-09-12	
6	Recommendation