From XBRLWiki

Revision as of 06:25, 16 March 2013

CEN Workshop Agreement

Status: Working Group Working Draft

Editing rules

Editorial comments should be highlighted as follows: A comment

Text or rules in discussion (white): Some text

Text or rules already aligned (green): Some text

Text or rules to be deleted (red): Some text

Text to be delivered (blue): Some text

Foreword

This document is a working document.
This document has been prepared by CEN/WS XBRL, the secretariat of which is held by NEN.
This document is a working document.

Introduction

The set of recommendations included in this document aim to facilitate the implementation of European National Supervisors to adopt XBRL in any of the reporting frameworks. The following chapters will provide guidance on the use, understanding, preparation, and extension of their filings in eXtensible Business Reporting Language (XBRL).

This guidance is in the form of notes in association with the pertaining requirements clause and uses the terms “should” (recommendation), “may” (allowance) and “can” (possibility). Organizations wishing to implement this CWA would be expected to consider all recommendations where the term “should”is used.

Scope

COREP, FINREP (and Solvency II or other future) XBRL taxonomies are offered to European regulators for national implementation. The first releases (2006) of the COREP and FINREP XBRL frameworks have proven that a standardized technical roll-out package is needed to increase the adoption rate and avoid implementation variances, which have a detrimental effect on the overall cross-border effectiveness of using one reporting standard. This roll-out guide tries as well to promote the economies of scale of a better adoption.

This CWA have divided the work/deliveries in two difference parts:

i) An XBRL supervisory roll-out guide: this is oriented towards national regulators on how to implement, extend and manage XBRL taxonomies

ii) An XBRL handbook for declarers: this is a roll-out guide or reference handbook would give a general introduction to XBRL and serve as a help to preparers of XBRL (reporting entities)

The scope of the current document is on the second part of the CWA; the XBRL handbook for declarers.
[DRAFT]

Normative references

The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.
EN xyz:199x, Title of the european standard.
EN ab c:199x, General title of series of parts — Part c: Title of part.

Terms and definitions

For the purposes of this document, the following terms and definitions apply / the terms and definitions given in … and the following apply.

Term1 

description on text for term1

Term2 

description on text for term2

How to start with XBRL from the declarer's perspective

XBRL stands for eXtensible Business Reporting Language. It is a language for the electronic communication of business information, providing major benefits in the preparation, analysis and communication of business information. It offers cost savings, greater efficiency and improved accuracy and reliability to all those involved in supplying or using business information.

XBRL is increasingly adopted as communication standard by more and more regulators around the world. The entities which are providing this information to the regulators might initially see XBRL as just another way or format of the required information. However, XBRL provides many benefits for the declarer as well. All types of organisations can use XBRL to save costs and improve efficiency in handling business and financial information. Because XBRL is extensible and flexible, it can be adapted to a wide variety of different requirements. All participants in the financial information supply chain can benefit, whether they are preparers, transmitters or users of business data.

XBRL can be used with the help of various software tools, in a way that the user doesn't need to understand or even see the XBRL itself. However, a basic understanding of the basic components of XBRL allows the user to better grasp the potential benefits of XBRL.

The ambition of this document is to explain the basic underpinnings of the XBRL standard. Although these aspects might seem technical at first, all topics will be addressed in a general, comprehensible way.

This section is further being elaborated during the Workshop with the input from the other project teams.

XML and XBRL: Introduction to its technological building blocks

This chapter aims to give an overview of the basic technologies that underpin XBRL. Our aim is to give a general introduction of each component in order to obtain a better understanding of this reporting language. Since XBRL is built upon the XML language, the this chapter will focus on the basics of the XML standard, in particular the XML components which are also used by XBRL.

XML

XML, or eXtensible Markup Language, is a W3C standard which enables the representation of structured data in the form of flat text. This simple and flexible text format is both machine readable and human readable. The XML specification, which is a derivative of SGML¹ , uses elements and attributes in order to structure content. Although originally designed for the publication of information, XML is increasingly important in facilitating electronic communications.

In the chapters further below, we'll elaborate on the following topics:

• How XML is a markup language
• How XML enables the structuring of information
• What are the main components of an XML document
• Namespaces and prefixes
• Unicode
• XML benefits

¹ SGML (or Standard Generalized Markup Language) is an ISO-standard technology for defining generalized markup languages for documents. SGML itself descends from GML (Generalized Markup Language), which is developed by IBM in the 1960s.

XML as a markup language

