Phase II - Design Considerations

Alternative ways to implement a versioning mechanism were identified and explored when considering the diffing mechanism for Phase I.  In phase II, many of the ideas in phase I are transferred to versioning and enhanced.

The concept of the versioning mechanism is summarised below together with an explanation of issues appearing during the design process. To understand this work, a basic knowledge of XML and XBRL is assumed as well as knowledge our phase I prerequisite project. Click here to see how a prototype online demonstration of this theory and versioning mechanism works.

Considerations and Issues:

1. Terminology
2. Meaning Change - Use Cases
3. Versioning Categories
   • Definition of Categories
   • Overlapping Categories
   • Cardinality of Categories
4. Typing of Changes
5. Versioning Linkbase
6. Visualisation of a Versioning Linkbase
7. Modularisation

1. Terminology

2. Meaning Change - Use Cases

The aim of phase II is to provide a mechanism to gather additional information about semantic differences between taxonomy versions and capture them in XBRL. We focus therefore on possible changes of meaning, rather than all differences as with phase I.

The following use cases represent diagrammatically different meaning change possibilities. In addition each use cases is classified in one of two ways:

Legend:

• the coloured squares allow us to represent and track the components of meaning.
• the squares on the left side represent content of taxonomy version n - on the right side of taxonomy version n+1. Please notice that a concept can combine meaning and change their meanings while keeping the same name in the new taxonomy release.

Use Case	Simple Samples	Description	XBRL Valid	Business Relevance	type of change
I		A new concept is added to taxonomy version n+1.	yes	1	added concept
II		An existing concept has been removed in the new taxonomy version.	yes	1	removed concept
III		The concept A (n) is equivalent to concept A(n+1). Both concepts have the same name.	yes	1	equivalent concepts
IV		The meaning of A(n) has completely changed in A(n+1). Normally this should not occur in taxonomy versioning.	no	3+	xbrl change or external meaning change
V		The concept is renamed but the meaning stays the same.	yes	2	renamed concept
VI		Part of the meaning of concept A (n) is removed in the newer version.	yes	3+	xbrl change or external meaning change
VII		The meaning of concept A is extended in the new version.	yes	3+	xbrl change or ext. meaning change
VIII		The meaning of concept A and B are switched in the new version. For example,  an incorrect linking of  references. Again the meaning of a concept should not change completely by keeping the same name.	no	not relevant	xbrl change or external meaning change
IX		This sample covers most split concepts and is  not critical. An example is the concept "depreciation & expenses " which is split into "depreciation" and "expenses".	yes	2	split concept
X		Concept A(n) separates some of its meaning in a new concept B(n+1). In contrast to use case IX the concept A keeps its name.	?	2	split concepts
Remark: The following samples do not distinguish between split  concepts, whether one concept keeps its name or not.
XI		Two concepts are completely merged into a single one.	yes	2	merged concepts
XII		Combination of merged and split concepts. Concept A(n) is split into concept C(n+1) and D(n+1) and concept A(n) and B(n) are merged to concept D(n+1).	yes	2	merged concepts and split concept
XIII			yes	2	merged concepts and split concept

3. Versioning Categories

The meaning changes by use case include changes which are not covered by the atomic differencing categories of phase I. Recall that  phase I defines the following categories: added concept, removed concept and changed concept with subclasses attribute change, label change and reference change. Equivalent concepts are not explicitly expressed, but covered implicitly by the namespace mapping.

In phase II we enhance the category model to meet the requirements on  changes to “meaning” by renamed concepts (use case V), split concepts (use case IX, X, XII and XIII), merged concepts (use cases XI, XII and XIII) and external meaning change (use case IV, VI, VII and VIII). Not covered by the use cases but already mentioned in phase I are modularisation- and changes in presentation-, calculation- and definition linkbases changes.

The complete versioning categorisation model is summarised below:

1. added concepts
2. removed concepts
3. equivalent concepts
4. renamed concepts
5. changed concepts
   1. attribute changes
   2. label, reference changes
   3. presentation, calculation and definition changes
6. merged concepts
7. split concepts
8. external meaning changes
9. modularisation changes

Click here to see the XBRL schema defining the versioning categorisation model.

Remark A: Modularisation and external meaning changes as well as changes in presentation, calculation and definition linkbases are out of scope for this phase II project due to their complexity. They will be addressed in our phase 3 project.

Remark C: The categories of phase I do not contain exactly the same concepts as the categories of phase II, even when they appear to be named the same. The following list summarises the relationship between the diffing and the versioning categories. The identifier in the brackets marks the category either with a (d) when it is from the diffing phase or with (v) when it is from the versioning phase.

