Copyright © 2014 XBRL International Inc., All Rights Reserved.
1 Introduction
2 In-scope requirements
2.1 Extensibility
2.2 Labeling and internationalisation
2.3 Domain member re-use
2.4 Enumeration value hierarchy and non-reportable items
3 Other requirements considered
3.1 Multi-valued enumerations
4 Use cases
4.1 Geographic regions as a dimension and a fact value
4.2 Stock exchange market classification
A Intellectual property status (non-normative)
B Acknowledgements (non-normative)
C Document history
D Errata corrections in this document
XBRL taxonomies define concepts using XML Schema element declarations. This allows concepts to make use of the XML Schema data type system, which includes the ability to define elements which take as their value one of an enumerated set of values. This is useful functionality, but it is not without limitations. This document describes a number of requirements for a more flexible enumeration system.
The following requirements are considered in-scope for an initial specification effort.
A key benefit of XBRL is the ability to extend taxonomies. This allows third
parties to take a published taxonomy, and make certain changes to it. This is
typically done either by preparers, seeking to customise a taxonomy to meet their
specific reporting requirements, or by a regulator that is making use of a
taxonomy that is defined by a central authority such as an accounting standards
body. In either scenario, it may be desirable to modify the list of values
allowed by an enumeration concept. The only provision for enumerated concepts
in XBRL is declaration of a concept using XML Schema's
xs:enumeration feature but as an element's data type cannot be
redefined by another schema, modification of the list of allowed values by an
extension taxonomy is not possible, other than by defining an entirely new
concept.
XBRL allows multi-language labels to be provided for almost all taxonomy components, allowing the same data definitions to be viewed in different languages. The values of an enumerated data type are an exception to this, as there is no mechanism for providing any label at all for the allowed value. This means that end users of a taxonomy are necessarily exposed to the "raw" values that are to be used in the instance document. These are typically terse identifiers, rather than labels designed for human consumption, and can only be provided in a single language.
XBRL provides related functionality to enumerations in the form of explicit dimensions. Explicit dimensions allow preparers to tag a fact with a dimension that takes a value from an enumerated list of domain members. In some cases, it is desirable to re-use the set of values that form allowed set of values for a dimension as the set of allowed values for a concept. Currently the only approach is to redefine the set of values as an enumerated data-type. This leads to a duplication of definitions, as well as losing the labeling and extensibility capabilites of a domain member tree.
For any non-trivial list of enumerated values, it may be useful to arrange the values into a tree for ease of presentation. Doing so may result in the introduction of addition nodes that are purely to give structure to the tree, and which are not intended to be used as reported values.
The Working Group has considered the following additional requirements, but does not plan to address them in the initial release of the specification.
In some cases, it is desirable to allow a fact to select multiple values from
a list of enumerated values. This is currently possible for XML Schema-based
enumerations using an xs:list of an enumerated data type.
This requirement was uncovered relatively late during the development process of the specification development process. The Working Group believes that the specification will meet most use cases without addressing this requirement, and that this requirement can be easily met through an extension or update to the specification, and as such, should be left out of scope for the initial release of this specification.
A taxonomy may define an explicit domain member tree in order to represent regions. This could be used as a dimensional qualification to provide a breakdown of information by region. For example a "Revenue" concept may be qualified by a "Region" dimension in order to provide a breakdown of revenue by region.
It may also be desirable to use this same regional breakdown as a fact value. For example, there may be a requirement to report the region of the filer's head office ( Section 2.3).
The regional breakdowns defined in the taxonomy may not match those used by the filer. In this case, the filer may need to modify the breakdown using an extension taxonomy. It is desirable that such modifications are also available when using the breakdown as a fact value ( Section 2.1).
In the case of international taxonomies, translations of concept names are typically provided using XBRL's mechanisms for multi-language labels. It would be desirable to provide localised translations of the regions used for fact values ( Section 2.2).
A listed company may be required to report the names of all of the markets within all stock exchanges on which they are listed. For example, a company may be listed on the "PROMarket" market of the Tokyo Stock Exchange, and the "Centrex" market of the Nagoya Stock Exchange. This gives rise to a requirement to allow reporting of multiple values from a single enumeration ( Section 3.1).
The classification is naturally modelled as a tree, with the different markets of a given stock exchange grouped under a parent representing the stock exchange itself. Filers are required to report the individual markets, and not the stock exchange itself. This requires the ability to flag individual nodes as "not-reportable", as they are there purely to provide groupings of other items ( Section 2.4).
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).
This document could not have been written without the contributions of many people.
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 Base Specification and Maintenance Working Group up to and including 26 March 2014. 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.
No errata have been incorporated into this document.