Simply put, one can say that XML is a language for the codification of structured information. This coding, which is done via the use of "tags", is the main reason why XML is commonly referred as a markup language. As a basic example, the list below represents a list of books:

   <book>On the Road</book>
   <book>The Catcher in the Rye</book>
   <book>The Hobbit</book>
   <book>The Name of the Rose</book>

The name of each book is delimited by two marks. The first mark contains an identifier enclosed in angle-brackets (<book>), indicating the beginning of a field. The second mark is equal to the first, but also contains a closing bracket (</book>), which indicates the end of a field. As a result, the content of each element of <book> is delimited by the opening and closing tags. With this method, a system that processes this information can easily identify the subject and aim of the provided information.

XML structures information

In the previous example, only the element <book> was provided. The XML information model is however hierarchical: an element can contain other elements, which in turn can also contain other elements. This is made clear with the following example:

<library>  
  <book>
    <title>On the Road</title>
    <author>Jack Kerouac</author>
  </book>
  <book>
  <book>
    <title>The Catcher in the Rye</title>
    <author>J. D. Salinger</author>
  </book>
  <book>
  <book>
    <title>The Name of the Rose</title>
    <author>Umberto Eco</author>
  </book>
  <book>
</library>

In the example above, the "library" element contains a set of "book" elements. Each of these "book" elements contains a "title" and an "author" element.

Components of an XML document

The most important components of an XML documents are the elements. Elements are defined by their name, their content (the value which is between the angled brackets, which can be null) and an indefinite number attributes. The example below shows an element with two attributes:

 <element attribute1="attr-value1" attribute2="attr-value2">content</element>

An XML document may start with an XML declaration, where the used XML version is identified (typically 1.0) as well as the character encoding. This is followed by the first element. This element is called root element. This will have a number of undetermined "children" elements.

 <?xml version="1.0" encoding="UTF-8"> 
 <library>  
    <!-- other items --> 
 </library> 

The example above shows an XML document which uses version 1.0, has UTF-8 encoding and has "library" as root element.

The XML specification defines an XML document as a text that is well-formed, i.e., it satisfies a list of syntax rules provided in the specification. This list is fairly lengthy, but some key points are:

• Only properly encoded legal Unicode characters are allowed.
• None of the special syntax characters such as "<" and "&" appear except when performing their markup-delineation roles.
• The begin, end, and empty-element tags that delimit the elements are correctly nested, with none missing and none overlapping.
• The element tags are case-sensitive; the beginning and end tags must match exactly.
• There is a single "root" element that contains all the other elements.

It is also possible to include comments in XML documents. These comments are not processed by applications and allow the inclusion of clarifications in the text document when deemed appropriate. Comments begin with the characters "<!-" and end with the characters "->".

Namespaces

The naming scheme that is described above is relatively limited, as it can lead to conflicts between elements. Consider the following two examples:

 <?xml version="1.0" encoding="UTF-8"> 
 <library>    
    <book author="J.R.R. Tolkien" language="English">The Lord of the Rings</book> 
    <book author="Molière" language="French">Tartuffe</book> 
  </library> 

 <?xml version="1.0" encoding="UTF-8"> 
 <xml-apps>    
    <tool name="xmlstarlet" language="c"/>
    <tool name="trang" language="java"/>
    <tool name="xmldiff" language="python"/>
 </xml-apps>    

The first document contains a representation of a collection of books. One of the attributes of each book is the language in which it is written. In the second document a small collection of XML applications is shown. In this case the language attribute is also used, but here it is referring to the programming language, which has a distinct meaning.

In principle, a human person would have little difficulty in distinguishing the use of the same attribute in different contexts. In order to facilitate the automatic processing of information by a machine, ambiguities must be avoided as much as possible

XML namespaces are used for providing uniquely named elements and attributes in an XML document. A namespace defines a grouping of concepts. Within a namespace, each concept is identified uniquely by its local name. Globally, each concept is identified uniquely by its local name plus the identifier of its namespace (or qualified name). With the earlier two examples, could thus be represented in the following way:

But how to ensure that there is no naming conflict at the namespace level? How to ensure, for example, that there are different interpretations of the namespace "literature"? The unique identification of a namespace is achieved with the use of an URI (or Unique Resource Identifier).

A namespace is identified by a URI (Uniform Resource Identifier), which as an example can look like this:


            http://www.acme.org/products


The fundamental idea of namespaces is that they incorporate an internet domain as part of its identifier. The use of namespaces allows the use of uniquely identified concepts. This is in an important aspect of the XBRL standard

Namespaces and prefixes

