Versioning Concept Use 1.0

Recommendation 27 February 2013

Copyright © 2009, 2010, 2011, 2012, 2013 XBRL International Inc., All Rights Reserved.

This version:
<http://www.xbrl.org/Specification/versioning-concept-use/REC-2013-02-27/versioning-concept-use-REC-2013-02-27.html>
Editors:
Roland Hommes, Rhocon <roland@rhocon.nl>
Paul Warren, CoreFiling <pdw@corefiling.com>
Contributors:
Ignacio Hernández-Ros, Reporting Estandar S.L. <ignacio@hernandez-ros.com>
Hugh Wallis, XBRL International Inc. <hughwallis@xbrl.org>
Haiko Philipp, IFRS Foundation <hphilipp@ifrs.org>
Geoff Shuetrim, Galexy <geoff@galexy.net>
Ian Stokes-Rees, CoreFiling <ijs@corefiling.com>
David North, CoreFiling <dtn@corefiling.com>
Herm Fischer, Mark V Systems <fischer@markv.com>
Richard Ashby, CoreFiling <rna@corefiling.com>

Status

Circulation of this Recommendation is unrestricted. This document is normative. 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.

Abstract

This specification is an extension to the versioning base specification [XVS-Base]. It specifies how to map and address concept names between two DTSs in a Versioning Report by defining three new events: Add, Delete, and Rename.

This specification is dependent upon the Versioning Base module [XVS-Base].

Table of Contents

1 Introduction
1.1 Relationship to other work
1.2 Namespaces and namespace prefixes
1.3 Language independence
1.4 Document conventions
1.4.1 Typographic conventions
1.4.1.1 Definition notation
1.4.1.2 Footnote notation
1.4.1.3 Element and attribute notation
1.4.2 Formatting conventions
1.5 Terminology
2 Mappings
3 Events
3.1 Validation Rules
4 Identifiers
4.1 Concept Identifier
4.1.1 Validation Rules
4.1.2 XML Representation

Appendices

A Schema
B References
C Intellectual property status (non-normative)
D Acknowledgements (non-normative)
E Document history (non-normative)
F Errata corrections in this document

Tables

1 Namespaces and namespace prefixes
2 Concept Use Events
3 XML representation summary: vercu:fromConcept and vercu:toConcept

Examples

1 Equivalent concept with datatype mismatch
2 Concept de-duplication

Definitions

Available For Use
Business Concept
Concept Identifier
Equivalent Concepts
Related Concepts

Error codes

vercue:inconsistentPhysicalAttribute
vercue:invalidConceptReference


1 Introduction

1.1 Relationship to other work

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.

1.2 Namespaces and namespace prefixes

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.

Table 1: Namespaces and namespace prefixes
Prefix Namespace URI
ver http://xbrl.org/2013/versioning-base
vere http://xbrl.org/2013/versioning-base/error
vercu http://xbrl.org/2013/versioning-concept-use
vercue http://xbrl.org/2013/versioning-concept-use/error

1.3 Language independence

The official language of XBRL International's own work products is English and the preferred spelling convention is UK English.

1.4 Document conventions

1.4.1 Typographic conventions

1.4.1.1 Definition notation

Definitions are highlighted with green text.

1.4.1.2 Footnote notation

Comments which are informative, but not essential to the understanding of the point at hand, are provided in footnotes. All footnotes are non-normative.

1.4.1.3 Element and attribute notation

When referring to a specific element, it will be identified by its namespace prefix and local name. For example, the root element of a versioning report would be referred to as <ver:report> .

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.

1.4.2 Formatting conventions

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 non-normative example.

The following highlighting is used for non-normative examples of poor, discouraged or disallowed usage.

Text of the discouraged example.

1.5 Terminology

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].

The key words concept, concept definition, fact, label, reference and DTS in this document are to be interpreted as described in the XBRL Specification [XBRL 2.1].

The key words element, attribute, local name, datatype, namespace name and namespace prefix in this document are to be interpreted as described in the XML Names Specification [XML Names].

The key word actual value in this document is to be interpreted as described in the XML Schema Structures Specification [XML Schema Structures].

A Business Concept is the abstract definition of an individual piece of business information. An XBRL concept is a concrete instantiation of a Business Concept. The distinction is relevant to this specification because a single Business Concept may be represented by different XBRL concepts in different DTSs. A Versioning Report can identify such Equivalent Concepts.

Two XBRL concepts are considered to be Equivalent Concepts when both 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 SHOULD have the same value space, allowing all values that are valid for the Business Concept. In practice, it is possible that the value spaces may be different.

Example 1: Equivalent concept with datatype mismatch

For example, a concept A in the From DTS may have a datatype string whereas the equivalent concept in the To DTS has a string datatype with a restrictive pattern that matches the valid values for the Business Concept more closely. Furthermore, 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 Concepts.

Documentation about the change in datatype can be associated with the relevant concepts using the Events in this specification. The Versioning Concept Extended specification provides events that allows documentation to be attached to the change in datatype specifically, rather than providing documentation at a concept level.

