Better Support for Role Type Discovery and Calculation Link Roles Coming in Next CTP

In a previous post, I related a frustration from a Gepsio user regarding the difficulty in discovering role types in calculation linkbases. I recently checked in a set of changes that make the user’s scenario much for straightforward; in fact, the next CTP will allow the use case to be accomplished with a few lines of code.

One of the design changes was to make it easy to return Gepsio RoleType objects for a given XBRL role label. This design changed added methods called GetRoleType() to the XbrlDocument, XbrlFragment, and XbrlSchema classes. The other design change is to add a property called RoleUri to the CalculationLink class (which, as mentioned in the previous post, was missing) and to also add a method called GetCalculationLink() to the XbrlDocument, XbrlFragment, XbrlSchema, and LinkbaseDocument classes. With all of this in place, the code for the use case is now down to a few lines:

var NewXbrlDocument = new XbrlDocument();
var balanceSheetRoleType = NewXbrlDocument.GetRoleType("BalanceSheet");
var balanceSheetCalculationLink = NewXbrlDocument.GetCalculationLink(balanceSheetRoleType);

This functionality will be available in the next CTP.

Discovering Relationships between Revenue Facts

I recently came across the following XBRL question on Stack Overflow:

How can we know beforehand the number of names that can a business fact in XBRL receive on XBRL instance documents?

For example if we want to find the Revenue of companies by looking into XBRL instances for this business fact alone we can meet different names for this same fact as:




The target is to find out a finite amount of names that every business fact can receive and then for every business fact loop all these names until we fine the one that is in the instance document.

is there a lexicon if you will where it has all of these names into one file? This is a theoretical question but requires technical expertise.

And most importantly since there are many lookalike names for a business fact can a name in one XBRL instance mean one fact and on the other instance document mean another business fact?

After a bit of prodding, I discovered that the root question was “why is revenue represented by many different facts in the taxonomy?”

The elements are different because they refer to different things. The SalesRevenueNet element is defined as follows:

Total revenue from sale of goods and services rendered during the reporting period, in the normal course of business, reduced by sales returns and allowances, and sales discounts.

The Revenues element is defined as follows:

Amount of revenue recognized from goods sold, services rendered, insurance premiums, or other activities that constitute an earning process. Includes, but is not limited to, investment and interest income before deduction of interest expense when recognized as a component of revenue, and sales and trading gain (loss).

(I can’t find an element in the US GAAP taxonomy named SalesRevenue, so I can’t comment on that one.)

The SalesRevenueNet element is a value summed from other elements, including Sales Revenue, Goods, Net, Shipping and Handling Revenue, Sales Revenue, Shipping, Net, and several other elements. The SalesRevenueNet element is, in turn, an item in the summation of the Revenues element, which also includes elements such as Financial Services Revenue. In algebraic terms, the calculation of the SalesRevenueNet item looks like this:

SalesRevenueNet = SalesRevenueGoodsNet + ShippingAndHandlingRevenue + ... 

The calculation of the Revenue item looks like this:

Revenue = SalesRevenueNet + FinancialServicesRevenue 

The XBRL Taxonomy Viewer is a helpful tool for providing a better view into some of these relationships. To see more, start the Taxonomy Viewer and do the following:

  1. When the XBRL Taxonomy Viewer is first launched, an “Open Taxonomy” dialog will appear. The dialog will contain a tree view listing all of the taxonomies supported by the viewer. The root of the tree is a folder labeled “XBRL US Public”, and one of the nodes beneath the root node is called “SEC Approved Taxonomies”.
  2. Expand the “SEC Approved Taxonomies” node, if it is not already expanded. Several child nodes will be listed, and one of the child nodes is labeled “2013 US GAAP Taxonomy (2013-01-31)”.
  3. Expand the “2013 US GAAP Taxonomy (2013-01-31)” node, if it is not already expanded. Several child nodes will be listed, and one of the child nodes is labeled “All Taxonomies”.
  4. Select the “All Taxonomies” node and click the “Open” button. The site will refresh with information about the taxonomy you have selected.
  5. At the bottom of the page, in the “Search” tab of the “Tools” pane, type in the name of an element (such as SalesRevenueNet) and click the “Search” button.
  6. Click on the element name in the Search Results list. After a bit of time, the pane in the upper right will refresh with information about the element you selected, such as labels, references, and calculation information.

