« Microsoft FRx in Microsoft Dynamics GP Supports XBRL | Main | Updated Interactive Information Viewer »

Extention Points and Extensibility Rules

I was very fortunate to participate on the team that created the US GAAP Taxonomy Architecture.  Part of this is how could you not learn a lot discussing things with people like Walter Hamscher, David vun Kannon, Campbell Pryde, Paul Sappington and Cliff Binstock (i.e. the other co-authors of the architecture).

Part of what we discussed and to a degree addressed in the US GAAP Taxonomy or realized that we could not address was the notion of extension points and extensibility rules.  These topics had come up before, we drilled into them in greater detail in creating that architecture.  Here are general definitions of these two terms:

  • Extension points: logical points in a taxonomy where extension makes sense. These are generally technical in nature.
  • Extensibility rules: rules relating to where a taxonomy can be extended.  These are generally domain related and have to do with semantic meaning.

Looking at a taxonomy will help make the difference between the two make more sense.

Extension points

Take a look at the figure below (for more information see the "Calculation" metapattern on this page, number 3):


The green areas in the graphic are extension points. It makes sense to add new members to a domain, new periods, perhaps new units, and a new concept to the list of concepts which make up some total.  For example, on row 10 above, it makes sense to add the concept "Airplanes" to an extension taxonomy and put it in that precise location in an XBRL taxonomy which extends another taxonomy. Likewise, it makes NO sense to do things like add a member as a child of the concept "Land".  These extension points are incredibly helpful to understand for a lot of different reasons.  One reason is that software can be built to make creating or extending an XBRL taxonomy a whole lot easier if these extension points are known, they are consistent, and they are communicated in some manner by the creators of a base XBRL taxonomy which someone else is extending.  I could go on and on pointing out good and bad examples, but I think you probably see the point here.

In the US GAAP Taxonomy does have extension points, even though they are not formally communicated.  For example, see section 4.5 Implementing Tables in the US GAAP Taxonomy Architecture document (page 34).  Realizing this can help you to more easily create appropriate extension taxonomies.

Extensibility Rules

Extensibility rules are different from extension points, but they can be very helpful in another way.  So, as an example, imagine the US GAAP taxonomy. (Or you can go look at it here.)


Consider the concepts "Assets [Abstract]" and "Liabilities and Stockholders' Equity [Abstract]". From a financial reporting business domain perspective, what sense does it make to add a concept into the US GAAP Taxonomy as a sibling to those two concepts?  What would that concept be?  Well, it doesn't make sense in this particular case, a balance sheet has two things which when added up the totals should be the same: total assets and the total of liabilities and equity.  That is why it is called a balance sheet.

There are other areas of a taxonomy where this same thing is true, extensions make no sense. For example, a cash flow statement breaks cash flows into three categories:  operating, financing, and investing.  That is dictated by the financial reporting literature.

What other areas does it make sense to not allow extension or two allow extension?  Should users of the US GAAP Taxonomy be able to add balance sheet line items?  Well, there are actually pros and cons to that.  On the one hand, what line item would they possibly want to add?  If it should be there, it probably already exists in the US GAAP Taxonomy.  On the other hand, it was not the case that things like Goodwill or Intangible assets ever existed on anyone's balance sheet.  But, finance reporting standards evolved, and these line items are in the financial reporting rules.  Allowing extensions at certain points really relate to financial reporting standards, not XBRL.

Generally it is the case that the deeper you get into a tree of concepts, the higher the probability that extension should be allowed.  The higher you are in a tree of concepts, the less likelihood that you would need to extend the US GAAP Taxonomy.  There are plenty of excepts to this rule, but in generally, that statement is fairly accurate.

How do you communicate extension points and extensibility rules?

Well, there is no standard way to do that now and there is no formal articulation if this information. This holds true for the US GAAP Taxonomy, the IFRS taxonomy and any other taxonomy which is out there really.

But why WOULD you communicate this information? Well, say there were a way to automate the process of detecting when a user extended a taxonomy in the wrong area (violated an extension point) or that the put a net tree of concepts on the balance sheet as a sibling of assets and liabilities and equity (violated an extensibility rule) and you could point this out to the user.  Or even better, the application simply would not let you make that mistake.  Or how about if a wizard lead you through the process of extending or building a taxonomy because the wizard had knowledge of such extension points and extensibility rules.  Wouldn't that be helpful to users?  I think so.



PrintView Printer Friendly Version

EmailEmail Article to Friend

Reader Comments

There are no comments for this journal entry. To create a new comment, use the form below.

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
All HTML will be escaped. Hyperlinks will be created for URLs automatically.