1 Introduction

The XBRL 2.1 specification [XBRL 2.1] 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 2.1] for a more exhaustive definition of a DTS).

XBRL has been used extensively in projects around the world. A common use of XBRL technology has been to model an existing information supply chain between regulators and regulated entities.

The digitalisation of that process, using 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 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 usually 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.

On the other hand, companies preparing their financial reports using XBRL technology can create their own taxonomies or taxonomy extensions. These companies can also make changes to their own taxonomies and may need to report to the market not only the reports according to the new DTS but also the changes they made to the taxonomies. In this case, the versioning report also serves as the communication tool in order to allow them to document the changes.

Most existing XBRL APIs are able to load the content of an XBRL DTS (a taxonomy) and can generate XBRL reports according to that taxonomy. But XBRL would not provide a true benefit at all if moving the software from one taxonomy version to another (on the report production side) or the process to review two consecutive reports from a company that has made changes to their taxonomy (on the consumers side) were a costly process for the users. This specification is specifically designed to address this issue. The reporting requirements change over time, the taxonomies change to cover those new requirements, but the technology used to create reports is the same [XBRL 2.1]. Moving applications to work from one taxonomy version to the next would be a trivial operation at least for concepts whose definition is the same.

1.1 Background

A number of projects have made significant contributions to this specification. These include the IASC Foundation which has contributed a methodology on which this specification is based, and the National Taxonomy Project ("NTP") initiated by the Dutch government, which has contributed the first initial documentation of a standardisation for a Versioning report. Several other initiatives such as the Committee of European Banking Supervisors have joined efforts together in order to help the XBRL Consortium and the XBRL industry to adopt a single common solution that satisfies the most critical business requirements in all those projects.

1.2 Relationship to other work

This specification depends upon the XBRL 2.1 Specification [XBRL 2.1].

1.3 Language independence

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

1.4 Terminology

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 are as defined by [XBRL 2.1].

An arc defines a relationship between its source and target concepts. The nature of that relationship is determined by its xlink:arcrole and other attributes.

Source [concept(s)] are 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)] are 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.

The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, in this specification, are to be interpreted as described in [IETF RFC 2119].

The term From DTS is used to refer to the source DTS that is the DTS that is being compared to the To DTS. The From DTS normally refers to the old taxonomy version.

The term From DTS is used to refer to the target DTS that is the DTS that is being compared to the From DTS. The To DTS normally refers to the new taxonomy version.

This specification uses the term action for referring to that which changes between the From DTS and the To DTS

This specification uses the term assignment either to refer to the business reasons for an action to change the contents of a DTS or to refer to the business reasons for starting to compare two DTSs.

1.5 Document conventions

1.5.1 Typographic conventions

1.5.1.1 Definition notation

Definitions are highlighted with green text.

1.5.1.2 Footnote notation

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

1.5.1.3 Element and attribute notation

When referring to a specific element, it will be identified by its namespace prefix and local name. For example, the root element for a specification container element would be referred to as <variable:generalVariable>.

Attributes are also identified by their local name and, where appropriate, their namespace prefix. Attributes are distinguished from elements by prefixing them by an @ symbol. Thus, @id refers to the attribute with the name id.

When referring to any attribute, so long as it has a specific namespace, the local name is replaced by an asterisk ( *). Thus, the notation @xml:* specifies any attribute in the namespace http://www.w3.org/XML/1998/namespace.

1.5.2 Formatting conventions

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

Example 1: A normative example

Text of the normative example.

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

Example 2: A non-normative example

Text of the helpful example.

Next paragraph of the helpful example.

Example 3 shows the formatting for non-normative examples of poor, discouraged or disallowed usage.

Example 3: An example of poor usage

The example itself.

1.6 Namespaces and namespace prefixes

Namespace prefixes [XML Names] will be used for elements and attributes in the form ns:name where ns is the namespace prefix and name is the local name. Throughout this specification, the mappings from namespace prefixes to actual namespaces is consistent with Table 1.

The prefix column in Table 1 is non normative. The namespace URI column is normative.

Table 1: Namespaces and namespace prefixes

Prefix	Namespace URI
`xlink`	`http://www.w3.org/1999/xlink`
`ver`	`http://xbrl.org/20072008/versioning`

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.

This specification distinguishes between "technical differences" and "semantic differences". "Technical differences" are those that can be automatically identified by software comparing the properties of the pair of information items under observation. "Semantic differences" are the interpretation of the "technical differences" made by the author of the versioning report. Given two DTSs and some rules to match information items from one DTS to the other, the set of "technical differences" is unique, but the set of "semantic differences" is unlimited because they are just an interpretation of the "technical differences". A "semantic difference" contains an aggregation of "technical differences" and human readable documentation that may be useful input to users migrating an application from using the previous taxonomy version to the next.

