A “Flat XML” Interface For XBRL

Apply here payday loans 100% secure

In my experience, software developers and IT professionals in general that face the requirement to convert data  from their business software packages to XBRL instance documents, or to import XBRL data into their back-end systems, frequently seek a way to convert XBRL to an intermediate, more familiar XML format.

The XBRL processing model is “different” because it cannot be understood in a traditional top-down way, since part of the information relevant for each data point is found in separate XML fragments (contexts/units) that are linked to the same data point through an attribute, and in linkbases. A hierarchical, “flat” XML representation of the same data where all the information can be found grouped together is perceived as a simpler interface to move XBRL data in and out of applications.

This is partially due to the fact that applications are generally not yet capable of creating/consuming XBRL, and enabling them to do so requires planning and might take a while due not only to technical constraints but also to organizational and other internal constraints. An XML interface can be a great way to meet the requirement to process XBRL data without having to rush in modifying the systems, to get familiar with the technology and in general to facilitate a smoother transition. 

Whatever the reason, the consequence is that many are building from scratch their own proprietary XML interface to XBRL. But one solution that is standardized, free and ready to use already exists – XBRL’s Global Ledger taxonomy (XBRL GL).

XBRL GL has been designed to be the bridge between source/target applications and XBRL. Its architecture is different from  the typical XBRL taxonomy, and it makes no direct use of XBRL specific features like context, units, linkbases, dimensions – no XBRL tooling is necessary to implement it, and normal XML processors do the job. Its Summary Reporting Contextual Data (SRCD) module  has what is necessary to convert to and from XBRL taxonomies/instances, including dimensional ones, and it provides that functionality via a flat set of XML elements optimized for the purpose.

These features provide XBRL GL with the capability of linking data from source (or in target) applications to one or more XBRL taxonomies; this means, for instance, that it can support alternative, simpler and more powerful ways to drive the creation of end reports in XBRL using data at the level of granularity required by the specific taxonomy to be used. Or, that it allows to drill down from a summarized XBRL report, say an SEC filing, to the underlying detailed data that it was created from, and even automatically reconcile it with a different “view” of the same information – say an IFRS instance document. Or, that it supports the use case just described: providing a complete, simple to implement and optimized XML interface to XBRL data.

XBRL GL has been built by XBRL International, with years of collaborative work within the community, and incorporates the expertise of many just for the purpose to come up with a standardized way to easily bridge from/to XBRL data. Any effort to build a “proprietary” XML schema from scratch for the same purpose would, in the best case scenario, reproduce the same set of elements, and in the worse would not take into consideration all the variables that are necessary to link to XBRL taxonomies/instances in a scalable, solution-independent way. XBRL GL has been built by people that know the XBRL Specification very well, and the result of their work is available for free.

Here is a summary of the distinctives that XBRL GL offers:

  1. It is a tested semantic representation of information summarized and detailed, with a specific module (SRCD) that has all the elements required to link to end reporting XBRL taxonomies, dimensional or not. A “built from scratch” solution would just reinvent the wheel; 
  2. It provides flexibility to use formats different from XML: the use of the semantics of XBRL GL through different technologies has already been explored, and XBRL GL is available in CSV, ASCII fixed format and relational databases versions; 
  3. It is very XML/XML Schema friendly and it is commonly implemented without specific XBRL tooling; 
  4. At the same time, it is also XBRL. Using it as a bridge to back-ends would be a very good first step towards the actual embedding of XBRL capabilities, both technically and in terms of facilitating the learning process of IT professionals; 
  5. Coming up with a new “simpler” proprietary XML format may seem straightforward, but it can easily lead to “hard code” a solution based on the way in which the XBRL taxonomy of interest is structured at the moment in which the XML interface is designed. This would result in change management issues as the XBRL taxonomy evolves – and as other taxonomies become of interest. It would take much more effort to make the proprietary solution scalable and fit to represent all the features that are available in the XBRL Specification, something that XBRL GL is ready for — now.

The fact that XBRL GL and its SRCD module are generic and standardized and not developed for a specific use case means that components and tools are already available to process them, while a proprietary XML interface to XBRL would require the creation/maintenance of tools and/or stylesheets for the purpose.

Check the CodeXBRL website, where web-based XBRL GL/SRCD utilities are available and free to use. Currently, only the conversion from an XBRL instance of your choice to the corresponding XBRL GL representation is available – the XBRL to back-ends XML interface that I have described in this post. The XBRL GL to XBRL FR conversion utility is coming soon, and other features to navigate and process XBRL GL data will be published in the very near future. The .NET and Java source code used in CodeXBRL as well as simple desktop applications to test it  is also available as open source in the CodeXBRL SourceForge project.

If you are interested, you may want to subscribe to the RSS feed of the project. Additional functionalities will be added constantly and this is probably the best way for you to be notified when they are released.


related post

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>