The key to making XBRL extensibility work correctly is the notion of "controlled flexibility". Having those extending XBRL-based taxonomies do so randomly can never work. Further, if one can make XBRL's extensibility serve you it seems that an entirely new class of software application is possible.
This is what I mean. First off it is important to understand the spectrum of flexibility. There are two extremes:
- Form: At one end of the spectrum you have a form which is an example of 100% control. With a form someone specifying some information they want to collect can "specify blanks" and then the user basically "fills in the blanks". Seems pretty straight forward. Now, if you think about this a little more you start to realize that you have another layer of control even with a form. For example, if you have a box that specifies an answer and you mean for the person filling out the form to enter "YES" or "NO"; but you don't control that appropriately and some people enter "MAYBE" then your data fields might be specified and users must fill in each field, but you will have data errors because what the user enters is not controlled appropriately. That is what something like XML Schema Data Types is all about, restricting what someone can enter into a form. Going further, if the form says the user needs to supply the value for "Assets" and also the value for "Liabilities and equity" and those two values must agree, but the form does not enforce that then you can get errors in your data. Something like XML Schema Data Types cannot enforce even that type of mathematical computation. So the reality is that even with a form where you "fill in the blanks" you still have to do other work to make sure that the quality of the information put into that form is intact.
- Freeform: At the other end of the spectrum you have "freeform". The definition of freeform provided by Google is "not conforming to a regular or formal structure or shape." An example of freeform is creating a Microsoft Word document such as a financial report. You have all sorts of issues controlling what a user does (i.e. the user has a lot of flexibility). From the perspective of the creator, they have a lot of flexibility to "fill out the form" however they see fit because there is basically little constraining what they create. From the perspective of a consumer of that information; while the information is richer because of the flexibly the user has in providing the information (i.e. they are not forced to fill in a form), using that information poses challenges because of the lack of structure.
But what if there were another way? What if there was something in between "form" and "freeform"? Would all information fit into that middle category? No. Are there advantages of having a middle category? I propose that there is.
Let me repeat the definition of freeform: not conforming to a regular or formal structure or shape.
First off, does something like XBRL have a "regular or formal shape"? Most people would say no, but they would be incorrect. XBRL does have a formal shape. If you look at the XBRL Abstract Model 2.0 you can see that formal shape. If you tried to map that XBRL Abstract Model 2.0 to things that exist in the real world you can also see that shape. I mapped the XBRL Abstract Model 2.0 to my model of a financial report expressed in the Financial Report Semantics and Dynamics Theory.
And I went even a step further. I tested 100% of SEC XBRL financial filings (all 10-Ks) to see if they fit into that model. Guess what: 99.99% of all representation or model structures and 95.8% of all such XBRL-based filings fit into that structure.
And so, XBRL-based business reports "fit" into a regular, formal structure/shape. But is that enough to capture high quality information? Well, first understand that XBRL uses XML Schema Data Types to enforce field level data quality. XBRL uses XML Schema Data Types. You can use any of the data type restrictions to provide things like enumerated lists of values such as "YES" or "NO", very powerful. XBRL also uses XBRL calculations and the more powerful XBRL Formulas to enforce mathematical computations. So those two pieces mentioned above are covered.
Is that enough? No.
Proof that that is not enough is the quality of today's SEC XBRL financial filings themselves. They don't have the quality they need. So what is missing? Well, here are specific things which are missing:
- Extension points: Where an XBRL taxonomy can and cannot be extended is not communicated in either the US GAAP XBRL Taxonomy or SEC Edgar Filer Manual (EFM) rules. For example, financial statements have "Assets" and they have "Liabilities and equity". Should SEC filers be allowed to create an extension at this level in the US GAAP XBRL Taxonomy, creating another category of financial information? Probably not. And they generally don't because the financial reporting rules are pretty clear that you cannot. But, a mechanism which controls where an XBRL taxonomy can be extended is not provided. But what if such a mechanism to control extension points was provided?
- Extension rules: How to properly extend the US GAAP XBRL Taxonomy is not controlled nearly enough. An example of a seemingly good control mechanism can be a good example of the possibilities. First of, suppose that every report element in the US GAAP XBRL Taxonomy were categorized into one of the 10 elements of a financial statement defined by the FASB in the US GAAP Conceptual framework: Assets, Liabilities, Equity, Revenues, Expenses, etc. Next, when an extension is created, the filer creating the extension must SPECIFICALLY associate that extension with one of those 10 core elements of a financial report? That is an example of control. This can be achieved using XBRL definition relations. Now, that list is not sufficient in my view, I use those 10 elements of a financial statement to make a point. Controlling extension rules is possible.
- Unchangeable concept framework: Imagine that a report had some sort of a "skeleton" or framework which every report followed. The fundamental accounting concepts is that framework for financial reports. Testing of SEC XBRL financial filings shows that financial reports follow this framework 98% of the time. It makes no sense for a filer to change the category of a concept. For example, if the US GAAP XBRL Taxonomy defined a concept to be an "Asset" and a filers used that concept on the cash flow statement, that would make no sense. It would likewise make no sense for a filer to change the relations between two of these concept categories. For example, "Assets = Current Assets + Noncurrent Assets"; why would a filer need to change that relation? Now a filer might not have noncurrent assets because they provide an unclassified balance sheet. That does not break the rule, that rule would not apply to them. If a filer did have a classified balance sheet but did not report noncurrrent assets, that would likewise not break this rule because noncurrent assets can always be imputed by: Noncurrent assets = Assets - Current assets. (If a filer does provide a classified balance sheet, they will ALWAYS provide assets and they will ALWAYS provide current assets. And so this set of unchangeable concepts and unchangeable relations between concepts controls extensibility by making sure SEC filers representing their information don't break that framework.
- Leverage common relation patterns: The elements which make up the "regular or formal structure or shape" have common patterns. These common patterns can be leveraged for many, many purposes. One of these purposes is managing extensibility. This is what I mean. First, there are two primary categories of relation patterns. The first are "member arrangement patterns" or "whole-part" type relations. The second are concept arrangement patterns: roll up, roll forward, adjustment, variance, hierarchy, etc. (For the back of your mind, another use of these common relation patterns is rendering of information in human-readable form.) Again, controlling extensions can be achieve by specifying the patterns that extended information fits into. For example, it makes little sense to have a roll up which has no total or two totals.
It might be the case that I am missing something, but I am pretty certain of two things: (1) If a system is not controlling the things mentioned above problems will occur which relate to how different creators of information extend an XBRL taxonomy; (2) if the things above are specified appropriately, it will control the flexibility offered to users of the system to employ and that controlled flexibility offers very useful between what is offered by a "form" and what is offered by "freeform" information gathering systems.
While I am providing SEC XBRL financial filings as an example of how controlled flexibility can make extensibility work for financial reporting, what I am showing is more generally useful. Perhaps a taxonomy has different extension points, different extensibility rules, a different unchangeable concept framework, and different common relations patterns; it is the creation and management of these which will make extensibility work for other business reporting domains.
Finally, the notion of "extension points", "extension rules" and "patterns" are not my idea. These ideas were origionally discussed as a group of us created the US GAAP XBRL Taxonomy Architecture. That document talks about the notion of "diciplined extensions".
For more information see this blog post.