3.1 Namespaces - Rename

3.2 Namespace - Merge

Note: Namespace merges are derived from the fact that multiple <ver:namespaceRename> events have the same content on the <ver:toURI> element.

3.3 Namespace - Split

Note: Namespace splits are derived from the fact that multiple <ver:namespaceRename> events have the same content on the <ver:fromURI> element.

3.4 Concept - Add

Note: Upon a <vercb:conceptAdd> event no other events on this concept are being created, that includes all possible relations to other concepts.

3.5 Concept - Delete

Note: Upon a <vercb:conceptDelete> event no other events on this concept are necessary, that includes all possible relations to other concepts.

Note 2: Upon removal of the concept all the attached relationships and its possible appearance as child in a content model, MUST be removed also to prevent an invalid DTS. No claim has been made in the specification as to how 'deep' the relationships should be removed (chaining). To prevent misunderstanding the user's intention it is preferable to have a conceptDelete event accompanied by a relationshipSetDelete event where the level of removal can be specified, if the concept has relations other than labels and references.

3.6 Concept - Rename

Note: Technically it is possible to rename a concept AND change all of its attributes and relationships and their content. Obviously this should be a conceptDelete followed by a conceptAdd. There is no limit set on what can also be changed when a conceptRename is being used (eg. a labelChange would be likely to occur too).

3.7 Concept - Change

This event does not exist on its own. It is expressed as a number of smaller events that handle all the possible attributes that can be placed on a concept. These events are about the content and FUNCTIONAL presence of the attributes on a concept. This means that the addition of @xbrli:balance on a concept is considered viable in <verce:conceptBalanceChange> as is the change of the @xbrli:periodType value from instant to duration in the <verce:conceptPeriodTypeChange> event. On these type of events the QName of <vercb:fromConcept> and <vercb:toConcept> MUST be the same to avoid a combination of events (like: conceptRename and conceptTypeChange). Two namespaces that are declared as <ver:namespaceRename> event are considered to be equal.

The multiple change event also covers addition or deletion from the attribute on the concept, however, attributes that have a default value (like @abstract) and are made explicit in the schema are NOT considered a change.

3.8 Concept - Change - @id

Note: This event will always be present if FRTA naming conventions are followed and the @name of a concept is being changed.

Note 2: Since the @id on concepts plays no business role, this will always be a technical event.

3.9 Concept - Change - @type

Note: Details of the @type change, like facets, are not explicitly communicated and need to be discovered by the software.

Note 2: Since Since @type changes could be for both business and technical reasons, the assignment reference is the only indicator (apart from the generic label content) for software to determine its impact.

3.10 Concept - Change - @substitutionGroup

Note: Details of the @substitutionGroup change, like new attributes, are not explicitly communicated and need to be discovered by the software.

Note 2: This change event is about the actual content of the @substitutionGroup not about the derived construction of the resolved QName.

3.11 Concept - Change - @default

3.12 Concept - Change - @nillable

A change from the value true to not stating the attribute on the concept at all (or vice versa) is NOT considered a change since true is the default value for this attribute.

3.13 Concept - Change - @abstract

A change from the value false to not stating the attribute on the concept at all (or vice versa) is NOT considered a change since false is the default value for this attribute.

3.14 Concept - Change - @block

The @block attribute is a technical construction concerning extension and restriction. The <ver:assignmnetRef> will always therefore be technical.

3.15 Concept - Change - @fixed

3.16 Concept - Change - @final

The @final attribute is a technical construction concerning extension and restriction. The <ver:assignmnetRef> will always therefore be technical.

3.17 Concept - Change - @xbrli:periodType

The @xbrli:periodType attribute is a construction concerning instant and duration. The <ver:assignmnetRef> will always therefore be business.

3.18 Concept - Change - Attribute - Add

Note: This event MUST NOT be used to add attributes in the xs, xbrli, or xbrldt namespace.

3.19 Concept - Change - Attribute - Delete

Note: This event MUST NOT be used to delete attributes in the xs, xbrli, or xbrldt namespace.

3.20 Concept - Change - Attribute - Change

Note: This event MUST NOT be used to change attributes in the xs, xbrli, or xbrldt namespace.

Note 2: The attribute QName on the <verce:customAttribute> MUST be the same to avoid combination of events. Two namespaces that are declared as <ver:namespaceRename> event are considered to be equal.

3.21 Concept - Change - Attribute - Tuple content

Note: The attribute QName on the <vercb:fromConcept> and <vercb:toConcept> MUST be the same to avoid combination of events. Two namespaces that are declared as <ver:namespaceRename> event are considered to be equal.

Note 2: All content of the complexType (tuple) is communicated with this single event: attributes, element nodes, @minOccurs- or @maxOccurs, the use of xs:choice etc. Everything that can appear in the content model. This also applies to changes to grandchildren or even further down in the nesting hierarchy. Software needs to discover the specific changes.

3.22 Concept - Label - Add

Note: This is the effective business event of adding a label to a concept. There is no indication for the linkrole. The software needs to discover this for itself.

Note 2: This particular label resource was addressed through the @id. For resources that do not have @ids the traditional approach of using an element scheme pointer such as (1/10/2) (i.e. 2nd child of 10th child of the root) is recommended.

Note 3: The resources are addressed using the full (relative) path from the perspective of the versioning report. Absolute paths are preferred.

3.23 Concept - Label - Delete

3.24 Concept - Label - Change

Note: There is no indication what has been changed on the resource: the @xlink:role, @xml:lang or the resource content itself. The software needs to discover this for itself.

Note 2: From this example can be deduced that the @id on resources is especially important in identifying the resource attributes and content. It is not appropriate to 'copy' @xlink:label and treat it as a piece of text. The resource must be treated like a concept.