Hint: the following paragraphs may mention categories by  number from above (e.g. 2 represents removed concepts or 6 represents merged concepts).

Overlapping Categories
In phase I the categories are exclusive except for the implicit category equivalent concepts. This means a concept can occur only once in each category. In phase II this restriction is generally relaxed due to the enhanced category model and the non exclusivity of its category components.

E.g. a concept named "assets" is renamed to "asset" and changes its label from "Assets" to "Asset" -> The concept occurs in categories 4 (renamed concept) and 5 (changed concept).

To have a better understanding of  overlapping categories, they should first be properly defined. There are different alternatives of category definitions:

1. Merged and split concepts are exclusive from other categories. There is no further analysis of attributes, labels, references, etc required.
   
   
2. The inclusive categories approach allows the comparison of attributes, references labels of involved concepts. .

From an accounting point of view it makes sense to define merged and split concepts as exclusive categories towards other categories, because merged and split concepts are obviously not the same concepts any more.

In the paragraph before, we considered how merged and split concepts overlap with other categories. Now we will take a look at how they relate to each other.

The following matrix visualises the overlapping categories.

Cardinality of Categories
From this matrix the cardinality of the overlapping categories can be derived, which is important for the implementation of the versioning linkbase.

4. Typing of Changes

Beside the fact that something has changed between different taxonomy versions,  the reason for the changes are important and should* be recorded along with the change. Each change is typed according to five basic overall classes:

• Literature / rules based change
• Interpretation change
• Taxonomy building error
• Improvements / enhancements change
• Other

Out of scope in this typing is the quality characteristic dimensions for this change, which could be divided into:

• Intrinsic - accuracy, reputation, objectivity
• Contextual - value added, relevance, completeness, timeliness
• Representational [clarity of definition] - understandability, interpretability, concise presentation, consistent representation

and a grade or ranking for the seriousness of a change, which we deem to be too subjective, for example:

• Significant / insignificant (material / immaterial)
• Grade of significance 1-5
• Other
  

