Tutorial on Versioning

Presented at the:

IX European Banking SupervisorsXBRL Workshop & TutorialIn: ParisOn: 29th September 2008

By: Katrin SchmehlMember of the CEBS XBRL Network

The XBRL Network of the

SIONING VERSIONING VERSIONING VERSIONING VERSIONING VERSIONING VERSIONI

SIONING VERSIONING VERSIONING VERSIONING VERSIONING VERSIONING VERSIONI

WIKI

3

Agenda

Definition of (XML) Versioning

Compatibility

Version Identification Technologies

XML Schema Versioning Strategies

Versioning Strategy in COREP and FINREP

XBRL Versioning Definition and Importance

Target groups and their requirements

XBRL information to be compared

Technical approaches

Conclusions

5

Definition of (XML) Versioning

Versioning describes the process of evolutionary change that results from the adding, deleting or amending of syntax or information.

Motives for change might be:- Bugs that need to be fixed,- New requirements,- Technical oriented adaptations.

Independent of the cause it’s important to deal with the process of change in a predictable and useful way.

6

Compatibility

Definition: The degree to which languages and programming can be interchanged among various computer-controlled systems.

Backward compatibility: If a receiving system has adopted a newer version, it is still able to process data successfully based on the previous version.

Forward compatibility: If a system still works with a previous version, it is able to ignore the not (yet) recognized data of the new version.

If backward- or forward-compatibility can’t be achieved, the costs of

updating the required software to adjust to the newer version is often very high.

7

Version Identification Technologies

The essential version identification technologies for XML are:

Qualified Name (namespace + local name)The local name is optionally preceded by another XML name called the prefix and a colon (':') character. The prefix must be mapped to a namespace URI through an in-scope namespace declaration.

TypeComplex types can be declared globally so they can be reused in further schemas.

1. A new schema is created and the previous schema imported.

2. To modify a type, an extended type can be created.

Version numberVersion numbers should be used to differentiate between different versions, preferably in a version attribute on the root element of the XML format.

8

XML Schema Versioning Strategies

Depending on the support of backward- and forward compatibility the version strategy is chosen:

Re-use namespace names Rule: If a backward- compatible change can be made to a specification, then the old namespace name SHOULD be used.Good Practice

New namespace to break Rule: A new namespace name SHOULD be used when backward-compatibility is not permitted. Good Practice

Non-backward compatible changes typically occur in two ways: a required information item is added

or the semantics of an existing information item are changed.

Language Identification Rule: Any languages intended for versioning SHOULD have a version identification strategy.Good Practice

9

Detection of Versioning differences

• Some XML software provide comparison tools for XML and XSD files.

• Example: XML Spy shows the differences marked with colours.

10

Versioning Strategy in COREP and FINREP

Identification Strategy– The version number is an instruction at the beginning of each file which

belongs to a COREP or FINREP taxonomy.

<?taxonomy-version 1.2.4?>

– A 3 level numbering system is used to manage the versions.

– Adjustments in numbering depends on the backward compatibility

• Compatible: change in the third level

• Non-compatible: change in the second level

• Non-compatible and major functional change: change in the first level

Major functional changes:

– Material amendments to templates and guidelines, new XBRL version

11

Versioning Strategy in COREP and FINREP

Namespace change

• Therefore only non-compatible changes result in a changein the namespace.

• The QNames between different releases (third level numbering) are the same -> no remapping is needed.

• For non-compatible versions the namespace changes in the date part:

Re-use namespace names Rule: If a backward- compatible change can be made to a specification, then the old namespace name SHOULD be used.Good Practice

Version Namespace

1.2.6 http://www.c-ebs.org/eu/fr/esrs/corep/2006-07-01

1.3.0 http://www.c-ebs.org/eu/fr/esrs/corep/2009-01-01

12

Versioning differences on COREP and FINREP

