1 Introduction

The XBRL 2.1 specification [XBRL] defines the syntax and semantics of that syntax in order to define concepts, resources and relationships between those concepts and concepts and resources in a DTS (See section 3.2 of the XBRL Specification for a more exhaustive definition of a DTS).

During the last years XBRL has been used extensively in several projects all around the world. The most common use of the XBRL technology has been to model an existing information supply chain between regulators and regulated entities.

The digitalization of that process, using the XBRL technology, has required the creation of an XBRL taxonomy (the DTS) used by people creating XBRL reports or submitting those reports to regulators.

One of the most important benefits of the XBRL technology is that XBRL is a standard about how to define the report content. This means that new reporting requirements from regulators to regulated entities can always be incorporated using the same XBRL 2.1 technology without having to change the XBRL technology. In fact, when a new version of a DTS is released, the regulated entities will have to adapt existing mappings between internal data and the old concept definitions to the new concept definitions. It is expected that for all concepts with no significant changes the mapping rules can be adapted automatically.

Existing software, able to understand the content of an XBRL DTS, can generate XBRL instances for whatever taxonomy without having to change anything in the software. But this would not be a true benefit if moving the software form one taxonomy version to another were a costly process. This specification is specifically designed to be used in this environment. The reporting requirements change over time, the taxonomies change to cover those new requirements, but if the technology used to create reports is the same (XBRL 2.1) moving applications to work from a taxonomy version to the next will be a trivial operation at least for concepts whose definition is the same regardless of other possible syntactical changes.

1.1 Background

Two projects have made significant contributions to this specification. They are the IASC Foundation who has contributed a methodology in which this specification is based on and the National Taxonomy Project ("NTP") initiated by the Dutch government who contributed the first initial documentation of a standardization for a Versioning report. Several other initiatives like 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.

1.2 Relationship to other work

This document pertains to XBRL as defined in the XBRL Specification [XBRL].

Parts of this document may reiterate for expository clarity certain semantic restrictions imposed by XBRL, but this document does not modify XBRL. In the event of any conflicts between this document and XBRL, XBRL prevails.

1.3 Terminology

Terminology used in XBRL frequently overlaps with terminology from other fields.

The following terms are used as described in the table below:

Term	Meaning
Arc, arcroleRef, base set, child, concept, context, duplicate item, descendant, DTS (discoverable taxonomy set), element, entity, fact, instance, item, linkbase, linkbaseRef, p‑equal, roleRef, taxonomy, taxonomy schema, u‑equal, XBRL instance.	As defined by XBRL [XBRL].
Relationship	An arc defines a relationship between its source concepts and target concepts that is determined by its xlink:arcrole and other attributes.
source [concept(s)]	The concepts identified by the URI content of the href attributes of the locator-type elements in the same extended-type link element, which have the same label attribute content as the content of the “from” attribute of an arc.
target [concept(s)]	The concepts identified by the URI content of the href attributes of the locator-type elements in the same extended-type link element, which have the same label attribute content as the content of the “to” attribute of an arc.
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: should: Conforming documents and applications are encouraged to behave as described. must: Conformant documents and consuming applications are required to behave as described; otherwise they are in error.
XBRL	Extensible Business Reporting Language (XBRL) 2.1 Recommendation [XBRL].
From DTS	The term "From DTS" is used to refer to the source DTS that is the DTS that will be compared to the "To DTS". The From DTS normally refers to the old taxonomy version.
To DTS	The term "To DTS" is used to refer to the target DTS or the DTS that is being compared with the "From DTS". The To DTS normally refers to the new taxonomy version.
Action	This specification uses the term "Action" for referring to what changes between the From DTS and the To DTS
Assignment	This specification uses the term "Assignment" for referring to the business reasons of an action to change things in a DTS or even the business reasons for start comparing two DTSs.

1.4 Document conventions

The following highlighting is used to present normative technical material in this document:

The following formatting is used for non-normative examples in this document:

The following formatting is used for non-normative counterexamples (examples of poor, discouraged or disallowed usage) in this document:

Non-normative editorial comments are denoted as follows and removed from final recommendations:

1.5 Namespaces

This table contains all the prefixes used within the text and XPath 2.0 expressions and the correspondent namespace URI:

Prefix	Namespace URI
xml	http://www.w3.org/XML/1998/namespace
xbrli	http://www.xbrl.org/2003/instance
xs	http://www.w3.org/2001/XMLSchema
xlink	http://www.w3.org/1999/xlink
link	http://www.xbrl.org/2003/linkbase
xl	http://www.xbrl.org/2003/XLink
ver	http://xbrl.org/2007/versioning

The Prefix column in the table above is non normative. The Namespace URI column is normative.

1.6 XPath

XPath expressions that appear in this document are XPath 2.0 [XPATH] expressions executed in a schema aware processor. Refer to the [XPATH] 2.0 specification for more information.

The prefixes used in the XPath expressions are indicated in section 1.5 above.

2 XBRL Versioning

Versioning is a term with several meanings. Different people have different interpretations of this term. XBRL Versioning is about standardising the content of a report of "information about the changes made to a taxonomy" in order for taxonomy users to save time in adapting their applications to a new taxonomy version.

For the rest of this specification the word From DTS will be used to refer to the DTS that is being compared with the To DTS.

For the rest of this specification the word To DTS will be used to refer to the DTS being compared with the From DTS.

The following figure represents the different layers in which the information of a versioning report is structured.

Figure 1: source of information for a versioning report

There are many examples that show how the information on a DTS can be written in one or many different files without any impact on applications using the DTS. A simple example:

o A taxonomy schema "A.XSD" for the namespace http://foo defining two concepts tx:One and tx:Two may reference one presentation linkbase with one parent-child arc in the http://www.xbrl.org/2003/role connecting the two concepts whereby tx:One is the parent of tx:Two.

o A different taxonomy schema "B.XSD" for the same namespace http://foo and defining the same concepts (tx:One and tx:Two), may have two embedded presentation linkbases in the same http://www.xbrl.org/2003/role role - one saying that tx:Two is the parent of tx:One and the other relationship prohibiting the previous relationship and creating another one saying that tx:One is the parent of tx:Two.

Both taxonomies are equivalent because even though taxonomy "A.XSD" and "B.XSD" are completely different in their syntaxes, both define the same concepts and the same resulting relationship between the concepts. Both DTSs define the same information set as it is used by applications consuming XBRL metadata other than, perhaps, XBRL Taxonomy editors that have more strict requirements about representing prohibited relationships to the user.

2.1 The XBRL versioning Infoset

The XBRL Infoset (Information Set) is an abstraction layer on top of the syntax layer. This abstraction layer expresses concept definitions based on the properties of a XBRL concept and not based on the properties of the elements that are used to express the concepts in XML Schemas or XBRL linkbases.

Versioning is built on top of the XBRL Infoset without making any reference to the actual underlying syntax. Of course, the relationship between the concept properties and the XBRL syntax exist and software tools can easily find and use it.

The XBRL versioning Infoset is a sub-set of the properties and objects defined in the XBRL Infoset. Not everything in the XBRL Infoset is related to concept definitions. The following table describes the set of items and properties in and out of the scope for the versioning report.

The DTS Information Item	[XIS 2.2.1]	All properties are included.
The XBRL Document Information Item	[XIS 2.2.2]	All properties are excluded.
The XBRL Taxonomy Information Item	[XIS 2.2.3]	Namespace [XIS 2.2.3.2] is included. All other properties are excluded.
The Imported Taxonomy Information Item	[XIS 2.2.4]	All excluded.
The Role Type Information Item	[XIS 2.2.5]	URI [XIS 2.2.5.4] is included. All other properties are excluded.
The Arcrole Type Information Item	[XIS 2.2.6]	URI [XIS 2.2.6.4] is included. All other properties are excluded.
The Used On Information Item	[XIS 2.2.7]	All properties are excluded.
The XBRL Concept Information Item	[XIS 2.2.8]	All properties are included except: · the parent property [XIS 2.2.8.1], and · the name property [XIS 2.2.8.2].
The XBRL Item Information Item	[XIS 2.2.9]	All properties are included.
The XBRL Tuple Information Item	[XIS 2.2.10]	All properties are included.
The XBRL Linkbase Information Item	[XIS 2.2.11]	All properties are excluded.
The Extended Link Information Item	[XIS 2.2.12]	The role URI on extended links is used to define the relationship identifier.
The Documentation Information Item	[XIS 2.2.13]	All properties are excluded.
The Relationship Information Item	[XIS 2.2.14]	Only relationships that exist after prohibition and overriding rules defined in the XBRL 2.1 specification are considered part of a concept definition. For those relationships, only the following properties are included: Type [XIS 2.2.14.2] From [XIS 2.2.14.3] To [XIS 2.2.14.4] Arcrole URI [XIS 2.2.6.4] Order [XIS 2.2.14.6] Priority [XIS 2.2.14.8] Attributes [XIS 2.2.14.9]
The Resource Information item	[XIS 2.2.15]	All resources in the DTS are considered. See section 2.4.3 below for more information. For resources, the following properties are included: Type [XIS 2.2.15.2] Role URI [XIS 2.2.5.4] Element [XIS 2.2.15.4] From [XIS 2.2.15.5] To [XIS 2.2.15.6] Attributes [XIS 2.2.15.7] Value [XIS 2.2.15.8]

Changes on other properties that are not included in the list above can be documented in the versioning report despite whether they produce Diff Events [Def 1] or not. The content model of the versioning report allows a report to contain specific documentation to a particular change and generic documentation not related to a particular change.

This specification defines the following additional properties that are derived from information that exist in the XBRL Information Set but not explicitly indicated as properties in the XIS documentation.

2.1.1

Preceding

The Preceding property of an XBRL Relationship Information Item R is the set of XBRL Relationship Information Items RS that satisfies the following conditions:

1. R and RS Belongs to the same Extended Link role [3], and

2. R and RS have the same value in the type property [XIS 2.2.14.2], and

3. RS is positioned immediately before R in the set of relationships that satisfies conditions 1 and 2 ordered using the value of the order property [XIS 2.2.14.6].

2.1.2

Following

The Following Relationship of an XBRL Relationship Information Item R is the set of XBRL Relationship Information Items RS that satisfies the following conditions:

1. R and RS Belongs to the same Extended Link role3, and

2. R and RS have the same value in the type property [XIS 2.2.14.2], and

3. RS is positioned immediately after R in the set of relationships that satisfies conditions 1 and 2 ordered using the value of the order property [XIS 2.2.14.6].

2.2 The differences between two DTSs

This specification defines the equivalency operation between two DTSs, the From DTS and the To DTS. The equivalency operation is independent of the syntax and modularization strategy used to express a DTS.

Two DTSs (From DTS and To DTS) are equivalent if there are no differences in the concept definitions and no differences in the resources defined in the DTSs.

Comparison of two DTSs that are not equivalent produces a set of differences that are identified in this specification. This specification does not define the algorithm to find the differences.

[Def 1] A Difference Event is the representation of something not equivalent found between properties of two corresponding XBRL Information Items being compared.

There are Difference Events defined for each type of difference that is possible between two XBRL Information Items under the subject of this specification.

The computation of the Difference Events requires three tables of paired properties that define the mapping rules between DTSs. See section 3.10 below and the definitions of namespace pair [Def 5], role URI pair [Def 6] and concept pair [Def 7]. Some properties must be compared after applying the appropriate mapping. This specification explicitly defines in which situation the mapping rules must be applied.

Some of the differences between two concept definitions can only be represented using a set of correlated difference events. This is for example the case of changes in attributes of a relationship that requires the following set of events:

[EvConceptRelationshipFrom] event with two parameters [ConceptId] pointing to the From and To concepts. This event will be the starting event and the parent of,

[EvRelationshipAttribute] event with parameters [RelationshipId] pointing to the From and To relationships where an attribute has been changed. This event will be the parent of,

[EvAttributesInequality] event with parameters [AttributeId] pointing to the From and To attribute whose values are not equal. This one will be the Ending event in the path.

[Def 2] A Difference Path is a set of Difference Events. Some of the events contain parameters to identify the concepts, relationships, resources, attributes or XML fragments.

[Def 3] The Starting Event of a path is always the first event in the path.

[Def 4] The Ending Event of a path is always the last event in the path.

A Difference Path contains just one starting event and one ending event. It is possible that the path contains just one event that plays the role of starting and ending event simultaneously. A Difference Path is not a tree with one starting event and multiple ending events.

The set of possible ending events are enumerated in section 2.5 below.

The set of possible starting events are those defined in sections 2.2.1, 2.2.2, 2.2.3 or 2.2.5 below.

The versioning taxonomy schema contains XML Schema constraints defining valid Difference paths.

2.2.1 Comparing two DTS Information Items:

Two DTS Information Items [XIS 2.2.1] D1 that is the From DTS and D2 that is the To DTS are equivalent if all the following conditions are satisfied:

1. For each XBRL Concept Information Item [XIS 2.2.8] defined in the Concepts property [XIS 2.2.1.2] of D1 where a corresponding XBRL Concept Information item [XIS 2.2.8] is found in D2; both items are equivalent if they satisfy all conditions in section 2.2.2 or 2.2.3 below.

2. For each XBRL Concept Information Item [XIS 2.2.8] defined in the Concepts property [XIS 2.2.1.2] of D1 where a corresponding XBRL Concept Information item [XIS 2.2.8] cannot be found in D2, this condition is not satisfied. Processors MUST document this difference generating a Concept deleted event [EvConceptDelete] with the concept identifier [ConceptId] in the [from DTS] parameter.

3. For each XBRL Concept Information Item [XIS 2.2.8] defined in the Concepts property [XIS 2.2.1.2] of D2 where a corresponding XBRL Concept Information item [XIS 2.2.8] cannot be found in D1, this condition is not satisfied. Processors MUST document this difference generating a Concept added event [EvConceptNew] with the concept identifier [ConceptId] in the [to DTS] parameter.

4. For each XBRL Resource Information Item [XIS 2.2.15] defined in the Resources property [XIS 2.2.1.3] of D1 where a corresponding XBRL Resource Information Item [XIS 2.2.15] is found in D2; both items are equivalent if they satisfy all conditions in section 2.2.5 below.

