1. Tutorial on Versioning Presented at the: IX European Banking Supervisors XBRL Workshop & Tutorial In: Paris On: 29th September 2008 By: Katrin Schmehl Member of the CEBS XBRL Network The XBRL Network of the

2. SIONING VERSIONING VERSIONING VERSIONING VERSIONING VERSIONING VERSIONI WIKI

3. 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

4. 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 its important to deal with the process of change in a predictable and useful way. 6

5. 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 cant be achieved, the costs of updating the required software to adjust to the newer version is often very high. 7

6. 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. Type Complex 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 number Version numbers should be used to differentiate between different versions, preferably in a version attribute on the root element of the XML format. 8

7. 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

8. 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

9. 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. –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

10. Versioning Strategy in COREP and FINREP Namespace change Therefore only non-compatible changes result in a change in 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 VersionNamespace 1.2.6http://www.c-ebs.org/eu/fr/esrs/corep/2006-07-01 1.3.0http://www.c-ebs.org/eu/fr/esrs/corep/2009-01-01 12

11. Versioning differences on COREP and FINREP The CEBS XBRL Network documents the changes on taxonomies on their website (http://www.corep.info).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

12. 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

13. 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

14. 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 processes need a standardised syntax. 16

15. 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

16. XBRL Versioning Specification Deliverables of Versioning Working Group Versioning Specification Requirements XBRL Versioning Specification Part I Description Definition of the information to be compared Rules of correspondence Content model XBRL Versioning Specification Part II Syntax Conformance Suite Test cases Sample reports XBRL Versioning Specification on Dimensions 18

17. Definition of the information to be compared Decisive factor for the comparison is the XBRL Infoset Description 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.3 2 Name: NCName 3 Type: XSDType 4 SubstitutionGroup: QName 5 Nillable: Boolean 6 Abstract: Boolean 7 Block: "#all"|"extension"|"restriction"| "substitution"|{empty} 8 Fixed: String 9 Final: "#all"|"extension"|"restriction"| {empty} 10 From (list): 2.2.14 11 To (list): 2.2.14 12 Attributes (list): xml: Attribute List 13 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.8 2 Period Type: "instant"|"duration" 3 Balance: "credit"|"debit"|{empty} 4 Default: String 2.2.14 – Relationship Information Item 1 Parent: 2.2.12 2 Type: QName 3 From: 2.2.15 or 2.2.8 or fragment 4 To: 2.2.15 or 2.2.8 or fragment 5 Arcrole: 2.2.6 6 Order: Decimal 7 Use: NMToken 8 Priority: Decimal 9 Attributes (list): xml: Attribute List 2.2.15 – Resource Information Item 1Parent: 2.2.12 2Type: QName 3 Role: 2.2.5 4 Element (list): XML Object list 5 From (list): 2.2.14 6 To (list): 2.2.14 7 Attributes (list): XML Attribute List 8 Value (list): XML Elements 2.2.2 – XBRL Document Information Item 1 Parents (list): 2.2.2 2 URI: URI 3 Additional Properties (list): 2.2.3 or 2.2.11 4 Document Information Item: not in Infoset 2.2.3 – XBRL Taxonomy Information Item 1Parent: 2.2.2 2Namespace: URI 3 Roles (list): 2.2.5 4 Arcroles (list): 2.2.6 5 Linkbases (list): 2.2.2 2.2.11 6 Imports (list): 2.2.4 7 Concepts (list): 2.2.8 2.2.11 – XBRL Linkbase Information Item 1 Parent: 2.2.2 2 Documentation (list): 2.2.13 3 Links (list): 2.2.12 4 Attributes (list): xml: Attribute List 2.2.4 – Imported XBRL Taxonomy Information Item 1 Parent: 2.2.3 2 Content: 2.2.2 3 Attributes (list): xml: Attribute List 2.2.5 – Role Type Information Item 1 Parent: 2.2.3 2 Definition: String 3 UsedOn (list): 2.2.7 4 URI: URI 5 Uses (list): 2.2.12 or 2.2.15 2.2.6 – Arcrole Type Information Item 1 Parent: 2.2.3 2 Definition: String 3 UsedOn (list): 2.2.7 4 URI: URI 5 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.6 2 Target: QName 2.2.12 – Extended Link Information Item 1 Parent: 2.2.11 2 Type: QName 3 Role: 2.2.5 4 Documentation (list): 2.2.13 5 Relationships (list): 2.2.14 6 Attributes (list): xml: Attribute List 2.2.13 – Documentation Information Item 1 Parent: 2.2.12 or 2.2.11 2 text: String 3 Attributes (list): xml: Attribute List 1 1..* 0..* 1 1..* 1 0..* 1 1 1..* 0..* Class Model XBRL Infoset 1 1 1 1..* 0..* 1 2.2.1 – DTS Information Item 1 Root: URI 2 Concepts (list) : 2.2.8 3 Resources (list): 2.2.15 0..* 11 19

18. Current syntax Syntax is defined in an XBRL taxonomy versioning report is an instance document Empty tuples are used to define the structure Advantages: extensibility well-know syntax the two compared taxonomy versions arent directly linked Disadvantages: real intension of an instance document wasnt a versioning report the design of the syntax is ruled by the XML schema of the XBRL instance 20

19. 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

20. 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

21. 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

22. Dimensional requirements: No report of changes that dont influence the Cartesian product of the hypercubes. No versioning information when the dimensional representation of a concept changed. Versioning on dimensions not all all Valid combinations in each context must be compared! 24

23. 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 dont 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

24. 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

25. The XBRL Network of the www.c-ebs.org www.corep.info www.finrep.info Katrin Schmehl Katrin.Schmehl@bundesbank.de +49 69 9566 6584