The CEBS XBRL Network documents the changes on taxonomies on their website (http://www.corep.info).

These changes can be manually adopted in mapping processes by taking the information out of the corresponding HTML file.

Extensive amendments are associated with a lot of workload and costs.

13

Definition of XBRL Versioning

XBRL Versioning is a process that compares the content of two different Discoverable Taxonomy Sets (DTSs), usually, an initial DTS and a revised DTS.

The comparison results in a report, that describes what has changed.

The necessary descriptive information why the change has been made can be added by the taxonomy developer.

14

Importance of XBRL Versioning

XBRL Versioning is important because it minimises the costs associated with migrating from one DTS to another.

Updating and revising DTSs are common features of any XBRL implementation and therefore XBRL Versioning is a highly sought after tool as it will provide a well documented trail of the changes associated with a migration to a new DTS.

XBRL Versioning will support the European financial institutions by providing a

standardised way to handle changes and differences between taxonomies.

15

Target groups and their Versioning requirements

Taxonomy developers:

To communicate changes from the previous to the next version.

To integrate changes in the base taxonomy into its extensions.

To add changes during and after the development process.

Instance creators:

To automatically integrate changes in the mapping process for the creation of XBRL reports.

Instance receivers:

To automatically integrate changes in the mapping process for receiving XBRL reports.

Automatic mapping processesneed a standardised syntax.

16

Target groups and their Versioning requirements

Taxonomy reviewer:

To check if all necessary changes have been made.

To check if changes have been sufficiently documented.

Taxonomy analyst:

To compare two different taxonomies (base or extension), e.g. IFRS or COREP/FINREP, in order to analyse the distinctions.

Taxonomy publisher:

To provide data from a specific point of view.

To add supplementary information and structures.

To provide a human readable versioning report.

17

XBRL Versioning Specification

Deliverables of Versioning Working GroupVersioning Specification Requirements

XBRL Versioning Specification Part IDescription

Definition of the information to be compared

Rules of correspondence

Content model

XBRL Versioning Specification Part IISyntax

Conformance SuiteTest cases

Sample reports

XBRL Versioning Specification on Dimensions

18

Definition of the information to be compared

Decisive factor for the comparison is the XBRL InfosetDescription of the content of a DTS without any reference to the XBRL syntax

All information important to be compared is defined.

Recommended by the VWG to be used for XBRL comparisons

Class model can be integrated in XBRL software

Current status: Public Working Draft

No inclusion of information on XBRL instances

2.2.8 – XBRL Concept Information Item

1 Parent: 2.2.32 Name: NCName3 Type: XSDType4 SubstitutionGroup: QName5 Nillable: Boolean6 Abstract: Boolean7 Block: "#all"|"extension"|"restriction"| "substitution"|{empty}8 Fixed: String9 Final: "#all"|"extension"|"restriction"| {empty}10 From (list): 2.2.1411 To (list): 2.2.1412 Attributes (list): xml: Attribute List13 Children (list): XML Objects

2.2.10 – XBRL Tuple Information Item

1 Parent: 2.2.8

2.2.9 – XBRL Item Information Item

1 Parent: 2.2.82 Period Type: "instant"|"duration"3 Balance: "credit"|"debit"|{empty}4 Default: String

2.2.14 – Relationship Information Item

1 Parent: 2.2.122 Type: QName3 From: 2.2.15 or 2.2.8 or fragment4 To: 2.2.15 or 2.2.8 or fragment5 Arcrole: 2.2.66 Order: Decimal7 Use: NMToken8 Priority: Decimal9 Attributes (list): xml: Attribute List

2.2.15 – Resource Information Item

1 Parent: 2.2.122 Type: QName3 Role: 2.2.54 Element (list): XML Object list5 From (list): 2.2.146 To (list): 2.2.147 Attributes (list): XML Attribute List8 Value (list): XML Elements

2.2.2 – XBRL Document Information Item

1 Parents (list): 2.2.22 URI: URI3 Additional Properties (list): 2.2.3 or 2.2.114 Document Information Item: not in Infoset

2.2.3 – XBRL Taxonomy Information Item

1 Parent: 2.2.22 Namespace: URI3 Roles (list): 2.2.54 Arcroles (list): 2.2.65 Linkbases (list): 2.2.2 → 2.2.116 Imports (list): 2.2.47 Concepts (list): 2.2.8

2.2.11 – XBRL Linkbase Information Item

1 Parent: 2.2.22 Documentation (list): 2.2.133 Links (list): 2.2.124 Attributes (list): xml: Attribute List

2.2.4 – Imported XBRL Taxonomy Information Item

1 Parent: 2.2.32 Content: 2.2.23 Attributes (list): xml: Attribute List

2.2.5 – Role Type Information Item

1 Parent: 2.2.32 Definition: String3 UsedOn (list): 2.2.74 URI: URI5 Uses (list): 2.2.12 or 2.2.15

2.2.6 – Arcrole Type Information Item

1 Parent: 2.2.32 Definition: String3 UsedOn (list): 2.2.74 URI: URI5 Cycles: "any"|"undirected"|"none"6 Uses (list): 2.2.14

2.2.7– Used On Information Item

1 Parent: 2.2.5 or 2.2.62 Target: QName

2.2.12 – Extended Link Information Item

1 Parent: 2.2.112 Type: QName3 Role: 2.2.54 Documentation (list): 2.2.135 Relationships (list): 2.2.146 Attributes (list): xml: Attribute List

2.2.13 – Documentation Information Item

1 Parent: 2.2.12 or 2.2.112 text: String3 Attributes (list): xml: Attribute List

1

1..*

0..*

0..*

1

1..*

1

0..*

0..* 1

0..*

1

0..*

0..*

0..*

1..*

0..*

0..*

Class ModelXBRL Infoset

11

1

1..*

0..*

1

0..*

2.2.1 – DTS Information Item

1 Root: URI2 Concepts (list) : 2.2.83 Resources (list): 2.2.15

0..*

1 1

0..*

19

Current syntax

• Syntax is defined in an XBRL taxonomyversioning report is an instance document

• Empty tuples are used to define the structure

• Advantages:extensibilitywell-know syntaxthe two compared taxonomy versions aren’t directly linked

• Disadvantages:real intension of an instance document wasn’t a versioning reportthe design of the syntax is ruled by the XML schema of the XBRL instance

20

Syntax of the Versioning Report

supports documentation of specific assignments (tasks) that have resulted in revisions on the initial DTS.

Assignments foresee the following motives for revisions: errataCategory businessCategory technicalCategory

Assignments can group the actions taken to complete them. An action is a collection of revisions to the initial DTS. A revision is expressed in a difference that explicitly identifies the item that has

been changed. indicates where the change has been made but do not record the

substance of the difference.

needs to be processed in combination with both underlying DTSs to analyse the entire revision made.

Example: Versioning report indicates that the name of a concept changed but would not provide the original or the revised name.

21

Syntax of the Versioning Report

gives information about the starting points of the DTSs .

can be refined to contain only the necessary or project relevant changes.

Example: IFRS changes with no impact on the FINREP taxonomy need not be part of the versioning report.

can contain mapping tables for namespaces, roles and concepts.

can include references to supplementary reports.

relies on Uniform Resource Identifiers (URI) to specify where the revision has been made.

supports the use of the generic label linkbase to add human readable documentation.

22

the next PWD contains both a raw xml and an instance approach

the syntax is very similar, only the container differs

Open question: Is it important to combine instance data with versioning information?

Possible example of use:An instance preparer that has the possibility to extend the base taxonomy could report the instance data together with the adjustments that has been made to the taxonomy.

Feedback is needed to decide about the most appropriate approach.

Comparison raw xml and instance approach

23

• Dimensional requirements:

No report of changes that don’t influence the Cartesian product of the hypercubes.

No versioning information when the dimensional representation of a concept changed.

Versioning on dimensions

not all not all

not all

allallall

all

Valid combinations in each context must be compared!

24

To DTS

Versioning on dimensions

i

i

i

SalesCanada

SalesSpain

SalesGermany

i Canada

i Spain

i Germany

A

A

A

i Sales

• Dimensional requirements:

No report of changes that don’t influence the Cartesian product of the hypercubes.

No versioning information when the dimensional representation of a concept changed.

FROM DTS

i

i

i

SalesCanada

SalesSpain

SalesGermany

FROM DTS

25

Conclusions

In excess of 8,000 users across Europe have to facilitate the mapping and remapping that will arise by using any new taxonomy version.

CEBS needs to have a workable solution on versioning to increase the acceptance of the COREP and FINREP taxonomies in Europe.

The current XBRL Versioning Specification is based on XBRL 2.1.covers a great amount of the requirements .provides an extensible as well as reducible versioning report.

A subgroup inside the VWG deals with the development of the XBRL Versioning Specification on Dimensions.

COREP XBRL Network mission: provide versioning files for each COREP/FINREP version/release, each new IFRS version as used in FINREP, national extensions, if necessary.

26

The XBRL Network of the

www.c-ebs.org

www.corep.info

www.finrep.info

Katrin SchmehlKatrin.Schmehl@bundesbank.de+49 69 9566 6584