5. For each XBRL Resource Information Item [XIS 2.2.15] defined in the Resources property [XIS 2.2.1.3] of D1 where a corresponding XBRL Resource Information Item [XIS 2.2.15] cannot be found in D2, this condition is not satisfied. Processors MUST document this difference generating a Resource deleted event [EvResourceDelete] with the resource identifier [ResourceId] in the [from DTS] parameter.

6. For each XBRL Resource Information Item [XIS 2.2.15] defined in the Resources property [XIS 2.2.1.3] of D2 where a corresponding XBRL Resource Information Item [XIS 2.2.15] cannot be found in D1, this condition is not satisfied. Processors MUST document this difference generating a Resource added event [EvResourceNew] with the resource identifier [ResourceId] in the [to DTS] parameter.

2.2.2 Comparing two XBRL Item Information Items:

Two XBRL Item Information Items [XIS 2.2.9] I1 which belongs to the From DTS and I2 which belongs to the To DTS are equivalent if all the following conditions are satisfied:

1. If the value of the Namespace property [XIS 2.2.3.2] of the XBRL Taxonomy Information Item [XIS 2.2.3] referenced in the Parent property [XIS 2.2.8.1] of I1 is equal to the value of the namespace pair [Def 5] of the Namespace property [XIS 2.2.3.2] of the XBRL Taxonomy Information Item [XIS 2.2.3] referenced in the Parent property [XIS 2.2.8.1] of I2 this condition is satisfied. Processors MUST raise a Concept namespace event [EvConceptNamespace] with the two concept identifiers [ConceptId] as parameters if this condition is not satisfied.

2. If the value of the Name property [XIS 2.2.8.2] of I1 is equal to the value of the Name property [XIS 2.2.8.2] of I2 this condition is satisfied. Processors MUST raise a Concept name event [EvConceptName] with the two concept identifiers [ConceptId] as parameters if this condition is not satisfied.

3. If the content of the Type property [XIS 2.2.8.3] of I1 is equivalent to the content of the Type property [XIS 2.2.8.3] of I2 according to section 2.2.8 below this condition is satisfied. Processors MUST raise a Concept Type event [EvConceptType] with the two concept identifiers [ConceptId] as parameters if this condition is not satisfied.

4. If the value of the Substitution Group property [XIS 2.2.8.4] of I1 is equal to the value of the Substitution Group property [XIS 2.2.8.4] of I2 this condition is satisfied. Processors MUST raise a Concept Substitution Group event [EvSubstitutionGroup] with the two concept identifiers [ConceptId] as parameters if this condition is not satisfied.

5. If the value of the Period Type property [XIS 2.2.9.2] of I1 is equal to the value of the Period Type property [XIS 2.2.9.2] of I2 this condition is satisfied. Processors MUST raise a Concept Period Type event [EvPeriodType] with the two concept identifiers [ConceptId] as parameters if this condition is not satisfied.

6. If the value of the Balance property [XIS 2.2.9.3] of I1 is equal to the value of the Balance property [XIS 2.2.9.3] of I2 this condition is satisfied. Processors MUST raise a Concept Balance event [EvBalance] with the two concept identifiers [ConceptId] as parameters if this condition is not satisfied.

7. If the value of the Default property [XIS 2.2.9.4] of I1 is equal to the value of the Default property [XIS 2.2.9.4] of I2. If this condition is satisfied. Processors MUST raise a Concept Default event [EvDefault] with the two concept identifiers [ConceptId] as parameters if this condition is not satisfied.

8. If the value of the Nillable property [XIS 2.2.8.5] of I1 is equal to the value of the Nillable property [XIS 2.2.8.5] of I2 this condition is satisfied. Processors MUST raise a Concept Nillable event [EvNillable] with the two concept identifiers [ConceptId] as parameters if this condition is not satisfied.

9. If the value of the Abstract property [XIS 2.2.8.6] of I1 is equal to the value of the Abstract property [XIS 2.2.8.6] of I2 this condition is satisfied. Processors MUST raise a Concept Abstract event [EvAbstract] with the two concept identifiers [ConceptId] as parameters if this condition is not satisfied.

10. If the value of the Block property [XIS 2.2.8.7] of I1 is equal to the value of the Block property [XIS 2.2.8.7] of I2 this condition is satisfied. Processors MUST raise a Concept Block event [EvBlock] with the two concept identifiers [ConceptId] as parameters if this condition is not satisfied.

11. If the value of the Fixed property [XIS 2.2.8.8] of I1 is equal to the value of the Fixed property [XIS 2.2.8.8] of I2 this condition is satisfied. Processors MUST raise a Concept Fixed event [EvFixed] with the two concept identifiers [ConceptId] as parameters if this condition is not satisfied.

12. If the value of the Final property [XIS 2.2.8.9] of I1 is equal to the value of the Final property [XIS 2.2.8.9] of I2 this condition is satisfied. Processors MUST raise a Concept Final event [EvFinal] with the two concept identifiers [ConceptId] as parameters if this condition is not satisfied.

13. For each XBRL Relationship Information Item [XIS 2.2.14] in the From property [XIS 2.2.8.10] of I1 where a corresponding XBRL Relationship Information Item [XIS 2.2.14] in the From property [XIS 2.2.8.10] of I2 exist; both relationships are equivalent if they satisfy all conditions in section 2.2.4 below. Processors MUST raise a Concept From event [EvConceptRelationshipFrom] with the two concept identifiers [ConceptId] as parameters if this condition is not satisfied. This event will be the parent of additional events according to section 2.2.4 below.

14. For each XBRL Relationship Information Item [XIS 2.2.14] in the From property [XIS 2.2.8.10] of I1 where a corresponding XBRL Relationship Information Item [XIS 2.2.14] cannot be found in the From property [XIS 2.2.8.10] of I2 this condition is not satisfied. In this case, Processors MUST raise a Concept From event [EvConceptRelationshipFrom] with the two concept identifiers [ConceptId] as parameters followed by a Relationship deleted event [EvRelationshipDelete] with the relationship identifier [RelationshipId] in the [From DTS] parameter.

15. For each XBRL Relationship Information Item [XIS 2.2.14] in the From property [XIS 2.2.8.10] of I2 where a corresponding XBRL Relationship Information Item [XIS 2.2.14] cannot be found in the From property [XIS 2.2.8.10] of I1 this condition is not satisfied. In this case, Processors MUST raise a Concept From event [EvConceptRelationshipFrom] with the two concept identifiers [ConceptId] as parameters followed by a Relationship added event [EvRelationshipNew] with the relationship identifier [RelationshipId] in the [To DTS] parameter.

16. For each XBRL Relationship Information Item [XIS 2.2.14] in the To property [XIS 2.2.8.11] of I1 where a corresponding XBRL Relationship Information Item [XIS 2.2.14] in the To property [XIS 2.2.8.11] of I2 exists; both relationships are equivalent if they satisfy all conditions in section 2.2.4 below. Processors MUST raise a Concept To event [EvConceptRelationshipTo] with the two concept identifiers [ConceptId] as parameters if this condition is not satisfied. This event will be the parent of additional events according to section 2.2.4 below.

17. For each XBRL Relationship Information Item [XIS 2.2.14] in the To property [XIS 2.2.8.11] of I1 where a corresponding XBRL Relationship Information Item [XIS 2.2.14] cannot be found in the To property [XIS 2.2.8.11] of I2 this condition is not satisfied. In this case, Processors MUST raise a Concept To event [EvConceptRelationshipTo] with the two concept identifiers [ConceptId] as parameters followed by a Relationship deleted event [EvRelationshipDelete] with the relationship identifier [RelationshipId] in the [From DTS] parameter.

18. For each XBRL Relationship Information Item [XIS 2.2.14] in the To property [XIS 2.2.8.11] of I2 where a corresponding XBRL Relationship Information Item [XIS 2.2.14] cannot be found in the To property [XIS 2.2.8.11] of I1 this condition is not satisfied. In this case, Processors MUST raise a Concept To event [EvConceptRelationshipTo] with the two concept identifiers [ConceptId] as parameters followed by a Relationship added event [EvRelationshipNew] with the relationship identifier [RelationshipId] in the [To DTS] parameter.

19. For each XML Attribute Information Item in the Attributes property [XIS 2.2.8.12] of I1 where a corresponding XML Attribute Information Item in the Attributes property [XIS 2.2.8.12] of I2 exists; both attributes are equivalent if they satisfy all conditions in section 2.2.7 below. Processors MUST raise a Concept Attribute event [EvConceptAttribute] with the two concept identifiers [ConceptId] as parameters if this condition is not satisfied. This event will be the parent of additional events according to section 2.2.7 below.

20. For each XML Attribute Information Item in the Attributes property [XIS 2.2.8.12] of I1 where a corresponding XML Attribute Information Item cannot be found in the Attributes property [XIS 2.2.8.12] of I2 this condition is not satisfied. In this case, Processors MUST raise a Concept Attribute event [EvConceptAttribute] with the two concept identifiers [ConceptId] as parameters followed by an Attribute deleted event [EvAttributeDelete] with the attribute identifier [AttributeId] in the [From DTS] parameter.

21. For each XML Attribute Information Item in the Attributes property [XIS 2.2.8.12] of I2 where a corresponding XML Attribute Information Item cannot be found in the Attributes property [XIS 2.2.8.14] of I1 this condition is not satisfied. In this case, Processors MUST raise a Concept Attribute event [EvConceptAttribute] with the two concept identifiers [ConceptId] as parameters followed by an Attribute added event [EvAttributeNew] with the attribute identifier [AttributeId] in the [To DTS] parameter.

22. For each XML Element Information Item in the Children property [XIS 2.2.8.13] of I1 where a corresponding XML Element Information Item in the Children property [XIS 2.2.8.13] of I2 exists; both XML Elements are equivalent if they satisfy all conditions in section 2.2.6 below. Processors MUST raise a Concept Child event [EvChild] with the two concept identifiers [ConceptId] as parameters if this condition is not satisfied. This event will be the parent of additional events according to section 2.2.6 below.

23. For each XML Element Information Item in the Children property [XIS 2.2.8.13] of I1 where a corresponding XML Element Information Item cannot be found in the Children property [XIS 2.2.8.13] of I2 this condition is not satisfied. In this case, Processors MUST raise a Concept Child event [EvChild] with the two concept identifiers [ConceptId] as parameters followed by a Element node deleted event [EvNodeDeleted] with the XML element identifier [NodeId] in the [From DTS] parameter.

24. For each XML Element Information Item in the Children property [XIS 2.2.8.13] of I2 where a corresponding XML Element Information Item cannot be found in the Children property [XIS 2.2.8.13] of I1 this condition is not satisfied. In this case, Processors MUST raise a Concept Child event [EvChild] with the two concept identifiers [ConceptId] as parameters followed by a Element node added event [EvNodeNew] with the XML element identifier [NodeId] in the [To DTS] parameter.

2.2.3 Comparing two XBRL Tuple Information Items:

Two XBRL Tuple Information Items [XIS 2.2.10] T1 which belongs to the From DTS and T2 which belongs to the To DTS are equivalent if all the following conditions are satisfied.

1. If the value of the Namespace property [XIS 2.2.3.2] of the XBRL Taxonomy Information Item [XIS 2.2.3] referenced in the Parent property [XIS 2.2.8.1] of T1 is equal to the value of the namespace pair [Def 5] of the Namespace property [XIS 2.2.3.2] of the XBRL Taxonomy Information Item [XIS 2.2.3] referenced in the Parent property [XIS 2.2.8.1] of T2 this condition is satisfied. Processors MUST raise a Concept namespace event [EvConceptNamespace] with the two concept identifiers [ConceptId] as parameters if this condition is not satisfied.

2. If the value of the Name property [XIS 2.2.8.2] of T1 is equal to the value of the Name property [XIS 2.2.8.2] of T2 this condition is satisfied. Processors MUST raise a Concept name event [EvConceptName] with the two concept identifiers [ConceptId] as parameters if this condition is not satisfied.

3. If the content of the Type property [XIS 2.2.8.3] of T1 is equivalent to the content of the Type property [XIS 2.2.8.3] of T2 according to section 2.2.8 below this condition is satisfied. Processors MUST raise a Concept Type event [EvConceptType] with the two concept identifiers [ConceptId] as parameters if this condition is not satisfied.

4. If the value of the Substitution Group property [XIS 2.2.8.4] of T1 is equal to the value of the Substitution Group property [XIS 2.2.8.4] of T2 this condition is satisfied. Processors MUST raise a Concept Substitution Group event [EvSubstitutionGroup] with the two concept identifiers [ConceptId] as parameters if this condition is not satisfied.

5. If the value of the Nillable property [XIS 2.2.8.5] of T1 is equal to the value of the Nillable property [XIS 2.2.8.5] of T2 this condition is satisfied. Processors MUST raise a Concept Nillable event [EvNillable] with the two concept identifiers [ConceptId] as parameters if this condition is not satisfied.

6. If the value of the Abstract property [XIS 2.2.8.6] of T1 is equal to the value of the Abstract property [XIS 2.2.8.6] of T2 this condition is satisfied. Processors MUST raise a Concept Abstract event [EvAbstract] with the two concept identifiers [ConceptId] as parameters if this condition is not satisfied.

7. If the value of the Block property [XIS 2.2.8.7] of T1 is equal to the value of the Block property [XIS 2.2.8.7] of T2 this condition is satisfied. Processors MUST raise a Concept Block event [EvBlock] with the two concept identifiers [ConceptId] as parameters if this condition is not satisfied.

8. If the value of the Final property [XIS 2.2.8.9] of T1 is equal to the value of the Final property [XIS 2.2.8.9] of T2 this condition is satisfied. Processors MUST raise a Concept Final event [EvFinal] with the two concept identifiers [ConceptId] as parameters if this condition is not satisfied.

