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.
The XBRL Versioning Specification: Part I [XVS I] defines the semantics of an XBRL versioning report. This specification defines an XML [XML] syntax for XBRL versioning reports. The syntax enables versioning reports to document revisions between two Discoverable Taxonomy Sets (DTS), usually, an initial DTS and a revised DTS. The documentation supports computer automation of updates to mappings against the initial DTS and it supports human analysis of the causes of the revisions that were made.
Versioning reports support documentation of the specific assignments (tasks) that have been completed or considered in relation to making changes to a DTS. The assignments can be categorised in various ways and they can be documented in terms of actions taken to complete them and the technical differences that those actions resulted in.
The syntax is intended to support the requirements for XBRL versioning reports set out in [XVR].
1 Introduction
1.1 Background
1.2 Relationship to other work
1.3 Language independence
1.4 Terminology
1.5 Document conventions
1.5.1 Typographic conventions
1.5.1.1 Definition notation
1.5.1.2 Footnote notation
1.5.1.3 Element and attribute notation
1.5.2 Formatting conventions
1.6 Namespaces and namespace prefixes
1.7 URI resolution
1.8 Validity of a versioning report
2 Syntax
2.1 Versioning reports
2.1.1 DTS identifiers
2.1.2 Labels, documentation and references
2.1.3 Supplementary reports
2.1.4 Categories
2.1.5 URI mappings
2.1.5.1 Namespace mappings
2.1.5.2 Link-role mappings
2.1.6 Assignments
2.1.6.1 Category tags
2.1.6.2 Assignment tags
2.1.6.3 Revisions
2.1.6.3.1 Events
2.1.7 Actions
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
Specific events
1 A normative example
2 A non-normative example
3 An example of poor usage
DTS identifier
F-DTS
T-DTS
URI mapping
XML schema
action
assignment
assignment tag
business category
category
category tag
concept-identifier
errata category
event
from-URI
from-identifier
identifier
link-role mapping
namespace mapping
relationship-identifier
report reference
resource-identifier
revision
rfc2119 terminology
supplementary report
technical category
to-URI
to-identifier
versioning-linkbase reference
versioning-report
xbrlvere:badArc
xbrlvere:badFromIdentifier
xbrlvere:badIdentifierTarget
xbrlvere:badToIdentifier
xbrlvere:invalidRelativeURI
xbrlvere:invalidXPointerScheme
xbrlvere:nonexistentLinkRoleURI
xbrlvere:nonexistentNamespaceURI
xbrlvere:overriddenRelationshipIdentified
xbrlvere:prohibitedRelationshipIdentified
xbrlvere:unrelatedSource
xbrlvere:unrelatedTarget
This specification defines an XML [XML] syntax for versioning reports.
A versioning report is a comparison of two DTSs, documenting revisions that, when applied to one DTS, manifest in the other DTS.
A revision is a change to an information item in a DTS.
Examples of revisions include:
Examples of revisions to a DTS include a change of target namespace for a schema, a change in an XLink role value, and the additions, deletions and modifications of concepts, relationships or XLink resources, and even modifications to the ordering of sibling relationships in a network of relationships.
The F-DTS is the DTS prior to the revisions documented in the versioning report.
The T-DTS is the DTS obtained after effecting the revisions documented in the versioning report.
It is important to recognise that versioning reports do not stand in isolation from the F-DTS or the T-DTS. Thus, it is not possible to use the F-DTS and a versioning report to obtain the information content of the T-DTS. Similarly, it is not possible to use the T-DTS and a versioning report to obtain the information content of the F-DTS.
Versioning reports depend on the F-DTS and the T-DTS because versioning reports record some or all of the information items that differ between their F-DTS and their T-DTS but they do not record the substance of those differences.
For example, a versioning report might indicate that a concept was subject to a name change. However, it would not indicate the original concept name and the revised concept name.
Similarly, a versioning report might indicate that a new custom attribute was added to an XLink relationship in the F-DTS. The versioning report would indicate the relationship that was modified and the attribute that was affected but it would not contain the value of that new custom attribute. That value would need to be determined from the T-DTS.
In general, when utilising a versioning report, it will be necessary to seek out and analyse the information items in the F-DTS and the T-DTS when deciding how to process each revision recorded in the versioning report.
A number of projects have made significant contributions to this specification. These include the IASC Foundation which has contributed a methodology on which this specification is based, and the National Taxonomy Project ("NTP") initiated by the Dutch government, which has contributed the first initial documentation of a standardisation for a Versioning report. Several other initiatives such as the Committee of European Banking Supervisors have joined efforts together in order to help the XBRL Consortium and the XBRL industry to adopt a single common solution that satisfies the most critical business requirements in all those projects.
This specification also owes much to the designs inherent in an earlier specification, edited by Ignacio Hernández-Ros.
This specification depends upon the XBRL 2.1 Specification [XBRL 2.1].
This specification also depends upon the XBRL Infoset Specification [XBRL Information Set]. It is also closely related to the XBRL Versioning Specification: Part I [XVS I], which defines the information content of the versioning reports expressed using the syntax defined in this specification.
This specification is intended to be augmented with a range of extensions to enable versioning information to be made specific to other extensions of the XBRL 2.1 Specification, including, for example, XBRL Formulae [FORMULA].
The official language of XBRL International's own work products is English and the preferred spelling convention is UK English.
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].
Where this document refers to an XML schema, it is referring to an XML document [XML] that contains a declaration of a schema that is compliant with XML Schema [XML Schema Structures].
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.
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 |
|---|---|
ver
|
http://xbrl.org/2008/versioning
|
xbrlvere
|
http://xbrl.org/2008/versioning/error
|
xs
|
http://www.w3.org/2001/XMLSchema
|
gen
|
http://xbrl.org/2008/generic
|
eg
|
http://example.com/
|
This specification requires relative Uniform Resource Identifiers (URI) [IETF RFC 3986] to be converted to an absolute URI. In all cases, the absolute URI MUST be obtained in accord with the XML Base Specification [XML Base].
Some URIs need to be resolved to obtain the resource that they identify. Some of those URIs MAY include an XPointer expression [XPOINTER].
Error code xbrlvere:invalidXPointerScheme
MUST
be thrown if the XPointer expression in a URI in
a versioning report is scheme-based and includes an
XPointer scheme
other than the xmlns() scheme ([XMLNS-SCHEME]) or the
element() scheme ([ELEMENT-SCHEME]).
The QNames in all XPath expressions in a versioning report MUST be resolvable using namespace declarations that are in scope for the element that contains the XPath expression or for the element with the attribute that contains the XPath expression. See Namespaces in XML [XML Names] for more information on namespace declarations and their scope.
A versioning report is valid if it validates against the normative XML schema in Appendix A and if the content of the versioning report does not require any of the errors defined in this specification to be thrown.
This specification only provides a textual declaration of syntax constraints when those constraints are not expressed by the normative schema supplied with this specification.
Explanations of elements and attributes are only supplied when explanations are not already provided in other specifications.
Unless explicitly stated otherwise, a reference to a specific element MUST be read as a reference to that element or to any element in its substitution group.
Various terms are defined throughout this specification. For some of those terms, the things that they refer to are said to manifest as particular elements. In such cases, the term will be used to refer to the thing itself and to the element that the thing manifests as.
A versioning report
manifests as a
<ver:report>
element.
A DTS identifier is a collection of absolute URIs that are interpreted as the starting points for discovery of the identified DTS.
A DTS identifier
manifests as an element in the
substitution group
for the
<ver:dtsIdentifier>
element.
DTS identifiers contain a set of zero or more
URIs. Each URI is the content of the
@value
attribute on a child
<ver:uri>
element in the DTS identifier.
Each URI in a DTS identifier MAY be absolute or relative. URIs in DTS identifiers MUST be resolved in accord with Section 1.7.
Note that, because using different sets of URIs as the starting points for discovery of a DTS can result in the same DTS being discovered, it is possible for two DTS identifiers, that contain different sets of URIs, to identify the same DTS.
Versioning reports contain a DTS identifier for the
F-DTS
and a DTS identifier for the
T-DTS.
The DTS identifier of the F-DTS manifests as a
<ver:fromDts>
element and the DTS identifier for the T-DTS
manifests as a
<ver:toDts>
element.
A DTS identifier MAY include the URI of XBRL instances. In such cases, the DTS supporting each such XBRL instance is in the DTS identified by the DTS identifier. However, the XBRL instances themselves, are not part of the DTS. This accords with the DTS definition.
Labels, documentation and references can be associated with versioning reports and the categories, assignments, actions, revisions, category tags and assignment tags that they contain, using generic labels [GENERIC LABELS] and generic references [GENERIC REFERENCES] in generic links [GENERIC LINKS].
Generic labels and references for a versioning report provide information about the versioning report as a whole.
Generic labels and references for a category can provide information about that specific category as it applies to all assignments that have been tagged with it.
Generic labels and references for a category tag can provide information about the category as it applies to the assignment containing the category identified by the category tag.
Generic labels and references for an assignment can provide information about the nature of the assignment.
Generic labels and references for an assignment tag can provide information about why the action was necessary to complete the assignment.
Generic labels and references for an action can provide information about the nature of the action.
Generic labels and references for a revision provide information about the revision itself.
A versioning report can include links to XBRL linkbases to assist in their location. However, the generic links that MAY be used to augment or document the content of a versioning report is not limited to that set of linkbases that are identified by links in the versioning report.
A versioning linkbase reference is an XLink simple link to an XBRL linkbase from within a versioning report.
A versioning-linkbase reference
manifests as an
<ver:linkRef>
element.
A supplementary report is information about the difference between the F-DTS and the T-DTS that is external to the versioning report.
Sometimes it can be useful to augment an XBRL versioning report with references to one or more supplementary reports. For example, an XBRL versioning report for changes to a core DTS might usefully be referenced by a versioning report for an extension to that core. In other cases, it can be useful to provide references to documentation about the differences between the two DTSs that are expressed without using XBRL syntax.
A report reference is an XLink simple link to a supplementary report.
An
report reference
manifests as an
<ver:reportRef>
element.
A category is a classification of a F-DTS modification assignment
A category
manifests as an element in the
substitution group
for the abstract
<ver:category>
element.
In a versioning report, all categories are child
elements of the
<ver:categories>
element that, itself, is a child of the
versioning report.
Each category in a versioning report is uniquely
identified by the value of its
@id attribute.
This specification defines three categories but additional categories can be defined by DTS maintainers should they wish to tag the revisions between versions of their DTSs with alternative categories.
An errata category is a category, that, when used to tag a revision, indicates that the revision is intended to correct errata in the F-DTS.
An errata category manifests as a
<ver:errataCategory>
element.
A business category is a category, that, when used to tag a difference, indicates that the difference is intended to bring the T-DTS into closer alignment with current business requirements.
A business category
manifests as a
<ver:businessCategory>
element.
A technical category is a category, that, when used to tag a revision, indicates that the revision is driven by technical requirements such as to distinguish the T-DTS from the F-DTS.
A technical category manifests as a
<ver:technicalCategory>
element.
To define a new category, DTS maintainers need to
create an XML schema that declares the new
category element to be directly or indirectly in
the substitution group for the
<ver:category>
element. The interpretation of the newly defined
category will need to be specified by the DTS
maintainer.
A URI mapping is global information that identifies an absolute URI in the F-DTS and associates that with the absolute URI in the T-DTS that replaces it.
A
URI mapping
manifests as an element in the
substitution group for the abstract
<ver:mapping>
element.
All URI mappings are global information required to correctly understand the versioning report. Further actions in the report depend on how the URI mappings are defined.
All URI mappings express two absolute URI values: the from-URI and the to-URI.
A from-URI is an absolute URI in the F-DTS.
A from-URI
is expressed by the
@value attribute on a
<ver:fromURI>
element.
A to-URI is an absolute URI in the T-DTS.
A to-URI
is expressed by the
@value
attribute on a
<ver:toURI>
element.
Error code xbrlvere:invalidRelativeURI MUST be thrown if a from-URI or a to-URI is not an absolute URI.
Two concrete URI mappings are defined in this specification.
A namespace mapping is a mapping from a target namespace URI in the F-DTS to a target namespace URI in the T-DTS.
A
namespace mapping
manifests as a
<ver:namespaceMapping>
element.
Error code xbrlvere:nonexistentNamespaceURI MUST be thrown if a from-URI in a namespace mapping is not an XML Schema namespace in the F-DTS or a to-URI in a namespace mapping is not an XML Schema namespace in the T-DTS.
A link-role mapping is a mapping from an XLink link role URI in the F-DTS to an XLink link role URI in the T-DTS.
A
link-role mapping
manifests as a
<ver:roleMapping>
element.
Error code xbrlvere:nonexistentLinkRoleURI MUST be thrown if a from-URI in a link-role mapping is not a link role URI in the F-DTS or a to-URI in a link-role mapping is not a link role URI in the T-DTS.
An assignment represents a versioning task.
An assignment manifests as an
<ver:assignment>
element.
Assignments serve three purposes. First, they enable the tasks to be documented using labels and references. Second, they enable the tasks to be broken down into individual actions, each of which may result in revisions to the F-DTS. Third, they enable tasks to be categorised into one or more of the categories included in the versioning report.
Assignments are categorised using category tags.
A category tag indicates that the containing
an assignment is in the category identified
by the
@ref attribute on the category tag.
A category tag
manifests as a
<ver:cTag>
element.
All assignments can be tagged with zero or more categories.
An assignment tag indicates that the containing
action
has been performed as part of completing the
assignment identified
by the
@ref attribute on the assignment tag.
A category tag manifests as a
<ver:aTag>
element.
A revision
manifests as an element in the substitution group for the
<ver:revision>
element.
An event is a revision that explicitly identifies the affected information item in the F-DTS, if any exists, and the affected information item in the T-DTS, again if any exists.
An event manifests as a
an element in the substitution group for the
<ver:event>
element.
Each kind of event defined in [XVS I] has a corresponding concrete element that is used to represent it in a versioning report. Thus, the element name of each event identifies exactly which kind of event is being documented.
That information is not sufficient, however, to fully document the event. It is also necessary to know which specific information items in the F-DTS and/or T-DTS are affected by the event. This information is provided by identifiers.
An identifier is a child element of a event that identifies an information item in either the F-DTS or the T-DTS.
Events that document additions to the F-DTS only identify an information item in the T-DTS. Events that document deletions from the F-DTS only identify an information item in the F-DTS. Events that document changes to an information item or one of its properties in the F-DTS identify an information item in the F-DTS and an information item in the T-DTS.
Identifiers identify information items by locating the
elements that represent them using XPointers for
Concepts and Resources in the DTS.
An XPointer is an element that contain an attribute called
<href>
whose content is an URI according to the allowed XPointer syntaxes.
Allowed XPointers syntaxes are Element Scheme XPointers and
Short Hand XPointers.
A concept identifier is a identifier for a Concept information item in the F-DTS or the T-DTS.
A resource identifier is a identifier for a Resource information item in the F-DTS or the T-DTS.
A relationship identifier is a identifier for a Relationship information item in the F-DTS or the T-DTS. Relationship are not elements in the F-DTS or the T-DTS because according to the XLink specification one arc may represent one or more relationships. This specification defines a relationship identifier that is able to locate one specific relationship regardless in which arc the relationship is defined.
A relationship identifier is expressed by a
<ver:fromR>
or
<ver:toR>
element. Those elements contains the following three
attributes:
@extendedLinkRole that contains the
URI
of the Role
of the Parent
extended link of the relationship,
@relationshipType
that contains the
arc type QName
and
@arcrole that contains the
arc role Type
as indicated in the
relationship.
The relationship identifier requires three additional elements to be completed:
an optional element
<ver:attributes>
that contains
a copy of the relationship attributes that are non exempt
as defined in section
3.5.3.9.7.4 equivalent
of the XBRL specification.
The root element of the source resource and the root element of the target
resource.
Error code xbrlvere:badArc
MUST
be thrown if a
<ver:arc>
element does not locate an XLink arc element.
Error code xbrlvere:unrelatedSource
MUST
be thrown if the
<ver:source>
element locates an
element that is not a source for the XLink arc
identified by the sibling
<ver:arc>
element.
Error code xbrlvere:unrelatedTarget
MUST
be thrown if the
<ver:target>
element locates an
element that is not a target for the XLink arc
identified by the sibling
<ver:arc>
element.
Error code xbrlvere:overriddenRelationshipIdentified MUST be thrown if an event identifies a source resource, target resource and arc expressing an overridden relationship unless that relationship is equivalent to a relationship that is not overridden.
Error code xbrlvere:prohibitedRelationshipIdentified MUST be thrown if an event identifies a source resource, target resource and arc expressing a prohibited relationship.
Error code xbrlvere:badIdentifierTarget MUST be thrown if an identifier does not identify an information item that is of the type affected by the event containing the identifier.
The XLM Schema content models for the various events impose constraints that ensure that the right kind of information identifier is used to identify the affected information items.
A from-identifier is an identifier in a event that identifies an information-item in the F-DTS.
A from-identifier manifests as a
child element of a event which is either a
<ver:fromE>
when the identifier locates a concept definition or a
<ver:fromR>
when the identifier locates a relationship.
Error code xbrlvere:badFromIdentifier MUST be thrown if a from-identifier does not identify an information item in the F-DTS.
A to-identifier is an identifier in a event that identifies information in the T-DTS.
A to-identifier manifests as a
child element of a event which is either a
<ver:toE>
when the identifier locates a concept definition or a
<ver:toR>
when the identifier locates a relationship.
Error code xbrlvere:badToIdentifier MUST be thrown if a to-identifier does not identify an information item in the T-DTS.
If an event does not contain a from-identifier then it documents an addition to the F-DTS.
If an event does not contain a to-identifier then it documents a deletion from the F-DTS.
If an event contain both a from-identifier and a to-identifier then it documents a change to an information item in the F-DTS.
Some events document changes to properties expressed by custom attributes on concepts, resources and relationships. Such events include markup to identify which specific attribute expresses the property affected by them.
For such events, when the affected attribute has a QName name, then the event
affecting it contains a child
<ver:attributeQname>
element.
Its QName value is expressed in the
@value attribute of
the
<ver:attributeQname>
element.
When the affected attribute does not have a QName name, then the event
affecting it contains a child
<ver:attributeName>
element.
Its Name value is expressed in the
@value attribute of
the
<ver:attributeName>
element.
The following sub-sections document the syntax of the events corresponding to
each of the events defined in [XVS I]. Additional events
MAY be defined in future specifications. Such events
MUST be expressed in versioning reports by elements that are
in the substitution group for the
<ver:event>
element.
Table 2 maps each of the events in [XVS I] to the concrete element used to express them in versioning reports.
An action is a collection of revisions to the F-DTS.
An action manifests as an
<ver:action>
element.
Actions serve two purposes. They support the grouping of related revisions and they enable such groups of related revisions to be associated with the assignment or assignments that motivated them.
The following is the XML schema provided as part of this specification. This is normative. Non-normative versions (which should be identical to these except for appropriate comments indicating their non-normative status) are also provided as separate files for convenience of users of the specification.
NOTE: (non-normative) Following the schema maintenance policy of XBRL International, it is the intent (but is not guaranteed) that the location of non-normative versions of these schemas on the web will be as follows:
http://www.xbrl.org/2008/ - during the drafting process for
this specification this directory should contain a copy of the
most recent published version of the schema at
http://www.xbrl.org/2008/versioning.xsd.
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 |
|---|---|---|
| 21 June 2008 | Geoff Shuetrim |
First internal working draft added to source control. |
| 27 June 2008 | Geoff Shuetrim |
Added in new error codes and mapping tables to firm up the connection to the XBRL Infoset Specification [XBRL Information Set] and the XBRL Versioning Specification: Part I [XVS I]. |
| 09 July 2008 | Geoff Shuetrim |
Changed the element names to be camel case. |
| 16 July 2008 | Hugh Wallis |
Changed status to WGWD (Working Group Working Draft) Refactored a number of the boilerplate sections in the source XML document |
| 23 July 2008 | Geoff Shuetrim |
Resolved comments based on feedback in conference calls. Eliminated the priority event, treating changes of priority relationship properties as relationship addition or deletion events, depending on the consequences of the change in the priority property of a relationship. |
| 24 July 2008 | Geoff Shuetrim |
Added explanatory materials on how generic labels are to be used with each of the parts of a versioning report. Added hyperlinks back to definitions in [XBRL Information Set]. Adjusted terminology to adhere to the distinction between information items and properties of information items, as made in [XBRL Information Set]. Corrected errors for relationship identifiers that identify overridden or prohibited relationships to avoid terms involving arcs rather than relationships.
Added the Updated the mapping from differences to difference events as defined in [XVS I]. |
| 31 July 2008 | Geoff Shuetrim |
Finalised the mapping to relationship-previous and relationship-next events. |
| 14 August 2008 | Geoff Shuetrim |
Eliminated nesting of actions as suggested by Ignacio Hernández-Ros and confirmed by the VWG. Eliminated arcrole mappings as suggested by Ignacio Hernández-Ros based on its not being included in the VWG requirements. Reverted to the term "category" in place of the term "motive". |
| 15 August 2008 | Geoff Shuetrim |
Added in assignments and assignment tags as per discussions at the VWG face-to-face meeting on August 14, 2008, to reflect the revelation that assignments are not assignments of categories to actions but rather assignments to be completed by the people that have been assigned with them. Changed the name of the alternative reports to supplementary reports given that a common use case for them is to link to other supplementary XBRL versioning reports. Explicitly included mention of the potential to use generic references as well as generic labels to document the parts of a versioning report, as discussed at August 14, 2008 face-to-face meeting. |
| 28 August 2008 | Geoff Shuetrim |
Clarified that DTS identifiers may include the URIs of XBRL instances. Removed the error code that was required to be thrown if a DTS identifier included the URI of a document that could not be part of a DTS. This change was in response to feedback from the VWG conference call on 26 August, 2008. Eliminated attribute identifiers in favour of specific difference event elements, one for each kind change to an information item or information item property that can be documented using a difference event. Simplified the identifiers to all be simple links that conform to the same constraints as simple links in the XBRL 2.1 specification.
Added in an event for documenting inconsequential concept changes
to replace the Ensured XML Schema validation of the structure of the identifiers used for each kind of difference event, although this still does not guarantee that the nodes located in the F-DTS or T-DTS are appropriate for the kind of difference event being documented. Eliminated the section dedicated to identifiers now that identifiers have been substantially simplified. Changed from.uri and to.uri element names to fromURI and toURI to conform better with usual XBRL element naming conventions. |
| 04 September 2008 | Geoff Shuetrim |
Adjusted the wording in relation to relationship information item identifiers to clarify the handling of equivalent relationships. This addresses a problem of inconsistency with [XBRL 2.1] identified by Ignacio Hernández-Ros. |
| 09 October 2008 | Ignacio Hernández-Ros |
Simple links are now turned into XPointer elements as per decision in the VWG call.
|
| 20 November 2008 | Ignacio Hernández-Ros |
Removed sections related to URI mappings for arc role types Mappings are not revisions but global information required to make possible for a tool comparing two taxonomies to identify the actions made by the taxonomy authors and let the user document them. The URI mappings has been put as a separate section and not as part of the actions section. Collapsed the two different types of role mappings for roles used in resources and roles used in extended links into one single mapping category for roles as there are no distinction in the XBRL specification to make a distinction here. Changed the syntax for Relationship identifiers so the identifier locates a relationship in the object model rather than an arc acting as a proxy for the relationship as per decisions made by the working group. Introduced definitions for concept identifiers, resource identifiers and relationship identifiers. |
| 10 December 2008 | Hugh Wallis |
Editorial for publication |
| 27 January 2009 | Roland Hommes |
Revert to Raw XML schema |
| 04 February 2009 | Hugh Wallis |
Editorial for publication |
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 04 February 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.