Making XBRL Easier
In order to achieve widespread adoption, standards need to be stable. XBRL v2.1 has been stable for over 12 years, which is a long time even for the slow-moving standards setting world.
This is partly due to XBRL v2.1 being designed in a way that has allowed us to address new business requirements by adding new modules rather through modifications to the original specification. It is also a reflection of the fact that the primary drivers of XBRL adoption to date, government regulators, are naturally wary of adopting a standard which is anything other than stable and established.
That stability remains an important part of our consortium, but the time has come to develop additional ways to allow people to use XBRL, in somewhat simpler ways.
To do so, we are kicking off a new initiative, called the OIM, or Open Information Model, within the consortium and asking our members to participate in, and bring their ideas, to a new Working Group. The OIM is aimed at providing standardised ways to deal with XBRL using alternative syntax. The first goal of the OIM is to make it simpler to deal with republished XBRL data – that is, XBRL information that has been validated and accepted as good.
In order to achieve this, as well as later goals, the Working Group will first be building on the work completed in the XBRL Abstract Model, to solve the problem associated with separating current XBRL syntax (in XML) from XBRL semantics (or meaning).
Separating syntax from semantics
At the heart of this problem is that XBRL is defined in terms of its syntax, rather than the information (or meaning) represented by an XBRL report. For as long as everything we do with XBRL is in XML this distinction is largely academic, but as soon as you start to work with XBRL data in other formats, such as a database or a different syntax, you’re forced to start making judgement calls about what constitutes business data and what is just syntactic detail.
To give an example, should the IDs used to link facts to their contexts be thought of as business information? The acid test is to ask whether two documents that differ only in the context IDs used are equivalent. I think most people would agree that they are, yet the lack of clarity on this point has lead in some cases to users being asked to review context ID values, exposing what should be syntactic technical details to business users.
This is a trivial example, but there are many more, and some of them are less clear-cut. The solution here is to define the standardised XBRL model: an authoritative definition of the information represented by an XBRL report.
What’s in a model?
Modelling is a topic which can very quickly get bogged down in complexity, but fundamentally what we need from an XBRL model is very simple: it is a statement of the business information that may be understood from an XBRL document and its accompanying taxonomy. To put it another way, any two documents which are the same information under our model are deemed to be equivalent, and any differences in their representation (for example, differing context IDs) are just that: irrelevant syntactic detail.
Once we have such a model, it becomes easy to convert XBRL data into different formats without losing information that another user might consider important.
The Open Information Model
As I mentioned, we have just announced a new initiative, under the title of the “Open Information Model” (OIM). The goal of this effort is to produce a syntax-independent model for XBRL with a focus on two closely related goals: simplification, and the ability to transform into non-XML syntaxes.
The key to achieving both of these is modelling XBRL as it should be, rather than exactly as it is now. If we attempt to capture everything that is currently possible in XBRL and its accompanying specifications, we will end up replicating all of the syntactic oddities that have accumulated over the years since XBRL v2.1 was declared stable. The goal is to come up with a clean, logical model that can be represented using current XBRL syntax, but which can also be transformed readily into other formats.
To give a simple, concrete example: XBRL v2.1 allows users to include arbitrary, unconstrained fragments of XML within certain elements, such as segment and scenario. Attempting to retain this in our model not only adds complexity, but such arbitrary XML fragments will not fit cleanly into most other syntaxes.
In order to test the model and provide a concrete goal, the deliverables of the OIM will include a mapping from the OIM to JSON, a goal which is intended to have practical benefit in allowing XBRL data collectors to republish their data in a manner that is easier for analysts and other users to consume.
The OIM will draw on the outputs of previous modelling efforts, including the XBRL Abstract Model PWD, and the XBRL Infoset PWD, but with a strong focus on simplification in order to achieve clean representations in multiple syntaxes.
We are actively seeking volunteers to participate in the new Open Information Model Working Group. If you would like to get involved please see the formal announcement here or contact email@example.com.