Better Validation Coming for Footnote Arcs and Arc Roles

The Sep 2013 CTP of Gepsio enforces an XBRL validation rule that requires footnote arcs move from an item or tuple locators to footnotes. However, Test 301.17 in the XBRL-CONF-CR5-2012-01-24 Conformance Suite is a valid test that challenges Gepsio’s initial implementation of this rule.

Test 301.17 contains several footnote arcs. Most arc from an item locator to a footnote:

<link:footnoteArc xlink:type="arc" xlink:arcrole="" xlink:from="item1loc" xlink:to="footnote1" order="1.0"/> 

However, it also contains arcs that link from a footnote to another footnote:

<link:footnoteArc xlink:type="arc" xlink:arcrole="" xlink:from="footnote1" xlink:to="footnote2" order="1.0"/> 

The Sep 2013 CTP of Gepsio incorrectly fails this test, because it ensures that all footnote arcs come from a fact and logs a validation error if that is not the case. Since the second footnote arc shown above arcs not from an item locator, but from a footnote, a validation error is logged. This is a mistake on Gepsio’s part.

A careful reading of the XBRL Specification offers this information: @xlink:arcrole attributes on <footnoteArc> elements

The value of the @xlink:arcrole attribute MUST be a URI that indicates the meaning of the arc.

One standard arc role value has been defined for arc role values on <footnoteArc> elements. Its value is:

This arc role value is for use on a <footnoteArc> from item or tuple Locators to footnote resources and it indicates that the <footnote> conveys human-readable information about the fact or facts.

This section states that Gepsio’s validation of footnote arcs as originating with a fact is valid only when the arc is in the standard arc role of

. It also implies that arcs not in that role are not bound to this validation. Indeed, the footnote-to-footnote arcs in Test 301.17 use a custom arc role of


The next release of Gepsio will validate footnote arcs as originating with a fact only when the arc is in the standard arc role of

. For other roles, it will simply ensure that the origin of the arc is a defined label, which could come from an item locator or another footnote. With this change, Test 301.17 will pass with the next release.

Gepsio’s XBRL Conformance Suite Unit Test In Need of an Upgrade?

The Gepsio project contains a set of unit tests. The most significant unit test involves running the code through each of the XBRL instances found in the XBRL-CONF-CR3-2007-03-05 conformance suite published by XBRL International. XBRL International describes the suites goals as follows:

The purpose of the conformance suite is to facilitate interoperable XBRL processor implementations.
XBRL documents (taxonomies and instances) produced by an XBRL conformant application should be consumable directly by a different XBRL conformant processor without loss of information.

Gepsio has long used the conformance suite as a unit test case, and, while Gepsio does not pass all of the tests in the suite, its pass/fail percentage has improved with every release. Gepsio will continue to be labeled as a “Community Technology Preview” until the entire conformance suite passes through Gepsio successfully, at which time a final 1.0 release that can truly be advertised as “compliant with the XBRL specification” can be made available.

XBRL International first published a working draft of the conformance suite in 2003. Since then, it has published several updates which support the XBRL specification. Updates were published in 2003, 2004, 2005, 2007, 2008, and 2012 (the entire publication history can be found here). To this point, Gepsio has used the suite published in 2007 as a unit testing source.

This suite, however, is now showing its age. Specifically, there is a problem with the “304-25-measure-reported-with-prefix-undefined-instance.xbrl” instance found in the suite. The root node of this instance is as follows:

<xbrl xmlns="" 








      xsi:schemaLocation=" BasicCalculation.xsd">


The schema location for that document, BasicCalculation.xsd, is no longer available. The schema location references a domain called UBmatrix provided XBRL-based software solutions enabling businesses to address FMIS, GRC and external reporting problems. EDGAR Online merged with UBmatrix on 23 Nov 2010, with UBmatrix becoming a wholly owned subsidiary of EDGAR Online. Of late, the subdomain has been redirecting to, which doesn’t resolve to a valid Web resource (though other subdomains, such as, remain active). Long story short: the schema location in the conformance suite instance is invalid, and the conformance suite unit test fails in a place that passed back when the UBMatrix domain was valid.

The most recent XBRL Conformance Suite was published on 24 Jan 2012. Hopefully, this more recent suite will bypass invalid domains and allow Gepsio to be tested with schemas that can be successfully loaded. The results of that investigation will be provided in a future blog post.