European XBRL Taxonomy Architecture V2.0
From XBRLWiki
| Revision as of 14:44, 11 June 2013 (edit) Katrin (Talk | contribs) (→Dimension items) ← Previous diff |
Revision as of 14:52, 11 June 2013 (edit) Katrin (Talk | contribs) (→Families) Next diff → |
||
| Line 373: | Line 373: | ||
| <span style="background-color:#A9D0F5">Example table to be filled</span> | <span style="background-color:#A9D0F5">Example table to be filled</span> | ||
| + | |||
| + | [[Image:Family.jpg]] | ||
| === Perspectives === | === Perspectives === | ||
Revision as of 14:52, 11 June 2013
CEN WS XBRL Experts: Thierry Declerck (DFKI), Roland Hommes (Rhocon), Katrin Heinze (Deutsche Bundesbank)
Contents |
Foreword
Introduction
The purpose of this document is to present and explain the European XBRL Taxonomy Architecture (EXTA) defined by European supervisory authorities. In particular, it explains the scope (coverage of information requirements), modularization in files, manner of defining concepts and relations and other important design aspects. It is fully compatible with the Data Point Methodology approach. As DPMs are semantic models being created by supervisory experts, they are not formalized from a technical point of view. XBRL as formal language can fill this gap. XBRL as data format is standardized and can therefore be used to enable automated processes. XBRL taxonomies are metadata specifications that provide a formal description of the data requirements to be used as data format in the European reporting process. The document intends also to provide a description for IT experts about the linkage between a DPM as source and the XBRL taxonomy as target of a transformation process.
These pages are hosting the guidelines to an European XBRL Taxonomy Architecture (EXTA).
- European: this project is funded by the EU commission to support the standardisation process for supervisory reporting in Europe, but there is no restriction in applying it anywhere else;
- XBRL: this format has been chosen by the supervisory authorities EBA and EIOPA for the electronic data exchange between national banking supervisors and the European authorities;
- Taxonomy Architecture: this architecture has been created to limit the wide variety of options to define an XBRL taxonomy; different European XBRL taxonomies for similar purposes cause incompatability and would lead to increased implementation costs for all adopters in the EU market.
Objective
The objective of the EXTA is to define a set of architecture guidelines that transforms an European DPM without a loss in quality in an XBRL format. The taxonomy architecture provides a set of rules for this transformation to enable the creation of consistent and predictable XBRL meta data definitions in an automated process. EXTA supports a modular structure to enable the extensibility of these taxonomies as well as to ease their maintenance. As EXTA is a formal representation of a DPM it contains several structural concepts which has no correspondance in other known XBRL architectures.
Target audience
EXTA is targetted at taxonomy authors. Initially organisations like EBA, EIOPA, ESMA, ECB etc. 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 need 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.
This document is aimed at users of the Bundesbank taxonomies, in particular editors of the taxonomy or producers of instance documents (by applying mappings to internal systems or assigning XBRL tags with values in any other manner) as well as developers of the IT solutions facilitating reporting in the XBRL format or analysis of XBRL data.
Relationship to other work
The reader of this EXTA is expected to be familiar with the 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
The EXTA has been defined for the creation of XBRL Taxonomies in the context of European supervisory reporting. XBRL taxonomie following this architecture are published by an European supervisory authority to reflect the data requirements based on a DPM in a machine-readable form.
Normative references
The eXtensible Business Reporting Language (XBRL), see | XBRL Standard
The Extensible Markup Language (XML), see | XML Standard
Terms and definitions
- Concept
- A concept is an XML element defined in the substitutionGroup xbrli:item or xbrli:tuple.
- Data Point Model (DPM)
- A DataPointModel defines structures of data describing the characteristics of the information exchanged in the context of supervisory reporting processes.
- Dimension
- A Dimension is a data set to one characteristic area which is composed of individual and non-overlapping data elements. In XBRL terms a dimension is an abstract concept in the substitutionGroup xbrldt:dimensionItem.
- Domain
- A Domain is a classification system to categorize items that share a common semantic identity. A domain is an abstract concept and is the parent in a domain-member relationship. E.g. all individual countries can be members in a domain 'Countries'.
- Family
- Families are groups of Dimensions relevant for presentation or querying purposes. In XBRL terms a family is an abstract concept in the substitutionGroup xbrli:item with the @type set to 'model:familyType'.
- Framework
- A Framework is a business term common to a group of business users that consists of reporting regulations for a domain specific scope of information, like COREP, FINREP or Solvency II. Frameworks are public elements represented using XBRL abstract items with @type set to 'model:frameworkType' in schema 'fws.xsd'.
- Item
- An item is an abstract XML element in the substitutionGroup xbrli:item that can be used to carry facts or to represent business measurements. The item is defined by XBRL International as a placeholder for creating concepts.
- (Domain) Member
- A domain-member is discrete and countable. These Members can be explicitly defined in a domain. A member is an abstract concept in the substitutionGroup xbrli:item and is the child in a domain-member relationship.
- Metric
- A metric represent the nature of the data with a fixed and unchangeable meaning. Metrics are strongly related to the underlying data type. Mostly they are numeric and quantitatively measurable but they can be also reflect boolean or date values. A metric also known in XBRL terms as primary 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.
- Namespace
- The unique string in the form of an URI that is the @targetNamespace content of (a set of) XML schema file(s).
- Owner
- The owner represents an European institution that defines concepts. The owner's namespace is a URI used to establish the namespace of the concepts defined by that owner.
- Perspective
- 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.
- Public elements
- Public elements of DPMs are represented as concepts in XBRL taxonomies. 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.
- SubstitutionGroup
- An XML attribute to classify a complexType of simpleType element so its construction can be re-used by other elements.
- TableGroup
- A TableGroup is a set of Tables that represents a business template. In XBRL terms tableGroups are public elements represented using XBRL abstract items with @type set to 'model:tableGroupType'.
- Taxonomy
- Taxonomies are defined as part of the DPM. It represents a version of the framework; kind like a 'name' for the set of definitions used in the framework that are not part of the dictionary. There is a virtual link with the XBRL term 'taxonomy' which is a set of concepts with their relationships and definitions. The XBRL taxonomy has much wider definition than the EXTA one. Taxonomies are public elements represented using XBRL abstract items with @type set to 'model:taxonomyType' in schema 'tax.xsd'.
European XBRL Taxonomy Architecture
Supporting concepts
Taxonomy levels and owners
Taxonomy concepts could be defined on one of the three levels:
- cross sector concepts and breakdowns (to be shared between different institutions e.g. banking, insurance and securities supervision),
- concepts from information requirements of an European supervisory authority,
- concepts defined by a NSA.
Level one are cross sector concepts that shall be eventually defined and agreed by a joint group of experts involved in setting up information requirements for different sectors such as banking, insurance and reporting of other commercial and non-profit companies. It is expected, that these concepts will mainly include the list of countries and currencies as defined by the ISO codes and subsequently extended by for example economy sectors, classes of financial instruments, accounting portfolios, time intervals, etc. This task will be most likely conducted by reconciliation between the dictionaries of business concepts defined by the EBA, EIOPA and other interested parties. Cross sector concepts will be published in the Eurofiling on-line resources as a set of XBRL schema and linkbase files that can be referenced from level two or level three dictionaries.
Level two are the concepts of an European supervisory authoriy. They represent the information requirements of COREP, FINREP, Solvency II and other scope defined on the European level. They may refer to and extend level one (cross-sector) concepts.
Level three are the concepts of national supervisors. They reflect information requirements set by a national legislation and specific banking regulations.
The idea of levels for concepts definitions has been addressed in the XBRL taxonomy model by introducing the notion of the owner. The owner represents an institution that defines concepts of the model. The owner is closely related to the idea of extensibility in XBRL. The main properties of the owner are:
- owner’s namespace {ons},
- owner’s prefix {opre}, and
- official location {oloc}.
The owner namespace {ons} is a URI used to establish the namespace of the concepts defined by that owner. This URI is generally built by adding xbrl to the internet domain of the institution that the owner represents. In case of the Bundesbank, the domain is extended by stat and sprv components to distinguish between statistical and supervisory datasets. The prefix {opre} is used as the basis to establish namespace prefixes in taxonomy files and for some short representations of the concepts by QNames using shorter prefixes (instead of long namespaces) plus the local name.
Official location {oloc} is a URL used to specify the location where taxonomy files associated to that owner are to be published. Different owners must have different official locations, even owners with the same internet domain/same namespace. The official location is generally built by adding three parts to the internet domain of the institution:
- representation of the geographical area covered by the institution (e.g. eu in case of the cross sector or the EBA concepts or es for the national specific concepts applied in a sample Europea country),
- indication of the scope of information requirement (e.g. fr for general financial reporting)
- fixed xbrl component identifying the type of standard used to express information requirements.
The following table presents examples of owners and applied namespaces, prefixes and official locations of taxonomy files.
| Owner | Namespace | Prefix | Official location |
|---|---|---|---|
| Cross-sector | http://www.eurofiling.info/xbrl | eu | http://www.eurofiling.info/eu/fr/xbrl |
| EBA | http://www.eba.europa.eu/xbrl | eba | http://www.eba.europa.eu/eu/fr/xbrl |
| Banca d’Esmirna | http://www.bde.se/xbrl | se | http://www.bde.se/se/fr/xbrl |
Copyright: text used as a header in every taxonomy file published by its owner.
Filing indicators
Filing indicators serve the purpose of communicating the scope of the reported data based on templates. The main purposes of filing indicators are:
- provide hints to applications using the taxonomy, on which templates/forms are included in the filing and for example shall be displayed to users,
- trigger execution of business rules (value assertions) to be run on a filing to check its correctness depending on the reported scope of data.
In technical terms, filing indicators are facts included as part of an instance document where the filer estates which templates/forms are being reported. Each template/form is represented as an instance fact of the item “table” under the “fIndicators” tuple element. These elements are defined in the namespace http://www.eurofiling.info/xbrl/ext/filing-indicators. The official location of this schema file is http://www.eurofiling.info/eu/fr/xbrl/ext/filing-indicators.xsd. This schema file is imported in every taxonomy module.
Throughout this document, the prefix find will be used to make reference to this schema namespace.
The following instance excerpt represents a filing with information about templates/forms with codes CA1 and MKRSAEQU:
<find:fIndicators> <find:table contextRef=”ctx”>CA1</find:table> <find:table contextRef=”ctx”>MKRSAEQU</find:table> </find:fIndicators>
The following instance excerpt represents a filing with information about tables with code 100 and 200:
<find:fIndicators> <find:table contextRef=”ctx”>100</find:table> <find:table contextRef=”ctx”>200</find:table> </find:fIndicators>
Context to which facts representing find:table element refer must identify the reporting entity and use the instant date which is the end date of the reporting period.
Table codes to be used on find:table facts are the ones identified by {template code} component of the documentation label of tabel:table resource (see 6.4.5.3 Tables). If a template results in multiple tables (as a result of its original arrangement in multiple physical tables or due to normalization process) it is identified by find:table fact only once.
Filing indicators are facts included as part of an instance document where the filer estates which tables are being reported. Each table is represented as an instance fact of the item “table” under the “fIndicators” element. These elements are defined in the namespace http://www.eurofiling.info/xbrl/ext/filing-indicators. The official location of this schema file is http://www.eurofiling.info/eu/fr/xbrl/ext/filing-indicators.xsd. Throughout this document, the prefix “find” will be used to make reference to this schema namespace.
This approach enables a clear separation between business facts (under the xbrli:xbrl element) and additional data required in the reporting process. Moreover, it does not require the addition of filing indicators to the dictionary of concepts, as filing indicators are defined in a generic way in its own schema.
Filing indicators include a Boolean attribute named “find:filed” with default value “true”. Tables not filed can be omitted from the list of filing indicators or have an entry with the “find:filed” attribute equal to “false”. The latter is especially useful if a footnote explaining the reasons for not filing a table want to be included.
Model supporting schema
The XBRL representation of the model makes use of some schema definitions in the namespace http://www.eurofiling.info/xbrl/ext/model. The official location of this schema file is http://www.eurofiling.info/eu/fr/xbrl/ext/model.xsd. Throughout this document, the prefix “model” will be used to make reference to this schema namespace.
Namespaces
The following table shows the prefixes used throughout this document as an abbreviated reference to namespaces:
Public elements
Public elements are all concepts based on a DPM that are identified by a code in a certain scope and may include some additional information such as readable labels, definitions and legal references in different languages.
Public elements include two attributes to reflect their creation date (model:creationDate) and the date when they was last modified (model:modificationDate).
Language specific information of public elements is represented using the following label resources: XBRL 2.1 labels (link:label) for xbrli:items (or derived) public elements,
- generic labels (label:label) for public elements represented as XLink resources or other construct (e.g. link:roleTypes).
- The default (standard) role (http://www.xbrl.org/2003/role/link) is used for the extended links containing the label resources.
The role types used as roles for generic and standard label resources are presented in the following table.
| Property | Generic label role | Standard label role |
|---|---|---|
| Name | http://www.xbrl.org/2008/role/label | http://www.xbrl.org/2003/role/label |
| Definition | http://www.xbrl.org/2008/role/verboseLabel | http://www.xbrl.org/2003/role/verboseLabel |
| Legal references | http://www.xbrl.org/2008/role/documentation | http://www.xbrl.org/2003/role/documentation |
The labels of the concepts of a schema or a linkbase file are represented jointly in a separate label linkbase file distinguished by language, in the same folder as its corresponding schema or linkbase file. Each language is stored in a separate label linkbase file. The naming convention for these label linkbase files is:
- {main-file}-lab-{lang}.xml
where {main-file} corresponds to the name of the schema or linkbase file where the concept is defined (without extension) and {lang} component represents the ISO 639-1 code of the language (lowercase).
In addition to this, some concepts of the dictionary may contain a special linkbase to represent codes needed for different purposes. In particular, the codes given to the columns and rows of tables or codes assigned to the data points are represented using this mechanism. The name of these linkbase files constructed as follows:
- {main-file}-lab-{lang}-codes.xml or {main-file}-lab-codes.xml
In case of the later, the distinction between codes appearing in different language versions is determined basing on xml:lang attribute on label resources. The labels for these codes are represented as resources with a custom role. The role defined in the model.xsd schema for resources representing codes of rows or columns is http://www.eurofiling.info/xbrl/role/rc-code.
Dictionary of concepts
The core concepts of the dictionary are metrics, dimensions, domains and domain members. Secondary concepts are families and perspectives (auxiliary concepts meant to group dimensions for presentation purposes). All the concepts in the dictionary are public elements.
To cope with changes in the reporting, in addition to the properties and language specific information of public elements, dictionary elements include two optional attributes that establish its currency period: the starting date of the period interval (model:fromDate attribute) and its end date (model:toDate attribute). If the model:fromDate attribute is not included, then the concept is assumed to be valid for any period prior to the model:toDate attribute. If the model:toDate attribute is not included, then the concept is assumed to be valid for any period after the model:fromDate attribute. If neither model:fromDate nor model:toDate attributes are included, then the concept is assumed to be current for any period of time. The first versions of the dictionary will not include these attributes. As new versions are released and some concepts become obsolete and replaced by others, these attributes will be updated. These attributes don’t have any impact on the reporting process itself; they are meant to simplify the management of the concepts of the dictionary.
All files in the dictionary of concepts are placed under the folder dict in the official location of its owner (see Table 3). Its namespace is obtained by adding a suffix that depends on the type of element to the namespace of the owner. The prefix to represent that namespace is obtained by adding a predefined suffix to the prefix of its owner (as presented in Table 4) where {oloc} represents the official location of taxonomy files of the owner of the concepts, {ons} its base namespace, {opre} the prefix of its base namespace, and {dc}/{DC} the code of a domain in lower and capital case.
| Dictionary concept | Official location | Target namespace | Namespace prefix |
|---|---|---|---|
| Metrics | {oloc}/dict/met/met.xsd | {ons}/dict/met | {opre}_met |
| Dimensions | {oloc}/dict/dim/dim.xsd | {ons}/dict/dim | {opre}_dim |
| Explicit domains | {oloc}/dict/dom/exp.xsd | {ons}/dict/exp | {opre}_exp |
| Typed domains | {oloc}/dict/dom/typ.xsd | {ons}/dict/typ | {opre}_typ |
| Explicit domain members | {oloc}/dict/dom/{dc}/mem.xsd | {ons}/dict/dom/{DC} | {opre}_{DC} |
Examples of location, target namespace and its prefix for dictionary concepts of the taxonomy are listed below:
| Dictionary concept | Official location | Target namespace | Namespace prefix |
|---|---|---|---|
| Cross-sector metrics | http://www.eurofiling.info/xbrl/dict/met | http://www.eurofiling.info/eu/fr/xbrl/dict/met/met.xsd | eu_met |
| Cross-sector dimensions | http://www.eurofiling.info/xbrl/dict/dim | http://www.eurofiling.info/eu/fr/xbrl/dict/dim/dim.xsd | eu_dim |
| EBA explicit domains | http://www.eba.europa.eu/xbrl/dict/exp | http://www.eba.europa.eu/eu/fr/xbrl/dict/dom/exp.xsd | eba_exp |
| EBA typed domains | http://www.eba.europa.eu/xbrl/dict/typ | http://www.eba.europa.eu/eu/fr/xbrl/dict/dom/typ.xsd | eba_typ |
| SE explicit domain members example (domain CP) | http://www.bde.se/xbrl/dict/dom/CP | http://www.bde.se/se/fr/xbrl/dict/dom/CP | se_CP |
| EBA families | http://www.eba.europa.eu/xbrl/dict/fam | http://www.eba.europa.eu/eu/fr/xbrl/dict/dim/fam.xsd | eba_fam |
| EBA perspectives | http://www.eba.europa.eu/xbrl/dict/pers | http://www.eba.europa.eu/eu/fr/xbrl/dict/dim/pers.xsd | eba_pers |
Metrics
Metrics define the nature of the measure to be performed. Metrics determine the data type, the period type (instant / duration) plus additional semantics of their corresponding data points. Metrics are represented in XBRL as primary items and defined in schema files named met.xsd that reference label linkbase files. A local name of metrics is composed of three components:
- a letter that represents the data type in lower case (for available options see the table below),
- a letter that represents the period type: i for instant and d for duration,
- a number that corresponds to the numeric code in the model (no zero padding or predetermined length).
| Model data type | XBRL data type | Local name codification letter | Reporting unit |
|---|---|---|---|
| Monetary (currency) | xbrli:monetaryItemType | m | Adequate currency using ISO 4217 codification (e.g.: iso4217:EUR) |
| Percent | num:percentItemType | p | xbrli:pure |
| Decimal | xbrli:decimalItemType | p | xbrli:pure |
| Integer | xbrli:integerItemType | i | xbrli:pure |
| Date | xbrli:dateItemType | d | not applicable |
| Boolean | xbrli:booleanItemType | b | not applicable |
| Text | xbrli:stringItemType | s | not applicable |
| Explicit domain | xbrli:qnameItemType | e | not applicable |
| Typed domain | typed domain corresponding data type, e.g. xbrli:stringItemType if a typed domain is xs:string |
In case of domain based data types, an additional attribute (model:domain) is included to identify the qualified name of the explicit or typed domain (e.g. model:domain="eba:GA").
The id of the element (necessary for XLink locators) is composed as:
{opre}_{name}
where {opre} represents the prefix of the base namespace of the owner of the base item and {name} represents the name described above.
The following table contains a few examples of metrics declared in a taxonomy.
| Owner | Data / period type | Code | Name | Id | Namespace | Prefix |
|---|---|---|---|---|---|---|
| Cross-sector | Boolean / duration | 3 | bd3 | eu_bd3 | http://www.eurofiling.info/xbrl/dict/met | eu_met |
| Cross-sector | Monetary / duration | 7 | md7 | eu_md7 | http://www.eurofiling.info/xbrl/dict/met | eu_met |
| EBA | Monetary / instant | 7 | mi7 | eu_mi7 | http://www.eba.europa.eu/xbrl/dict/met | eba_met |
| EBA | Text / instant | 7 | si7 | eu_si7 | http://www.eba.europa.eu/xbrl/dict/met | eba_met |
| BdE | Boolean / duration | 3 | bd3 | se_bd3 | http://www.bde.se/xbrl/dict/met | se_met |
| BdE | Monetary / duration | 7 | md7 | se_md7 | http://www.bde.se/xbrl/dict/met | se_met |
As a DPM is the source of a transformation process with an XBRL taxonomy as its target graph transformations are being used to describe how the structure of a DPM, represented as class diagram in UML, is mapped to an UML class diagram visualising the underlying XBRL structure. To express the model transformation the UML source model of the DPM as well as the UML target model for representing the XBRL structure is given. Between the two graphs an abstract transformation syntax is used to describe the transformation rules from the source to the target model. The graph transformation intends to ease the understanding of the correlation between data structures reflected in Data Point Models and how these objects and structures can be matched to an XBRL data format. The graph transformation is limited to an essential part of the whole process. UML class diagrams reflecting the XBRL specification structure are visualized in the Aspect Model 2.0 of XBRL International.
The transformation process starts from the DPM UML graph on the left hand side marked in blue to the UML class diagram using red squares to visualize the XBRL structure. The black arrows between both UML class diagrams are not part of the general UML language but customized extensions which are used to describe the graph transformation. The square between two black arrows contains an abbreviation what is being mapped. We distinguish eight different types of mappings rules between the two graphs:
- C2C - transformation from an UML class in the DPM meta model in an UML class representing an XBRL concept,
- A2A - transformation from an attributevof a DPM meta class to an attribute of an XBRL element,
- A2R - transformation from an attribute of a DPM meta class to a XBRL resource as part of an XBRL linkbase,
- A2E - transformation from an attribute of a DPM meta class to its XML element representation in XBRL,
- C2RS - transformation of an UML class of the DPM meta model to an UML class representing an Relationship which is located in an XBRL linkbase,
- RS2RS - transformation of an UML class of the DPM meta model representing an Relationship to an UML class representing an Relationship which is located in an XBRL linkbase,
- C2Arc - transformation of an UML class of the DPM meta model to an XBRL arc combining two XBRL elements, in the given examples resources,
- C2E - transformation of an UML class of the DPM meta model to a table linkbase specific XBRL element which links to an XBRL concept.
The graph above shows how the meta class DimensionedElement of the DPM meta model is mapped to an XBRL concept with its corresponding XBRL attributes according to the EXTA definitions. Dimensioned Elements are known as metrics in the EXTA (synonym in XBRL: Primary item). Dimensioned Elements are part of the Dictionary so they inherit the attributes defined by the abstract concept of a Dictionary element. The abstract Dictionary element is subordinated element of the abstract meta class representing a Public element so the Dimensioned Element inherits also the attributes defined by this superordinated element. In XBRL terms a metric in EXTA must include at least the attribute model:creationDate of the custom attributes defined in the model.xsd schema.
Dimension items
Dimension items’ representation in XBRL is defined in the XBRL Dimensions 1.0 specification.
The local name of each dimension corresponds to its code in the model: a short sequence of capital case letters (usually two, but may be more).
Value of the id attribute of the element representing a dimension item (necessary for XLink locators) is composed according to the following pattern :
{opre}_{name}
where {opre} represents the prefix of the base namespace of the owner of the dimension and {name} represents the name described above. A few examples of dimension items are presented in the table below:
Example table to be filled
Names of schema files defining dimension items is dim.xsd and they include references to label linkbase files and a definition linkbase whose file name is dim-def.xml and are placed in the same folder as the schema file.
This definition linkbase includes the following information about explicit dimensions:
- reference to the domain associated to the dimension by means of a dimension-domain relationship (with xbrldt:usable attribute equal to false) pointing to a domain item defined in respective exp.xsd or typ.xsd schema file of any referenced or defined owner,
- reference to the default member of that dimension by means of a dimension-default relationship (note that although the model defines default members at the domain level, the XBRL Dimensions specification establishes this relationship at dimension level; thus, each dimension using a domain with a default member must include this relationship).
These relationships associating dimension with a domain and its default members are defined in an extended whose role is the standard one (i.e. http://www.xbrl.org/2003/role/link).
Families
Families are placed in the same folder as dimensions. Families are represented as XBRL abstract items of data type model:familyType. The local name of each family corresponds to its numeric code in the model preceded by a lower case letter f. Value of the id attribute of family elements is composed as follows:
{opre}_{name}
where {opre} represents the prefix of the base namespace of the owner of the family and {name} represents the local name described above. Some examples are presented in the table below.
Example table to be filled
Perspectives
Perspectives are placed in the same folder as dimensions and families. Perspectives are represented as extended link roles that are used in presentation linkbases, where the relationships between dimensions and families are formalized.
The URI of these roles is built according to the following pattern:
{ons}/role/dict/pers/{code}
where {ons} corresponds to the owner namespace and {code} represents the numeric code given to the perspective in the model. Value of the id attribute of the role type is composed according to the following patter:
{opre}_p{code}
where {opre} corresponds to the owner prefix and {code} represents the numeric code of the perspective in the model. Examples of perspectives are presented in the table below:
Example table to be filled
The schema file defining perspectives (pers.xsd) imports the schemas of families and dimensions, and refers to a generic linkbase containing generic labels of perspectives and a presentation linkbase (pers-pre.xml) including extended links that correspond to each perspective. The arcs in these extended links have families as source (root) nodes and dimensions as target nodes.
Domains
Explicit domains are represented using XBRL abstract items of domain type model:explicitDomainType in the schema file exp.xsd.
Typed domains are represented as XML elements that are not in the substitution group of xbrli:item. These elements are defined in the schema file typ.xsd. Explicit domains are xbrli:items whereas typed domains are not. Because of this, labels for the former ones are defined using standard label links and labels for the latter using generic label links.
The local name of each domain corresponds to its code in the model model {dom-code}: a short sequence of capital case letters (usually two, but may be more). Value of the id attribute of the element of the base namespace of the owner is composed according to the following pattern:
{opre}_{name}
where {opre} represents the prefix of the base namespace of the owner of the domain and {name} represents the name described above.
Some examples of domains items are presented in the table below:
Example table to be filled
| Owner | Code | Element Name | Type | Id | Namespace | Prefix |
|---|---|---|---|---|---|---|
| Cross-sector | GA | GA | Explicit | eu_GA | http://www.eurofiling.info/xbrl/dict/exp | eu_exp |
| EBA | CO | CO | Explicit | eba_CO | http://www.eba.europa.eu/xbrl/dict/exp | eba_exp |
| EBA | MI | MI | Typed | eba_MI | http://www.eba.europa.eu/xbrl/dict/typ | eba_typ |
| Bundesbank Statistics | CG | CG | Explicit | de_stat_CG | http://www.bundesbank.de/stat/xbrl/dict/exp | de_stat_exp |
| Bundesbank Supervision | ICTX | ICTX | Typed | de_sprv_ICTX | http://www.bundesbank.de/sprv/xbrl/dict/typ | de_sprv_typ |
Although the namespace of explicit and typed domains is different, different local names should be used to avoid confusion.
Explicit domain members and hierarchies
Explicit domain members are represented using XBRL abstract items of domain item type defined in the non-numeric set of types of the XBRL International type registry: nonnum:domainItemType.
The local name of each explicit domain member corresponds to its numeric code in the model preceded by a lower case x. Local names are XML schema tokens and thus, are not allowed to start with a numeric character. If the concept represented already has a widely accepted standard codification, like ISO codes or UN code lists, the local name will match the existing codification in lower case. More specifically, the following ISO codes are used:
- ISO 4217: standard currency codes composed of three alphabetical characters,
- ISO 3166-1 alpha-2: standard country codes composed of two alphabetical characters.
Value of the id attribute of explicit domain members follows the general rule:
{opre}_{name}
The default domain member of a domain (usually the one with numeric code component of the name set to 0) is marked with an attribute: model:isDefaultMember=”true”.
A special domain, identified in the model with code BC (Base categories), may define members whose declaration includes an additional xbrli:balance attribute specifying the credit or debit nature of the financial concept (according to the double entry accounting rule).
The schema file that represents explicit members is placed in a folder with the name of its corresponding domain. The schema file for explicit domain members is called mem.xsd. Examples of schema files defining explicit domain members in the taxonomies are presented in the table below:
Example table to be filled
Hierarchies are represented using XBRL extended link roles whose role type URI is built according to the following pattern:
{ons}/role/dict/dom/{dom-code}/{hierarchy-code}
where {ons} represents the namespace of the owner, {dom-code} represents the code of the domain and {hierarchy-code} the numeric code of the hierarchy. Value of id attribute of these roles is composed following the pattern: {opre}_{code} Examples of extended link roles used for hierarchies of domains are presented in the table below:
Example table to be filled
The schema file that represents hierarchies (defining role types and referring linkbases) is placed in the same folder as members and it is named hier.xsd. Examples of such schema files, their namespaces and prefixes are presented in the table below:
Example table to be filled
Each hierarchy of domain members (represented by an extended link role as explained above) must indicate at least one dimension related to a hierarchy. Identification of this dimension is made:
- in the standard role of generic label (of a hierarchy) by indication of a dimension label (optional),
- in the documentation role of generic label (of a hierarchy) by indication a QName (qualified name) of a dimension item declaration (obligatory).
Example of hierarchy reference to a dimension QName with documentation label role is presented below:
<link:loc xlink:type="locator" xlink:href="hier.xsd#eu_1" xlink:label="loc_eu_1" /> <label:label xlink:type="resource" xlink:label="label_eu_1_1" xml:lang="en" xlink:role="http://www.xbrl.org/2008/role/documentation">eu_dim:CS</label:label> <gen:arc xlink:type="arc" xlink:arcrole="http://xbrl.org/arcrole/2008/element-label" xlink:from="loc_eu_1" xlink:to="label_eu_1_1" />
This relation between hierarchies and dimensions is “many-to-many”, which means that a number of dimensions can be attached to one hierarchy and more than one hierarchy can be referred by the same dimension.
In addition to labels, these schemas refer to three additional linkbases with information about hierarchies:
- a presentation linkbase (hier-pre.xml), which represents the hierarchical disposition of members in hierarchies using parent-child relationships,
- a definition linkbase (hier-def.xml), which enables the inclusion of the members of a hierarchy in dimensional combinations using domain-member relationships,
- a calculation linkbase (hier-cal.xml), which establishes some basic arithmetical relationships between a member of the hierarchy and its children:
- a member is equal to the addition of its child members in the hierarchy: complete-breakdown relationships,
- a member is greater or equal than the addition of its child members in the hierarchy: partial-breakdown relationships,
- a member is less or equal than the addition of its child members in the hierarchy: superset-breakdown relationships.
These calculation arcs include a weight attribute to indicate whether the child member contributes to the aggregation positively (+1) or negatively (-1). These roles that represent these calculation relationships are defined in the model.xsd schema that supports the model and are presented in the table below.
Example table to be filled
The root member of the definition and presentation relationship networks is the domain item defined in the schema exp.xsd associated with the owner.
Domain members that extend the domain of another owner are placed in a folder preceded by the prefix of the extended owner. Example of extension of the cross-sector domain by with EBA specific concepts are presented in the table below.
Example table to be filled
Typed domains
Members of typed domains are neither listed as XBRL items with labels nor arranged in hierarchies. The content of typed domains is restricted by XML data type constraints, as these domains (according to the XBRL Dimension specification) are XML elements.
In most of the cases, a typed domain would be represented by an XML element with a simple data type (e.g. xs:string or xs:decimal). Further restrictions on the expected value are introduced by means of the Formula specification where value assertions define detailed constraints on the allowed values of a typed domain in association with a certain dimension. For example, the typed domain Code, being a string data type, may follow a certain pattern defined by a value assertion when referred from the Related entity code dimension and another pattern when used by the Instrument code dimension.
Reporting requirements layer
Frameworks, taxonomies, tables, modules and other concepts constitute the layer of the model where actual reporting requirements are specified with the support of the financial concepts defined in the dictionary.
All the files that correspond to this layer are placed under the folder fws in the official location of its owner. Its namespace is obtained by adding the suffix fws to the base namespace of the owner plus some additional suffixes that depend on the type of the concept represented.
Frameworks
Frameworks are public elements represented using XBRL abstract items of the framework type (model:frameworkType) in the schema file fws.xsd. General framework properties are presented in the table below:
Example table to be filled
The local name of each framework element corresponds to its code in the model and its id follows the general pattern.
Examples of frameworks defined by the EBA or Bundesbank taxonomies for statistical and supervisory data are presented in the following table:
Example table to be filled
Each framework has a folder where the files of its taxonomies are placed. This folder has the name of its code in the model as presented by the following examples:
Example table to be filled
Taxonomies
Taxonomies are public elements represented using XBRL abstract items of the taxonomy type (model:taxonomyType). These elements are stored in the schema file tax.xsd under the folder of its framework, a subfolder that corresponds to its normative code or legislation publication date (using the ISO 8601 codification) and another subfolder with the date of taxonomy version.
Thus, the file tax.xsd includes a single element. Its local name corresponds to its code in the model and value of its id attribute is constructed according to the general pattern ({opre}_{taxonomy code}). General taxonomy properties are presented in the table below.
Example table to be filled
To facilitate the specification of additional taxonomy resources in this document, hereinafter in applies:
- {taxonomy-loc} to the URL {oloc}/fws/{framework}/{normative code or legislation publication date with “pub_” prefix}/{taxonomy publication date},
- {taxonomy-ns} to the URI {ons}/fws/{framework}/{normative code or legislation publication date with “pub_” prefix}/{taxonomy publication date}.
Examples of taxonomy folders are presented below.
Example table to be filled
The folder of taxonomy includes three subfolders for:
- tables (tab),
- modules (mod) and
- validations (val).
Content of these subfolders is explained in the next sections of this document.
Tables
The table folder includes a schema file (tab.xsd) that references a generic linkbase with the hierarchy of table groups and tables (tab-pre.xml) and a label linkbase for table groups (tab-lab-en.xml). The schema includes the definitions of table groups (if any), which are represented using XBRL abstract items of the table group type (model:tableGroupType). Name of a table group item is composed by adding the prefix tg to the code of a table group in the model. General properties of a table group are presented in the table below:
Example table to be filled
Table groups are used to link numerous tables defined by one template or resulting from normalization of templates or if an original templates is composed by two or more physical tables.
The files that define the content of each table are placed in a folder whose name corresponds to the code of the template in the model ({table code}). General properties of a table are presented below:
Example table to be filled
Schema file for a table in refers to a table linkbase ({table}-rend.xml), a definition linkbase ({table}-def.xml) and a label linkbase ({table}-{lang}-lab.xml).
The table linkbase includes the definition of the table according to the Table Linkbase specification. The relationships of each table are placed in an extended link whose role is built according to the following pattern:
{ons}/role/fws/{framework}/{normative code or legislation publication date with “pub_” prefix}/{taxonomy publication date}/tab/{table code}
In this linkbase, the different components of tables are represented using resources. Value of the id attribute of these resources is based on the code or sequential number plus a prefix to obtain a unique code in the context of the linkbase file.
Example table to be filled
According to the Table Linkbase specification, aspect rules are used to specify the concepts represented in predefined axes. In the case of duration type metrics, the size of the period to be reported is constrained using time aspect rules in the context of a table. The default value is a reference period. Reference period is defined as the period that starts at the beginning of the period covered by a report and ends at the reference date. Another possible values are month, quarter, year, etc. In case of data points that correspond to an instant or period of time prior to the reference period, temporal aspect rules include a temporal offset relative to the reference date.
The reference date and the reference period shall be defined in terms of two parameters defined in a linkbase file (http://www.eurofiling.info/eu/fr/xbrl/func/params.xml):
- refPeriodEndDate: reference date and end date of the reference period,
- refPeriodStartDate: starting date of the reference period.
Examples of use of time references are presented below:
Example table to be filled
The definition linkbase includes dimensional relationships valid in the context of the table. Valid combinations are defined using only positive (all) closed hypercubes obtained from the set of valid cells of the table following certain algorithm in order to optimize their number.
Each extended link role contains one or more primary items and a single hypercube. The model schema includes a hypercube element to be used. There is no need to define hypercube elements in each table or taxonomy. In case of multiple primary items, the first one will be used to group the rest and reduce the number of all arcs. The domain element will be used as the target of dimension-domain arcs to avoid cycles. The @xbrldt:targetRole attribute might be necessary in the case of hypercubes with dimensions sharing the same domain.
The roles of the extended links necessary to express these combinations are built adding numeric suffixes to the role previously defined for the table. For example:
- {ons}/role/fws/{framework}/{normative code or legislation publication date with “pub_” prefix}/{taxonomy publication date}/tab/{table code}/1
- {ons}/role/fws/{framework}/{normative code or legislation publication date with “pub_” prefix}/{taxonomy publication date}/tab/{table code}/2
Modules
Modules are represented using XBRL abstract items of the module type (model:moduleType). Each module is stored in a different schema file whose name is the same as the code of the module in the model plus the extension .xsd. These schema files import the schemas of all the tables required by that module and additionally header taxonomy and filing indicators. General properties of a module are presented below:
Example table to be filled
In addition to label linkbases, each module includes a presentation linkbase ({module}-pre.xml) where the relationships between modules and tables or table groups are expressed using group-table arcs (defined in the model.xsd schema file) whose source is the module element and whose target is a table or a table group element. The module schema also imports the formula linkbases and optionally, the linkbases with the preconditions on filing indicators.
Validations
Validations are expressed using XBRL assertions. In order to handle the error margin caused by the imprecision of input data, assertions can make use of a set of functions implemented according to the Custom Functions Implementation specification. These functions use the same name as the ones defined in the XPath 2.0 Functions specifications, but are defined in the following namespace and placed in the following location: Namespace:
Official location:
Some example functions are:
- iaf:numeric-equal(arg1, arg2): true : if two values are equal or are within the tolerance interval derived from its reported precision.
- iaf:numeric-less-than(arg1, arg2): checks whether arg1 is less than arg2, considering their precision.
An entry point for these functions and additional ones that could be provided in the future is placed in the following location: http://www.eurofiling.info/eu/fr/xbrl/func/functions.xsd
Variables used are defined in no namespace; this way, there is a clear separation between variables and filing indicator parameters and the pivot-variable (see below). The naming convention for variables is lower camel case notation. Whenever an expression involves a certain number of facts used uniformly, sequence variables shall be used in order to improve the readability of the expression and the performance of the processor.
Assertion sets
Validations are grouped into assertion sets that correspond to the tables they are to be applied. In the context of a table, not reported or nil numeric values will be assumed to be zero; consequently, fallback values shall be used in their corresponding assertion definitions. The link between an assertion set and the table (or tables) it applies is represented using applies-totable arcs from the assertion set to the resource that corresponds to the table. The URI of this arc is as follows: http://www.eurofiling.info/xbrl/arcrole/applies-to-table
If an assertion applies to multiple tables individually or to multiple sets of tables, then it will be associated to different assertion sets.
Example table to be filled
Assertion sets resources might include the attributes model:fromDate and model:toDate to constraint the reference date where their associate assertions should be applied.
Assertions are identified by a unique code, so that it enables the identification of errors in a validation process with the corresponding definition . Assertions might include a description and custom error messages, as defined by business experts.
As suggested by the XBRL specification, assertion sets can be used as a mechanism to control the set of assertions to be evaluated in a validation process. Following this approach, an application processing a certain filing would configure the processor to skip all those assertion sets that are linked to a table that is not reported.
However, at the time of the writing of this document, the XBRL specifications do not provide a standard API to pass this information to XBRL processors, neither a standard way for the filer to indicate that only a subset of all the tables in an entry point is being submitted. To overcome this situation, a mechanism based on preconditions and filing indicators is provided.
Preconditions and filing indicator parameters
Each value assertion defined is associated to a precondition on filing indicators. Assertions might have additional precondition as required by the logic of the assertion to be performed. But these additional preconditions do not depend on filing indicators. To avoid XBRL instance syntactic dependencies, rather than including directly an XPath expression, preconditions include a reference to a filing indicator parameter (no variableset-variable arc are required). This approach is quite convenient, as there is a new line of work in the Formula WG to define a subset of validations considered to be portable. This will enable the possibility of having XBRL processors performing validations on data in a database, rather than information on a single XML document. The default value of this parameter is an XPath expression to obtain the information from the filing indicators in the instance document. This way, there is no need to provide externally a value to the processor (the value from the instance is used), the parameter is guaranteed to be only evaluated once (providing more chances for processors to perform optimizations), precondition expressions are simpler, and it makes possible, for more advanced uses, to override this value at application level (for instance, if the filing requirements of a credit institution are known, an application could override the values for filing indicator parameters rather than accepting the values provided by the filter). Filing indicators parameters are defined in the namespace of the filing indicators schema and have a name according to the following convention:
t{table-code}
where table-code represents the code of the corresponding table. Thus, the definition of one of these parameters would look like this:
<variable:parameter name="find:t{table-code}" select="//find:fIndicators/find:table = ‘{table-code}’" as="xs:boolean" …/>
Each precondition is composed as a sequence of or expressions that correspond to each set of tables where the validation is to be applied. Each or expression is composed of a sequence of and expressions on the tables involved:
$find:t{c1.1} and $find:t{c1.2} and …
or $find:t{2.1} and $find:t{2.2} and …
or …”
See examples provided below:
Example table to be filled
Existence assertions
Existence assertions are not compatible with the precondition-based control schema proposed in the previous chapter. Existence assertions perform a test on the number of evaluations of a set of variables. Preconditions restrict the number of evaluations of the assertion, but not the evaluation of the assertion itself. Consequently, existence assertions are always evaluated (unless controlled using assertion sets); if a filing indicator precondition is added to an existence assertion, it will raise false errors. Preconditions are not a mechanism designed to control the evaluation of assertions, but to restrict the set of data where a validation is applied. In fact, there is a new line of work in the Formulae WG to add preconditions at variable-set level. This way, preconditions could be used to control the evaluation of the assertions in the scope of a certain assertion set. However, this new and better approach is not expected to be ready in time for the release of EBA taxonomies. Nevertheless, the approach proposed in this document is ready to be adapted to the new standard in future releases of EBA taxonomies.
However, most existence assertions can be re-defined as value assertions using the following pattern:
- The assertion includes a “pivot-variable”: a fact variable that matches data in the instance document known to be reported always. The variable uses aspect cover filters to avoid any interference with the rest of variables. This variable is defined once as a sequence variable that matches the filing indicators.
- The rest of variables in the original existence assertion are included with a fallback value (a value given to the variable if the fact is not found in the instance document).
The pivot-variable is defined in the namespace http://www.eurofiling.info/xbrl/ext/pivot-variable. The official location of this schema file is http://www.eurofiling.info/eu/fr/xbrl/ext/pivotvariable.xsd. The pivot variable is linked to the assertion using the name {pvar:pivot} in the pivotvariable namespace.
Though unlikely, there might be the case of validations that cannot be defined using value assertions. For instance, checking that the number of rows (in a table with a variable number of rows) that verify a certain condition on several columns is greater than a certain number can be easily implemented using an existence assertion. The equivalent rule using a value assertion is extremely contrived and will have a very negative impact on the performance of the processor. If such a kind of rule were required, it should be implemented using an existence assertion. The id attribute of such assertions follows a predefined naming convention to help applications not relying on validation sets to discard such evaluations:
- Id for existence assertions: e{code}
- Id for value assertions: v{code}
Notation
Assertions will be identified by a unique code, so that it enables the identification of errors in a validation process with the corresponding definition. It must be noted that an XBRL assertion might produce several evaluations covering different sets of data points. Assertions might include a description and custom error messages, as defined by business experts. Existence assertions shall only be used to detect errors in the case of data that should have been reported. Whenever it is possible, value assertion shall be used instead of existence assertion, as the former enable more comprehensive error messages and makes possible the usage of preconditions on filing indicators.
The files that define assertions and assertion sets are grouped into files depending on their scope. These files are placed in the “val” folder of the corresponding taxonomy, together with files to define preconditions and filters14 of common use shared by different assertions in the taxonomy and parameters. These filters and preconditions should be independent of the assertion they apply to, and thus, should not depend on the variables defined by specific assertions.
Example table to be filled
Any of these linkbases can have its corresponding set of label linkbases, following the convention defined in this document. In the cases of assertions, an additional set of linkbases might be included for error messages expressed in different languages:
{assertions-file}-err-{lang}.xml
or
{assertions-file}-err-{lang}-{country}.xml
Where {assertions-file} corresponds to the name of the file with the assertions whose error message are described, without the extension. These files will be included by the modules defined in the taxonomy.
Architecture file structure