9. For each XBRL Relationship Information Item [XIS 2.2.14] in the From property [XIS 2.2.8.10] of T1 where a corresponding XBRL Relationship Information Item [XIS 2.2.14] in the From property [XIS 2.2.8.10] of T2 exist; both relationships are equivalent if they satisfy all conditions in section 2.2.4 below. Processors MUST raise a Concept From event [EvConceptRelationshipFrom] with the two concept identifiers [ConceptId] as parameters if this condition is not satisfied. This event will be the parent of additional events according to section 2.2.4 below.

10. For each XBRL Relationship Information Item [XIS 2.2.14] in the From property [XIS 2.2.8.10] of T1 where a corresponding XBRL Relationship Information Item [XIS 2.2.14] cannot be found in the From property [XIS 2.2.8.10] of T2 this condition is not satisfied. In this case, Processors MUST raise a Concept From event [EvConceptRelationshipFrom] with the two concept identifiers [ConceptId] as parameters followed by a Relationship deleted event [EvRelationshipDelete] with the relationship identifier [RelationshipId] in the [From DTS] parameter.

11. For each XBRL Relationship Information Item [XIS 2.2.14] in the From property [XIS 2.2.8.10] of T2 where a corresponding XBRL Relationship Information Item [XIS 2.2.14] cannot be found in the From property [XIS 2.2.8.10] of T1 this condition is not satisfied. In this case, Processors MUST raise a Concept From event [EvConceptRelationshipFrom] with the two concept identifiers [ConceptId] as parameters followed by a Relationship added event [EvRelationshipNew] with the relationship identifier [RelationshipId] in the [To DTS] parameter.

12. For each XBRL Relationship Information Item [XIS 2.2.14] in the To property [XIS 2.2.8.11] of T1 where a corresponding XBRL Relationship Information Item [XIS 2.2.14] in the To property [XIS 2.2.8.11] of T2 exists; both relationships are equivalent if they satisfy all conditions in section 2.2.4 below. Processors MUST raise a Concept To event [EvConceptRelationshipTo] with the two concept identifiers [ConceptId] as parameters if this condition is not satisfied. This event will be the parent of additional events according to section 2.2.4 below.

13. For each XBRL Relationship Information Item [XIS 2.2.14] in the To property [XIS 2.2.8.11] of T1 where a corresponding XBRL Relationship Information Item [XIS 2.2.14] cannot be found in the To property [XIS 2.2.8.11] of T2 this condition is not satisfied. In this case, Processors MUST raise a Concept To event [EvConceptRelationshipTo] with the two concept identifiers [ConceptId] as parameters followed by a Relationship deleted event [EvRelationshipDelete] with the relationship identifier [RelationshipId] in the [From DTS] parameter.

14. For each XBRL Relationship Information Item [XIS 2.2.14] in the To property [XIS 2.2.8.11] of T2 where a corresponding XBRL Relationship Information Item [XIS 2.2.14] cannot be found in the To property [XIS 2.2.8.11] of T1 this condition is not satisfied. In this case, Processors MUST raise a Concept To event [EvConceptRelationshipTo] with the two concept identifiers [ConceptId] as parameters followed by a Relationship added event [EvRelationshipNew] with the relationship identifier [RelationshipId] in the [To DTS] parameter.

15. For each XML Attribute Information Item in the Attributes property [XIS 2.2.8.12] of T1 where a corresponding XML Attribute Information Item in the Attributes property [XIS 2.2.8.12] of T2 exists; both attributes are equivalent if they satisfy all conditions in section 2.2.7 below. Processors MUST raise a Concept Attribute event [EvConceptAttribute] with the two concept identifiers [ConceptId] as parameters if this condition is not satisfied. This event will be the parent of additional events according to section 2.2.7 below.

16. For each XML Attribute Information Item in the Attributes property [XIS 2.2.8.12] of T1 where a corresponding XML Attribute Information Item cannot be found in the Attributes property [XIS 2.2.8.12] of T2 this condition is not satisfied. In this case, Processors MUST raise an Concept Attribute event [EvConceptAttribute] with the two concept identifiers [ConceptId] as parameters followed by an Attribute deleted event [EvAttributeDelete] with the attribute identifier [AttributeId] in the [From DTS] parameter.

17. For each XML Attribute Information Item in the Attributes property [XIS 2.2.8.12] of T2 where a corresponding XML Attribute Information Item cannot be found in the Attributes property [XIS 2.2.8.12] of T1 this condition is not satisfied. In this case, Processors MUST raise a Concept Attribute event [EvConceptAttribute] with the two concept identifiers [ConceptId] as parameters followed by an Attribute added event [EvAttributeNew] with the attribute identifier [AttributeId] in the [To DTS] parameter.

18. For each XML Element Information Item in the Children property [XIS 2.2.8.13] of T1 where a corresponding XML Element Information Item in the Children property [XIS 2.2.8.13] of T2 exists; both XML Elements are equivalent if they satisfy all conditions in section 2.2.6 below. Processors MUST raise a Concept Child event [EvChild] with the two concept identifiers [ConceptId] as parameters if this condition is not satisfied. This event will be the parent of additional events according to section 2.2.6 below.

19. For each XML Element Information Item in the Children property [XIS 2.2.8.13] of T1 where a corresponding XML Element Information Item cannot be found in the Children property [XIS 2.2.8.13] of T2 this condition is not satisfied. In this case, Processors MUST raise a Concept Child event [EvChild] with the two concept identifiers [ConceptId] as parameters followed by a Element node deleted event [EvNodeDeleted] with the XML element identifier [NodeId] in the [From DTS] parameter.

20. For each XML Element Information Item in the Children property [XIS 2.2.8.13] of T2 where a corresponding XML Element Information Item cannot be found in the Children property [XIS 2.2.8.13] of T1 this condition is not satisfied. In this case, Processors MUST raise a Concept Child event [EvChild] with the two concept identifiers [ConceptId] as parameters followed by a Element node added event [EvNodeNew] with the XML element identifier [NodeId] in the [To DTS] parameter.

2.2.4 Comparing two XBRL Relationship Information Items:

Two XBRL Relationship Information Items [XIS 2.2.14] R1 which belongs to the From DTS and R2 which belongs to the To DTS are equivalent if all the following conditions are satisfied.

1. If the object in the From DTS pointed to by the From property [XIS 2.2.14.3] of R1 corresponds to the object in the To DTS pointed to by the From property [XIS 2.2.14.2] of R2 this condition is satisfied. Processors MUST add a Relationship Source event [EvSource] to the parent event with the two relationship identifiers [RelationshipId] as parameters if this condition is not satisfied.

2. If the object in the From DTS pointed to by the To property [XIS 2.2.14.4] of R1 corresponds to the object in the To DTS pointed to by the To property [XIS 2.2.14.4] of R2 this condition is satisfied. Processors MUST add a Relationship Target event [EvTarget] to the parent event with the two relationship identifiers [RelationshipId] as parameters if this condition is not satisfied.

3. If each relationship in the relationship set that precedes R1 [XVS 2.1.1] in the From DTS corresponds to another relationship in the relationship set that precedes R2 [XVS 2.1.1] in the To DTS, or both relationships have no preceding relationship set this condition is satisfied. Processors MUST add a Relationship Previous event [EvPrevious] to the parent event with the two relationship identifiers [RelationshipId] as parameters if this condition is not satisfied.

4. If each relationship in the relationship set that follows R1 [XVS 2.1.2] in the From DTS corresponds to another relationship in the relationship set that follows R2 [XVS 2.1.2] in the To DTS, or both relationships have no a following relationship set this condition is satisfied. Processors MUST add a Relationship Next event [EvNext] to the parent event with the two relationship identifiers [RelationshipId] as parameters if this condition is not satisfied.

5. If the value of the Priority property [XIS 2.2.14.8] of R1 is equal to the value of the Priority property [XIS 2.2.14.8] of R2 this condition is satisfied. Processors MUST add a Relationship Priority event [EvPriority] to the parent event with the two relationship identifiers [RelationshipId] as parameters if this condition is not satisfied.

6. For each XML Attribute Information Item in the Attributes property [XIS 2.2.14.9] of R1 where a corresponding XML Attribute Information Item in the Attributes property [XIS 2.2.14.9] of R2 exists; both attributes are equivalent if they satisfy all conditions in section 2.2.7 below. Processors MUST add a Relationship Attribute event [EvRelationshipAttribute] with the two relationship identifiers [RelationshipId] to the parent event if this condition is not satisfied. This event will be the parent of additional events according to section 2.2.7 below.

7. For each XML Attribute Information Item in the Attributes property [XIS 2.2.14.9] of R1 where a corresponding XML Attribute Information Item cannot be found in the Attributes property [XIS 2.2.14.9] of R2 this condition is not satisfied. In this case, Processors MUST add a Relationship Attribute event [EvRelationshipAttribute] with the two relationship identifiers [RelationshipId] to the parent event followed by a Attribute deleted event [EvAttributeDelete] with the attribute identifier [AttributeId] in the [From DTS] parameter.

8. For each XML Attribute Information Item in the Attributes property [XIS 2.2.14.9] of R2 where a corresponding XML Attribute Information Item cannot be found in the Attributes property [XIS 2.2.14.9] of R1 this condition is not satisfied. In this case, Processors MUST add a Relationship Attribute event [EvRelationshipAttribute] with the two relationship identifiers [RelationshipId] to the parent event followed by a Attribute added event [EvAttributeNew] with the attribute identifier [AttributeId] in the [To DTS] parameter.

2.2.5 Comparing two XBRL Resource Information Items:

Two XBRL Resource Information Items [XIS 2.2.15] X1 which belongs to the From DTS and X2 which belongs to the To DTS are equivalent if all the following conditions are satisfied:

1. If the value of the Type property [XIS 2.2.15.2] of X1 is equal to the value of the Type property [XIS 2.2.15.2] of X2 this condition is satisfied. Processors MUST raise a Resource Type event [EvResourceType] with the two resource identifiers [ResourceId] as parameters if this condition is not satisfied.

2. If the value of the URI property [XIS 2.2.5.4] of the XBRL Role Type Information Item [XIS 2.2.5] referenced in the Role property [XIS 2.2.15.3] of X1 is equal to the value of the value of the URI property [XIS 2.2.5.4] of the XBRL Role Type Information Item [XIS 2.2.5] referenced in the Role property [XIS 2.2.15.3] of X2 this condition is satisfied. Processors MUST raise a Resource Role event [EvRole] with the two resource identifiers [ResourceId] as parameters if this condition is not satisfied.

3. For each XBRL Relationship Information Item [XIS 2.2.14] in the From property [XIS 2.2.15.5] of X1 where a corresponding XBRL Relationship Information Item [XIS 2.2.14] in the From property [XIS 2.2.15.5] of X2 exist; both relationships are equivalent if they satisfy all conditions in section 2.2.4 above. Processors MUST raise a Resource From event [EvResourceFrom] with the two resource identifiers [ResourceId] as parameters if this condition is not satisfied. This event will be the parent of additional events according to section 2.2.4 above.

4. For each XBRL Relationship Information Item [XIS 2.2.14] in the From property [XIS 2.2.15.5] of X1 where a corresponding XBRL Relationship Information Item [XIS 2.2.14] cannot be found in the From property [XIS 2.2.15.5] of X2 this condition is not satisfied. In this case, Processors MUST raise a Resource From event [EvResourceFrom] with the two resource identifiers [ResourceId] as parameters followed by a Relationship deleted event [EvRelationshipDelete] with the relationship identifier [RelationshipId] in the [From DTS] parameter.

5. For each XBRL Relationship Information Item [XIS 2.2.14] in the From property [XIS 2.2.15.5] of X2 where a corresponding XBRL Relationship Information Item [XIS 2.2.14] cannot be found in the From property [XIS 2.2.15.5] of X1 this condition is not satisfied. In this case, Processors MUST raise a Resource From event [EvResourceFrom] with the two resource identifiers [ResourceId] as parameters followed by a Relationship added event [EvRelationshipNew] event with the relationship identifier [RelationshipId] as a parameter.

6. For each XBRL Relationship Information Item [XIS 2.2.14] in the To property [XIS 2.2.15.6] of X1 where a corresponding XBRL Relationship Information Item [XIS 2.2.14] in the To property [XIS 2.2.15.6] of X2 exists; both relationships are equivalent if they satisfy all conditions in section 2.2.4 above. Processors MUST raise a Resource To event [EvResourceTo] with the two resource identifiers [ResourceId] as parameters if this condition is not satisfied. This event will be the parent of additional events according to section 2.2.4 above.

7. For each XBRL Relationship Information Item [XIS 2.2.14] in the To property [XIS 2.2.15.6] of X1 where a corresponding XBRL Relationship Information Item [XIS 2.2.14] cannot be found in the To property [XIS 2.2.15.6] of X2 this condition is not satisfied. In this case, Processors MUST raise a Resource To event [EvResourceTo] with the two resource identifiers [ResourceId] as parameters followed by a Relationship deleted event [EvRelationshipDelete] with the relationship identifier [RelationshipId] in the [From DTS] parameter.

8. For each XBRL Relationship Information Item [XIS 2.2.14] in the To property [XIS 2.2.15.6] of X2 where a corresponding XBRL Relationship Information Item [XIS 2.2.14] cannot be found in the To property [XIS 2.2.15.6] of X1 this condition is not satisfied. In this case, Processors MUST raise a Resource To event [EvResourceTo] with the two resource identifiers [ResourceId] as parameters followed by a Relationship added event [EvRelationshipNew] with the relationship identifier [RelationshipId] in the [To DTS] parameter.

9. For each XML Attribute Information Item in the Attributes property [XIS 2.2.15.7] of X1 where a corresponding XML Attribute Information Item in the Attributes property [XIS 2.2.15.7] of X2 exists; both attributes are equivalent if they satisfy all conditions in section 2.2.7 below. Processors MUST raise a Resource Attribute event [EvResourceAttribute] with the two resource identifiers [ResourceId] as parameters if this condition is not satisfied. This event will be the parent of additional events according to section 2.2.7 below.

10. For each XML Attribute Information Item in the Attributes property [XIS 2.2.15.7] of X1 where a corresponding XML Attribute Information Item cannot be found in the Attributes property [XIS 2.2.15.7] of X2 this condition is not satisfied. In this case, Processors MUST raise a Resource Attribute event [EvResourceAttribute] with the two resource identifiers [ResourceId] as parameters followed by an Attribute deleted event [EvAttributeDelete] with the attribute identifier [AttributeId] in the [From DTS] parameter.

