Knowledge is linked information. Information that cannot be connected with other current information or information stored in the past is useless for its consumers. But, previous research has shown that XBRL on an XML basis lacks an idea for linkage of financial information. Currently there is an ongoing discussion in the XBRL community about expanding the technical basis of XBRL from XML to more semantic-web compatible formats like JSON. This article introduces the pros and cons of switching the technical basis of XBRL from XML to JSON regarding linkage of financial information. It defines and explains the concepts of intra-linkage (within the same domain / taxonomy-framework / namespace) and inter-linkage (between different domains / taxonomy-frameworks / namespaces). At the end there is an indication that the implementation of XBRL-JSON comes at a high price with even less beneficial impact on (intra-)linkage of information compared to XBRL-XML. The contribution of this paper to the XBRL community consists of increasing awareness for the linkage problems of XBRL inherited by the underlying data formats (XML, JSON), explaining the importance of intra-linkage over interlinkage and providing some thoughts how to cope with the intra-linkage problem.
Due to the several knowledge frameworks such as the knowledge-stairway by North
[
Imagine a financial supervisory authority receiving a regulatory report from a
supervised company containing the figure 1.000.000,00€. First this is just data but by its
surrounding context, e.g. as part of a balance sheet, this figure is assigned to a
meaning. This meaning can be ‘eligible own funds’ for instance. By adding a meaning the
figure evolves to information. By linking this information to other current information
(e.g. a ‘minimum solvency capital requirement’ (mcr) of 800.000,00€) and
information from the past (e.g. ‘eligible own funds’ (eof) of 1.500.000,00€ and an mcr of
800.000,00€ in the previous year) the responsible supervisor can assess a decrease of
the eof/mcr-ratio from 187,5% to 125,0%. He now knows that there is a tendency that
this company might get in trouble to fulfill its eof/mcr-ratio in the next year.
Contacting the company and investigating the cause could be a wise and sustainable decision
in this situation.
Unfortunately XBRL on the technical basis of XML (XBRL-XML) does not natively
support the linkage of filings neither from different financial entities nor from
different reporting periods. [
First, this is because integration of XBRL-XML-formatted filings by Extract,
Transform, Load (ETL) regularly leads to loss of meta-data about the quality and
layout of a filing. [
Second, even if the integration of XBRL-XML-formatted financial information is basically possible it still remains an effortful bespoke ETL- and Data-Warehousesolution which does not follow a standardized approach.
Recently JavaScript Object Notation (JSON) was presented by XBRL II as one
means to ease integration and ETL. [
The next section will take a closer look on the reasons for a shift from XBRLXML to XBRL on the basis of JSON (XBRL-JSON) and explain some characteristics of the latter. 2
JSON compared to XML is a lightweight data format which needs less overhead to describe financial items. While a primary item in XBRL-XML consists of a fact and a related context tag an object in XBRL-JSON is a tighter, smaller chunk of information. The following listings are an exemplary juxtaposition of a code fragment in JSON and XML respectively for the same financial concept.
Listing 1 [
<xbrli:identifier scheme="http://standards.iso.org/iso/17442">12345</xbrli: identifier> </xbrli:entity> <xbrli:period> <xbrli:startDate>2015-01-01</xbrli:startDate> <xbrli:endDate>2015-12-31</xbrli:endDate> </xbrli:period> </xbrli:contextRef> <xbrli:unit id="u1">
<xbrli:measure>iso4217:USD</xbrli:measure> </xbrli:unit> <gaap:Profit contextRef="c1" unitRef="u1" decimals="-6" >12000000 </gaap:Profit>
Listing 2 [
The <context>- and <unit>-tag of the XML representation could be re-used but it is still obvious that much shorter and due to the simple enumeration of key-value-pairs easy to understand.
The tree-structure of an XBRL-XML document has to be parsed by the software
which processes it to map the content of XML-tags to corresponding data types used
by the software. [
Moreover, beyond pure JSON which is in discussion for XBRL a W3C
recommendation called “JSON-LD 1.0”, whereas LD stands for Linked Data, was published
in 2014. JSON-LD is deemed to support interconnection of information from
different namespaces by using context-tags to describe the domain to which a fact belongs.
JSON-LD aims to ease interconnection of heterogeneous information. [
This section introduces the concepts of inter- and intra-linkage of XBRL-formatted financial information. It also argues about the impact of the underlying data format, XML or JSON, on each kind of linkage.
Inter-linkage is about the interconnection of information which stems from different domains, taxonomy-frameworks or namespaces. When inter-linking information the receiver may not expect information to be structured in the same way using the same data model and the same semantic expressions. That is because the context of information is different and different facts might have the same name or the other way around. The dictionary of information is regularly very different.
XBRL-XML, at least in some taxonomy-frameworks, considers some aspects of
inter-linkage by design, but only very limited. For example in reporting frameworks
like Solvency II concepts of the CoRep and FinRep taxonomies have been re-used.
[
XBRL-JSON on the other hand provides a much less complex architecture. There
are, for example, no XLink-interdependencies and schema imports in JSON (in
contrast to an XML-formatted Discoverable Taxonomy Set (DTS)). [
In contrast to inter-linkage, intra-linkage is about the interconnection of information within the same domain/taxonomy-framework/namespace. Main use-cases for intra-linkage are, for example, the integration of filings from several financial entities or the integration of filings from one and the same financial entity for several reporting periods. This integration of financial filings is a mandatory task for financial supervisory authorities when they want to be able to conduct benchmarking among supervised companies and variation analyses about one company over time. In the context of intra-linkage the dictionary of information among reporting entities is one and the same.
Related to intra-linkage of financial information XBRL-XML allows for deriving
the data model of the target database (e.g. as component of a data warehouse, DWH)
from the XBRL-taxonomy and its included XML-schema-files. For example, the
metrics used and defined in the taxonomy can be seen as the role model for facts of a
DWH data model and DWH dimensions can be derived from the dimensions
incorporated in the taxonomy due to dimension specification. [
In the context of intra-linkage XBRL-JSON seems less powerful. Indeed, JSON is
easy to process during ETL as it is built upon commonly understandable data types
(integer, string etc.) and objects (arrays, key/value-maps etc.). But the simplicity, light
weight and flexibility of JSON comes at the price of less assurance of structure and
content of filings. A receiver of information, e.g. a financial supervisory authority,
may no longer rely on the same data model or content respectively used and sent by
company A and company B(, C etc.). Because of the absence of strict schemas and
validation rules content and quality of filings will be less uniform. In fact,
XBRLJSON formatted information can still be loaded to analytical Warehouses technically
easy, especially when the target are document-oriented databases which can reflect
the submitted data almost one-to-one. [
To sum up, the expectable pros and cons of using XML or respectively JSON as underlying data format for XBRL are opposed in a tabular view. The table includes a differentiation between inter- and intra-linkage perspectives as well.
1. Usage of contexts (in JSONLD specification for Linked Data) 2. Easy to understand due to common data types 3. Easy to load and consolidate due to document-oriented databases and flexible (noSQL)data-models 1. Semantic context information only provided when using JSON-LD specification
Linkage
Pros data model 2. No schema-based dictionary 2. Each data model/XML schema depends on a dedicated shredding and
ETL process 1. Given Data Model in- 1. Lightweight ETL process cluding dimensions al- due to simple data model lows taxonomy-driven 2. Modeling of an integrated derivation of analytical target-data-model needless data models due to potential use of docu2. Consolidation of infor- ment-oriented databases mation is less errorprone since business validations guarantee a minimum-standard for data quality 3. Business validations (formulae linkbase) and rendering instructions (table linkbase) can potentially be used in a DWH/BI-Solution if they could be stored and processed 4. XML-based ETL processes already implemented on receivers’ sides 1. Taxonomical meta-data for business validations and rendering instructions are at risk to get lost during ETL process 1. Taxonomical meta-data for business validations and rendering instructions not provided in uniform technical syntax at all, thus less data quality expectable and, as to that, nothing to transfer to a
DWH/BI-Solution 2. Minimum content and comparability of filings cannot be assured due to lack of a strict model and schema files 3. Effort to switch from proven
XML-based validation and ETL processes on receivers’ side The number and character of pros and cons slightly indicates that XBRL-JSON might have an overall advantage over XBRL-XML related to inter-linkage of information, especially due simplicity and its flexibility as it is not bound to one single strict data model and schemas.
On the other hand, the advantage of flexibility vanishes if intra-linkage is required. The received information is based on the same reporting framework, thus it is adequate and sensible to use a uniform strict data model to assure consistency between filings (among entities and among time) and a certain level of data quality. Moreover, XBRL-XML supports application of business validations and rendering of filings within the borders of a reporting framework. There is no reason obvious why one should give up this additional information in advance. Hence XBRL-XML is clearly recommended for intra-linkage of financial filings.
And finally, before mashing up financial information from several heterogeneous sources, it seems logical that information from one and the same source (e.g. companies reporting to a financial supervisory authority under the same reporting framework) should be properly integrated first (including all the useful meta-data which XBRL currently provides). Hence, at the moment and in the perspective of information integration and knowledge management, no compulsory need for switching the basis of XBRL from XML to JSON is given. There may be plenty good reasons for other purposes but these potential purposes are not in the scope of this paper. This paper is about integration of financial information to gain better knowledge and for this purpose XBRL-XML is the best (and cheapest because already implemented) tool we, the XBRL community, currently have. 4
The goal of this paper and contribution to the XBRL community is to stress the importance of integration of financial information among financial entities and over time. Due to several knowledge frameworks only integrated information leads to knowledge which is, in the context of financial supervisory authorities, the prerequisite for sophisticated and sensible supervisory action. The main question of this paper is if the current discussion about XBRL-JSON can contribute to improve the information integration capabilities of XBRL. Therefore, in its analytical section the study has introduced and explained two perspectives of information integration (interlinkage versus intra-linkage) and has argued which underlying data format, XML or JSON, is better for each perspective. It has turned out that JSON has a slight advantage in terms of inter-linkage, while it is vice-versa in terms of inter-linkage. Since intra-linkage (linkage of information within the same reporting framework) is deemed the primary task (before mashing information up with data from other, foreign sources), XBRL-XML is the winner of this comparison and this paper strongly advises to keep and/or improve XBRL-XML for the purpose of information integration.
Such an improvement could, for example, be to retain some relevant meta-data
(like business validations or rendering instructions) through ETL processes and to
potentially allow for this meta-data to be applied to more than one single file (e.g.
beyond the borders of one report per one entity per one period). This could perhaps be
achieved, if databases regularly used for data-warehouses could natively understand
XBRL business validations and BI-Tools could natively understand XBRL rendering
instructions “out of the box” (without depending on additional tools of bespoke ETL
solutions). But, this is just an outlook and a task for further research. [
Nevertheless, it is to say that, in this paper, XBRL-JSON has been examined only with regard to integration of financial information. It is explicitly not the intention of this paper to lessen the potential benefits of JSON for other purposes in general. References