For readability purposes within an XML document, each full namespace identifier is replaced with prefixes. The association between prefixes and its corresponding namespaces are usually set at the root node. The association between prefixes and namespaces is done with a special attribute: xmlns:[prefix]="Namespace". This is illustrated with an example below:


    <?xml version="1.0" encoding="UTF-8">

    <bk:book-collection xmlns:bk="http://www.book.org">  

        <bk:book author="Norman Davies" language="English">Europe: A History</bk:book>

        <bk:book author="Homeros" language="Greek">Ilias</bk:book>

        <bk:book author="Jonathan Litell" language="French">Les Bienveillantes</bk:book>

    </bk:book-collection>

In the above example document, the element "bk:book" has "book" as local name, and "http://www.book.org" as namespace. This namespace uses "bk" as prefix.

UNICODE

Unicode is a standard for the representation of text expressed in most of the world's writing systems. Included in the Unicode representation are any character used in English, Spanish, Greek or any other western language, Chinese, Cyrillic, Hebrew, Arabic, Mongolian, Ethiopian and many others. Unicode was originally developed by a consortium of companies including Apple, Microsoft, IBM, Xerox, HP and Adobe in order to obtain a universal character set. It is now integrated in almost all modern operating systems as well as technological languages like XML, Java, or the Microsoft .Net Framework. Unicode can be implemented by different character encodings. One of the most commonly used encodings is UTF-8 (which is also compatible with the older ASCII code).

Thanks to the use of Unicode, XML allows the representation of text in any language.

XML Benefits

Throughout all the previous sections, the main elements of the XML syntax were introduced. XML is a markup language allowing the description of data structures in a global format.

The benefits of XML are among others:

• An easy readable language, by humans as well as by machines
• It is self-contained. An XML document not only describes the data values, but also its structure and the naming of the fields
• Its hierarchical structure allows the representation of virtually any data structure in a simple way
• It is platform-independent. XML documents can be used on any operating system and with any programming language
• The use of a strict syntax leads to an efficient processing by tools

XML is used at the core of all information exchange over the internet

XML Schema

An XML schema is a collection of definitions of a type of XML document. These definitions, called schema components, are generally about the structure and content of the document and are more specific that the XML syntax itself. The rules of an XML schema determine if an XML document can be considered "valid" according to that schema.

XML Schema Components

A schema defines the elements and attributes that make up an XML document. Elements and attributes are defined by stating their name as well as the possible values that they can take: their type. Attributes can only be of simple type, while elements can also be a complex type. A complex type allows the specification of an element's valid attributes and specifies complex content: elements that are composed of other elements. An element identified as a simple type cannot contain other elements.

In addition, other auxiliary components exist that, although not directly used in XML documents, can be used in a schema (or in other schemas extending the schema). Auxiliary components like types, groups of elements and groups of attributes.

Predefined types

One of the main features of an XML Schema is that a broad set of types are incorporated by default. These predefined types can in turn be divided into primitives and derivatives. Derived types are types whose definition is based on other types. Primitive types are the most basic types of the specification: its definition does not depend on other types.

Among the primitive types of the XML Schema are: the string type (a string of characters), the Boolean type (a type with only 2 logical values: true of false), the decimal type (a decimal number with an arbitrary precision), the duration type (represents an extension of time) and the time type (represents a time of the day).

Among the derived types of the XML Schema are: the normalizedString type (a string of characters which cannot contain carriage return, new line or tab), the positiveInteger type (integer number values larger than zero), the negativeInteger type (integer number values smaller than zero).

All these types are defined in the namespace of the XML Schema. As a result, the types will appear with their corresponding prefix (usually "xs"). For example: "xs:string", "xs:integer", …

Besides these predefined types, the XML Schema allows the creation of many more in order to meet large number of requirements.

Extension of simple types

Simple content types do not contain XML structures, their possible values can thus be expressed by a sequence of flat characters. Existing simple types can serve as a basis for the creation of new simple types or can be used in complex types.

These simple types are most commonly extended through the use of a restraining mechanism, via the declaration of properties (facets) that are imposing limits on the extended base type. For example, if the base type is xs:integer, minimum and maximum values can be defined in order to obtain a new type.

The properties that can be applied depend on the base that is extended. For example, the number of digits of a numeric type can be limited, a date can have a maximum value or a regular expression can be applied to a string.

Extension of types: attribute declaration

XML Schema allows the extension of attributes of extended types (simple types do not have any attributes). Conversely; the use of attributes can also be restricted.

