XBRL-based structured digital financial reporting - Blog: Digital Financial Reporting (using XBRL)

This is a series of posts where I am providing information relating to figuring out what the best data format to use and why. Basically, when is XML better, when is XBRL better, and when is RDF/OWL better.

In another blog post I looked at different information exchange formats, among those formats was XML. In yet another blog post I looked at different forms of XML.

In this blog post I look at many different forms of XBRL. What I mean by different forms of XBRL is using different XBRL features to model the exact same meaning. What I did was use a simple data set, the same data set I used to look at different data exchange formats and the different forms of XML. That is, I used population data for the U.S. States. A rendering of this data set can be seen in this PDF.

(I became well exposed to issues relating to different forms of XML when working as part of the teams creating the US GAAP Taxonomy Architecture and the US GAAP Taxonomy. Rene van Egmond and I summarized what we saw in the following document, How a Simpler XBRL can Make a Better XBRL. This work resulted in something Rene, myself, and a few others created called XBRLS trying to overcome the issues we noticed.)

The data exists in a Microsoft Access database. I constructed the different taxonomies I would need to represent the data using an off-the-shelf taxonomy creation and validation tool. I generated the XBRL instances from within the Microsoft Access database. Basically, this shows the exact same meaning being modeled using different approaches; each automatically generated from exactly the same relational database information.

Here are the different approaches. For each approach an XBRL instance, the XBRL taxonomy, the validation of the computations, and a rendering of the presentation linkbase of the taxonomy is shown so you can get a quick sense of the XBRL taxonomy structure. You can load the instance and taxonomy within an XBRL tool to better look at them if you wish. (This discussion is more for business people with some technical understanding of XML and XBRL or at least willing to dig into this a little. So, you will need to look at some XML to truly grasp these issues. I have made some renderings of things available, but the good information is in the XML/XBRL files. Sorry, you cannot understand these things without getting your hands a little dirty.):

Model using XBRL Tuples: (XBRL instance, XBRL taxonomy, Computations validation, Taxonomy rendering) In this taxonomy you have only two concepts (the name of the state and the population). Those two concepts are wrapped inside a tuple. You can then use that tuple to express the states. The down side is that you can put in any state, meaning you cannot control which state name the user of the taxonomy adds. You could add an enumerated list to the name concept, but then you could not extend the list should a new state me needed. Note that there is no way to arrange tuples into a hierarchy, for example if you wanted to summarize the states by region. You cannot change the tuple, it is hard coded with only those two concepts. If you wanted to add say the state bird to the tuple, you would have to create a new tuple, the tuples are not extensible. That is why XBRL does not use the content models (that is what a tuple is, a content model).
Model using XBRL Items: (XBRL instance, XBRL taxonomy, Computations validation, Taxonomy rendering) In this approach, each state is its own concept. That concept contains the value for the population. The downside is that you have 50 concepts. You cannot use the wrong value like you could using a tuple. With items, they fact values can be arranged into a hierarchy by region if you desire. You can easily add new items. There is no content model to get in the way. If you wanted to add a state bird to the information set, you would have to add 50 additional concepts, one per state.
Model using XBRL Dimensions: (XBRL instance, XBRL taxonomy, Computations validation, Taxonomy rendering) In this approach, each state has its own concept, but the state is a measure (a value of the "State" dimension). There is an additional concept "Population". The state dimension is used to describe the fact value expressed in the population concept, which helps to distinguish the which state the population relates to. This approach is extensible. In fact, when you want to add another data point for say the state bird, you have to only add one new concept, not 50. You can also easily express the states in a hierarchy, say by region. (In this approach hypercubes are used to hook measures with facts using the multidimensional model.)

There are two very important points you should keep in the back of your mind when it comes to figuring out which approach to use. First, the approach you choose needs to serve your needs. Second, when extension is allowed to the XBRL used within your system you have to control which approach those extending the XBRL taxonomy can use because if you don't they could use any approach (i.e. different users can extend using different approaches, leading to inconsistencies).

Looking at these three approaches to modeling XBRL has nothing to do with which modeling approach is better: tuples, items, or XBRL Dimensions. The point here is that when multiple approaches exist you need to guide the user to what approach you want them to use if you desire consistency between the users within your system.

Each approach has its pros and cons; none is perfect. You will want to pick the modeling approach which best serves your needs. This is more about expressing your meaning consistently and accurately, the syntax matters little, if at all really.