XBRL Versioning
Specification 1.0
Public
Working Draft, dated 2007-11-28
Copyright © 2007 XBRL International Inc., All Rights
Reserved
This version:
XVS-PWD-2007-11-28.htm
is NON-NORMATIVE. The NORMATIVE version is in the file XVS-PWD-2007-11-28.rtf
Authors
Name |
Contact |
Affiliation |
Ignacio Hernández-Ros |
Contributors
Name |
Contact |
Affiliation |
Timo Philipp |
tphilipp@IASB.ORG.UK |
IASC Foundation |
Paul Warren |
pdw@DECISIONSOFT.COM |
DecisionSoft |
Raynier van Egmond |
C3i SMC LLC. |
Abstract
This specification defines the syntax and semantics of the versioning report. The versioning report represents the changes made to the concept definitions and resources that exist in two different DTSs.
In the most common use case, the two DTSs will represent two consecutive versions of the same taxonomy.
The most important motivation for the standardisation of a versioning report is the capacity to communicate changes in a DTS to taxonomy users. This capacity allows taxonomy users to identify and apply changes to internal systems. Some of the changes may be performed automatically by software using the versioning report and without human intervention and some other changes will always require human intervention. For example, this is the case of software updating a taxonomy extension so that it may be applied to a new release of the core taxonomy or adapting ETL[1] software already mapped to a previous version of a taxonomy.
The information that is communicated in the versioning report has two purposes. Firstly there is the set of changes that software can identify comparing the concept definitions that appear in the two DTSs. Once the properties of a concept definition are established[2], the differences between concept definitions can be obtained automatically. However, the versioning report is not just this set of differences. Secondly, the versioning report is a communication tool that satisfies higher level business requirements about what changes are made to concept definitions. In this sense, the versioning report is a communication tool about the differences that can be found between two DTSs, including human readable documentation about the changes.
Because the versioning report is a communication tool, different taxonomy authors may want to communicate the same things in different ways. In this sense, the set of possible differences found between two DTSs can be ignored, considered separately or grouped together and documented separately in the versioning report.
This specification does not impose any obligation to taxonomy authors to document changes in a specific way but rather provides a framework to standardize the way the changes are communicated so applications can consume that information for its purposes.
Status
Circulation of this Public Working Draft is unrestricted. Recipients of this draft are invited to submit comments to the authors and contributors, and to submit notification of any relevant patent rights of which they are aware and to provide supporting documentation.
Table of Contents
1.2 Relationship
to other work
2.1 The
XBRL versioning Infoset
2.2 The
differences between two DTSs
2.2.1 Comparing
two DTS Information Items:
2.2.2 Comparing
two XBRL Item Information Items:
2.2.3 Comparing
two XBRL Tuple Information Items:
2.2.4 Comparing
two XBRL Relationship Information Items:
2.2.5 Comparing
two XBRL Resource Information Items:
2.2.6 Comparing
two XML Element Information Items:
2.2.7 Comparing
two XML Attribute Information Items:
2.2.8 Comparing
two Schema Type Definitions:
2.3 Definition
of the s-equal2 operation between two sequences of XML nodes:
2.4 Rules
of correspondence between Information Items
2.4.1 Correspondence
of Concept Definitions
2.4.2 Correspondence
of Relationships
2.4.3 Correspondence
of Resources
2.4.4 Correspondence
of XML Attributes
2.4.5 Correspondence
of XML Element Nodes
2.5 Hierarchical
organization of the events.
3 The
content model of the versioning report
3.1 Complete
versioning reports
3.2 The
Concept or resource A component
3.3 The
Concept or resource B component
3.9 The
Documentation component
4 The
versioning report syntax
4.2.1 The
instance-linkbase arc role type
4.2.2 The
assignment-label arc role type
4.2.3 The
action-label arc role type.
4.2.4 The
assignment-action arc role type
4.3.1 Main
concept definitions
4.3.2.1 Intermediate
event types
4.3.2.2 Events
related to concept definitions
4.3.2.3 Events
related to relationships
4.3.2.4 Events
related to resources
4.3.2.5 Events
related to attributes
4.3.2.6 Events
related to node elements
4.3.3.1 The
concept identifier
4.3.3.2 The
relationship identifier
4.3.3.3 The
resource identifier
4.3.3.4 The
XML Attribute node identifier
4.3.3.5 The
fragment identifier
B Requirements
Reference (non-normative)
D Intellectual
Property Status
Table of Definitions
[Def 1] A Difference
Event is the representation of something not equivalent found between
properties of two corresponding XBRL Information Items being compared..................................................... 6
[Def 2] A Difference
Path is a set of Difference Events............................................................... 7
[Def 3] The Starting
Event of a path is always the first event in the path................................. 7
[Def 4] The Ending
Event of a path is always the last event in the path................................... 7
[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................ 23
[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................................................................................. 23
[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.............. 23
[Def 8] The resource
pair of a From resource is the To resource defined in the resource mapping
table. 24
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.
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.
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.
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. |
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:
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 |
|
xs |
|
xlink |
|
link |
|
xl |
|
ver |
http://xbrl.org/2007/versioning |
The Prefix column in the table above is non normative. The Namespace URI column is normative.
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.
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.
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 |
All properties are included. |
|
The XBRL Document Information Item |
[XIS 2.2.2] |
All properties are excluded. |
The XBRL Taxonomy Information Item |
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 |
URI [XIS 2.2.5.4] is included. All other properties are excluded. |
|
The Arcrole Type Information Item |
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 |
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 |
All properties are included. |
|
The XBRL Tuple Information Item |
All properties are included. |
|
The XBRL Linkbase Information Item |
[XIS 2.2.11] |
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 |
[XIS 2.2.13] |
All properties are excluded. |
The Relationship Information Item |
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 |
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.
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]. |
|
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]. |
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.
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.
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.
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.
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.
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.
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.
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.
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.
The s-equal2 operation is the same
operation defined in section 4.10 of the [XBRL] specification replacing XPath 1.0 with XPath
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.
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.
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.
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
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].
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.
Two XML Element nodes N1 and N2 are in correspondence if they are s-equal2 nodes.
The events documenting the differences are organized according to the following table:
Code |
Event |
Parent Event |
Parameter From DTS |
Parameter To DTS |
Final |
None |
[ConceptId] |
- |
Yes |
||
None |
- |
[ConceptId] |
Yes |
||
None |
[ConceptId] |
[ConceptId] |
Yes |
||
None |
[ConceptId] |
[ConceptId] |
Yes |
||
None |
[ConceptId] |
[ConceptId] |
Yes |
||
None |
[ConceptId] |
[ConceptId] |
Yes |
||
None |
[ConceptId] |
[ConceptId] |
Yes |
||
None |
[ConceptId] |
[ConceptId] |
Yes |
||
None |
[ConceptId] |
[ConceptId] |
Yes |
||
None |
[ConceptId] |
[ConceptId] |
Yes |
||
None |
[ConceptId] |
[ConceptId] |
Yes |
||
None |
[ConceptId] |
[ConceptId] |
Yes |
||
None |
[ConceptId] |
[ConceptId] |
Yes |
||
None |
[ConceptId] |
[ConceptId] |
Yes |
||
None |
[ConceptId] |
[ConceptId] |
No |
||
None |
[ConceptId] |
[ConceptId] |
No |
||
None |
[ConceptId] |
[ConceptId] |
No |
||
None |
[ConceptId] |
[ConceptId] |
No |
||
[EvConceptAttribute] or [EvRelationshipAttribute] or [EvResourceAttribute] |
[AttributeId] |
- |
Yes |
||
[EvConceptAttribute] or [EvRelationshipAttribute] or [EvResourceAttribute] |
- |
[AttributeId] |
Yes |
||
[EvConceptAttribute] or [EvRelationshipAttribute] or [EvResourceAttribute] |
[AttributeId] |
[AttributeId] |
Yes |
||
[EvChild] or [EvContent] |
[NodeId] |
- |
Yes |
||
[EvChild] or [EvContent] |
- |
[NodeId] |
Yes |
||
[EvChild] or [EvContent] |
[NodeId] |
[NodeId] |
Yes |
||
[EvConceptRelationshipFrom] or [EvConceptRelationshipTo] or [EvResourceFrom] or [EvResourceTo] |
[RelationshipId] |
- |
Yes |
||
[EvConceptRelationshipFrom] or [EvConceptRelationshipTo] or [EvResourceFrom] or [EvResourceTo] |
- |
[RelationshipId] |
Yes |
||
[EvConceptRelationshipFrom] or [EvConceptRelationshipTo] or [EvResourceFrom] or [EvResourceTo] |
[RelationshipId] |
[RelationshipId] |
Yes |
||
[EvConceptRelationshipFrom] or [EvConceptRelationshipTo] or [EvResourceFrom] or [EvResourceTo] |
[RelationshipId] |
[RelationshipId] |
Yes |
||
[EvConceptRelationshipFrom] or [EvConceptRelationshipTo] or [EvResourceFrom] or [EvResourceTo] |
[RelationshipId] |
[RelationshipId] |
Yes |
||
[EvConceptRelationshipFrom] or [EvConceptRelationshipTo] or [EvResourceFrom] or [EvResourceTo] |
[RelationshipId] |
[RelationshipId] |
Yes |
||
[EvConceptRelationshipFrom] or [EvConceptRelationshipTo] or [EvResourceFrom] or [EvResourceTo] |
[RelationshipId] |
[RelationshipId] |
Yes |
||
[EvConceptRelationshipFrom] or [EvConceptRelationshipTo] or [EvResourceFrom] or [EvResourceTo] |
[RelationshipId] |
[RelationshipId] |
Yes |
||
[EvConceptRelationshipFrom] or [EvConceptRelationshipTo] or [EvResourceFrom] or [EvResourceTo] |
[RelationshipId] |
[RelationshipId] |
No |
||
None |
[ResourceId] |
- |
Yes |
||
None |
- |
[ResourceId] |
Yes |
||
None |
[ResourceId] |
[ResourceId] |
Yes |
||
None |
[ResourceId] |
[ResourceId] |
Yes |
||
None |
[ResourceId] |
[ResourceId] |
No |
||
None |
[ResourceId] |
[ResourceId] |
No |
||
None |
[ResourceId] |
[ResourceId] |
No |
||
None |
[ResourceId] |
[ResourceId] |
No |
||
None |
[ResourceId] |
[ResourceId] |
Yes |
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.
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.
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.
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.
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.
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.
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.
This component represents one Difference Path [Def 2].
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.
This is represents the text of the human readable documentation for the in-scope change event.
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.
This specification defines a normative XBRL 2.1 DTS to generate versioning reports.
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" xlink:role=http://www.xbrl.org/2003/role/labelLinkbaseRef
xlink:arcrole="http://www.w3.org/1999/xlink/properties/linkbase"/> |
· The presentation Linkbase module contains generic parent-child relationships between the concepts defined representing the expected nested structure of the items in the report.
· The labels Linkbase module contains English labels for the concepts defined in the versioning taxonomy.
The taxonomy schema defines the following four arc role types
The instance-linkbase arc role type is used on instance documents to include a generic Linkbase to the instance document which contains locators, arcs and resources to document the relationships between the assignments and actions and document assignments and actions.
<link:arcroleType arcroleURI="http://xbrl.org/2007/versioning/instance-linkbase" cyclesAllowed="none" id="instanceLinkbase"> <link:definition>Used in the
xlink:arcrole attribute of link:schemaRef elements on instance
document.</link:definition>
<link:usedOn>link:linkbaseRef</link:usedOn> </link:arcroleType> |
The assignment-label arc role type is used to create relationships between gen:label resources and assignments in the instance document. In turn, the gen:label resource contains human readable information related to the assignment.
<link:arcroleType arcroleURI="http://xbrl.org/2007/versioning/assignment-label" cyclesAllowed="none" id="assignmentLabel"> <link:definition>Used
in a generic linkbase to document assignments</link:definition> <link:usedOn>gen:arc</link:usedOn> </link:arcroleType> |
The action-label arc role type is used to create relationships between gen:label resources and actions in the instance document. In turn, the gen:label resource contains human readable information related to the action taken to implement the change or explaining the action itself if no assignments are associated to this action.
<link:arcroleType arcroleURI="http://xbrl.org/2007/versioning/action-label" cyclesAllowed="none" id="actionLabel"> <link:definition>Used in a
generic linkbase to document actions</link:definition>
<link:usedOn>gen:arc</link:usedOn> </link:arcroleType> |
The assignment-action arc role type is used to create relationships between assignments and actions in the instance document. It is allowed that N to M relationships exists between assignments and actions. N or M can be 0. Assignments and actions are optional content on a versioning report.
<link:arcroleType arcroleURI="http://xbrl.org/2007/versioning/assignment-action" cyclesAllowed="none" id="assignmentAction"> <link:definition>Used in a
generic linkbase to connect assignments to actions</link:definition>
<link:usedOn>gen:arc</link:usedOn> </link:arcroleType> |
The Version Information tuple represents the serialization of the content of the "The Version " defined in section 3.10 above.
<element name="version"
id="ver_version" substitutionGroup="xbrli:tuple"> <complexType> <sequence> <element maxOccurs="1"
ref="ver:fromURL"/> <element maxOccurs="1"
ref="ver:toURL"/> <element
maxOccurs="unbounded" minOccurs="0"
ref="ver:nsMap"/> <element
maxOccurs="unbounded" minOccurs="0"
ref="ver:roleMap"/> <element
maxOccurs="unbounded" minOccurs="0"
ref="ver:conceptMap"/> <element
maxOccurs="unbounded" minOccurs="0"
ref="ver:resourceMap"/> </sequence> <attribute name="id"
use="optional" type="ID"/> </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"> <complexType> <all> <element
ref="ver:fromURI"/> <element
ref="ver:toURI"/> </all> </complexType> </element> |
The role mapping table is defined as follows:
<element name="roleMap"
id="ver_roleMap" substitutionGroup="xbrli:tuple"> <complexType> <all> <element
ref="ver:fromURI"/> <element
ref="ver:toURI"/> </all> </complexType> </element> |
The concept mapping table is defined as follows:
<element name="conceptMap"
id="ver_conceptMap" substitutionGroup="xbrli:tuple"> <complexType> <all> <element
ref="ver:fromConcept"/> <element
ref="ver:toConcept"/> </all> </complexType> </element> |
The resource mapping table is defined as follows:
<element name="resourceMap"
id="ver_resourceMap" substitutionGroup="xbrli:tuple"> <complexType> <all> <element
ref="ver:fromResource"/> <element
ref="ver:toResource"/> </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" |