Two XBRL 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. Related Concepts MAY be used to indicate the logical successor or successors to a concept that has no Equivalent Concepts in a DTS.

An XBRL concept is Available For Use if it is legitimate, in business terms, to use that concept in an instance for a given DTS. Being legitimate in business terms may be a stricter requirement than being XBRL valid, as it is common for modular taxonomies to include concepts in a DTS that are not intended for use in a given reporting scenario. A Versioning Report can identify when concepts become Available For Use or stop being Available For Use between two versions of a taxonomy.

2 Mappings

Concept mapping information is obtained from the versioning report as follows:

A concept, CF, in the From DTS and a concept, CT, in the To DTS are Related Concepts if there exists an Action that contains:

Concepts CF and CT are Equivalent Concepts if:

Or:

Example 2: Concept de-duplication

It should be noted that a concept may be defined as being Equivalent to more than one other concept. This would typically be used to address concept de-duplication, where a taxonomy (the From DTS) has more than one XBRL concept for the same underlying Business Concept, and these are de-duplicated into a single concept in the To DTS.

In this case, multiple concepts in the From DTS would legitimately be defined as being Equivalent to a single concept in the To DTS.

3 Events

This specification defines three Events. These Events, in conjunction with Namespace Mappings, establish pairs of concepts, one from each of the From DTS and To DTS as being Equivalent Concepts or Related Concepts, as described in Section 2.

Table 2: Concept Use Events
Code Element From Identifier To Identifier
[ConceptDelete] <vercu:conceptDelete> Concept Identifier -
[ConceptAdd] <vercu:conceptAdd> - Concept Identifier
[ConceptRename] <vercu:conceptRename> Concept Identifier Concept Identifier

The fundamental purpose of ConceptAdd and ConceptDelete events is to convey information about the business usability of a concept. In addition, the @physical attribute is used to indicate whether the change is also reflected by a physical change in the DTS.

When the @physical attribute has the actual value of true this indicates that there has been a change in which concepts are actually present in the DTSs.

When the @physical attribute has the actual value of false these events communicate changes in the concepts that are Available For Use in the From DTS and To DTS, but in circumstances where the concepts are present in both DTSs.

3.1 Validation Rules

Error code vercue:inconsistentPhysicalAttribute is raised for every concept use event where the appropriate one of the following conditions is not met:

If the @physical attribute has the actual value of true then:

If the @physical attribute has the actual value of false then:

The check for the concept in the relevant DTS is carried out after allowing for any Namespace Rename events identified in the Versioning Report.

4 Identifiers

4.1 Concept Identifier

A concept identifier is an identifier for a concept in the From DTS or the To DTS whose actual value is an xs:QName that resolves to that concept definition.

4.1.1 Validation Rules

The actual value of the Concept Identifier MUST resolve to a valid concept definition in:

Error code vercue:invalidConceptReference is raised otherwise.

4.1.2 XML Representation

In this specification a concept identifier is represented by:

Table 3: XML representation summary: vercu:fromConcept and vercu:toConcept
<vercu:fromConcept

  name = xs:QName>

  Content: None

</vercu:fromConcept>
<vercu:toConcept

  name = xs:QName>

  Content: None

</vercu:toConcept>
Property Representation
{Concept} The concept definition obtained by resolving the actual value of the @name attribute.

Appendix A Schema

The normative version of this schema can be found at http://www.xbrl.org/2013/versioning-concept-use.xsd. For convenience, a copy of the schema is included below.

<!-- Copyright 2007-2013 XBRL International. All Rights Reserved. -->
<xs:schema
  xmlns:xs
="http://www.w3.org/2001/XMLSchema"

  xmlns:vercu
="http://xbrl.org/2013/versioning-concept-use"

  xmlns:ver
="http://xbrl.org/2013/versioning-base"
targetNamespace="http://xbrl.org/2013/versioning-concept-use" elementFormDefault="qualified">
<xs:import namespace="http://xbrl.org/2013/versioning-base" schemaLocation="versioning-base.xsd"/>
<!-- Parents of the events -->
<xs:element name="fromConcept" type="ver:name.type" id="xml-from-e"/>
<xs:element name="toConcept" type="ver:name.type" id="xml-to-e"/>
<!-- Common attribute. Note that this is wrapped in a group to allow it to remain unqualified. -->
<xs:attributeGroup name="physicalAttributeGroup">
<xs:attribute name="physical" type="xs:boolean" default="true"/>
</xs:attributeGroup>
<!-- complexTypes event nodes-->
<xs:complexType id="xml-add.element.event.type" name="add.element.event.type">
<xs:complexContent>
<xs:extension base="ver:event.type">
<xs:sequence>
<xs:element ref="vercu:toConcept"/>
</xs:sequence>
<xs:attributeGroup ref="vercu:physicalAttributeGroup"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType id="xml-delete.element.event.type" name="delete.element.event.type">
<xs:complexContent>
<xs:extension base="ver:event.type">
<xs:sequence>
<xs:element ref="vercu:fromConcept"/>
</xs:sequence>
<xs:attributeGroup ref="vercu:physicalAttributeGroup"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType id="xml-change.element.event.type" name="change.element.event.type">
<xs:complexContent>
<xs:extension base="ver:event.type">
<xs:sequence>
<xs:element ref="vercu:fromConcept"/>
<xs:element ref="vercu:toConcept"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- Concept events -->
<xs:element id="xml-concept.add.event" name="conceptAdd" type="vercu:add.element.event.type" substitutionGroup="ver:event"/>
<xs:element id="xml-concept.delete.event" name="conceptDelete" type="vercu:delete.element.event.type" substitutionGroup="ver:event"/>
<xs:element id="xml-concept.rename.event" name="conceptRename" type="vercu:change.element.event.type" substitutionGroup="ver:event"/>
</xs:schema>

