Phase I - Design Considerations

During the design process of a diffing mechanism several issues appear. These are summarised below, together with an explanation of the rules that have been defined for the solution. To understanding this work, a basic knowledge of XML and XBRL is required.

Considerations and Issues:

1. Categorising differences
2. Equality of elements
   • Semantic equivalence
   • Syntactic equivalence
3. Data collection
   • Capturing concept changes
   • Capturing label changes
   • Capturing reference changes
   • Omitting pure syntactical changes
   • Dependencies of changes
4. Diffing linkbase
5. Visualisation of a diffing linkbase
6. Taxonomy modularisation

1. Categorising differences

The changes within consecutive taxonomy versions which form the basis for the diffing mechanism and the diffing output are categorised below.

From a high level point of view, three atomic differences can occur to a taxonomy:

• an element is added
• an element is deleted
• an element is changed

At first, a diffing mechanism needs to be able to identify equal elements in the two versions of a taxonomy which are compared to each other. After it has identified an equivalent element in both taxonomy versions it is able to inspect if the element has changed and tracks a possible change by assigning one of the change categories defined above to the element in the diffing output.

Equality of elements is a key issue of taxonomy versioning and will be explored in the next section.

2. Equality of elements

Equality of XBRL elements can be observed on two levels – the syntactical and the semantic level. On the former level elements are represented by XML/XBRL tags. On the latter level XBRL elements reflect the meaning of the part of an accounting standard which they represent, i.e. the concept named IntangibleAssets is defined in IAS 38, paragraph 8 as "an identifiable non-monetary asset without physical substance" which clearly adds some meaning to the pure XML element on the syntactical level.

A diffing mechanism needs to be able to observe the equivalence of any two XBRL elements of the same type (concepts, labels etc.).

The following two paragraphs explore syntactic and semantical equivalence of XBRL elements and its relation to the design of a diffing mechanism.

Semantic equivalence

In general a computer is not capable of detecting the semantic equivalence of any two concepts. Software cannot detected easily that two elements e.g. "Assets" and (misspelled) "As_ets" have the same meaning.

Whereas it is possible to track elements that have been added or removed, there is no definite way for a computer to track changed elements. Such a change in the taxonomy would appear as two changes in a diffing report, namely the removal of the element with the old name and the addition of the element with the new name.

Because of these technical restrictions, semantic equivalence cannot be tracked by a diffing mechanism and a changed element will be reported like explained above.

Syntactic equivalence

To detect the syntactical equivalence, a diffing mechanism needs to be able to identify elements within a taxonomy.

Because of the nature of XML schemas, each schema file in a taxonomy defines a unique namespace (i.e. xmlns:ifrs-gp="http://xbrl.iasb.org/int/fr/ifrs/gp/2006-08-15") identifying all of its elements. The elements are identified by a name which is unique for the schema (i.e. IntangibleAssetsNet).

To identify concepts in taxonomies, a pair of namespace and concept name can be used (i.e. ifrs-gp:IntangibleAssetsNet).

Applied to two versions of a taxonomy, the identifying mechanism needs to be adapted as the two versions use different namespaces in their schemas. Therefore the identification of elements as explained above will fail.

A straight forward solution to this problem is to create a mapping between the namespaces of the two taxonomy versions, so a mechanism can identify similar element in each of them.

Example of a namespace mapping:

After the namespace mapping was created, the following rules can be applied to detect the differences of elements within two versions of a taxonomy:

For each element in Taxonomy ver. A OR Taxonomy ver. B:

• If it exists in Taxonomy A but not in Taxonomy B, it is captured as removed.
• If it exists in Taxonomy B but not in Taxonomy A, it is captured as an added concept.
• If the concept exists in both taxonomies, it then checks if all the attributes and additional information are the same.
  • If yes, the concept is captured as equal
  • If no, it is captured as changed.

3. Data collection

The quality of a diffing report depends on the right level of granularity. This section states which XBRL element changes will be reported in the diffing output.

Concepts and label changes will be tracked, as these two element categories form the most basic parts of a taxonomy.

References are important as well, because they refer to the accounting standards and instance creators as well as taxonomy extension developer could be affected by those changes. Here is a limitation to the diffing mechanism. Only changes on the references to the standard (e.g. Name: IAS; Number: 1; Paragraph: 95) can be captured, not the text changes on the "written" standards itself.

Changes to the calculation linkbase are not tracked, as the calculation linkbase will be replaced by the formula linkbase in the future.

The definition linkbase is also out of scope because it is only rarely used at the moment. As the presentation linkbase provides no semantic information, it is also ignored in this context.

To reduce the overhead of a diffing, changes in locators and arcs are not captured by the diffing mechanism because they do not have a semantic value to the taxonomy.

In summary the following differences will be captured:

1. Concepts
2. Labels
3. References

The following three paragraphs outline the captured changes for concepts, labels and references.

(a) Capturing concept changes

The following list defines a set of attributes satisfying the requirements for identifying concepts:

1. id
2. type
3. attributes

Because of the inability to detect semantic changes, (see semantic equivalence) changes to concept names are not tracked.

(b) Capturing label changes

The following list defines a set of attributes satisfying the requirements for identifying labels:

1. corresponding concept
2. language
3. roleytype
4. label itself

The next step is to specify the level of detail for the change capturing process. The following illustrates alternatives to capture the differences for labels.

