Dimensional Taxonomies Requirements
Public Working Draft dated 2005-06-21
DIM-REQ-PWD-2005-06-21.htm
is non-normative. The normative version is that found in
DIM-REQ-PWD-2005-06-21.rtf
|
Ignacio Hernández-Ros |
XBRL International |
Contributors
|
Walter Hamscher |
Standard Advantage / PricewaterhouseCoopers |
|
|
David vun Kannon |
KPMG LLP |
|
|
Hugh Wallis |
XBRL International |
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.
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)
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:
|
||||
|
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.
|
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. |
|
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.
IHR: Required by COREP. Validation is not yet implemented. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
G02 |
One context may have multiple Dimensions. The Dimensions may be implicit or explicit.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
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.
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:
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.
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.
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:
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.
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.
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.
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. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
T1 |
The specification must include a conformance suite and the requirement that there be two independent implementations correctly processing that conformance suite. |
|
[COREP] |
Common Solvency Ratio Reporting Taxonomy Project |
|
|
Commission of European Banking Supervisors (http://www.c-ebs.org) |
|
|
|
|
|
|
|
Scott Bradner |
|
|
|
Key words for use in RFCs to Indicate Requirement Levels, March 1997 |
|
|
|
|
|
|
|
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. |
|
|
|
|
|
|
|
Chris Simmons (editor). |
|
|
|
XBRL Functions 1.0, Internal Working Draft. |
|
|
XF-IWD-2005-04-22.htm |
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).
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).
|
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 |
|
|
|
|
|
|
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.
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 |
|
|
|
|