Copyright ©2009 XBRL International Inc., All Rights Reserved.
Circulation of this Public Working Draft is unrestricted. This document is normative. Other documents may supersede this document. Recipients are invited to submit comments to versioning-feedback@xbrl.org, and to submit notification of any relevant patent rights of which they are aware and provide supporting documentation.
This specification is an extension to the versioning base specification. It specifies how to map and address concept names between two DTS's in a versioning container file.
This specification can only be used in conjuntion with the base module [XVS-Base].
1 Introduction
1.1 Relationship to other work
1.2 Language independence
1.3 Document conventions
1.3.1 Typographic conventions
1.3.1.1 Definition notation
1.3.1.2 Footnote notation
1.3.1.3 Element and attribute notation
1.3.2 Formatting conventions
1.4 Terminology
1.5 Namespaces and namespace prefixes
2 Events and mappings
2.1 Events
2.2 Concept mappings
A Normative schema
B References
C Intellectual property status (non-normative)
D Acknowledgements (non-normative)
E Document history (non-normative)
F Errata corrections in this document
1 Namespaces and namespace prefixes
2 Hierarchical organisation of events
1 A normative example
2 A non-normative example
3 An example of poor usage
Concept information item
DTS information item
Item information item
Tuple information item
business concept
concept-identifier
equivalent concepts
from-identifier
related concepts
rfc2119 terminology
to-identifier
This specification depends upon the XBRL 2.1 Specification [XBRL 2.1] and the base versioning specification [XVS-Base].
The official language of XBRL International's own work products is English and the preferred spelling convention is UK English.
Comments which are informative, but not essential to the understanding of the point at hand, are provided in footnotes. All footnotes are non-normative.
When referring to a specific element, it will be identified by
its namespace prefix and local name. For example, the root
element for a specification container element would be referred to as
<variable:generalVariable>
.
Attributes are also identified by their local name and, where
appropriate, their namespace prefix. Attributes are
distinguished from elements by prefixing them by an
@
symbol. Thus,
@id
refers to the attribute with the name id.
When referring to any attribute, so long as it has a specific
namespace, the local name is replaced by an asterisk (
*).
Thus, the notation
@xml:* specifies any attribute
in the namespace
http://www.w3.org/XML/1998/namespace.
The following highlighting is used for normative technical material in this document:
Text of the normative example.
The following highlighting is used for non-normative examples in this document:
Text of the helpful example.
Next paragraph of the helpful example.
Example 3 shows the formatting for non-normative examples of poor, discouraged or disallowed usage.
The example itself.
This specification depends upon the following XBRL specifications:
In the event of any conflicts between this specification and the specifications upon which it depends, this specification does not prevail.
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, in this specification, are to be interpreted as described in [IETF RFC 2119].
A concept identifier is an identifier for a Concept information item in the F-DTS or the T-DTS.
A from-identifier is an identifier in an event that identifies a versioning information item in the F-DTS.
A to-identifier is an identifier in an event that identifies a versioning information item in the T-DTS.
A business concept is the abstract definition of an individual piece of business information. An XBRL concept [XBRL 2.1] is a concrete instantiation of a business concept. The distinction is relevant to versioning because a single business concept may be represented by different XBRL concepts in different taxonomies. A versioning report can identify such equivalent concepts.
Two concepts are considered to be equivalent concepts when both concepts represent the same business concept. This implies that a fact reported using either concept would be understood by a consumer to represent the same piece of information. The requirements for concept equivalence place no specific constraints on the XBRL representation of the concepts. Equivalent concepts may have different local names, namespaces, labels, references or datatypes. As the two concepts represent a single business concept, the datatypes of the concepts will be expected to have the same value space, allowing all values that are valid for the business concept. In practice, the value spaces may be different. For example, one concept may use a more tightly constrained datatype that more closely matches the values that are valid for the business concept. Further, errors in datatype definition may mean that values that are valid for the business concept may not be valid for one or other concept. This does not prevent the concepts from being equivalent.
Two concepts are considered to be related concepts when there is overlap in the definitions of the underlying business concepts. Unlike equivalent concepts, there is no implication that a fact reported according to one concept would be understood to have the same business meaning when reported using the other. Concept correspondence MAY be used to indicate the logical successor or successors to a concept that has no equivalent concept in a taxonomy.
A DTS information item is the Versioning information item that contains all of the XBRL information in the corresponding DTS.
A Concept information item is an abstract object representing a concept defined in a taxonomy. A concept can be an XBRL Item or an XBRL Tuple. Both have properties in common and the Concept Information Item represents the properties in common between Items and Tuples.
An Item information item is an object representing a concept defined in a taxonomy in the substitutioGroup xbrli:item. All properties that are exclusive to an item are represented by the Item Information Item.
A Tuple information item is an object representing a concept defined in a taxonomy in the substitutioGroup xbrli:tuple. All properties that are exclusive to a tuple are represented by the Tuple Information Item.
Namespace prefixes [XML Names] will be used
for elements and attributes in
the form ns:name where ns is the
namespace prefix and name is the local name.
Throughout this specification, the mappings
from namespace prefixes to actual namespaces is consistent
with
Table
1.
The prefix column in Table 1 is non normative. The namespace URI column is normative.
| Prefix | Namespace URI |
|---|---|
vercb
|
http://xbrl.org/2008/versioning-basic-concepts
|
xbrlvercbe
|
http://xbrl.org/2008/versioning-basic-concepts/error
|
This specification defines four events. These events, in conjunction with namespace mappings, establish pairs of concepts, one from each of the F-DTS and T-DTS as being equivalent concepts or related concepts, as described in Section 2.2.
A from-identifier manifests as a
child element of a event which is a
<vercb:fromE>
when the identifier locates a concept definition.
Error code xbrlvercbe:badFromIdentifier MUST be thrown if a from-identifier does not identify an information item in the F-DTS.
A to-identifier manifests as a
child element of a event which is a
<vercb:toE>
when the identifier locates a concept definition.
Error code xbrlvercbe:badToIdentifier MUST be thrown if a to-identifier does not identify an information item in the T-DTS.
Concept mapping information is obtained from the versioning report as follows:
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 including the participants in the Versioning Working Group.
| Date | Author | Details |
|---|---|---|
| 06 October 2009 | Roland Hommes |
Merged PWD-2009-05-27 on Context and Syntax into one document, and split the result into modules, this being the 'basic concepts' module which enables concept-level versioning. |
| 28 October 2009 | Roland Hommes |
Updates as per comments from Haiko Philipp. Events never MUST be reported, only when the report author chooses to. |
| 24 November 2009 | Paul Warren |
Updates based on comments from Dan Bromley: Updated references to use the definitions for "paired namespace" and "paired role URI" where appropriate. |
| 27 November 2009 | Roland Hommes |
Updates as per comments from Maciej Piechocki: Removal of XIS references, table2 refers to XML nodes of events. |
| 29 November 2009 | Paul Warren |
Introduced defintions of equivalent concepts and related concepts. Re-drafted Concept Mappings in terms of information obtained from versioning events. Removed ConceptNamespace. |
| 30 November 2009 | Paul Warren |
Renamed EvConceptNew to EvConceptAdd. Fixed list of terminology dependencies. Removed "Ev" prefix from all events. |
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 Versioning Working Group up to and including 03 December 2009. 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.