Approach

In this section we discuss two important pre-considerations to this project.

(1) What is meant by change?

In this context, we are attempting to detect and document the result of alteration or modification to a component or collection of components of a taxonomy.  It is important to note that there is a difference between semantics (meaning) and syntax (grammar or structure) in this context. So an important consideration which requires clarification is “What should be captured: semantics, syntax or a mixture of both?”

While syntactic changes to taxonomy structure are easily and automatically detectable, the semantics changes are only understandable by a computer in so far as their meaning is derived from their impact on structure, or in so far as they are indicated by the user.

(2) When should a change be captured?

An important pre-consideration for this project is the requisite timing of recording a change made to a taxonomy.

Alternative 1 – Contemporaneous “Runtime” Change Solution

A straight forward solution is to implement a versioning mechanism into taxonomy editing tools. A taxonomy developer can then “comment” each change directly using the taxonomy editing software and explain what kind of change it is (i.e. typos, spelling mistakes, new concepts, changed concepts, etc.) at the time a taxonomy is changed (or versioned).

If each taxonomy editing tool implements a proprietary versioning mechanism different versioning formats may evolve.

To increase interoperability of XBRL software tools, the IASC Foundation XBRL team encourages the use of a standardised versioning format.

Alternative 2 – Post Factum Change Solution

An alterative is to provide a post factum (after the act) change solution (see figure1). This method is taxonomy editing tool independent, because the comparison is made with the two taxonomy versions, after they have been built, not at the time of a change.

A first thought might be to create a versioning linkbase in one step, automatically. But this is not possible. The reason is illustrated by considering a simple change.  For example, in a new taxonomy version, two elements are deleted from a previous taxonomy version and a new element appears in the new version of that taxonomy. It is not possible to determine whether:

• One element is renamed and one new element has been added to the new version of the taxonomy; or
• The two old elements have been merged to form the element in the new version; or
• The two old elements are independent of the element added to the new version.

In the post factum change method the first step of creating a versioning linkbase is to record change using a differencing (diffing) mechanism, where all syntactic changes and some semantic changes are detected and captured automatically. In our web service prototype it is possible to identify all additions, deletions and changed concepts.

In a second step the taxonomy developer provides commentary on the pre-selected differences and should give them a precise meaning. In our example above this is the step where the taxonomy developer records that one concept is renamed and a new one is added.

From this information a versioning linkbase can be created. Figure 1 provides an overview of the process

  Figure 1

Conclusion

In this project we will use the post factum change solution to provide as much flexibility as possible the person creating the new version and to ensure that the solution is software independent.

Click here to go to the Overview of phase I.