Unlike elements, attributes cannot be repeated within the same element. The order in which they are declared in an element is also irrelevant. An XML Schema however, can control whether their use is mandatory, optional or prohibited.

Sometimes it is useful to allow attributes in XML documents that are defined in the scheme in advance. In this case, the component "xs:anyAttribute" is used. This component can be accompanied by a namespace attribute delimiting the number of attributes that can be included the namespace. This is a widely used technique XBRL that provides flexibility to the schema.

Extension of types: composition of elements

The extension of simple types is not sufficient to express the variety of data structures that can be represented with XML. In order to express nested element structures, we need to compose elements within the schema.

In the following example, the contents of root element "library" may contain the "book" or "audiocd". The elements of type "book" can in turn contain a pair of singles ("title" and "author"), not following a predetermined order. The elements of type "audiocd" contains a list of elements "track-title" and "track-duration" which contains the title information and its duration for each track on the CD:

  <?xml version="1.0" encoding="UTF-8">
  <library>	
     <book>
        <author>Hilary Mantel</author>
        <title>Wolf Hall</title>
     </book>
     <book>
        <title>Raghuram Rajan</title>
        <author>Fault Lines</author>
     </book>
     <audiocd album="Kind Of Blue">
        <track-title>So What</track-title>
        <track-duration>9</track-duration>
        <track-title>Freddie Freeloader</track-title><
        <track-duration>10</track-duration>
        <track-title>Blue In Green</track-title>
        <track-duration>5</track-duration><
     </audiocd>
  </library>

There are three mechanisms in an XML Schema that can be used to define compositional relationships: "sequence", "choice" and "all":

• Sequence: indicates that the content of a type is an ordered list of elements. In the example shown above, "audiocd" contains elements "track-title" and "track-duration"
• Choice: allows the choice of a component from an available list. In the above example, "library" can be expressed as a "choice" of the elements "book" and "audiocd".
• All: allows the creation of an unordered list or set. Unlike "sequence", "all" does not establish an order. In the above example, "book" consists of the elements "title" and "author" without a predetermined order.

This can be schematically represented in the following illustration:

XLink

This section is further being elaborated during the Workshop with the input from the other project teams.

Technological components used by XML and by XBRL

XPath

This section is further being elaborated during the Workshop with the input from the other project teams.

XSLT

This section is further being elaborated during the Workshop with the input from the other project teams.

XQuery

This section is further being elaborated during the Workshop with the input from the other project teams.

XBRL: Extensible Business Reporting Language

High level description

How to structure reporting data?

Before starting to explain XBRL, we would like to show via an example why the structuring of reported data can be useful. Reported financial data tend to be represented a table format. For example, the COREP Capital Adequacy table looks this:

<p-ca:EligibleCapital>215</p-ca:EligibleCapital>

Although this information is already quite structured, some contextual information is missing. Information like the currency of the amount:

<p-ca:EligibleCapital unitRef=”EUR”>215</p-ca:EligibleCapital>

And finally, the reporting period:

<p-ca:EligibleCapital unitRef=”EUR” contextRef=”2012-12-31”>215</p-ca:EligibleCapital>

The above example shows, in a nutshell, how XBRL allows to structure reporting data.

XBRL Introduction

XBRL, or eXtensible Business Reporting Language, is a communication standard developed in order to simplify the exchange of business and financial data.
XBRL normalises the format of data (via the use of XML techniques) en the validation of data (via XBRL taxonomies).

• Standard validation rules (mathematical and logical rules)
• The use of label linkbases (which allows multi-lingual taxonomies)
• The possibility to provide rendering
• Standard toolset which allow to work with XBRL

XBRL Taxonomies

This section is further being elaborated during the Workshop with the input from the other project teams.

Schemas

This section is further being elaborated during the Workshop with the input from the other project teams.

Linkbases

This section is further being elaborated during the Workshop with the input from the other project teams.

Extensibility

This section is further being elaborated during the Workshop with the input from the other project teams.

Taxonomy Extensions

Creating new relationships

Dimensions

This section is further being elaborated during the Workshop with the input from the other project teams.

The multidimensional model

XBRL dimensions

This section is further being elaborated during the Workshop with the input from the other project teams.

Formulas

This section is further being elaborated during the Workshop with the input from the other project teams.

XBRL Reporting: Instance documents

This section is further being elaborated during the Workshop with the input from the other project teams.

Validation of XBRL reports

This section is further being elaborated during the Workshop with the input from the other project teams.

Bibliography

[1] :xxx

[2] :xxx