European XBRL Taxonomy Architecture

From XBRLWiki

(Difference between revisions)

Jump to: navigation, search

Revision as of 06:01, 25 October 2012

1 Foreword
2 Introduction
3 Scope
- 3.1 Approach
4 Normative references
5 Terms and definitions
6 Symbols and abbreviations
7 Rules
8 Bibliography

Foreword

Introduction

These pages are hosting the guidelines to an European XBRL Taxonomy Architecture. (EXTA, for short)

European; because this project is funded by the EU commission, but there is no restriction in applying it anywhere else;
XBRL; because that is the syntax standard that has been chosen to be used in electronic information exchange between national banking supervisors and the European authorities;
Taxonomy architecture, because creation of different 'dictionaries' or 'reporting frameworks' in XBRL have such a wide variety of options it would cause incompatability between the different XBRL taxonomies which would lead to increased implementation costs for all adopters in the EU market.

Objective

The objective of the EXTA is to create an XBRL taxonomy that isComment-06:

Consistent and predictable;
(Automated) controllable;
Modular, which enables lean extensions and ease of maintenance;
Following international best practices;

Target audience

EXTA is targetted at taxonomy authors. Initially organisations like EBA, EIOPA, ESMA, ECB etcetera. As a spin-off of these taxonomies, local (national) initiatives will emerge, hosted by National Supervisory Agencies (NSA's). To meet local legislation the European taxonomies may have to be extended with local requirements. The EXTA is also aimed at supporting these national extensions according to the same guiding principles. The main advantage being a consistent framework of XBRL taxonomies which enables a cost efficient implementation in software solutions.

Consistent taxonomies throughout Europe also creates the opportunity for cross-EU harmonisation of terminology and, in a later stage, consistent reported facts that are more easily analyzed since the underlying structure is the same and terms used are complementary to each other.

A consequence of a consistent taxonomy framework is that software developers can choose to support only the architectural guidelines of EXTA. Although this limits their software in supporting full fledged XBRL taxonomies it eases implementation costs.

Relationship to other work

The reader of this EXTA is expected to be familiar with the basic principles of data modelling and have a thorough understanding of the XBRL family of specifications to evaluate the impact of the rules set to the XBRL taxonomy that needs to be created.

Scope

From a semantic point of view, EXTA is aimed at European financial reporting frameworks. This involves (but not limits to) banks, insurance companies, pension funds, stock exchanges and investor vehicles that have an obligation to report their financial status to European supervisors.

From a syntax point of view, EXTA works with:

XBRL 2.1
XBRL for Dimensional Taxonomies (XDT) 1.0
XBRL Generic Link 1.0
XBRL Formula 1.0
XBRL Versioning 1.0
XBRL Table linkbase (not released yet)

The syntax standards documentation is freely available at | XBRL International

Approach

Designing any consistent architecture requires a methodology. For EU supervisors the Data Point Modelling (DPM) methodology has been chosen. This methodology relies on defining datapoints (facts) and support all of their aspects as dimensions. For an explanation of how to work with DPM, dedicated pages are provided in this Wiki at | Data Point Methodology

As a consequence to EXTA the taxonomy will rely heavily on the use of dimensions and their members. Given the XBRL specification of how to express dimensions the taxonomy will have some 'exceptions' to support specific dimensional constructs. EXTA will also provide a number of naming conventions for the XBRL building blocks that are needed to construct the taxonomy.

There will be multiple taxonomies from multiple EU agencies based on multiple reporting frameworks. This means that modularity is important to prevent a complex structure with intensive maintenance tasks. It is recognized that there will be two major components to all of the taxonomies: the more or less 'fixed' part compromised of all the detailed building blocks like concepts, types and their labels, and the 'flexible' part that is formed by the reporting requirements of a single table, form or report. It is expected that both parts can be extended but that the frequency in which modifications will have to be made lies mostly in the 'flexible' part.

The 'fixed' part of the building blocks is known as the dictionary layer, the 'flexible' part as the framework.

Comment-01

Normative references

The eXtensible Business Reporting Language (XBRL), see | XBRL Standard

The Extensible Markup Language (XML), see | XML Standard

Semantics of Business Vocabulary and Business Rules (SBVR), an OMG standard, see | SBVR

ISO 639, Language codes

ISO 3166, Codes for the representation of names of countries and their subdivisions

ISO 4217, Codes for the representation of currencies and funds

Simple Knowledge Organization System (SKOS), see | SKOS. Relevant mainly for the use of SKOS lexical labels in XBRL (see | SKOS lexical labels)

Terms and definitions

Term	Definition	Explanation
Concept	A concept is an XML element defined in the substitutionGroup xbrli:item or xbrli:tuple.	Concepts are the general term that refers to all elements created in the XBRL taxonomy which can serve different objectives. These different objectives (or goals) will have specialized terminology that will refer back to that term being a specialisation of 'concept'.
Data Point Model (DPM)	A DPM is a systematic representation of the data of a reporting framework
Dimension	A dimension (or axis, plural: axes) is an abstract concept in the substitutionGroup xbrldt:dimensionItem. It serves as a place holder for domains and their members. The combination of a dimension and one of its individual members that is tied (through a table) to a primary gives extra semantic meaning to the primary.
Domain	A domain is an abstract concept in the substitutionGroup xbrli:item and is the parent in a domain-member relationship. It serves as a place holder for a group of members that are strongly (semantically) related. E.g. all individual countries are a member in the domain 'Countries'.	A domain has no technical relevance, it expresses a semantically relevant group of members. A domain CAN be a member in another domain.
Families	A family is an abstract concept in the substitutionGroup xbrli:item with the @type set to 'model:familyType'.
(domain)Member	A member is an abstract concept in the substitutionGroup xbrli:item and is the child in a domain-member relationship.	A member consists in a semantic sense only as its name (a string). There are no other semantically relevant details expressed in the taxonomy on a member.
Item	Am item is simple abstract element that represents a single fact or business measurement.
Metrics	A metric is a non abstract concept in the substitutionGroup xbrli:item that is defined based on the unique combination of a (XML) type and xbrli:periodType.	A metric is a sub-class of a primary; a concept that is used in XBRL for communicating facts. Primaries can however represent semantics, metrics represent only the technical uniqueness without any semantic meaning.
Namespace	The unique string in the form of an URI that is the @targetNamespace content of (a set of) XML schema file(s).	A namespace is the identifier for all the content a schema defines. Multiple schema's can have the same namespace if xs:include is being used.
Owner	The owner represents an European institution that defines concepts, it is represented through folders, URI's in the taxonomy.	The owner is the top level of everything that is defined in the data point model.
Perspectives	Perspectives are extended linkroles that have a child node <link:usedOn>link:presentationLink</link:usedOn> AND contain only parent-child relationships in which families are the parent and dimensions are the child.
Primary	A primary is a non abstract concept in the substitutionGroup xbrli:item that is used for carrying facts in an instance.	The term primary was introduced to differentiate between elements that play a role in defining the dimensional space (tables, axes, domains, members) and the elements that actually carry facts. The introduction of this term makes it possible to differentiate between members that are abstract (cannot hold facts) and members that are not abstract (can hold facts).
Public elements	Public elements are XBRL concepts in the data point model.	They are identified by a code in a certain scope. They MAY include additional information such as readable labels, definitions and legal references in different languages.
Secondary concepts	Secondary concepts are abstract concepts that are used for grouping dimensions for presentation purposes.
substitutionGroup	An XML attribute to designate an element as either an item or a tuple.
Tuple	A tuple is a complex abstract element that represents sets of facts that are dependent on each other. A tuple may contain both items and other tuples.

Comment-03

Comment-04

Comment-05

Symbols and abbreviations

Rules

Localisation, extensibility

There are two areas that are commonly understood as part of a 'localisation' of the taxonomy. In some cases this refers to enabling the taxonomy to operate in a certain language area and in other cases the term is referring to the enabling of the taxonomy to support local legal requirements. The term 'local' is often understood as geographical based but it can also be industry specific or represent any other grouping of businesses involved in the reporting domain.

Language

If there is a need to have a representation of taxonomy content for a certain language, XBRL offers the option of extending the taxonomy with extra labels in the language preferred. This can be done by anybody with the proper knowledge of the taxonomy content and the preferred language. In the European Union all member state language belong to the 'official' languages of the EU. It is up to the EU agency to provide the necessary languages with their taxonomy. By providing the different languages in separate files (linkbases) and NOT linking them directly into the taxonomy, any regulator can create an extension calling only the required languages and save on the size of the taxonomy being discovered by the XBRL enabled software.

Legal and other requirements

Local NSA's may create extra tables or extend existing tables with columns/rows that are needed to abide local legal regulations. For reporters that create reports in multiple countries it eases the reporting burden when these extensions to the base taxonomy are created in a similar way (from a technical perspective). The scenarios that allow for extensions are:

adding rows/columns to existing tables
adding new tables
dividing existing cells

Detail pages

Bibliography

Retrieved from "https://xbrlwiki.info/index.php?title=European_XBRL_Taxonomy_Architecture"

 |-
 |Owner
-|The owner represents an European institution that defines concepts in the ''data point model''.
+|The owner represents an European institution that defines concepts, it is represented through folders, URI's in the taxonomy.
-|The owner is the top level of everything that is defined in the taxonomy. It is represented by a schema in which a number of characteristics of an owner are stored.
+|The owner is the top level of everything that is defined in the ''data point model''.
 |-
 |Perspectives
 |}
-<span style="background-color:yellow">[[Talk:European_XBRL_Taxonomy_Architecture#Comment-02|Comment-02]]</span>
 <span style="background-color:yellow">[[Talk:European_XBRL_Taxonomy_Architecture#Comment-03|Comment-03]]</span>