Note 3: There is no @id change event defined in the XII Versioning specification. This leads to the practice that a change in the @id resource content MUST be treated as a delete and add event. The consequences of having naming conventions on the @id will hamper versioning. Renaming will lead to different @ids whereas the content has not changed at all. This leads to the recommendation to have the @id's value unique and stable during the lifespan of the DTS.

3.25 Concept - Reference - Add

Note: This is the effective business event of adding a reference to a concept. There is no indication of the linkrole in which the reference is placed. The software needs to discover this for itself.

Note 2: This particular reference resource was addressed through the @id. For resources that do not have @ids the traditional approach of using an element scheme pointer such as (1/10/2) (i.e. 2nd child of 10th child of the root) is recommended.

Note 3: The resources are addressed using the full (relative) path from the perspective of the versioning report. Absolute paths are preferred.

3.26 Concept - Reference - Delete

3.27 Concept - Reference - Change

Note: There is no indication what has been changed on the resource: the @xlink:role or the resource content itself. The software needs to discover this for itself.

Note 2: From this example can be deduced that the @id on resources is especially important in identifying the resource attributes and content. It is not appropriate to 'copy' @xlink:label and treat it as a piece of text. The resource must be treated like a concept.

Note 3: There is no @id change event defined in the XII Versioning specification. This leads to the practice that a change in the @id resource content MUST be treated as a delete and add event. The consequences of having naming conventions on the @id will hamper versioning. Renaming will lead to different @ids whereas the content has not changed at all. This leads to the recommendation to have the @id's value unique and stable during the lifespan of the DTS.

3.28 Presentation relationship - Add Child

Add single child to existing parent linkrole

Note: No linkbase is being defined. If the same linkrole is used in multiple linkbases there is a problem to express that the addition needs to be placed in a specific linkbase, which is of no use to the mapper or reporter. It is only of interest to the DTS extender.

Note 2: The @order, @preferredLabel and optional custom attributes on the arc must be detected by the software.

Note 3: If the added child is already present as parent in any presentationArc of the same linkrole there may be consequences for the nesting in the tree.

3.29 Presentation relationship - Delete Child

Delete single child from existing parent linkrole

Note: This event is the result of effectively not having the relationship between the parent and child. That could be the result of using @use='prohibited' or adding a similar relationship with a higher @priority or physically removing the relationship arc from the linkrole..

Note 2: If the deleted child already has presentationArcs in which it is the parent in the same linkrole there may be consequences for the nesting in the tree.

3.30 Presentation relationship - Add Parent and Children

Add a parent with all its children in existing linkrole

Note: If the added child is already present as parent in any presentationArc of the same linkrole there may be consequences for the nesting in the tree.

3.31 Presentation relationship - Delete Parent and Children

Delete a parent with all its children from existing linkrole

Note: If the deleted child already has presentationArcs in which it is the parent in the same linkrole there may be consequences for the nesting in the tree.

3.32 Presentation relationship - Add Parent and Siblings

Add a parent with all its siblings in existing linkrole

3.33 Presentation relationship - Delete Parent and Siblings

Delete a parent with all its siblings from existing linkrole

3.34 Presentation relationship - Add linkrole

Add a linkrole with all its content

Note: There is no add linkrole event without any relationships as content because there would be no business use for such an event.

3.35 Presentation relationship - Delete linkrole

Delete a linkrole with all its content

3.36 Presentation relationship - Change @preferredLabel content

3.37 Presentation relationship - Change @order content

3.38 Presentation relationship - Change @linkrole content

3.39 Presentation relationship - Change @arcrole content

3.40 Calculation relationships - See Presentation Relationship Events

Calculationship relationchanges are covered in the same way presentation relationships are. For examples please see the appropriate presentation relationship change.

3.41 Calculation relationships - Change @weight content

Note: It could be argued that explicit mention of the @weight is unnecessary because the discovery mechanisms should be able to detect the change. However, other fragments may also be changed and it is better to be explicit than implicit.

Note 2: Although allowed by the specification, combining multiple changes on the same relationship, such as the @weight and some custom attribute, is NOT advisable, even if it is just for connecting specific business reasons through generic labels.

3.42 Non XDT Definition Relationships - See Presentation Relationship Events

3.43 XDT Definition Relationships through the Aspects Module - Not Stable Yet

4.1 Assignments

An assignment is the top level of a reason why a change has been made. Three predefined types are available: business, technical and errata. The first two speak for themselves. The errata is for everything that doesn't fit the first two assignment types. Every <ver:action> MUST be connected to a <ver:assignment> . The assignment carries the type and an @id which points to free text explaining the assignment. There is no further structured content. Technically it is allowed to have a single <ver:action> refer to multiple <ver:assignment> s. There is no limit to the number of assignments or actions, they just need unique @ids to enable connecting to generic labels and/or references. But from a business perspective this can be confusing.

A construct that has been found to work very effectively is as follows:

• one 'general' business assignment; this is needed for all the business actions that need to be explained;
• one 'general' technical assignment; this is needed for all the technical actions that need to be explained;
• as many as needed assignments that each connect to multiple actions - the action does not get a label (there is always one technical: for namespaceRename);
• uses for errata assignments are still sought

Note: a consideration for assigning multiple assignments to a single action MAY be the different target groups the report is intended for.

4.2 Actions

Actions are sometimes used as container to group events that derive meaning from each other: conceptMerge and conceptSplit. Mostly the actions are derived from the assignment. If the assignment is to change DTS content to reflect new reporting rules, a project is being formed. It is at the preference of the manager of the DTS as to how he tackles the task: work concept by concept changing everything that is needed, or working by DTS artefact: change all data types first, than all labels, then ... etc. From this approach the reasons are derived that need to group all the events (excluding the conceptMerge and conceptSplit events).