11. For each XML Attribute Information Item in the Attributes property [XIS 2.2.15.7] of X2 where a corresponding XML Attribute Information Item cannot be found in the Attributes property [XIS 2.2.15.7] of X1 this condition is not satisfied. In this case, Processors MUST raise a Resource Attribute event [EvResourceAttribute] with the two resource identifiers [ResourceId] as parameters followed by a Attribute added event [EvAttributeNew] with the attribute identifier [AttributeId] in the [To DTS] parameter.

12. If the resource has complex content and for each node N1 in the sequence of nodes of the Element property [XIS 2.2.15.4] of X1; a node N2 exist that is the node in the same position in the sequence of nodes in the Element property [XIS 2.2.15.4] of X2 and N1 is s-equal2 to the node N2 (except for the attributes in the XLINK namespace and the id attributes that must be skipped) this condition is satisfied. Processors MUST raise a Resource Content event [EvContent] with the two resource identifiers [ResourceId] as parameters if this condition is not satisfied. This event will be the parent of additional events according to section 2.2.6 below.

13. If the resource has complex content and for each node N1 in the sequence of nodes of the Element property [XIS 2.2.15.4] of X1; a node N2 that is the node in the same position in the sequence of nodes in the Element property [XIS 2.2.15.4] of X2 does not exist this condition is not satisfied. In this case, a Processor MUST raise a Resource Content event [EvContent] with the two resource identifiers [ResourceId] as parameters followed by an Element node deleted event [EvNodeDeleted] with the XML Element Identifier [NodeId] in the [From DTS] parameter.

14. If the resource has complex content and for each node N2 in the sequence of nodes of the Element property [XIS 2.2.15.4] of X2; a node N1 that is the node in the same position in the sequence of nodes in the Element property [XIS 2.2.15.4] of X1 does not exist this condition is not satisfied. In this case, a Processor MUST raise a Resource Content event [EvContent] with the two resource identifiers [ResourceId] as parameters followed by an Element node added event [EvNodeNew] with the XML Element Identifier [NodeId] in the [To DTS] parameter.

15. If the resource has simple content and the value of the Value property [XIS 2.2.15.8] of X1 is s-equal2 to the value of the Value property [XIS 2.2.15.8] of X2 this condition is satisfied. Processors MUST raise a Resource Value event [EvValue] with the two resource identifiers [ResourceId] as parameters if this condition is not satisfied.

2.2.6 Comparing two XML Element Information Items:

If two XML Element Information Items E1 and E2 are s-equal2 except for the attributes in the XLINK namespace and the id attribute that are always considered equivalent this condition is satisfied. Processors MUST add a Not s-equal2 nodes event [EvNodesInequality] to the parent event with the two element identifiers [NodeId] as parameters if this condition is not satisfied.

2.2.7 Comparing two XML Attribute Information Items:

If two XML Attribute Information items A1 and A2 are s-equal2 nodes this condition is satisfied. The s-equal2 operation is defined in section 2.3 below. Processors MUST raise a Not s-equal2 attributes event [EvAttributesInequality] to the parent event with the two attribute identifiers [AttributeId] as parameters if this condition is not satisfied.

2.2.8 Comparing two Schema Type Definitions:

This document does not impose any specific XSD object model, but the definition of equality of two XML types is necessary in order to properly implement a mechanism that identifies if an item or tuple definition has changed from one taxonomy version to another.

Therefore, it is the responsibility of the vendor specific object model to provide information about the equality of Item and Tuple data types.

As long as two different XSD data types are recognized as not equal, the amount of information provided about the differences is vendor dependant.

The XVS conformance suite provides a minimum set of test cases about differences in data type definitions. Processors MUST recognize changes in XSD data types at least for the types of use cases defined in the XVS conformance suite.

2.3 Definition of the s-equal2 operation between two sequences of XML nodes:

The s-equal2 operation is the same operation defined in section 4.10 of the [XBRL] specification replacing XPath 1.0 with XPath 2.0 in the definition of the x-equal operation and with the "XPath 1.0 compatibility mode" property set to false in the static context (See the implementation note below).

IMPLEMENTATION NOTE: The [XBRL] 2.1 specification is based on XPath 1.0. According to section 5.3 of the XPath 1.0 specification, the content of attributes is always a string-value rather than a QName. XBRL APIs implementing the equivalence operation between XML Information Items should take care of this and normalize the prefixes of QNames in order to effectively compare QNames and not their lexical representation.

2.4 Rules of correspondence between Information Items

This section describes the conditions that two information items MUST satisfy in order to be considered a correspondent information item in the To DTS of another information item that exist in the From DTS.

2.4.1 Correspondence of Concept Definitions

Two concept definitions A and B are in correspondence if both are XBRL Concept Information Items [XIS 2.2.8], and the QName defined with the Namespace property [XIS 2.2.3.2] of the Parent property [XIS 2.2.8.1] of concept B and Name property [XIS 2.2.8.2] of concept B is equal to the concept pair [Def 7] of concept A.

2.4.2 Correspondence of Relationships

Two relationships A and B are in correspondence if all the following conditions are satisfied:

· The correspondent Information Item of the content of the From property [XIS 2.2.14.3] of relationship A is the Information Item in the content of the From property [XIS 2.2.14.3] of relationship B. For the identification of the correspondent content in the From property [XIS 2.2.14.3] of the relationship A the section 2.4.1, 2.4.3 or 2.4.5 must be used according to the content type, and

· The URI pair [Def 6] of the URI property [XIS 2.2.5.4] of the role property [XIS 2.2.12.3] of the Extended Link [XIS 2.2.12] that is the Parent property [XIS 2.2.14.1] of the relationship A is equal to the value of the URI property [XIS 2.2.5.4] of the role property [XIS 2.2.12.3] of the Extended Link [XIS 2.2.12] that is the Parent property [XIS 2.2.14.1] of the relationship B, and

· The Type property [XIS 2.2.14.2] of relationship A is equal to the Type property [XIS 2.2.14.2] of relationship B, and

· The URI property [XIS 2.2.6.4] of the Arcrole property [XIS 2.2.14.5] of relationship A is equal to the URI property [XIS 2.2.6.4] of the Arcrole property [XIS 2.2.14.5] of relationship B, and

· The correspondent Information Item of the content of the To property [XIS 2.2.14.4] of relationship A is the Information Item in the content of the To property [XIS 2.2.14.4] of relationship B. For the identification of the correspondent content in the To property [XIS 2.2.14.4] of the relationship A the section 2.4.1, 2.4.3 or 2.4.5 must be used according to the content type, and

2.4.3 Correspondence of Resources

Two resources A and B are in correspondence if both are XBRL Resource Information Items [XIS 2.2.15], and there is a resource pair defined [Def 8].

2.4.4 Correspondence of XML Attributes

Two Attribute Information Items A1 and A2 are in correspondence if their node names are equal. The attribute value is not used to find the correspondent attribute of another attribute.

2.4.5 Correspondence of XML Element Nodes

Two XML Element nodes N1 and N2 are in correspondence if they are s-equal2 nodes.

3 The content model of the versioning report

A versioning report is a set of one or more version information items.

A version information item is the set of information that documents what happened between to concepts or resources between two DTSs.

The content of a version information item is represented in figure 2 below.

Figure 2: Content of a version information item

Each one of the containers in the figure represents different pieces of information about changes made to a taxonomy.

Assignments can:

· group actions made to a DTS, and

· be categorized in order to allow business users to filter what information they want to access to, and

· be documented separately, and

· are optional content in a versioning report.

Actions can:

· group a set of events of differences between the From DTS and the To DTS, and

· provide a semantic meaning about the change, and

· provide specific human readable documentation.

Looking at the information in the versioning report as if it was a database, the in-scope documentation for a change is the result of a query that identifies the set of human readable documentation that satisfies the query conditions.

The query conditions can be completely generic or very explicit to a particular change event or change event path. The in-scope documentation can range from being as extensive as the whole report for generic queries to being as explicit as the documentation related to a specific action for a particular event made to a particular concept.

3.1 Complete versioning reports

A complete versioning report is a versioning report that contains in-scope documentation for every Difference Path [Def 2] generated by not satisfying conditions in section 2.2 above.

This specification does not impose any requirement that versioning reports be complete.

The completeness of a versioning report can be validated by tools.

3.2 The Concept or resource A component

This component represents concepts or resources defined in the From DTS.

When a concept or resource defined in the To DTS has no correspondence with any concept or resource defined in the From DTS there is no concept or resource A component in the event.

Concepts or resources referenced in this component can have a one to many relationships with Actions.

3.3 The Concept or resource B component

This component represents concepts or resources defined in the To DTS.

When a concept or resource defined in the From DTS has no correspondence with any concept or resource defined in the To DTS there is no concept or resource B component in the event.

Concepts or resources referenced in this component can have a one to many relationships with Actions.

3.4 The Assignment component

This is a container of human readable documentation related to the reasons of a set of actions.

The existence of assignments in a versioning report is optional.

Assignments can be categorized.

An assignment with no relationships to actions represents unimplemented but solicited changes to a DTS.

3.5 The Action component

This is a container of a set of multiple events and documentation connected to the concept or resource referenced in Concept or resource A component and/or the Concept or resource B component.

Action components may be referenced from one or more assignments. Action components may not be referenced by any assignment.

An action component referenced from Concept or resource A components and with references to Concept or resource B components represents changes made to the concept or resource definitions that are in correspondence.

Action components referenced from Concept or resource A components without references to Concept or resource B components represents concepts deleted from the From DTS.

Action components referencing Concept or resource B components without being referenced by Concept or resource A components represents new concepts added to the To DTS.

Action components may contain no events. In this case they play the role of a container for generic information related to the new version of the DTS.

3.6 The Event component

One Event is a container of a set of zero or more differences between the From DTS and the To DTS.

Differences can be grouped together in a set to provide semantic meaning to the Event. The semantic meaning of different groups of differences is defined in table 1 on section 4.3.1 below.

One single Action may have zero or more Events.

3.7 The Differences component

This component represents one Difference Path [Def 2].

3.8 The Categories component

This box represents a set of code categories for the changes. There are some pre-defined categories in this specification.

a. Errata

b. Business

c. Technical

Each project is able to define new sub categories of these categories.

3.9 The Documentation component

This is represents the text of the human readable documentation for the in-scope change event.

3.10The Version component

This component represents contextual information about the DTSs where Concept or resource A and Concept or resource B is defined. This information includes:

a. The starting point of the DTS Concept or resource A belongs to.

b. The starting point of the DTS Concept or resource B belongs to.

c. The namespace mapping information that identifies the correspondence between namespace definitions in the From DTS and namespace definitions in the To DTS.

d. The role mapping information that identifies the correspondence between role URIs used in the From DTS and role URIs used in the To DTS.

e. The concept mapping information that identifies the correspondence between concept definitions in the From DTS and concept definitions in the To DTS.

f. The resource mapping information that identifies the correspondence between resource definitions in the From DTS and resource definitions in the To DTS.

Only one instantiation of the version container is allowed per versioning report.

The namespace mapping information is a set of namespace pairs identifying which is the From and To namespaces.

[Def 5] The namespace pair of the From namespace is the To namespace defined in the namespace mapping or the same From namespace if none is explicitly defined in the namespace mapping. This relationship is symmetric.

The role mapping information is a set of URI pairs identifying which are the From URI and the To URI.

[Def 6] The role URI pair of the From role URI is the To URI defined in the role mapping or the same From URI if none is explicitly defined in the role mapping. This relationship is symmetric.

The concept mapping information is a set of QName pairs identifying which are the From concept QName and the To concept QName.

[Def 7] The concept pair of a From concept QName is the To concept QName defined in the concept mapping or the same From concept QName if none is explicitly defined in the concept mapping. This relationship is symmetric.

The resource mapping information is a set of XPointer reference pairs identifying which are the From resource and the To resource.

[Def 8] The resource pair of a From resource is the To resource defined in the resource mapping table. This relationship is symmetric.

4 The versioning report syntax

This specification defines a normative XBRL 2.1 DTS to generate versioning reports.

4.1 DTS modules

The taxonomy schema is defined as follows:

<schema

elementFormDefault="qualified"

targetNamespace="http://xbrl.org/2007/versioning"

xmlns="http://www.w3.org/2001/XMLSchema"

xmlns:ver="http://xbrl.org/2007/versioning"

xmlns:xbrli="http://www.xbrl.org/2003/instance">

The versioning DTS is serialized in three modules. The Taxonomy schema and two Linkbases:

<link:linkbaseRef

xlink:type="simple"

xlink:href="versioning-2007-10-03-presentation.xml"

xlink:role=http://www.xbrl.org/2003/role/presentationLinkbaseRef

xlink:arcrole="http://www.w3.org/1999/xlink/properties/linkbase"/>

<link:linkbaseRef

xlink:type="simple"

xlink:href="versioning-2007-10-03-label.xml"

4.3.1 Main concept definitions

The Version Information tuple represents the serialization of the content of the "The Version " defined in section 3.10 above.

</sequence>

</complexType>

</element>

The instance document containing a versioning report is limited to one occurrence of the version tuple.

The tuple contains the URL of the From DTS and To DTS starting points and the three optional mapping rules.

The From DTS and To DTS starting points are defined using xbrli:items as follows:

<element

name="fromURL"

id="ver_fromDTS"

type="xbrli:anyURIItemType"

substitutionGroup="xbrli:item"

xbrli:periodType="instant"/>

<element

name="toURL"

id="ver_toDTS"

type="xbrli:anyURIItemType"

substitutionGroup="xbrli:item"

xbrli:periodType="instant"/>

The namesapace mapping table is defined as follows:

<element

name="nsMap"

id="ver_nsMap"

substitutionGroup="xbrli:tuple">

<all>

</all>

</complexType>

</element>

The role mapping table is defined as follows:

<all>

</all>

</complexType>

</element>

The concept mapping table is defined as follows:

<all>

</all>

