tutorial on versioning presented at the: ix european banking supervisors xbrl workshop &...
TRANSCRIPT
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 [email protected]+49 69 9566 6584