Figure 1 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 in a DTS can be written in one or many different files without any impact on applications using the DTS. A simple example:

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.
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 from the DTS consumer perspective because, even though taxonomy "A.XSD" and "B.XSD" are completely different in their syntax, 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) [XBRL Information Set] is an abstraction layer on top of the syntax layer. This abstraction layer expresses every information item in a DTS (concept definition, resource definition, relationship, etc) based on its property and not based on the syntax used to serialise it in XML Schemas or XBRL linkbases.

Versioning is built on top of [XBRL Information Set] without making any reference to the actual underlying syntax. Of course, the relationship between the information item properties and the XBRL syntax exists and software tools can easily find and use it.

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

Table 2: The XBRL Versioning Infoset

The DTS Information Item	All properties are included.
The XBRL Document Information Item	All properties are excluded. ¹
The XBRL Taxonomy Information Item	[Namespace] is included. All other properties are excluded.
The Imported Taxonomy Information Item	All excluded.
The Role Type Information Item	[URI] is included. All other properties are excluded.
The Arcrole Type Information Item	[URI] is included. All other properties are excluded.
The Used On Information Item	All properties are excluded.
The XBRL Concept Information Item	All properties are included.
The XBRL Item Information Item	All properties are included.
The XBRL Tuple Information Item	All properties are included.
The XBRL Linkbase Information Item	All properties are excluded.
The Extended Link Information Item	The role URI on extended links is used to define the relationship identifier.
The Documentation Information Item	All properties are excluded.
The Relationship Information Item	Only relationships that exist after prohibition and overriding rules defined in [XBRL 2.1] are considered part of a concept definition. For those relationships, only the following properties are included: [Type], [From], [To], [Arcrole], [Parent], [Order] , [Priority] and [Attributes]
The Resource Information Item	All resources in the DTS are considered. See Section 2.4.3. for more information. For resources, the following properties are included: [Type], [Role] , [Parent], [Element] , [From], [To], [Attributes] and [Value]

1. Note that this is safe because this object is extended by other objects whose important properties are included as in the case of the namespace property of an XBRL Taxonomy Information Item.

Changes to other properties that are not included in the list above can be documented in the versioning report despite the fact that they will not produce Diff Events according to this specification. The content model of the versioning report allows a report to contain specific documentation about 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 exists in [XBRL Information Set] but not explicitly indicated as properties therein.

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

very member of the set RS belongs to the same Extended Link role, ^{[
2
]} and
R and RS have the same value in the [Type] property, and
RS is positioned immediately before R in the set of relationships that satisfies the previous 2 conditions, ordered using the value of the [Order] property.

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

R and RS belong to the same Extended Link role, and
R and RS have the same value in the [Type] property, and
RS is positioned immediately after R in the set of relationships that satisfies the previous 2 conditions, ordered using the value of the [Order] property.

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 modularisation strategy used to serialize 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 technical differences that are identified in this specification. This specification does not define any specific algorithm to find the differences.

A Difference Event is the representation of something not equivalent found between properties of two corresponding XBRL Information Items being compared. This is equivalent to what was referred to as a "technical difference" earlier in this document.

There are Difference Events defined for each type of "technical difference" that is possible between two XBRL Information Items covered by this specification.

The computation of the Difference Events requires two tables of paired properties that define the mapping rules between DTSs. See Section 3.10 and the definitions of namespace pair and role URI pair. 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 "technical differences" between two concept definitions or resource 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:

Example 4: Relationship Attribute Change