</complexType>

</element>

The resource mapping table is defined as follows:

<all>

</all>

</complexType>

</element>

The following elements are the content of the mapping tables defined above.

<element

name="fromConcept"

id="ver_fromConcept"

type="xbrli:QNameItemType"

substitutionGroup="xbrli:item"

nillable="true"

xbrli:periodType="instant"/>

<element

name="toConcept"

id="ver_toConcept"

type="xbrli:QNameItemType"

substitutionGroup="xbrli:item"

nillable="true"

xbrli:periodType="instant"/>

<element

name="fromURI"

id="ver_fromURI"

type="xbrli:anyURIItemType"

substitutionGroup="xbrli:item"

xbrli:periodType="instant"/>

<element

name="toURI"

id="ver_toURI"

type="xbrli:anyURIItemType"

substitutionGroup="xbrli:item"

xbrli:periodType="instant"/>

<element

name="fromResource"

id="ver_fromResource"

type="xbrli:anyURIItemType"

substitutionGroup="xbrli:item"

nillable="true"

xbrli:periodType="instant"/>

<element

name="toResource"

id="ver_toResource"

type="xbrli:anyURIItemType"

substitutionGroup="xbrli:item"

nillable="true"

xbrli:periodType="instant"/>

The following concept definition corresponds to the "The Assignment " in section 3.4 above.

<element

name="assignment"

id="ver_assignment"

type="ver:categoryTupleType"

substitutionGroup="xbrli:tuple"/>

</sequence>

</complexType>

The following concept definition corresponds to the "The Categories " in section 3.8 above.

<element

name="category"

id="ver_category"

type="ver:emptyTupleType"

substitutionGroup="xbrli:tuple"

abstract="true"/>

</complexType>

The following three concept definitions are the three categories defined in this specification.

<element

name="erratum"

id="ver_categoryErratum"

type="ver:emptyTupleType"

substitutionGroup="ver:category"/>

<element

name="business"

id="ver_categoryBusiness"

type="ver:emptyTupleType"

substitutionGroup="ver:category"/>

<element

name="technical"

id="ver_categoryTechnical"

type="ver:emptyTupleType"

substitutionGroup="ver:category"/>

An assignment is serialized in the instance document by an instantiation of a tuple with no content. That tuple may contain an ID used within a generic Linkbase to attach human readable documentation to the assignment.

The following concept definition corresponds to the "The Action " in section 3.5 above.

</sequence>

</complexType>

</element>

The action acts as a container of event containers that group several differences together.

Actions can be documented in the generic Linkbase attached to the instance document.

The following concept definition corresponds to the definition of "The Differences " in section 3.7 above.

<element

maxOccurs="unbounded"

minOccurs="0"

ref="ver:EvConceptNamespace"/>

<element

maxOccurs="unbounded"

minOccurs="0"

ref="ver:EvConceptName"/>

<element

maxOccurs="unbounded"

minOccurs="0"

ref="ver:EvConceptDelete"/>

<element

maxOccurs="unbounded"

minOccurs="0"

ref="ver:EvConceptNew"/>

<element

maxOccurs="unbounded"

minOccurs="0"

ref="ver:EvConceptType"/>

<element

maxOccurs="unbounded"

minOccurs="0"

ref="ver:EvSubstitutionGroup"/>

<element

maxOccurs="unbounded"

minOccurs="0"

ref="ver:EvPeriodType"/>

<element

maxOccurs="unbounded"

minOccurs="0"

ref="ver:EvNillable"/>

<element

maxOccurs="unbounded"

minOccurs="0"

ref="ver:EvAbstract"/>

<element

maxOccurs="unbounded"

minOccurs="0"

ref="ver:EvBlock"/>

<element

maxOccurs="unbounded"

minOccurs="0"

ref="ver:EvBalance"/>

<element

maxOccurs="unbounded"

minOccurs="0"

ref="ver:EvDefault"/>

<element

maxOccurs="unbounded"

minOccurs="0"

ref="ver:EvFixed"/>

<element

maxOccurs="unbounded"

minOccurs="0"

ref="ver:EvFinal"/>

<element

maxOccurs="unbounded"

minOccurs="0"

ref="ver:EvConceptRelationshipFrom"/>

<element

maxOccurs="unbounded"

minOccurs="0"

ref="ver:EvConceptRelationshipTo"/>

<element

maxOccurs="unbounded"

minOccurs="0"

ref="ver:EvConceptAttribute"/>

<element

maxOccurs="unbounded"

minOccurs="0"

ref="ver:EvChild"/>

<element

maxOccurs="unbounded"

minOccurs="0"

ref="ver:EvResourceDelete"/>

<element

maxOccurs="unbounded"

minOccurs="0"

ref="ver:EvResourceNew"/>

<element

maxOccurs="unbounded"

minOccurs="0"

ref="ver:EvResourceType"/>

<element

maxOccurs="unbounded"

minOccurs="0"

ref="ver:EvRole"/>

<element

maxOccurs="unbounded"

minOccurs="0"

ref="ver:EvResourceFrom"/>

<element

maxOccurs="unbounded"

minOccurs="0"

ref="ver:EvResourceTo"/>

<element

maxOccurs="unbounded"

minOccurs="0"

ref="ver:EvResourceAttribute"/>

<element

maxOccurs="unbounded"

minOccurs="0"

ref="ver:EvContent"/>

<element

maxOccurs="unbounded"

minOccurs="0"

ref="ver:EvValue"/>

</choice>

</sequence>

</complexType>

</element>

Only events that can be considered starting events [Def 3] are allowed in content of the event tuple.

An event tuple may contain zero or more difference paths [Def 2]. Grouping several difference paths together into the same event container provides additional semantics. The following table contains the semantic meaning of different difference path groups:

Table 1: Semantic meaning of a group of differences

A group of	Means
One EvConceptDelete event and one EvConceptNew	New concept definition replaces old concept definition
One EvConceptDelete event and more than one EvConceptNew	There is a concept split. The concept definition in the From DTS no longer has the same semantic meaning because part of its semantic is now divided into several other concept definitions. False EvConceptDelete of the concept in the From DTS followed by a false EvConceptNew of the correspondent concept in the To DTS is allowed to indicate a situation in which the old concept has not been deleted from the DTS.
One EvConceptNew event and more than one EvConceptDelete	There is a concept join.

4.3.2 Events

The following concept definition and type definition corresponds to the abstract representation of an event.

<element

name="diff"

id="ver_diff"

type="ver:nestedEventType"

substitutionGroup="xbrli:tuple"

abstract="true"

nillable="false"/>

</choice>

</sequence>

</complexType>

Subsequent events defined in this specification are derived by restriction of this abstract event type and are valid substitutes for the diff concept definition.

Some intermediate complex types are defined in order to facilitate the definition of the required event concepts.

4.3.2.1 Intermediate event types

The finalEventType type definition represents an event that is the ending event in a difference path [Def 4]. An event whose type is derived of this type definition will not have the possibility to contain nested events.

</sequence>

</restriction>

</complexContent>

</complexType>

The finalDeleteEventType type definition is an intermediate type used to define a final event type that contains a From DTS parameter but no To DTS parameter.

</sequence>

</restriction>

</complexContent>

</complexType>

The finalNewEventType type definition is an intermediate type used to define a final event type that contains a To DTS parameter but no From DTS parameter.

</sequence>

</restriction>

</complexContent>

</complexType>

The hasRelationshipEventType type is defined to constraint the valid nested events that an event that is the parent of another event related to a relationship may have.

</choice>

</sequence>

</restriction>

</complexContent>

</complexType>

The hasAttributeEventType type is defined to constraint the valid nested events that an event that is the parent of another event related to an attribute may have.

</choice>

</sequence>

</restriction>

</complexContent>

</complexType>

The hasChildEventType type is defined to constraint the valid nested events that an event that is the parent of another event related to XML nodes that appear as child of some information items can have.

</choice>

</sequence>

</restriction>

</complexContent>

</complexType>

4.3.2.2 Events related to concept definitions

The conceptFinalEventType type definition is a final event type with parameters pointing to concept definitions in the From DTS and in the To DTS. See the section "The concept identifier" 4.3.3.1 below.

</sequence>

</restriction>

</complexContent>

</complexType>

The following events are using this type definition:

<element

name="EvConceptNamespace"

id="ver_EvConceptNamespace"

type="ver:conceptFinalEventType"

substitutionGroup="ver:diff"/>

<element

name="EvConceptName"

id="ver_EvConceptName"

type="ver:conceptFinalEventType"

substitutionGroup="ver:diff"/>

<element

name="EvConceptType"

id="ver_EvConceptType"

type="ver:conceptFinalEventType"

substitutionGroup="ver:diff"/>

<element

name="EvSubstitutionGroup"

id="ver_EvSubstitutionGroup"

type="ver:conceptFinalEventType"

substitutionGroup="ver:diff"/>

<element

name="EvPeriodType"

id="ver_EvPeriodType"

type="ver:conceptFinalEventType"

substitutionGroup="ver:diff"/>

<element

name="EvNillable"

id="ver_EvNillable"

type="ver:conceptFinalEventType"

substitutionGroup="ver:diff"/>

<element

name="EvAbstract"

id="ver_EvAbstract"

type="ver:conceptFinalEventType"

substitutionGroup="ver:diff"/>

<element

name="EvBlock"

id="ver_EvBlock"

type="ver:conceptFinalEventType"

substitutionGroup="ver:diff"/>

<element

name="EvBalance"

id="ver_EvBalance"

type="ver:conceptFinalEventType"

substitutionGroup="ver:diff"/>

<element

name="EvDefault"

id="ver_EvDefault"

type="ver:conceptFinalEventType"

substitutionGroup="ver:diff"/>

<element

name="EvFixed"

id="ver_EvFixed"

type="ver:conceptFinalEventType"

substitutionGroup="ver:diff"/>

<element

name="EvFinal"

id="ver_EvFinal"

type="ver:conceptFinalEventType"

substitutionGroup="ver:diff"/>

The conceptDeleteEventType type definition is a final event type with a parameter pointing to a concept definition in the From DTS. See the section "The concept identifier" 4.3.3.1 below.

</sequence>

</restriction>

</complexContent>

</complexType>

The following event is using this type definition:

<element

name="EvConceptDelete"

id="ver_EvConceptDelete"

type="ver:conceptDeleteEventType"

substitutionGroup="ver:diff"/>

The conceptNewEvenType type definition is a final event type with a parameter pointing to a concept definition in the To DTS. See the section "The concept identifier" 4.3.3.1 below.

</sequence>

</restriction>

</complexContent>

</complexType>

The following event is using this type definition:

<element

name="EvConceptNew"

id="ver_EvConceptNew"

type="ver:conceptNewEventType"

substitutionGroup="ver:diff"/>

The conceptHasRelationshipEventType type definition is an event type that contains a nested event related to a relationship and parameters pointing to concept definitions in the From DTS and in the To DTS. See the section "The concept identifier" 4.3.3.1 below.

</choice>

</sequence>

</restriction>

</complexContent>

</complexType>

The following events are using this type definition:

<element

name="EvConceptRelationshipFrom"

id="ver_EvConceptRelationshipFrom"

type="ver:conceptHasRelationshipEventType"

substitutionGroup="ver:diff"/>

<element

name="EvConceptRelationshipTo"

id="ver_EvConceptRelationshipTo"

type="ver:conceptHasRelationshipEventType"

substitutionGroup="ver:diff"/>

The conceptHasAttributeEventType type definition is an event type that contains a nested event related to an attribute and parameters pointing to concept definitions in the From DTS and in the To DTS. See the section "The concept identifier" 4.3.3.1 below.

</choice>

</sequence>

</restriction>

</complexContent>

</complexType>

The following event is using this type definition:

<element

name="EvConceptAttribute"

id="ver_EvConceptAttribute"

type="ver:conceptHasAttributeEventType"

substitutionGroup="ver:diff"/>

The conceptHasChildEventType type definition is an event type that contains a nested event related to a XML Node that is child of the concept definition and parameters pointing to concept definitions in the From DTS and in the To DTS. See the section "The concept identifier" 4.3.3.1 below.

</choice>

</sequence>

</restriction>

</complexContent>

</complexType>

The following event is using this type definition:

<element

name="EvChild"

id="ver_EvChild"

type="ver:conceptHasChildEventType"

substitutionGroup="ver:diff"/>

4.3.2.3 Events related to relationships

The relationshipFinalEventType type definition is a final event with parameters pointing to relationship definitions in the From DTS and in the To DTS. See the section "The relationship identifier" 4.3.3.2 below.

</sequence>

</restriction>

</complexContent>

</complexType>

The following events are using this type definition:

<element

name="EvSource"

id="ver_EvSource"

type="ver:relationshipFinalEventType"

substitutionGroup="ver:diff"/>

<element

name="EvTarget"

id="ver_EvTarget"

type="ver:relationshipFinalEventType"

substitutionGroup="ver:diff"/>

<element

name="EvPrevious"

id="ver_EvPrevious"

type="ver:relationshipFinalEventType"

substitutionGroup="ver:diff"/>

<element

name="EvNext"

id="ver_EvNext"

type="ver:relationshipFinalEventType"

substitutionGroup="ver:diff"/>

<element

name="EvPriority"

id="ver_EvPriority"

type="ver:relationshipFinalEventType"

substitutionGroup="ver:diff"/>

The relationshipDeleteEventType type definition is a final event type with parameters pointing to a relationship in the From DTS. See the section "The relationship identifier" 4.3.3.2 below.

</sequence>

</restriction>

</complexContent>

</complexType>

The following event is using this type definition:

<element

name="EvRelationshipDelete"

id="ver_EvRelationshipDelete"

type="ver:relationshipDeleteEventType"

substitutionGroup="ver:diff"/>

The relationshipNewEventType type definition is a final event type with parameters pointing to a relationship in the To DTS. See the section "The relationship identifier" 4.3.3.2 below.

</sequence>

</restriction>

</complexContent>

</complexType>

The following event is using this type definition:

<element

name="EvRelationshipNew"

id="ver_EvRelationshipNew"

type="ver:relationshipNewEventType"