[*Note: Change Typing as a versioning requirement, was originally suggested by the Dutch NTP XBRL project, in particular, to signal a literature change.  The IASC Foundation has identified the other categories.  The list is intended to be exhaustive, but needs to be tested.

5. Versioning Linkbase

As a consequence of enhancing the category model for phase II, we needed to adjust the storage format to meet the new requirements:

1. Storage of versioning model including n-m relationships
2. Storage of meta information like author, creation date and general comments
3. Storage of the namespace m
4. apping in the linkbase
5. Tracking value changes for labels and references (see label changes - phase I)
6. Enable taxonomy authors to comment on changes and type them

Before we implement the requirements for phase II, we should clarify whether we are using the more general, generic linkbase format or moving to a specific versioning linkbase extension of the generic linkbase enabling the author to use their own resource semantic and syntax.

The benefit of using the specialised format is a more efficient storage and human readable linkbase file. The price of the enhanced possibilities is the complication that normal XBRL processors supporting the generic linkbase technology have to understand the versioning extension - otherwise they are unable to process the versioning data.

Because the IASCF XBRL Team wishes to encourage simplified use of the versioning linkbase , the more general generic linkbase format is chosen.

Note: the possibility to store versioning information in the generic linkbase approach is limited to arcs, arcroles and "simple" resources.

Implementation of the Versioning Linkbase Requirements

In the images below the following symbols are used:

	concept or XBRL element
	resource like label, reference or a resource in the versioning linkbase
	represents a connection consisting of a locator, arc and locator bridge
	"id" attribute on arcs
	arcrole on arcs
	Some description, which is not represented in XBRL

1. Enhanced categorisation model
   The following diagrams illustrate how n-m relationships are expressed in the versioning linkbase. We begin first with use case IX (split concepts) and XI (merged concepts) and then move to the hybrid use cases XII and XIII.
    
    

   Use Case IX: split concepts

   Use Case XI: Merged concepts

    
   Use Case XII: Combination of merged and split concepts
   
   
    Use Case XIII: Combination of merged and split concepts
   
    
2. Storage of metadata
   First of all it we discuss if all meta information should be stored and if so what kind of information should be captured into the linkbase. Looking at other relational linkbases in general no meta information of the nature of a general comment is stored (e.g. presentation linkbases do not include a general comment except for those in xml comments). To keep the overhead of data as minimal as possible we do not include meta data in our versioning linkbase.
   
   
3. Store namespace mapping
   Does it make sense to include the namespace mapping into the versioning linkbase? We think the answer is a "yes", because the namespace mapping is used to identify equivalent concepts.
   
   The namespace mapping is information, which is not directly related to the individual concepts themselves. There are different alternatives how to store the information in a linkbase.
   
   
   1. Alternative:
      The first alternative uses a unique and fixed labelled resource. This resource label is used as an entry point to the namespace information.
      
      Because we use the generalised,  generic linkbase format, the information about the namespace mapping and its relations have to be stored in individual resources and not in the entry point resource. Each resource stores a different namespace and arcs connect the resources in the way the mapping is defined.
      
      To keep a single entry point, a resource with a special label is connected through arcs with all namespaces of taxonomy version n. The picture below illustrates the storage of the namespace mapping.
      
      
      First namespace mapping alternative
      
      
   2. Alternative:
      This alternative is only slightly different from the one before. Instead of identifying the resources through an entry point, they get a special role to identify them.

      Model

      XBRL Code

      Second namespace mapping alternative

      <label xlink:type="resource" xlink:role="http://xbrl.iasb.org/lab/2007/versioning/nsmapping" xlink:label="FROM_NS_1" xml:lang="en">http://www.ird.govt.nz/nz/fr/tax/en/ir10/gp/2006-02-01</label> <label xlink:type="resource" xlink:role="http://xbrl.iasb.org/lab/2007/versioning/nsmapping" xlink:label="TO_NS_1" xml:lang="en">http://www.ird.govt.nz/nz/fr/tax/en/ir10/gp/2007-02-01</label> <gen:arc xlink:type="arc" xlink:arcrole="http://xbrl.iasb.org/lab/2007/versioning/roles/nsmapping-arc" xlink:from="FROM_NS_1" xlink:to="TO_NS_1" order="1.0" />

   
   The IASCF decided to use the second approach for the demonstrator.
   
    
4. Track value changes for labels and references
   The following diagrams visualises the methods to store value changes:
   
   Capture the value change
   
   First track value changes approach
   
   In the diagram above, an arc in the versioning linkbase points with an xlink to a external resource (in this case a label in the label linkbase or an reference in the reference linkbase). Because of the nature of xlink, the local xlink label can not be accessed from outside the linkbase where the resource is placed, so we need a new mechanism to point to the resource. There a two possible solutions:
   1. introduce an id attribute on the resource. The xlink would look like
      xlink:href="ifrs-gp-lab-2005-05-15.xml#my_resource_id"
   2. use the element()-Scheme of the XPointer. The xlink would look like:
      xlink:href="ifrs-gp-lab-2005-05-15.xml#element(/1/343)"
      [where /1/343 means the 343th child of the root.]
   
   

   In the end it does not matter how to point to the resources, the only difference between the two approaches is that option 1 requires id attributes on resources,  but is more human readable.
   
   For simplicity reasons, our solution for phase II will only work with the id attribute on resources.

   
   This alternative has the disadvantage that the developer has to be careful how to implement this model. It is not allowed to have two or more arcs connecting the same locators.
   
   

   “Constraint: No Arc Duplication
   Each arc-type element must have a pair of from and to values that does not repeat the from and to values (respectively) for any other arc-type element in the same extended link; that is, each pair in a link must be unique.” [see http://www.w3.org/TR/xlink/#link-semantics ]”
   
   Therefore different locators should be used to point to the same concepts, when multiple arcs appear. To solve this problem a different alternative can be used, which does not have this problem. The idea is to connect arcs with arcs. The next image points out how to do this.
   
   

   Connecting two arcs

   Connecting two arcs simplified visualisation

   
   The arcs in the versioning linkbase get an "id" attribute and locators pointing to the arcs are created. The third arc is created connecting the two arc locators. For simplicity reasons this is shown in the next picture only as an arc, like we do it always.
   
   
   Second track value changes approach
   
   This picture visualise how more than one change is connected between the concept versions. In the versioning linkbase the IASCF decided to use the second approach.
   
   

5. Enable comments on changes and type them
   Comments can be realised in two alternative ways:
   
   1. Store the comment in an attribute of the arc, which describes the change. A disadvantage is the general restriction on attributes. Special characters are not allowed in the comment and the length of the comment is restricted.
   2. Store the comment and the type in an extra resource and connect the resource with the arc. One benefit is that more than one comment is possible e.g. for multilingual comments. One disadvantage is that the definition of resources need more space and commenting the same change in different languages is not effective.
      
      
   
   A problem with attributes is the n-m relationship. They are made up  of several arcs, and therefore the comments can be placed on a random one, where as in the second alternative with the resources all arcs are able to point to one resource.

DTS Model

Beside the difference between general or special generic linkbase aproach it is important how the DTS will look after the implementation. This question is important when a taxonomy is loaded into the XBRL processor and the DTS (Discoverable Taxonomy Set) is produced.

In XBRL generic linkbases are two different types of locators:

1. link:loc
2. gen:loc

While link:locs are taken into consideration during the taxonomy discovery and the document where the locator is pointing to is also discovered, the gen:locs are ignored.

Now let us assume that our taxonomy discovery starts at our versioning linkbase. Depending which locators the versioning linkbase use, the resulting DTS will look diffently:

1.	Combined DTS: When using link:locs our DTS would combine both taxonomies. This could cause conflics, when the taxonomies are pointing to the same files.
2.	Seperate DTS: With gen:locs no files from taxonomy n and taxonomy n+1 are discovered and loaded into the DTS. The DTS would only contain the versioning linkbase.
3.	Hybrid DTS: There is of cause a hybrid solution to this, when using constantly xlink:loc for elements and resources of the new taxonomy version n+1 and gen:link for all elements and resources of taxonomy version n.   Of cause it could also be the other way around and then taxonomy version n is included into the DTS and taxonomy version n+1 is not.

Normally a starting point for the DTS is not the versioning linkbase and instead some other schema or instance depending on the information people want to inlcude into the DTS.

Beside the locators mechanism there are other ways to include linkbases - also generic linkbases - into a taxonomy (see include or import). But what happens if a taxonomy imports a versioning linkbase by default to its DTS like a label linkbase. Then the taxonomy discovery will add all the files which are highlighed in case 1, 2 and 3. For case 1 and 3 this would lead to a combined DTS, which is undisired. Therefore gen:locs are used in the generic linkbase.

The result is a clean separation between taxonomies. Now it is possible to import the versioning linkbase into a taxonomy without including the other version.

Looking a step ahead versioning linkbase chains are possible like shown in the next picture.

Click here to see a sample of the versioning linkbase.

6. Visualisation of the Versioning Linkbase

In this paragraph we discuss how to visualise the final versioning linkbase. The additional gathered information like comments or multiple categories cause a more complex visualisation than the visualisation of the diffing linkbase.

Two alternative views on the versioning information are available:

1. Alphabetical Concept List
   The aim of this view is to show information of special concepts. All concepts inclusive of equivalent ones are listed in an alphabetically. The user has the possibility to select more detailed information on concepts. This detailed view contains information like comments, type of change, the value changes and groupings, such as merged and split concepts.
   
   A search mask for concepts can provide the same functionality as this list. The advantage is that the user does not have to search thousands of concepts to pick the right one.
    
2. Versioning Category Grouping
   All concepts are grouped into their versioning categories. This view provides a good overview of versioning categories. Within the category groupings themselves, the concepts are sorted alphabetically. In the changed concepts grouping, a sub grouping, like in phase I is possible. Merged and split categories provide a detail view of  all member concepts  of split and merged concepts.
   
   The selection of concepts is again possible, to provide detailed information about the change observed.

In addition with the visualisation of the versioning linkbase the amount of information, which is presented to the user or consumer, can be scaled. Filter mechanism or aggregation methods present only the needed information to the user.Of cause this is only possible if the versioning linkbase already contains detailed information about changes.

7. Modularisation

Even if modularisation is out of scope in this phase, modularisation should still be discussed here, because later phases should only enhance the functionality of versioning without changing the underlying model.

Recall that in phase I equivalence of a concept is defined by a namespace mapping, which translates the namespace from taxonomy n to taxonomy n+1. With the help of this mapping, a qualified name (namespace and name) of a concept can be compared between different taxonomy versions and then marked as equivalent or not.

But modularisation does not take place on a namespace level, instead it uses files identified by filenames. Therefore the namespace mapping is replaced by a file mapping from which the namespace mapping can be derived.

The benefit of using a file mapping is the possibility to compare each file and its content directly. This information is required for modularisation. The rest of the comparison stays the same and uses the derived namespace mapping. To derive the namespace mapping from a file mapping, the mechanism only has to look up the targetNamespaces from the schema files and connect them in the way the files are connected.

File Mapping	Derived Namespace Mapping

There might be an issue if two concepts in the new taxonomy version have the same concept name. From an XML point of view this is possible because they can be in a different namespace. This issue is trivial, because this will occur rarely. Nevertheless, in order to solve this issue a validation mechanism should check whether this happens or not.