[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 attributes whose values are not equal. This event will be the ending event in the path.

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.

The Starting Event of a path is always the first event in the path.

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 is enumerated in Section 2.5.

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

2.2.1 Comparing two DTS Information Items

Two DTS Information Items D1 (the From DTS) and D2 (the To DTS) are equivalent if both the following conditions are satisfied and none of the "NOT equivalent" conditions defined in Section 2.2.1.1 exist:

For each XBRL Concept Information Item defined in the [Concepts] property of D1 there exists a corresponding XBRL Concept Information Item in D2 ; both items are equivalent if they satisfy all conditions in section Section 2.2.2 or Section 2.2.3.
For each XBRL Resource Information Item defined in the [Resources] property of D1 where a corresponding XBRL Resource Information Item is found in D2 ; both items are equivalent if they satisfy all conditions in Section 2.2.5.

2.2.1.1 "NOT equivalent" conditions

Two DTS Information Items D1 (the From DTS) and D2 (the To DTS) are NOT equivalent if both the following conditions are satisfied and any of the following conditions exist:

For any XBRL Concept Information Item defined in the [Concepts] property of D1 there does not exist any corresponding XBRL Concept Information Item in D2 . Processors MUST document all such differences by generating a Concept deleted event [EvConceptDelete] with the concept identifier [ConceptId] in the [from DTS] parameter.
For any XBRL Concept Information Item defined in the [Concepts] property of D2 a corresponding XBRL Concept Information Item cannot be found in D1 . Processors MUST document all such differences by generating a Concept added event [EvConceptNew] with the concept identifier [ConceptId] in the [to DTS] parameter.
For any XBRL Resource Information Item defined in the [Resources] property of D1 a corresponding XBRL Resource Information Item cannot be found in D2 . Processors MUST document all such differences by generating a Resource deleted event [EvResourceDelete] with the resource identifier [ResourceId] in the [from DTS] parameter.
For any XBRL Resource Information Item defined in the [Resources] property of D2 a corresponding XBRL Resource Information Item cannot be found in D1 . Processors MUST document all such differences by generating a Resource added event [EvResourceNew] with the resource identifier [ResourceId] in the [from DTS] parameter.

2.2.2 Comparing two XBRL Item Information Items

Two XBRL Item Information Items I1 which belongs to the From DTS and I2 which belongs to the To DTS are equivalent if all the following conditions are satisfied and none of the "Not Equivalent" conditions defined in Section 2.2.2.1 exist:

If the value of the Namespace property of the XBRL Taxonomy Information Item referenced in the Parent property of I1 is equal to the value of the namespace pair of the Namespace property of the XBRL Taxonomy Information Item referenced in the Parent property 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.
If the value of the Name property of I1 is equal to the value of the Name property 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.
If the content of the Type property of I1 is equivalent to the content of the Type property of I2 according to Section 2.2.8 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.
If the value of the Substitution Group property of I1 is equal to the value of the Substitution Group property 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.
If the value of the Period Type property of I1 is equal to the value of the Period Type property 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.
If the value of the Balance property of I1 is equal to the value of the Balance property 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.
If the value of the Default property of I1 is equal to the value of the Default property 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.
If the value of the Nillable property of I1 is equal to the value of the Nillable property of I2 this condition is satisfied. Processors MUST raise a Concept Nillable event [EvNillable]l with the two concept identifiers [ConceptId] as parameters if this condition is not satisfied.
If the value of the Abstract property of I1 is equal to the value of the Abstract property 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.
If the value of the Block property of I1 is equal to the value of the Block property 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.
If the value of the Fixed property of I1 is equal to the value of the Fixed property 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.
If the value of the Final property of I1 is equal to the value of the Final property 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.
For each XBRL Relationship Information Item in the From property of I1 where a corresponding XBRL Relationship Information Item in the From property of I2 exist; both relationships are equivalent if they satisfy all conditions in Section 2.2.4. 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.
For each XBRL Relationship Information Item in the To property of I1 where a corresponding XBRL Relationship Information Item in the To property of I2 exists; both relationships are equivalent if they satisfy all conditions in Section 2.2.4. 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.
For each XML Attribute Information Item in the Attributes property of I1 where a corresponding XML Attribute Information Item in the Attributes property of I2 exists; both attributes are equivalent if they satisfy all conditions in Section 2.2.7. 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.
For each XML Element Information Item in the Children property of I1 where a corresponding XML Element Information Item in the Children property of I2 exists; both XML Elements are equivalent if they satisfy all conditions in Section 2.2.6. 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 Section 2.2.6.

2.2.2.1 "NOT equivalent" conditions

Two XBRL Item Information Item s I1 , which belongs to the From DTS, and I2 , which belongs to the To DTS, are NOT equivalent if any of the following conditions exist:

For any XBRL Relationship Information Item in the From property of I1 a corresponding XBRL Relationship Information Item cannot be found in the From property of I2 . 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.
For any XBRL Relationship Information Item in the From property of I2 a corresponding XBRL Relationship Information Item cannot be found in the From property of I1 . 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.
For any XBRL Relationship Information Item in the To property of I1 a corresponding XBRL Relationship Information Item cannot be found in the To property of I2 . 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.
For any XBRL Relationship Information Item in the To property of I2 a corresponding XBRL Relationship Information Item cannot be found in the To property of I1 . 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.
For any XML Attribute Information Item in the Attributes property of I1 a corresponding XML Attribute Information Item cannot be found in the Attributes property of I2 . 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.
For any XML Attribute Information Item in the Attributes property of I2 a corresponding XML Attribute Information Item cannot be found in the Attributes property of I1 . 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.
For any XML Element Information Item in the Children property of I1 a corresponding XML Element Information Item cannot be found in the Children property of I2 . 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.
For any XML Element Information Item in the Children property of I2 a corresponding XML Element Information Item cannot be found in the Children property of I1 . 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, T1 , which belongs to the From DTS, and T2 , which belongs to the To DTS, are equivalent if all the following conditions are satisfied and none of the "NOT equivalent" conditions defined in Section 2.2.3.1 exist.

If the value of the Namespace property of the XBRL Taxonomy Information Item referenced in the Parent property of T1 is equal to the value of the namespace pair of the Namespace property of the XBRL Taxonomy Information Item referenced in the Parent property 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.
If the value of the Name property of T1 is equal to the value of the Name property 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.
If the content of the Type property of T1 is equivalent to the content of the Type property of T2 according to Section 2.2.8 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.
If the value of the Substitution Group property of T1 is equal to the value of the Substitution Group property 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.
If the value of the Nillable property of T1 is equal to the value of the Nillable property 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.
If the value of the Abstract property of T1 is equal to the value of the Abstract property 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.
If the value of the Block property of T1 is equal to the value of the Block property 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.
If the value of the Final property of T1 is equal to the value of the Final property 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.
For each XBRL Relationship Information Item in the From property of T1 where a corresponding XBRL Relationship Information Item in the From property of T2 exist; both relationships are equivalent if they satisfy all conditions in Section 2.2.4. 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.
For each XBRL Relationship Information Item in the To property of T1 where a corresponding XBRL Relationship Information Item in the To property of T2 exists; both relationships are equivalent if they satisfy all conditions in Section 2.2.4. 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.
For each XML Attribute Information Item in the Attributes property of T1 where a corresponding XML Attribute Information Item in the Attributes property of T2 exists; both attributes are equivalent if they satisfy all conditions in Section 2.2.7. 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.
For each XML Element Information Item in the Children property of T1 where a corresponding XML Element Information Item in the Children property of T2 exists; both XML Elements are equivalent if they satisfy all conditions in Section 2.2.6. 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.

2.2.3.1 "NOT equivalent" conditions

Two XBRL Tuple Information Items, T1 , which belongs to the From DTS, and T2 , which belongs to the To DTS, are NOT equivalent if any of the following conditions exist.

For any XBRL Relationship Information Item in the From property of T1 a corresponding XBRL Relationship Information Item cannot be found in the From property of T2 . 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.
For any XBRL Relationship Information Item in the From property of T2 a corresponding XBRL Relationship Information Item cannot be found in the From property of T1 . 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.
For any XBRL Relationship Information Item in the To property of T1 a corresponding XBRL Relationship Information Item cannot be found in the To property of T2 . 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.
For any XBRL Relationship Information Item in the To property of T2 a corresponding XBRL Relationship Information Item cannot be found in the To property of T1 . 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.
For any XML Attribute Information Item in the Attributes property of T1 a corresponding XML Attribute Information Item cannot be found in the Attributes property of T2 . 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.
For any XML Attribute Information Item in the Attributes property of T2 a corresponding XML Attribute Information Item cannot be found in the Attributes property of T1 . 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.
For any XML Element Information Item in the Children property of T1 where a corresponding XML Element Information Item cannot be found in the Children property of T2 . 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.
For any XML Element Information Item in the Children property of T2 where a corresponding XML Element Information Item cannot be found in the Children property of T1 . 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 R1 , which belongs to the From DTS, and R2 , which belongs to the To DTS, are equivalent if all the following conditions are satisfied and none of the "NOT equivalent" conditions defined in Section 2.2.4.1 exist.

If the object in the From DTS pointed to by the From property of R1 corresponds to the object in the To DTS pointed to by the From property 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.
If the object in the From DTS pointed to by the To property of R1 corresponds to the object in the To DTS pointed to by the To property 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.
If each relationship in the [Preceding] relationship set of R1 in the From DTS corresponds to another relationship in the [Preceding] relationship set of R2 in the To DTS, or the [Preceding] relationship set of both relationships are empty 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.
If each relationship in the [Following] relationship set of R1 in the From DTS corresponds to another relationship in the [Following] relationship set of R2 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.
If the value of the Priority property of R1 is equal to the value of the Priority property 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.
For each XML Attribute Information Item in the Attributes property of R1 where a corresponding XML Attribute Information Item in the Attributes property of R2 exists; both attributes are equivalent if they satisfy all conditions in Section 2.2.7. 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.

2.2.4.1 "NOT equivalent" conditions

Two XBRL Relationship Information Items R1 , which belongs to the From DTS, and R2 , which belongs to the To DTS, are NOT equivalent if any of the following conditions exist.

For any XML Attribute Information Item in the Attributes property of R1 a corresponding XML Attribute Information Item cannot be found in the Attributes property of R2 . 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.
For any XML Attribute Information Item in the Attributes property of R2 a corresponding XML Attribute Information Item cannot be found in the Attributes property of R1 . 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, X1 , which belongs to the From DTS, and X2 , which belongs to the To DTS, are equivalent if all the following conditions are satisfied and none of the "NOT equivalent" conditions defined in Section 2.2.5.1 exist:

If the value of the Type property of X1 is equal to the value of the Type property 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.
If the value of the URI property of the XBRL Role Type Information Item referenced in the Role property of X1 is equal to the value of the value of the URI property of the XBRL Role Type Information Item referenced in the Role property 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.
For each XBRL Relationship Information Item in the From property of X1 where a corresponding XBRL Relationship Information Item in the From property of X2 exist; both relationships are equivalent if they satisfy all conditions in Section 2.2.4. 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.
For each XBRL Relationship Information Item in the To property of X1 where a corresponding XBRL Relationship Information Item in the To property of X2 exists; both relationships are equivalent if they satisfy all conditions in section Section 2.2.4. 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.
For each XML Attribute Information Item in the Attributes property of X1 where a corresponding XML Attribute Information Item in the Attributes property of X2 exists; both attributes are equivalent if they satisfy all conditions in Section 2.2.7. 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.
If the resource has complex content and for each node N1 in the sequence of nodes of the Element property of X1 ; a node N2 exists that is the node in the same position in the sequence of nodes in the Element property 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.
If the resource has simple content and the value of the Value property of X1 is s-equal2 to the value of the Value property 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.5.1 "NOT equivalent" conditions

Two XBRL Resource Information Items X1 , which belongs to the From DTS, and X2 , which belongs to the To DTS, are NOT equivalent if any of the following conditions exist:

For any XBRL Relationship Information Item in the From property of X1 a corresponding XBRL Relationship Information Item cannot be found in the From property of X2 . 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.
For any XBRL Relationship Information Item in the From property of X2 a corresponding XBRL Relationship Information Item cannot be found in the From property of X1 . 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.
For any XBRL Relationship Information Item in the To property of X1 a corresponding XBRL Relationship Information Item cannot be found in the To property of X2 . 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.
For any XBRL Relationship Information Item in the To property of X2 a corresponding XBRL Relationship Information Item cannot be found in the To property of X1 . 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.
For any XML Attribute Information Item in the Attributes property of X1 a corresponding XML Attribute Information Item cannot be found in the Attributes property of X2 . 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.
For any XML Attribute Information Item in the Attributes property of X2 a corresponding XML Attribute Information Item cannot be found in the Attributes property of X1 . 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.
For any resource that has complex content and for each node N1 in the sequence of nodes of the Element property of X1 a node N2 that is the node in the same position in the sequence of nodes in the Element property of X2 does not exist. 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.
For any resource that has complex content and for each node N2 in the sequence of nodes of the Element property of X2 a node N1 that is the node in the same position in the sequence of nodes in the Element property of X1 does not exist. 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.

2.2.6 Comparing two XML Element Information Items

Two XML Element Information Items E1 , which belongs to the From DTS and E2 , which belongs to the To DTS, are equivalent if the following condition is satisfied:

If E1 and E2 are s-equal2 nodes except for the attributes in the XLINK namespace and the id attribute 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

Two XML Attribute Information items A1 ,which belongs to the From DTS and A2 , which belongs to the To DTS are equivalent if the following condition is satisfied:

If A1 and A2 are s-equal2 nodes this condition is satisfied. 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, tuple or resource 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, tuple and resource 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.

Processors MUST detect where the lexical space (as defined by 2.3 of [XML Schema Datatypes]) of a concept's data type has changed.

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

The s-equal2 predicate is identical to the s-equal predicate defined in section 4.10 of [XBRL 2.1] replacing [XPATH1-SCHEME] with [XPATH 2.0] in the definition of the x-equal operation for the cases in which the s-equal predicate relies on x-equality. [XPATH 2.0] equality MUST be performed with the "XPath 1.0 compatibility mode" property set to false in the static context (See the implementation note below).

IMPLEMENTATION NOTE (non-normative): [XBRL 2.1] is based on [XPATH1-SCHEME]. According to section 5.3 of [XPATH1-SCHEME], 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 normalise the prefixes of QNames in order to effectively compare QNames and should not use their lexical representation for the comparison.

2.4 Rules of correspondence between Information Items

Section 2.2 of this specification compares two information items that correspond one (in the From DTS) to the other (in the To DTS). Only two information items that correspond are subject to be compared to detect "technical differences". The rules of correspondence of two information items are described in this section.

Two information items A and B correspond if they are of the same type and satisfy all conditions in the appropriate section according to the information item type.

2.4.1 Correspondence of Concept Definitions

Two concept definitions A and B are in correspondence if there is at least one Diff Event in the versioning report that contains the concept identifier [ConceptId] of concept A in the [From DTS] parameter and the concept identifier [ConceptId] of concept B in the [To DTS] parameter.

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 of relationship A is the Information Item in the content of the From property of relationship B . For the identification of the correspondent content in the From property of the relationship A the appropriate Section 2.4.1, Section 2.4.3 or Section 2.4.5MUST be used according to the content type, and
The role URI pair of the URI property of the role property of the Extended Link that is the Parent property of the relationship A is equal to the value of the URI property of the role property of the Extended Link that is the Parent property of the relationship B , and
The Type property of relationship A is equal to the Type property of relationship B , and
The URI property of the Arcrole property of relationship A is equal to the URI property of the Arcrole property of relationship B , and
The correspondent Information Item of the content of the To property of relationship A is the Information Item in the content of the To property of relationship B . For the identification of the correspondent content in the To property of the relationship A the appropriate section Section 2.4.1, Section 2.4.3 or Section 2.4.5 sec-corresp-xml-element-nodes MUST be used according to the content type.

2.4.3 Correspondence of Resources

Two resources A and B are in correspondence if there is at least one Diff Event in the versioning report that contains the resource identifier [ResourceId] of resource A in the [From DTS] parameter and the resource identifier [ResourceId] of resource B in the [To DTS] parameter.

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.

2.5 Hierarchical organisation of events

The events documenting the "technical differences" are organised according to Table 3. [Hugh Wallis: Links from terms such as [ConceptId] will be added to point to the relevant definition in the syntax specification once that specification is finalised. ]

Table 3: Hierarchical organisation of events

Code	Event	Parent Event	From DTS	To DTS	Final
[EvConceptDelete]	Concept deleted	None	[ConceptId]	-	Yes
[EvConceptNew]	Concept added	None	-	[ConceptId]	Yes
[EvConceptNoChangeEvent]	Concept equivalency	None	[ConceptId]	[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
[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]	Yes
[EvResourceDelete]	Resource deleted	none	[ResourceId]	-	Yes
[EvResourceNew]	Resource added	none	-	[ResourceId]	Yes
[EvResourceNoChangeEvent]	Resource equivalency	none	[ResourceId]	[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

2.6 Extensibility model of Events

[Hugh Wallis: This section will be updated once the syntax specification is agreed upon to ensure that concepts therein that are referenced here are properly linked. ]

Events in a versioning report are not limited to those defined in Section 2.5 . This specification provides one abstract event called ver:EvOther that can be used in other specifications to define new events more appropriate to the content they are dealing with.

The only constraint for those new events is that they MUST be defined in the substitution group of the ver:EvOther event and the type definition MUST be a valid restriction of ver:nestedEventType. Refer to Part 2 of this document for more information about the limitations imposed by the ver:nestedEventType.

It is expected that extensions of this specification will provide new ways to identify a concept or a resource in a DTS. For this reason, the extensibility of the "technical differences" is complemented with the existence of two extensibility points to define new concept identifiers and new resource identifiers.

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 to concepts or resources between two DTSs.

The content of a version information item is represented in Figure 2

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 categorised in order to allow business users to filter what information they want to access, and
be documented separately, and
are optional content in a versioning report.

Actions can:

group a set of "technical differences" between the From DTS and the To DTS, and
provide a semantic meaning for the change, and
provide specific human readable documentation.

3.1 Complete versioning reports

Looking at the information in the versioning report as if it were 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.

A complete versioning report MUST contain in-scope documentation for every "technical difference" represented as a Difference Path generated by conditions according to Section 2.2.

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

The completeness of a versioning report can be validated by versioning processors implemented according to this specification.

3.2 The Concept A or Resource X 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 A or resource component in the event.

3.3 The Concept B or Resource Y component

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

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

3.4 The Assignment component

This is a container of human readable documentation related to the reasons for 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 the concept A or resource X component and/or the concept B or resource Y component.

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

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

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

Action components referencing concept B or resource Y components without being referenced by concept A or resource X 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

An 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 in Part 2 of this specification. [Hugh Wallis: This will require updating with proper references once the syntax specification is decided upon. Since Part 2 is about syntax it may be appropriate to restructure this in order to avoid having semantics defined therein? ]

A single Action may have zero or more Events.

3.7 The Differences component

This component represents one Difference Path

3.8 The Categories component

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

Errata
Business
Technical

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

3.9 The Documentation component

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

3.10 The Version component

This component is the container of a versioning report between two DTSs. It contains information about the DTSs where Concept A or Resource X and Concept B or Resource Y are defined. This information includes:

The starting point of the DTS that Concept A or Resource X belongs to.
The starting point of the DTS that Concept B or Resource Y belongs to.
Optionally, references to other versioning reports.
Optionally, the namespace mapping information that identifies the correspondence between namespace definitions in the From DTS and namespace definitions in the To DTS.
Optionally, the role mapping information that identifies the correspondence between role URIs used in the From DTS and role URIs used in the To DTS.

[Hugh Wallis: The final specification may also include definitions of all the terms used here: i.e. "From namespace", "To namespace", "From concept", "To concept", "From URI", "To URI", "From role URI", "From Resource", "To Resource" so as to ensure these terms are unambiguous ]

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

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. [Hugh Wallis: The WG would appreciate feedback on whether this would be better called the "paired namespace"? "Namespace Pair" implies a pair of "things" but this is really only one "thing" ]

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

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. [Hugh Wallis: Similar comment as before - perhaps the "paired role URI" might be better? ]

The concept mapping information is a set of QName pairs identifying which are the From concept QName and the To concept QName. The concept mapping table is not explicitly written in the versioning report but obtained from the From DTS and To DTS parameters in the To DTSs.

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. [Hugh Wallis: Same comment as before - suggest "paired concept" ]

The resource mapping information is a set of [XPOINTER] reference pairs identifying which are the From resource and the To resource. The resource mapping table is not explicitly written in the versioning report but obtained from the From DTS and To DTS parameters in the To DTSs.

The resource pair of a From resource is the To resource defined in the resource mapping table. This relationship is symmetric. [Hugh Wallis: Same comment as before - perhaps "paired resource"? ]

Appendix A References

IETF RFC 2119: IETF (Internet Engineering Task Force). "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels"
Scott Bradner.
(See http://www.ietf.org/rfc/rfc2119.txt)
XBRL 2.1: XBRL International Inc.. "Extensible Business Reporting Language (XBRL) 2.1 Includes Corrected Errata Up To 2008-07-02"
Phillip Engel, Walter Hamscher, Geoff Shuetrim, David vun Kannon, and Hugh Wallis.
(See http://www.xbrl.org/Specification/XBRL-RECOMMENDATION-2003-12-31+Corrected-Errata-2008-07-02.htm)
XBRL Information Set: XBRL International Inc.. "XBRL Infoset"
Ignacio Hernández-Ros.
(See http://www.xbrl.org/Specification/Infoset/PWD-2009-02-04/infoset-PWD-2009-02-04.html)
XML Names: W3C (World Wide Web Consortium). "Namespaces in XML 1.0 (Second Edition)"
Tim Bray, Dave Hollander, Andrew Layman, and Richard Tobin.
(See http://www.w3.org/TR/REC-xml-names/)
XML Schema Datatypes: W3C (World Wide Web Consortium). "XML Schema Part 2: Datatypes Second Edition"
Paul V. Biron, and Ashok Malhotra.
(See http://www.w3.org/TR/xmlschema-2/)
XPATH 2.0: W3C (World Wide Web Consortium). "XML Path Language (XPath) 2.0"
Anders Berglund, Scott Boag, Don Chamberlin, Mary F. Fernández, Michael Kay, Jonathan Robie, and Jérôme Siméon.
(See http://www.w3.org/TR/xpath20/)
XPATH1-SCHEME: Text Encoding Initiative. "XPointer xpath1() Scheme"
(See http://www.tei-c.org/release/doc/tei-p5-doc/en/html/SA.html#SATSXP)
XPOINTER: W3C (World Wide Web Consortium). "XPointer Framework"
Paul Grosso, Eve Maler, Jonathan Marsh, and Norman Walsh.
(See http://www.w3.org/TR/xptr-framework/)

Appendix B Intellectual property status (non-normative)

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to XBRL International or XBRL organizations, except as required to translate it into languages other than English. Members of XBRL International agree to grant certain licenses under the XBRL International Intellectual Property Policy (www.xbrl.org/legal).

This document and the information contained herein is provided on an "AS IS" basis and XBRL INTERNATIONAL DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

The attention of users of this document is directed to the possibility that compliance with or adoption of XBRL International specifications may require use of an invention covered by patent rights. XBRL International shall not be responsible for identifying patents for which a license may be required by any XBRL International specification, or for conducting legal inquiries into the legal validity or scope of those patents that are brought to its attention. XBRL International specifications are prospective and advisory only. Prospective users are responsible for protecting themselves against liability for infringement of patents. XBRL International takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Members of XBRL International agree to grant certain licenses under the XBRL International Intellectual Property Policy (www.xbrl.org/legal).

Appendix C Acknowledgements (non-normative)

This document could not have been written without the contributions of many people including the participants in the Versioning Working Group.

Appendix D Document history (non-normative)

Date	Author	Details
04 January 2007	Ignacio Hernández-Ros	First skeletal draft created.
15 February 2007	Ignacio Hernández-Ros	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.
21 February 2007	Ignacio Hernández-Ros	Updated properties are: Content of a Imported XBRL Information item MAY not exist Linkbases in an XBRL Taxonomy Information Item are not ordered
15 March 2007	Ignacio Hernández-Ros	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.
14 April 2007	Ignacio Hernández-Ros	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
17 August 2007	Ignacio Hernández-Ros	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.
12 September 2007	Ignacio Hernández-Ros	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.
09 October 2007	Ignacio Hernández-Ros	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.
22 October 2007	Ignacio Hernández-Ros	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 Assignment is now in the categoryTupleType 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.
02 November 2007	Ignacio Hernández-Ros	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.
15 November 2007	Ignacio Hernández-Ros	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.
11 April 2008	Ignacio Hernández-Ros	Updated from DPWD back to IWD Wording changes in the Abstract section Wording changes in the Introduction Namespace changed from 2007 to 2008. Redlined version of the document may show 20072008 rather than just 2008. This is due to a bug Word that does not remove from the final variable value the text deleted in a paragraph. XBRL Versioning, a new paragraph has been added to define "technical differences" and "semantic differences". Figure 1 updated according to comments received by Geoff Shuetrim. Section 2.1, wording changes to better explain the content of the XBRL Infoset and state that this specification covers changes in resource definitions as well as changes in concept definitions. Section 2.2 other editorial wording changes there are no changes to the comparison rules. Section 2.4 Changed the definition of the correspondence of concept definitions and the correspondence of resource definitions due to the reason the no longer exist. Section 2.5 added the two new events related to documenting no changes in concept definitions and no changes in resource definitions. Deleted the unnecessary EvArcrole event. New section 2.6 explaining that the event model is extensible and how to extend it. Section 3, changed figure 2 according to comments received from Walter Hamscher and updated the versioning box to accommodate the new content. Section 3.1 wording changes to include part of the text in the previous section. The completeness of a versioning report is now easier to understand thanks to the new definitions. Section 3.10 changed to accommodate the new content of the version component and the removal of the concept mapping table and resource mapping table. Section 4. Several changes: reworded the sections that suffered impact of the changes in the taxonomy and the addition of the new extensibility points. Relevant changes in section 4.3.3 to accommodate the new extensibility points at the time to define a concept identifier or a resource identifier. Appendix B requirements Reference has been updated because this new release of the document allows some requirements that was not addressed before. Versioning Taxonomy Summary has been updated.
20 May 2008	Ignacio Hernández-Ros	Chapter 4 (Syntax) moved into a different document (Part 2) Status changed from PWD into Draft Final Working Draft.
22 May 2008	Hugh Wallis	Editorial review and changes for publication. Rearranged sections dealing with conditions to be satisfied and not satisfied into a different logical structure for ease of understanding. Corrected title of document to Draft Public Working Draft (DPWD)
28 May 2008	Ignacio Hernández-Ros	Added a note to clarify that the versioning specification could also be used by companies reporting changes to their taxonomies. Reviewed editorial changes made by Hugh Wallis. Added changes according to comments from Herm Fischer. Revert document title to Internal Working Draft (IWD)
03 June 2008	Hugh Wallis	Minor editorial updates for wider distribution as IWD to other working groups.
10 June 2008	Hugh Wallis	Editorial to update to Draft PWD
09 August 2008	Hugh Wallis	Converted to S4S WGWD - many comments inserted
10 December 2008	Hugh Wallis	Edited for publication as a PWD. Included the WG's resolution to many editing comments - allowed some comments to remain for resolution after receiving feedback on the PWD.

Appendix E Errata corrections in this document

This appendix contains a list of the errata that have been incorporated into this document. This represents all those errata corrections that have been approved by the XBRL International Versioning Working Group up to and including 04 February 2009. Hyperlinks to relevant e-mail threads may only be followed by those who have access to the relevant mailing lists. Access to internal XBRL mailing lists is restricted to members of XBRL International Inc.

No errata have been incorporated into this document.

End Notes

[1]: ETL stands for Extract, Transform and Load
[2]: Note that, as a result of the definitions in [XBRL 2.1] and [XBRL Information Set], two relationships belong to the same Extended Link role if they have the same value in the [URI] property of the Role Type Information Item that is the value of the [Role] property of the [Parent] property of each relationship

Versioning Report Content 1.0

Public Working Draft 04 February 2009

Status

Abstract

Comments

Table of Contents

Appendices

Tables

Figures

Examples

Definitions