Solution:

Solutions 2 and 3 are harder to implement in the resulting diffing mechanism than the simple first alternative, because it’s not possible to point to resources outside the diffing linkbase.

To keep the result simple and enable efficient software processing, alternative 1 is favoured.

(c) Capturing reference changes

The comparison of references uses the same approach like labels even if it is a bit more complex. The reason is that the set of attributes satisfying the requirements for identifying references are more dynamic than label ones. References contain a user defined set of child elements and values.

The set for identifying references are:

1. related concept
2. roletype
3. child elements of reference element

Omitting pure syntactical changes

To avoid bloating of the diffing report and to increase its quality, syntactical changes to a taxonomy which have no effect on the semantics of the taxonomy should not be reported.

This section explores two cases of syntactical changes which don't affect semantics.

•Default values of attributes

If an attribute with a default value is deleted, then the syntax of this element has been changed, but not the semantic. The diffing mechanism should not capture this syntactical difference, because the meaning of the concept remains the same.

The following example illustrates such a syntactical change without a corresponding semantic one:

The code snippet of the element AssetsTotal is modified from

to

The attribute abstract with its value false has been deleted.

The meanings of both element declarations are the same, because if no abstract attribute is defined, the default value for the attribute abstract applies which is "false". So the semantic remains the same. The syntactic is different, because the second element has no attribute abstract.

The following table shows all possible attributes and their default values:

•Multiple ways of defining complex XML element content

In taxonomies there are two types of concepts:

• Concepts of type item - they are expressed in schema files as simple elements
• Concepts of type tuple - they are expressed in schema files as complex elements

Because of the high expressiveness of the XML Schema language the same semantic concept can be expressed by different means.

Here is an example of the tuple "ClassOfAssetOfEntityAcquired".

The complex type (marked in bold) defines the child elements of this tuple, their order (in this case as a sequence), min and max occurrence of the child elements, attributes etc. The same semantic concept can be defined with a different complex type syntax .

A diffing linkbase should only identify semantic changes to keep the result simple for this phase.

Change dependencies

Element changes in a taxonomy may be related to each other. Here are two examples of dependencies of an element change:

1. If a concept is removed from a taxonomy all of its labels and references will be removed as well. The removal of the labels and references depend on the removal of the concept.

2. If the attribute substitutionGroup of a concept changes from tuple to item, the concept becomes a simple type. This implies that the whole complex type content has to be deleted. The removal of the complex type depends on the change of substitutionGroup which is already captured.

The IASCF XBRL Team has already begun research in this area and captured some example dependencies in a Versioning Matrix (around 20 dependencies).

To prevent misunderstandings, a simple principle for dependencies applies to this diffing:

Capture all dependencies except those where concepts are added or deleted. In this case it is clear enough that the references, labels and attributes are deleted too.

4. Diffing linkbase

The diffing report is stored as a diffing linkbase in the XBRL generic linkbase format to enable its processing by XBRL tools.

With this approach, software vendors should be able to process the information provided in XBRL without having to adopt a new format.  

The Generic linkbase enables the storage of custom information in an XBRL compliant format. In comparison to other linkbases (e.g. the Presentation linkbase) a Generic linkbase is able to use custom roles. These roles can express user defined information about the concepts like "added/deleted/changed concepts".

Note: The Generic linkbases is currently a working draft. Future changes of the standard might affect the implementation of the diffing linkbase.

Diffing linkbase design alternatives

XBRL Generic linkbases provide two different approaches to capture diffing data:

Structure of the diffing linkbase

Within the diffing linkbase we create custom linkroles to represent different categories of differences which are applied to Arcs on concept-concept and concept-resource connections. The custom arcroles are defined in a separate schema for import into diffing reports.

Listed below are the arcroles defined in the diffing linkbase schema with their respective meaning. An attribute or complex content change implies that the concept has changed. This is not captured separately. Click here to see the XBRL schema representing the diffing roles.

Remember that there are two different kinds of connection in a linkbase:

• concept-locator-arc-resource
• concept-locator-arc-locator-concept

The concept-locator-arc-resource connection is used in this case to capture when a concept is added or removed, because then there is no corresponding concept to connect with.

The concept-locator-arc-locator-concept relationship is used for all changes (e.g. attribute, label or reference change).

5. Visualisation of a diffing linkbase

The purpose of a diffing visualisation is to provide the user an human readable "change log" on differences between the two taxonomy versions. The next paragraphs details attributes of a visualisation which are important.

There are several possibilities to visualise the differences in a sufficient way. Normally it makes sense to group differences by added, deleted and changed concepts. The following sub groupings are possible.

1. Group all changes by concept
   
2. Group all changes by type of change (resource, id-attribute, type-attribute, ...)

The groups should be sorted alphabetically to keep them structured and easily searchable. Additional information like the changed values can also improve the readability.

6. Modularisation

Taxonomy modularisation over several files like in IFRS-GP results in an easier maintenance process and a better taxonomy overview. Modularisation also affects taxonomy diffing, as elements can be moved over taxonomy modules.

To keep a first attempt by the IASC Foundation XBRL team at a diffing implementation as simple as possible, the modularisation aspect will not be captured in a diffing. The versioning interface will enable the user to mark taxonomy changes related to taxonomy modularisation in a versioning linkbase.