Appendix B References

IETF RFC 2119
IETF (Internet Engineering Task Force). "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels"
Scott Bradner.

(See http://www.ietf.org/rfc/rfc2119.txt)
XBRL 2.1
XBRL International Inc.. "Extensible Business Reporting Language (XBRL) 2.1 Includes Corrected Errata Up To 2012-01-25"
Phillip Engel
, Walter Hamscher, Geoff Shuetrim, David vun Kannon, and Hugh Wallis.
(See http://www.xbrl.org/specification/xbrl-recommendation-2003-12-31+corrected-errata-2012-01-25.htm)
XML Names
W3C (World Wide Web Consortium). "Namespaces in XML 1.0 (Third Edition)"
(See http://www.w3.org/TR/REC-xml-names/REC-xml-names-20091208)
XML Schema Structures
W3C (World Wide Web Consortium). "XML Schema Part 1: Structures Second Edition"
Henry S. Thompson
, David Beech, Murray Maloney, and Noah Mendelsohn.
(See http://www.w3.org/TR/xmlschema-1/REC-xmlschema-1-20041028/)
XVS-Base
XBRL International Inc. "XBRL Versioning Base 1.0"
Roland Hommes
, and Paul Warren.
(See http://www.xbrl.org/Specification/versioning-base/PR-2013-01-15/versioning-base-PR-2013-01-15.html)

Appendix C 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).

Appendix D Acknowledgements (non-normative)

This document could not have been written without the contributions of many people.

Appendix E Document history (non-normative)

DateAuthorDetails
06 October 2009Roland 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 2009Roland Hommes

Updates as per comments from Haiko Philipp. Events never MUST be reported, only when the report author chooses to.

24 November 2009Paul 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 2009Roland Hommes

Updates as per comments from Maciej Piechocki: Removal of XIS references, table2 refers to XML nodes of events.

29 November 2009Paul Warren

Introduced definitions of equivalent concepts and related concepts. Re-drafted Concept Mappings in terms of information obtained from versioning events. Removed ConceptNamespace.

30 November 2009Paul Warren

Renamed EvConceptNew to EvConceptAdd. Fixed list of terminology dependencies. Removed "Ev" prefix from all events.

31 January 2010Roland Hommes

Processed comments from Walter Hamscher, redesigning ´concept mappings´ and list THREE events.

04 March 2010Paul Warren

Renamed F-DTS and T-DTS to From DTS and To DTS.

08 March 2010Paul Warren

Editorial changes for consistency with versioning-base. Reworked mappings section. Added XML Representation for Concept Identifier.

09 March 2010Paul Warren

Renamed spec document and target namespace of schema to reflect canonical name of "versioning-concept-base".

10 March 2010Hugh Wallis

Editorial for Candidate Recommendation

23 April 2010Paul Warren

Editorial fix (broken bibref, identified by Suguru Washio)

20 June 2010Ian Stokes-Rees

ConceptName changed to ConceptRename and all associated IDs updated accordingly. Identifiers changed from fromE and toE to fromConcept and toConcept. Unnecessary intermediate Concept Basic abstract "event" element removed and equivalent Base abstract event element used instead.

23 January 2011Herm Fischer

Updated schema for QName concept identifier.

26 April 2011Paul Warren

Added example documenting multiple concept equivalence.

16 February 2012David North

Deleted redundant paragraph relating to QName prefix resolution for concept identifiers.

21 February 2012David North

Fixed definition of equivalent concepts so that concepts with the same namespace name and local name are considered equivalent.

27 April 2012David North

Renamed from 'Versioning Concept Basic' to new canonical name, 'Versioning Concept Use'.

03 July 2012Richard Ashby

Added @physical attribute to ConceptAdd and ConceptDelete events, to clarify when these events are used to convey changes in usage only or physical changes to the taxonomy as well. Introduced vercu:inconsistentPhysicalAttribute error code for when use of this attribute does not correspond to actual contents of taxonomy.

17 December 2012Richard Ashby

Changed schema definition of @physical attribute from qualified to unqualified (local) attribute.

08 January 2013Richard Ashby

Updated schema namespace to http://xbrl.org/2013/versioning-concept-use and error namespace to http://xbrl.org/2013/versioning-concept-use/error.

Appendix F Errata corrections 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 Versioning Working Group up to and including 27 February 2013. 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.