substitutionGroup="ver:diff"/>

The relationshipHasAttributeEventType type definition is a nested event type whose content is another event related to an attribute and with parameters pointing to a relationship in the From DTS and in the To DTS. See the section "The relationship identifier" 4.3.3.2 below.

</choice>

</sequence>

</restriction>

</complexContent>

</complexType>

The following event is using this type definition:

<element

name="EvRelationshipAttribute"

id="ver_EvRelationshipAttribute"

type="ver:relationshipHasAttributeEventType"

substitutionGroup="ver:diff"/>

4.3.2.4 Events related to resources

The resourceFinalEventType type definition is a final event type with parameters pointing to resources in the From DTS and in the To DTS. See the section "The resource identifier" 4.3.3.3 below.

</sequence>

</restriction>

</complexContent>

</complexType>

The following events are using this type definition:

<element

name="EvResourceType"

id="ver_EvResourceType"

type="ver:resourceFinalEventType"

substitutionGroup="ver:diff"/>

<element

name="EvRole"

id="ver_EvRole"

type="ver:resourceFinalEventType"

substitutionGroup="ver:diff"/>

<element

name="EvValue"

id="ver_EvValue"

type="ver:resourceFinalEventType"

substitutionGroup="ver:diff"/>

The resourceDeleteEventType type definition is a final event type with a parameter pointing to a resource in the From DTS. See the section "The resource identifier" 4.3.3.3 below.

</sequence>

</restriction>

</complexContent>

</complexType>

The following event is using this type definition:

<element

name="EvResourceDelete"

id="ver_EvResourceDelete"

type="ver:resourceDeleteEventType"

substitutionGroup="ver:diff"/>

The resourceNewEventType type definition is a final event type with parameters pointing to a resource in the To DTS. See the section "The resource identifier" 4.3.3.3 below.

</sequence>

</restriction>

</complexContent>

</complexType>

The following event is using this type definition:

<element

name="EvResourceNew"

id="ver_EvResourceNew"

type="ver:resourceNewEventType"

substitutionGroup="ver:diff"/>

The resourceHasRelationshipEventType type definition is a nested event type whose content is another event related to a relationship and with parameters pointing to a resources in the From DTS and in the To DTS. See the section "The resource identifier" 4.3.3.3 below.

</choice>

</sequence>

</restriction>

</complexContent>

</complexType>

The following events are using this type definition:

<element

name="EvResourceFrom"

id="ver_EvResourceFrom"

type="ver:resourceHasRelationshipEventType"

substitutionGroup="ver:diff"/>

<element

name="EvResourceTo"

id="ver_EvResourceTo"

type="ver:resourceHasRelationshipEventType"

substitutionGroup="ver:diff"/>

The resourceHasAttributeEventType type definition is a nested event type whose content is another event related to an attribute of the resource and with parameters pointing to resources in the From DTS and in the To DTS. See the section "The resource identifier" 4.3.3.3 below.

</choice>

</sequence>

</restriction>

</complexContent>

</complexType>

The following event is using this type definition:

<element

name="EvResourceAttribute"

id="ver_EvResourceAttribute"

type="ver:resourceHasAttributeEventType"

substitutionGroup="ver:diff"/>

The resourceHasChildEventType type definition is a nested event type whose content is another event related to an XML Node that is child of the resource and with parameters pointing to resources in the From DTS and in the To DTS. See the section "The resource identifier" 4.3.3.3 below.

</choice>

</sequence>

</restriction>

</complexContent>

</complexType>

The following event is using this type definition:

<element

name="EvContent"

id="ver_EvContent"

type="ver:resourceHasChildEventType"

substitutionGroup="ver:diff"/>

4.3.2.5 Events related to attributes

The attributeDeleteEventType type definition is a final event type with a parameter pointing to an attribute in the From DTS. See the section "The XML Attribute node identifier" 4.3.3.4 below.

</sequence>

</restriction>

</complexContent>

</complexType>

The following event is using this type definition:

<element

name="EvAttributeDelete"

id="ver_EvAttributeDelete"

type="ver:attributeDeleteEventType"

substitutionGroup="ver:diff"/>

The attributeNewEventType type definition is a final event type with a parameter pointing to an attribute in the To DTS. See the section "The XML Attribute node identifier" 4.3.3.4 below.

</sequence>

</restriction>

</complexContent>

</complexType>

The following event is using this type definition:

<element

name="EvAttributeNew"

id="ver_EvAttributeNew"

type="ver:attributeNewEventType"

substitutionGroup="ver:diff"/>

The attributeFinalEventType type definition is a final event type with parameters pointing to attributes in the From DTS and in the To DTS. See the section "The XML Attribute node identifier" 4.3.3.4 below.

</sequence>

</restriction>

</complexContent>

</complexType>

The following event is using this type definition:

<element

name="EvAttributesInequality"

id="ver_EvAttributesInequality"

type="ver:attributeFinalEventType"

substitutionGroup="ver:diff"/>

4.3.2.6 Events related to node elements

The nodeDeleteEventType type definition is a final event type with a parameter pointing to a node that is child of another information item in the From DTS. See the section "The node identifier" 4.3.3.6 below.

</sequence>

</restriction>

</complexContent>

</complexType>

The following event is using this type definition:

<element

name="EvNodeDelete"

id="ver_EvNodeDelete"

type="ver:nodeDeleteEventType"

substitutionGroup="ver:diff"/>

The nodeNewEventType type definition is a final event type with a parameter pointing to a node that is child of another information item in the To DTS. See the section "The node identifier" 4.3.3.6 below.

</sequence>

</restriction>

</complexContent>

</complexType>

The following event is using this type definition:

<element

name="EvNodeNew"

id="ver_EvNodeNew"

type="ver:nodeNewEventType"

substitutionGroup="ver:diff"/>

The nodeFinalEventType type definition is a final event type with parameters pointing to a node that is child of another information item in the From DTS and in the To DTS. See the section "The node identifier" 4.3.3.6 below.

</sequence>

</restriction>

</complexContent>

</complexType>

The following event is using this type definition:

<element

name="EvNodesInequality"

id="ver_EvNodesInequality"

type="ver:nodeFinalEventType"

substitutionGroup="ver:diff"/>

4.3.3 Identifiers

Events defined in this specification require references to concept definitions, relationships, resources, External XML fragments, attributes or nodes that are child of a complex type resource. The identifiers are used to locate such elements in the DTS. This specification defines identifiers only to the elements required to create a versioning report.

All identifiers defined in this specification derive from the ver:genericIdType type definition:

</sequence>

</complexType>

The attributes used in this type definition are defined as follows:

The following elements are defined as of the ver:genericIdType type.

<element

name="genricId"

id="ver_genricId"

type="ver:genericIdType"

substitutionGroup="xbrli:tuple"

abstract="true"/>

<element

name="fromId"

id="ver_fromId"

type="ver:genericIdType"

substitutionGroup="xbrli:tuple"

abstract="true"/>

<element

name="toId"

id="ver_toId"

type="ver:genericIdType"

substitutionGroup="xbrli:tuple"

abstract="true"/>

<element

name="sourceId"

id="ver_sourceId"

type="ver:genericIdType"

substitutionGroup="xbrli:tuple"

abstract="true"/>

<element

name="targetId"

id="ver_targetId"

type="ver:genericIdType"

substitutionGroup="xbrli:tuple"

abstract="true"/>

All of them are abstract elements and represents the position in which an id of one information item must be used.

For example, when identifiers refer to information items defined in the From DTS they are documented in elements that participate in the ver:fromId substitution group. When identifiers refer to information items defined in the To DTS they are documented in elements that participate in the ver:toId substitution group.

4.3.3.1 The concept identifier

The concept identifier [ConceptId] locates a concept definition in a DTS.

The ver:conceptIdType type is defined by eliminating everything that is not needed in the ver:genericIdType type.

</restriction>

</complexContent>

</complexType>

The content of the ver:concept attribute is the concept QName as it is used in a fact on an instance document.

The following elements are defined using this type definition:

<element

name="fromConceptId"

id="ver_fromConceptId"

type="ver:conceptIdType"

substitutionGroup="ver:fromId"/>

<element

name="toConceptId"

id="ver_toConceptId"

type="ver:conceptIdType"

substitutionGroup="ver:toId"/>

<element

name="conceptAsSourceId"

id="ver_conceptAsSourceId"

type="ver:conceptIdType"

substitutionGroup="ver:sourceId"/>

<element

name="conceptAsTargetId"

id="ver_conceptAsTargetId"

type="ver:conceptIdType"

substitutionGroup="ver:targetId"/>

They are used in the following situations:

fromConceptId	Identify a concept in the From DTS. For all events that require a concept as a parameter.
toConcpetId	Identify a concept in the To DTS. For all events that require a concept as a parameter.
conceptAsSourceId	Identify a concept when it is used in the source of a relationship.
conceptAsTargetId	Identify a concept when it is used in the target of a relationship.

4.3.3.2 The relationship identifier

The relationship identifier [RelationshipId] locates a relationship in a DTS. Note that a relationship is not the surrounding arc in the extended link. One arc may represent several relationships. For the purpose of defining a versioning report each relationship represented by the same arc is a different relationship with a different relationship identifier.

The ver:relationshipIdType type is defined by eliminating everything that is not needed in the ver:genericId type.

</sequence>

</restriction>

</complexContent>

</complexType>

A relationship identifier consists of the following elements:

1. Ids of all attributes defined in the relationship.

2. The Id of the information item that is the source of the relationship. In turn this can be a Concept Id, a Resource Id or a Fragment Id.

3. The Id of the information item that is the target of the relationship. In turn this can be a Concept Id, a Resource Id or a Fragment Id.

4. The URI of the Extended Link Role where the relationship is defined.

5. The relationship type represented by the QName of the surrounding arc node.

6. The URI of the relationship arcrole.

The following elements are defined using this type definition:

<element

name="fromRelationshipId"

id="ver_fromRelationshipId"

type="ver:relationshipIdType"

substitutionGroup="ver:fromId"/>

<element

name="toRelationshipId"

id="ver_toRelationshipId"

type="ver:relationshipIdType"

substitutionGroup="ver:toId"/>

They are used in the following situations:

fromRelationshipId	Identify a relationship in the From DTS. For all events that require a relationship as a parameter. The relationship event always has a parent event that locates either a concept or a resource.
toRelationshipId	Identify a relationship in the To DTS. For all events that require a concept as a parameter. The relationship event always has a parent event that locates either a concept or a resource.

A relationship id requires two other ids locating the source and the target of the relationship. The following elements are defined in this specification to be used inside a relationship identifier. They locate the source and the target of the relationship:

conceptAsSourceId	Identify a concept when it is used in the source of a relationship.
conceptAsTargetId	Identify a concept when it is used in the target of a relationship.
resourceAsSourceId	Identify a resource when it is used in the source of a relationship.
resourceAsTargetId	Identify a resource when it is used in the target of a relationship.
fragmentAsSourceId	Identify a node when it is used in the source of a relationship.
fragmentAsTargetId	Identify a node when it is used in the target of a relationship.

4.3.3.3 The resource identifier

The resource identifier [ResourceId] locates a resource in a DTS.

The ver:resourceIdType type is defined by eliminating everything that is not needed in the ver:genericIdType type.

</restriction>

</complexContent>

</complexType>

The content of the ver:resourceRef attribute is an XPointer whose syntax is defined in section 3.5.4 of the XBRL 2.1 specification.

The following elements are defined using this type definition:

<element

name="fromResourceId"

id="ver_fromResourceId"

type="ver:resourceIdType"

substitutionGroup="ver:fromId"/>

<element

name="toResourceId"

id="ver_toResourceId"

type="ver:resourceIdType"

substitutionGroup="ver:toId"/>

<element

name="resourceAsSourceId"

id="ver_resourceAsSourceId"

type="ver:resourceIdType"

substitutionGroup="ver:sourceId"/>

<element

name="resourceAsTargetId"

id="ver_resourceAsTargetId"

type="ver:resourceIdType"

substitutionGroup="ver:targetId"/>

They are used in the following situations:

fromResourceId	Identify a resource in the From DTS. For all events that require a resource as a parameter.
toResourceId	Identify a resource in the From DTS. For all events that require a resource as a parameter.
resourceAsSourceId	Identify a resource when it is used in the source of a relationship.
resourceAsTargetId	Identify a resource when it is used in the target of a relationship.

4.3.3.4 The XML Attribute node identifier

The attribute identifier [AttributeId] locates an attribute used in a concept definition, a relationship or a resource when the related event requires a reference to an attribute.

The ver:attributeIdType type is defined by eliminating everything that is not needed in the ver:genericIdType type.

</restriction>

</complexContent>

</complexType>

The content of the ver:attributeXPath attribute is the XPath expression that locates the attribute using the node where the attribute is used as context for XPath evaluation.

All prefixes used within the XPath expression MUST be declared as is scope namespaces defined in the element that contains the ver:nodeXPath attribute.

The content of the ver:value attribute is the string representation of the attribute value except when the attribute value is a QName. For QNames, the James Clark representation of the QName value is used.

The following elements are using this type definition:

<element

name="attributeId"

id="ver_attributeId"

type="ver:attributeIdType"

substitutionGroup="ver:genricId"/>

<element

name="fromAttributeId"

id="ver_fromAttributeId"

type="ver:attributeIdType"

substitutionGroup="ver:fromId"/>

<element

name="toAttributeId"

id="ver_toAttributeId"

type="ver:attributeIdType"

substitutionGroup="ver:toId"/>

They are used in the following situations:

attributeId	When another id requires an attribute to be referenced. For example in a relationship id.
fromAttributeId	Locates an attribute in the From DTS. Used under the scope of another event and in an event related to the attribute referenced.
toAttributeId	Locates an attribute in the To DTS. Used under the scope of another event and in an event related to the attribute referenced.

4.3.3.5 The fragment identifier

The fragment identifier [FragmentId] locates an XML fragment external to the DTS. Relationships defined in generic linkbases can potentially point from or to external files and nodes inside external files using XML format.

The ver:fragmentIdType type is defined by eliminating everything that is not needed in the ver:genericIdType type.

</restriction>

