Galexy Pty. Limited

Back to the index

Published on 14/08/2005

Introduction

The XBRL specification promises significant improvements in the efficiency with which the investor community can compare the financial statements being published by public companies. This promise is pretty central to adoption of the standard, yet some features of XBRL undermine its ability to deliver.

How normal XML specifications work

In most XML specifications, the meaning of an element or attribute can be discerned from its name and, if the specification has been clumsy, from the names of its ancestor elements.

For example an XML specification for capturing summary information about a book might lead to XML documents that look like the following:


<book xmlns="http://www.galexy.net/specification/">
  <author>Dr. Seuss</author>
  <title>Green Eggs and Ham</title>
</book>

The book element, the author element and the title element all would be given a meaning that is defined in the original specification book descriptions. The book element contains information about the author and the title. The author element contains the text value of the name of the author and the title element contains the text of the title.

Software that understanding this specification can process such documents relying on the usage of these book, author and title elements to remain consistent.

How XBRL specifications work

XBRL does not provide the same level of assurance to software. That may sound alarming to software developers that are considering supporting XBRL. It certainly concerns me. What is it about XBRL that undermines my confidence in the stability of the way that XML elements are used?

The problem is caused by the interaction of two features of XBRL.

First XBRL gives people an XML specification that they can use to document their own XML specifications. Huh? XML specifications for XML specifications? Bizarre right? Well, not really. XBRL is designed to cover such a broad range of business reporting that it was never feasible to just sit down and write a specification that covered the lot. Instead the XBRL specification delegates that duty to subject matter experts. It tells them how to use XML to write their own XML specification that covers their specific business reporting activity.

Why is that better than writing such a specific business reporting XML specification and ignoring XBRL? Some might say it isn't but others, myself included, argue that using XBRL to write your XML specification for business reporting ensures that you inherit broad range of software support for the new specification. Very nice, especially when you consider the challenges of getting software vendors to do custom development to support yet another wretched and poorly designed XML specification!

The second feature of XBRL that leads to the concerns being raised in this article is the ability to modify the XML specifications that have been developed by others. Going back to the book summary example, this feature gives specification authors the ability to add additional fields that describe books. For example, an extension to the original specification might be published that adds new elements to capture data about the number of pages in a book, the publisher, the publication date etc. That all sounds natural enough, and if the book summary specification were created intelligently enough, then that would be entirely possible without XBRL.

The source of inconsistencies

XBRL strays into dangerous territory, however, because it gives the creator of an extension specification the ability to change the meaning of the elements that were defined in the original specification. For example, if the book summary specification were expressed using XBRL the author element could be modified by the extension specification in a way that implied that it should only be used for reporting the last name of the author. More dastardly or incompetent writers of extension specifications could change the expected usage of the author element so that it was only appropriate for recording the weight of the book.

The ability to change specifications that have been written by others arises because the specifications are expressed in XML and because XBRL provides a syntax for expressing changes to the rules set out in those specifications without actually having to modify the original specification documents.

On a cranky day, I could create an extension of the specification that was created for financial reporting according to international accounting standards that modified the definitions of all the elements associated with balancesheet reporting. I could store the modifications on my own web server and make them available for broad usage. The unwitting or malevolent could then start reporting using that extension of the international accounting standards specification. The information that they would be disseminating would be wrapped in the tags defined by the international accounting standards specification for financial reporting but they would not be interpretable in the same way as reports that did not use my extension specification.

That becomes a serious problem. Because of it, XBRL-enabled software is in the unique position of not being able to rely on the consistency of usage of elements. Going back to the simple example of a book summary specification, in some XML documents the author element will contain the name of the author but in others they could contain anything.

I know of no other XML specification that is so unhelpful to software vendors. Instead of being able to parse an XML document and decide the treatment of an element by determining its name (and namespace), software must also explore the XBRL representation of the specification that the document is based upon.

Is this just a small technical problem or is it a serious threat to adoption? It significantly undermines the comparability of XBRL reports. Software that takes this concern seriously would only do comparisons of information across XBRL reports where the two reports are based on identical specifications. Any extension to the specification that is used by one report and not by the other would prevent the comparison from being conducted. One of the promises of XBRL is an increase in the amount of data that can be easily used to benchmark new financial reports. This promise starts to sound hollow as the consequences of this non-comparability sink in.

Considering the problem from a software design perspective, what about the implications for the very common process of mapping data from XBRL reports to databases. Most XML mappings to databases will map elements with the same name (and meaning) to the same database structure (a table or field or what have you). Those mappings are expressed in terms of the name (and namespace) of the elements being mapped. In XBRL, however, the element name and namespace are not sufficiently unique identifiers. That makes mapping processes much less straightforward.

Mitigating the problem

The majority of these concerns can be addressed if taxonomies do not make use of the XBRL features enabling relationships between concepts and from concepts to their documentation to be modified.

A second step in alleviating the problems associated with this feature of XBRL is to ensure that users of software can elect to ignore some or all of the relationship modifications specified in an extension taxonomy. Any XBRL software designed to meet the needs of the investor community should build in this kind of capability.