</complexContent>

</complexType>

The content of the ver:fragmentRef attribute is an XPointer whose syntax is defined in section 3.5.4 of the XBRL 2.1 specification.

The following elements are using this type definition:

<element

name="fragmentAsSourceId"

id="ver_fragmentAsSourceId"

type="ver:fragmentIdType"

substitutionGroup="ver:sourceId"/>

<element

name="fragmentAsTargetId"

id="ver_fragmentAsTargetId"

type="ver:fragmentIdType"

substitutionGroup="ver:targetId"/>

They are used in the following situations:

fragmentAsSourceId	Identify a node when it is used in the source of a relationship.
fragmentAsTargetId	Identify a node when it is used in the target of a relationship.

4.3.3.6 The node identifier

The node identifier [NodeId] locates an element node when it is the child of a concept definition, or the child of a resource definition.

The ver:nodeIdType type is defined by eliminating everything that is not needed in the ver:genericIdType type.

</restriction>

</complexContent>

</complexType>

The content of the ver:nodeXPath attribute is an XPath 2.0 expression that locates the element node using the concept or resource where this node is child as context for the XPath expression evaluation.

All prefixes used within the XPath expression MUST be declared as is scope namespaces defined in the element that contains the ver:nodeXPath attribute.

The following elements are using this type definition:

<element

name="fromNodeId"

id="ver_fromNodeId"

type="ver:nodeIdType"

substitutionGroup="ver:fromId"/>

<element

name="toNodeId"

id="ver_toNodeId"

type="ver:nodeIdType"

substitutionGroup="ver:toId"/>

They are used in the following situations:

fromNodeId	Locates a node in the From DTS. Used under the scope of another event and in an event related to the node referenced.
toNodeId	Locates an attribute in the To DTS. Used under the scope of another event and in an event related to the node referenced.

A References

[RFC2119]	Scott Bradner
	Key words for use in RFCs to Indicate Requirement Levels, March 1997
	http://www.ietf.org/rfc/rfc2119.txt

[SCHEMA-0]	World Wide Web Consortium.
	XML Schema Part 0: Primer.
	http://www.w3.org/TR/xmlschema-0/

[SCHEMA-1]	World Wide Web Consortium.
	XML Schema Part 1: Structures.
	http://www.w3.org/TR/xmlschema-1/

[SCHEMA‑2]	World Wide Web Consortium.
	XML Schema Part 2: Datatypes.
	http://www.w3.org/TR/xmlschema-2/

[XINFOSET]	XML Information Set (Second Edition)
	W3C Recommendation 4 February 2004
	http://www.w3.org/TR/xml-infoset/

[XBRL]	Phillip Engel, Walter Hamscher, Geoff Shuetrim, David vun Kannon, Hugh Wallis.
	Extensible Business Reporting Language (XBRL) 2.1 Recommendation with corrected errata to 2006-12-18
	http://www.xbrl.org/SpecRecommendations/

[XLINK]	Steve DeRose, Eve Maler, David Orchard
	XML Linking Language (XLink) Version 1.0.
	http://www.w3.org/TR/xlink/

[XPATH]	Anders Berglund, Scott Boag, Don Chamberlin, Mary F. Fernández, Michael Kay, Jonathan Robie, Jérôme Siméon.
	XML Path Language (XPath) 2.0
	http://www.w3.org/TR/xpath20/

[XML Base]	Jonathan Marsh
	XML Base.
	http://www.w3.org/TR/xmlbase/

[XPTR]	Paul Grosso, Eve Maler, Jonathan Marsh, and Norman Walsh, editors
	XML Pointer Language (XPointer Framework) V1.0.
	http://www.w3.org/TR/xptr-framework/

[XIS]	Ignacio Hernández-Ros
	XBRL Infoset
	Not yet publicly available

[VREQ]	Sergio Quiroz and Katrin Schmehl, editors
	Versioning Specification Requirements
	Not yet publicly available

B Requirements Reference (non-normative)

This section cross references to the versioning requirements [VREQ].

ID	PRINCIPLE		MEANING			Satistied
P1	Consistency		XBRL concepts and terminology should be used to describe the solution. In particular, versioning components should be described using XBRL related technologies as taxonomies, linkbases, XLink, XML Schema and others.			Yes
P2	No Redundancy		The solution should not require instances, schemas or linkbases to encode the same information in multiple places.			TBD
P3	Simplicity		The solution must not include features for which there is no documented need.			TBD
P4	Priority		An implementation of these requirements must not violate the most current edition of the XBRL 2.1 specification.			Yes
P5	Usability		It must be possible to implement the solution in software in a user friendly manner for both: the taxonomy authors who want to create new versions of their taxonomies and for instance document authors who must adapt their systems to produce documents according to new the new taxonomy versions. If something in the design were in conflict between the two groups defined above the point of view that should prevalence is the one that gives more simplicity to the instance document authors			Yes
P6	Compatibility		The solution SHOULD be compatible with current XBRL Taxonomies and Taxonomies that are using XBRL modules that are based on XBRL technology, such as the Dimensions Specification 1.0 and the Formula Linkbase Specification.			Yes
U1101	New XBRL concept		The adding of a new item [[XIS] 2.2.8 + [XIS] 2.2.9] or a new tuple [[XIS] 2.2.8 + XIS 2.2.10] MUST be documented.			Yes
U1102	Deletion of an XBRL concept		The deletion of an item [XIS 2.2.8 + [XIS] 2.2.9] or a tuple [[XIS] 2.2.8 + [XIS] 2.2.10] MUST be documented.			Yes
U1201	Change in the QName		If a concept QName [[XIS] 2.2.3.2 + XIS 2.2.8.2] has changed, this change MUST be documented.			Yes, in the mapping rules
U1202	Change in the ID attribute value		If an element ID has changed may be to correspond with the element name, this change should NOT be documented.			Yes
U1203	Change in the substitutionGroup attribute value		A change in the substitutionGroup [[XIS] 2.2.8.4] MUST be documented.			Yes
U1204	Change in the abstract attribute value		If the abstract attribute value [[XIS] 2.2.8.6] has changed, this change MUST be documented.			Yes
U1205	Change in the nillable attribute value		If the nillable attribute value [[XIS] 2.2.8.5] has changed, this change MUST be documented.			Yes
U1206	Change in the type definition		If the type definition [[XIS] 2.2.8.3] has changed, this change MUST be documented.			Yes
U1207	Change in the periodType attribute value		If the periodType attribute value [[XIS] 2.2.9.2] has changed, this change MUST be documented.			Yes
U1208	Change in the balance attribute value		If the balance attribute value [[XIS] 2.2.9.3] has changed, this change MUST be documented.			Yes
U1209	Change in the block attribute value		If the block attribute value [[XIS] 2.2.8.7] has changed, this change MUST be documented.			Yes
U1210	Change in the default attribute value		If the default attribute value [[XIS] 2.2.9.4] has changed, this change MUST be documented.			Yes
U1211	Change in the fixed attribute value		If the fixed attribute value [[XIS] 2.2.8.8] has changed, this change MUST be documented.			Yes
U1212	Change in the final attribute value		If the final attribute value [[XIS] 2.2.8.9] has changed, this change MUST be documented.			Yes
U1213	Change of a child element		If a new child [[XIS] 2.2.8.13] has been added, deleted or changed inside a tuple element, this change MUST be documented.			Yes, but due to changes in the data type only.
U1214	Change in additional attributes		Changes on additional attributes [[XIS] 2.2.8.12] MUST be documented.			Yes
U1215	New relationship		If a new relationship [[XIS] 2.2.8.10 + [XIS] 2.2.8.11] has been added to a concept where the concept acts as source or target, this change MUST be documented.			Yes
U1216	Deletion of a relationship		If a relationship [[XIS] 2.2.8.10 + [XIS] 2.2.8.11] refering to a concept does no longer exist, this change MUST be documented.			Yes
U1217	New resource		The addition of a new resource [[XIS] 2.2.15] linked to a concept i.e. a label or a reference MUST be documented.			Yes
U1218	Deletion of a resource		If a resource [[XIS] 2.2.15] referenced by a concept has been deleted, this change MUST be documented.			Yes
U1219	New attribute		If an attribute has been added to a concept, this change MUST be documented.			Yes
U1220	Deletion of an attribute		The deletion of an attribute of a concept MUST be documented.			Yes
U1301	Change in the URI of an extended link role		A change in the URI of an extended link role MUST be documented.			Yes, in the mapping rules
U1303	Change in the arcrole type		If the arcrole type [[XIS] 2.2.14.5] has changed, this change MUST be documented.			No, a deletion of the old relationship and creation of a new relationship is documented
U1305	Change in the order attribute value		If the order attribute value [[XIS] 2.2.14.6] has changed, this change should only be documented when the ordering of the concepts has changed.			Yes
U1306	Change in the highest priority relationship(s)		When the highest priority relationship(s) [[XIS] 2.2.14.8] has changed, this change MUST be documented. Changes on relationship(s) with lower priority should not be documented.			Yes
U1307	Change in additional attributes		Changes on additional attributes [[XIS] 2.2.14.9] MUST be documented.			Yes
U1308		Addition of an attribute		If an attribute has been added to a relationship, this change MUST be documented.	Yes
U1309		Deletion of an attribute		The deletion of an attribute of a relationship MUST be documented.	Yes
U1401	Change in the role attribute		If there is a change in the definition of a role attribute [[XIS] 2.2.15.3] of a resource, this change MUST be documented.			Yes
U1402	Change of the content of a resource		If the content of a resource [[XIS] 2.2.15.8] has changed, this change MUST be documented.			Yes
U1501	Add a documentation for a change		If an addition, deletion or a change has been made, the taxonomy editor should be able to add an explanation for this change.			Yes
U1502	Add a documentation of a group of changes		If changes can be grouped, it should be possible to add documentation for a summary of changes: examples include splitting of concepts, collapsing of concepts etc.			Yes
U1503	Additional information for change documentation		The following information should be possible to include in the change documentation: Error description, change description, found by, severity, change date. It would be preferable to have a structural and extensible documentation.			Yes
U1504	Add a change category		It should be possible to add a change category to distinguish if a change is due to an error, a new requirement, change that affect automated processing or do not affect automated processing etc. A short list of predefined change categories should be provided but also a possibility to add new categories.			Yes
U1505	No documentation of syntactical changes		If the changes have no semantics so that they are only syntactical, these changes should no be documented. For example a resource like a label moves from one linkbase file to another.			Yes
U1506	Multi-lingual documentation		It should be possible to add documentation on a change in different languages.			Yes
U1601	Give information about the completeness of a versioning report		If a versioning report contains only a limited number of changes because unrelevant changes are left out. The versioning report should contain information that not all changes are listed.			Yes (in the queue)
U1602	Information about compatibility		It should be possible to add information about the backward and forward compatibility of the old and new version of a taxonomy.			No
U1603	Additional metadata		It should be possible to add metadata to document who created the versioning report, including additional contact information.			No
U1604	Add information about the versioning strategy		It should be possible to add information about the versioning strategy.			No, unsure, or depending on syntax
U1605	Give information about the mapping rules		A version report should also list the mapping rules that are the basis of the generated report.			Yes
U1701		Detect equivalent dimensional relationships		If a dimensional relationship has only syntactical changes, these changes should not be reported (i.e. the composition of a hypercube has changed or it is divided but the relationships between primary and dimensional elements are the same).	No
U1702		Change on the dimensional representation of a set of concepts		Changes on the dimensional representation of a concept: a concept doesn't change from a business perspective, but it's XBRL dimensional representation does. I.E: Version 1 Version 2 A <==> X ( D = d1 ) B <==> X ( D = d2 ) C <==> X ( D = d3 ) Where A, B, C and X are primary items, D is a dimension and d1, d2 and d3 are domain members of a dimension. It should be possible to express this kind of equivalences so that ETL tools and others would be able to update mappings according to this information	No
U2101	Choose the level of detail		It should be possible to choose if the level of detail as well as not to list unrelevant changes in a versioning report.			This is a requirement for tools consuming the versioning report. This spec guarantees that this will be possible to implement
U2102	Creation of a version report		The version report should be created in XBRL syntax as well as in a human readable form ( i.e. HTML). It should be also possible to extract business-oriented changes for an excerpt report addressed to business people.			Yes
U2103	Change documentation		XBRL software including versioning techniques should be able to add documentation on individual changes and group changes in a combined documentation.			Yes
U2104	Process of a versioning report		A versioning report should be technically readable to enable, whenever possible, dynamic processing of the changes.			Yes
U2105	Changes on instances		XBRL software including versioning techniques should support users to take into account the taxonomy changes in corresponding instances.			No
U2106	Capture versioning information during development		It should be possible to capture versioning information during the development phase of a taxonomy. XBRL software including versioning techniques should provide a set of services for taxonomy change management.			Yes
U2107	Change report		In case of changes on existing elements and attributes, the versioning report should show the old and the new value.			No, this contradicts P2. The information is always available in the source and target DTS. Applications consuming a versioning report can do this.
U2108	Business-oriented versioning report		It should be possible to create a human readable versioning report oriented to business people, for example, based on the change category. It should not include technical changes and not present the changes in an IT-based reporting language like HTML.			TBD
U2109	Impact analysis		XBRL software including versioning techniques should be able to make the impact analysis on calculation linkbase, dimensional relationships, formula linkbase (in the future). It should be possible to infer that a change on a concept in a new version has a potential impact on every concept that depends on the changed one.			This spec is designed in a way that applications consuming the versioning report can produce this information.
U2120	Comparison of extension taxonomies		XBRL software including versioning techniques should be able to compare two different extension taxonomies.			Yes
U2121	Process of extension taxonomies		XBRL software should provide support for taxonomy editors to adopt changes in the base taxonomy.			Yes
U2201	It MUST be possible to assert that a versioning report is complete, and to validate this assertion.		It is important that a versioning report documents all relevant changes. In some cases this will correspond to all the changes DTS being documented. In other cases, just a subset will be documented. Where all changes in the DTS are being documented, it would be useful to assert that this is the case so that the completeness of the report can be verified by third parties.			Not yet in the document but yes.
U3101	New entry point		An additional entry point should be documented; for example, a new taxonomy has been added to the XBRL framework.			No
U3102	Entry point removed		If an entry point has been removed by the taxonomy editor, this change should be documented.			No
U3103	Changes in the URI of entry points		If the URI has changed, this change should be documented.			No
U3104	New base taxonomy		An additional base taxonomy should be documented.			No
U3105	Base taxonomy removed		The deletion of a referenced base taxonomy should be documented.			No
U3106	Changes to the URI of the base taxonomy		If the URI has changed (for example, because of a new version that is now used), this change should be documented.			No
U3107	Changes on the base taxonomy		If the changes relate to an extension taxonomy, changes in the base taxonomy itself should not be documented.			No
U3108	Changes on documentary information		The changes in documentary information of the taxonomy header should be documented.			No
U3109	Version numbering		It should be possible to add a numbering for the versions.			No
U3110	Validity period		The taxonomy header should contain information about the validity period of a taxonomy.			No
U3201	Add a validity to a concept		It should be possible to define a validity for a concept and to validate this restriction.			No
U3202	Define a dynamic change		It should be possible to define that changes have a dynamic character and might be valid only for a special period. Explanation: A new version of the taxonomy should be published each time a new requirement has to be included or a “bugs fixing” is needed. If some concepts included in the taxonomy are very changeable (e.g. securities or vital statistics about geography or people), a very frequent update of the taxonomy is needed. Usually, Regulators do not publish a new version each time “something” has changed, but only with a view to the whole business process, so the validity period of the new version is related to the business scope. This would mean that the information about the actual “life” of dynamic concepts are, usually, lost. In fact, it is possible to assume that: When the concept is included in the new version, then its existence validity is equal to the version validity period When the concept is not included in the new version, then its “death” agrees with the end-date of the previous version validity period In both cases, this may be not true for dynamic concepts. Because of it’s important to collect facts considering exactly the “existence” of the related concepts (think about “multidimensional data”) so it’s important to properly document dynamic “real world changes”.			No
U3301	Detect equivalent dimensional relationships		If a dimensional relationship has only syntactical changes, these changes should not be reported (i.e. the composition of a hypercube has changed or it is divided but the relationships between primary and dimensional elements are the same).			No

C Versioning Taxonomy Summary

Purpose and Scope	The versioning taxonomy contains concept definitions to create versioning reports according to this specification.
Owner	XBRL International Inc.
Date	2007-11-02
Status	Public Working Draft
Approval level	XBRL International Acknowledge
Specification version	XBRL Specification Version 2.1 and errata correction 2006-12-18
Contact	ignacio@reportingstandard.com
Comments
Namespace	http://xbrl.org/2007/versioning
Namespace prefix	ver
Phisical location of files in the DTS	http://www.xbrl.org/2007/versioning-2007-11-02.xsd http://www.xbrl.org/2007/versioning-2007-11-02-label.xml http://www.xbrl.org/2007/versioning-2007-11-02-presentation.xml
Summary document	This document.
References to other taxonomies	None.

D Intellectual Property Status

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

E Acknowledgements

This document is a result of careful consideration by the participants of the XBRL International Versioning Working Group. The XBRL International Versioning Working Group is chaired by Paul Warren (DecisionSoft) and vice chaired by Katrin Schmehl (Deutsch Bundesbank).

F Document History

Date	Editor	Summary
2007-01-04	IHR	First skeletal draft created.
2007-02-15	IHR	Updated Introduction and Background Added XPath 2.0 expressions on XBRL Information Items Added static definitions for role types defined in the XBRL 2.1 specification Lots of clarifications and notes added to properties on the elements.
2007-02-21	IHR	Updated properties are: Content of a Imported XBRL Information item MAY not exist Linkbases in a XBRL Taxonomy Information item are not ordered
2007-03-15	IHR	Updated XPath 2.0 expressions. Removed the XBRL Pointer of a Relationship Information Item and the XBRL Locator Information Item. Updated the Relationship Information Item. Sources and targets of a relationship are the objects pointed and not the locators that points to the objects.
2007-04-15	IHR	Shorter property names. Added section 2.3 about comparing the elements in the Versioning Infoset. The XBRL Infoset is now created on top of a generic XSD Infoset Revised the Infoset related to an XBRL Resource
2007-08-17	IHR	XIS property numbers synchronized with XIS-IWD-2007-08-07 Preceding relationship and Following relationships defined in section 2.1 Section 2.2 (the algorithm) updated to make it more implementable in software. Some parts of the algorithm still requires revision. Deleted events that cannot be raised because the properties are used to find the correspondent Information Item. EvNamespace and EvName. Added EvBalance and EvDefault. Parameters of the events has been updated. The algorithm is simplified because of the new definition of a Concept Information Item as the parent of Item and Tuple. Comparison of relationships updated. All rules for finding the correspondent Information Item are now grouped into a specific section. Rules for cocnpet and relationship matching updated. The Hierarchical organization of events updated to reflect changes in the wording. Added section 2.7 about the constraints of difference paths. Hopefully this section can be deleted in the future if a non recursive algorithm is feashible. Content model updated to reflect concept mappings.
2007-09-12	IHR	Section 2.1 some editorial changes The algorithm about how to compute the Previous and Next properties from information in the XBRL Inset has been explained in detail. Section 2.2 Added a reference to the tables of namespace mapping, role mapping and concept mapping as input for the diff algorithm to run. Section 2.2.1 Added the Resources property of a DTS Information Item to the algorithm (not tested in software yet) The wording of the generation of events has been changed according to the new events table and the events removed in the latest conf calls. Section 2.5 updated according to changes in the events structure and events deleted in the latest conf calls Section 2.6 has been deeply reworded. Added a new section B in the appendix with references to the requirements documentation.
2007-10-09	IHR	Added the syntax section Updated the wording in the diff conditions so it is not an algorithm anymore but the description of conditions satisfied by both information items being compared Updated the diagram in section 3. No PowerPoint documents included anymore. Updated the definition of a correspondent concept to the new Concept QName mapping table. Lots of wording changes everywhere.
2007-10-22	IHR	Added definition of 4 new terms (From DTS, To DTS, Action and Assignment) Event names: EvDeleteRelationship and EvNewRelationship changed to EvRelationshipDelete and EvRelationshipNew respectively The term Change Request has been changed to Assignment The word box within section 3 has been changed to container or component. Added cardinality indicators in figure of section 3 Added the definition of a version information item Added cardinality to containes in the Figure 2 Changes made to the versioning taxonomy The request concept definition has been changed to assignment Assignment is now in the categoryTupleType The action content model changed to remove the categories from there. Typo in EvReSourceTo. Now is EvResourceTo Typo in EvNewRelationship. Now is EvRelationshipNew Typo in EvDeleteRelationship. Now is EvRelationshipDelete ver:role attribute on Resource Ids is optional content not required content. ver:value attribute on Attribute Ids is required content. Two relationships are different if they have different content in one attribute. Typo in fragmentId. It was fragmetId and now is fragmented Updated the Requirements reference to contain the new requirements incorporated.
2007-11-02	IHR	Added wording on the Introduction and Background sections. Changed correspondence of resources in order to make them explicit in a resources mapping table. Defined a new ElementId different from the NodeId. ElementId works to refer to information out of the DTS and NodeId can only be used within another Id because it locates an XML element as child of another XML element. Section 3.10 added definition 8 regarding the resource mapping table.
2007-11-15	IHR	Editorial changes according to suggestions from Ronald Hommes. Removed event EvFixed from tuple comparison. It was unnecessary. Added a constraint to make explicit the declaration of namespace prefixes used in XPath expressions when the XPath expression is used in an attribute of an element. Changed status from IWD to DPWD.
2007-11-28	HW	Editorial for publication as a PWD

[1] ETL stands for Extract, Transform and Load

[2] The XIS (XBRL Information Set) documentation defines the properties of every object in a DTS.

[3] Two relationships belongs to the same extended link role if they have the same value in the URI property [XIS 2.2.5.4] of the Role Type Information Item that is the value of the role property [XIS 2.2.12.2] of the parent property [XIS 2.2.14.1] of each relationship.

Name	Contact	Affiliation
Timo Philipp	tphilipp@IASB.ORG.UK	IASC Foundation
Paul Warren	pdw@DECISIONSOFT.COM	DecisionSoft
Raynier van Egmond	rve@c3ismc.com	C3i SMC LLC.

Code	Event	Parent Event	Parameter From DTS	Parameter To DTS	Final
[EvConceptDelete]	Concept deleted	None	[ConceptId]	-	Yes
[EvConceptNew]	Concept added	None	-	[ConceptId]	Yes
[EvConceptNamespace]	Concept namespace	None	[ConceptId]	[ConceptId]	Yes
[EvConceptName]	Concept name	None	[ConceptId]	[ConceptId]	Yes
[EvConceptType]	Concept Type	None	[ConceptId]	[ConceptId]	Yes
[EvSubstitutionGroup]	Concept Substitution Group	None	[ConceptId]	[ConceptId]	Yes
[EvPeriodType]	Concept Period Type	None	[ConceptId]	[ConceptId]	Yes
[EvNillable]	Concept Nillable	None	[ConceptId]	[ConceptId]	Yes
[EvAbstract]	Concept Abstract	None	[ConceptId]	[ConceptId]	Yes
[EvBlock]	Concept Block	None	[ConceptId]	[ConceptId]	Yes
[EvBalance]	Concept Balance	None	[ConceptId]	[ConceptId]	Yes
[EvDefault]	Concept Default	None	[ConceptId]	[ConceptId]	Yes
[EvFixed]	Concept Fixed	None	[ConceptId]	[ConceptId]	Yes
[EvFinal]	Concept Final	None	[ConceptId]	[ConceptId]	Yes
[EvConceptRelationshipFrom]	Concept From	None	[ConceptId]	[ConceptId]	No
[EvConceptRelationshipTo]	Concept To	None	[ConceptId]	[ConceptId]	No
[EvConceptAttribute]	Concept Attribute	None	[ConceptId]	[ConceptId]	No
[EvChild]	Concept Child	None	[ConceptId]	[ConceptId]	No
[EvAttributeDelete]	Attribute deleted	[EvConceptAttribute] or [EvRelationshipAttribute] or [EvResourceAttribute]	[AttributeId]	-	Yes
[EvAttributeNew]	Attribute added	[EvConceptAttribute] or [EvRelationshipAttribute] or [EvResourceAttribute]	-	[AttributeId]	Yes
[EvAttributesInequality]	Not s-equal2 attributes	[EvConceptAttribute] or [EvRelationshipAttribute] or [EvResourceAttribute]	[AttributeId]	[AttributeId]	Yes
[EvNodeDeleted]	Element node deleted	[EvChild] or [EvContent]	[NodeId]	-	Yes
[EvNodeNew]	Element node added	[EvChild] or [EvContent]	-	[NodeId]	Yes
[EvNodesInequality]	Not s-equal2 nodes	[EvChild] or [EvContent]	[NodeId]	[NodeId]	Yes
[EvRelationshipDelete]	Relationship deleted	[EvConceptRelationshipFrom] or [EvConceptRelationshipTo] or [EvResourceFrom] or [EvResourceTo]	[RelationshipId]	-	Yes
[EvRelationshipNew]	Relationship added	[EvConceptRelationshipFrom] or [EvConceptRelationshipTo] or [EvResourceFrom] or [EvResourceTo]	-	[RelationshipId]	Yes
[EvSource]	Relationship Source	[EvConceptRelationshipFrom] or [EvConceptRelationshipTo] or [EvResourceFrom] or [EvResourceTo]	[RelationshipId]	[RelationshipId]	Yes
[EvTarget]	Relationship Target	[EvConceptRelationshipFrom] or [EvConceptRelationshipTo] or [EvResourceFrom] or [EvResourceTo]	[RelationshipId]	[RelationshipId]	Yes
[EvArcrole]	Relationship Arcrole	[EvConceptRelationshipFrom] or [EvConceptRelationshipTo] or [EvResourceFrom] or [EvResourceTo]	[RelationshipId]	[RelationshipId]	Yes
[EvPrevious]	Relationship Previous	[EvConceptRelationshipFrom] or [EvConceptRelationshipTo] or [EvResourceFrom] or [EvResourceTo]	[RelationshipId]	[RelationshipId]	Yes
[EvNext]	Relationship Next	[EvConceptRelationshipFrom] or [EvConceptRelationshipTo] or [EvResourceFrom] or [EvResourceTo]	[RelationshipId]	[RelationshipId]	Yes
[EvPriority]	Relationship Priority	[EvConceptRelationshipFrom] or [EvConceptRelationshipTo] or [EvResourceFrom] or [EvResourceTo]	[RelationshipId]	[RelationshipId]	Yes
[EvRelationshipAttribute]	Relationship Attribute	[EvConceptRelationshipFrom] or [EvConceptRelationshipTo] or [EvResourceFrom] or [EvResourceTo]	[RelationshipId]	[RelationshipId]	No
[EvResourceDelete]	Resource deleted	None	[ResourceId]	-	Yes
[EvResourceNew]	Resource added	None	-	[ResourceId]	Yes
[EvResourceType]	Resource Type	None	[ResourceId]	[ResourceId]	Yes
[EvRole]	Resource Role	None	[ResourceId]	[ResourceId]	Yes
[EvResourceFrom]	Resource From	None	[ResourceId]	[ResourceId]	No
[EvResourceTo]	Resource To	None	[ResourceId]	[ResourceId]	No
[EvResourceAttribute]	Resource Attribute	None	[ResourceId]	[ResourceId]	No
[EvContent]	Resource Content	None	[ResourceId]	[ResourceId]	No
[EvValue]	Resource Value	None	[ResourceId]	[ResourceId]	Yes

1.2 Relationship to other work

1.3 Terminology

2.2 The differences between two DTSs

2.4.4 Correspondence of XML Attributes

2.5 Hierarchical organization of the events

3 The content model of the versioning report

3.4 The Assignment component

3.5 The Action component

3.7 The Differences component

3.8 The Categories component

3.10The Version component

4.3.3.4 The XML Attribute node identifier