Tuesday, May 17, 2011

Calculation Arc Validation Errors Are Common?

I ran across this tweet from a gentleman named Tom Gleeson about Gepsio's support for calculation arcs. Gepsio was failing to validate one of Oracle's XBRL documents posted through EDGAR. Although the Feb 2011 Gepsio CTP has passed the the Section 320 Calculation Binding tests in the XBRL-CONF-CR3-2007-03-05 conformance suite, I was initially confident in Gepsio's calculation arc validation code, though I wouldn't be surprised to find an issue that the tests don't cover. I'm certainly not smug enough to say "Gepsio must be right and the document must be wrong".

In this follow-up tweet, Tom alludes to the fact that Gepsio failed to validate one of the document's calculation arcs but also mentions that this is a "unfortunately very common" problem. In another follow-up tweet, he mentions that this same data is viewable in Arelle without any problems.

I was intrigued by Tom's comment that calculation arc validation errors are a common problem. Since I am still learning about XBRL and the community in which it lives, I wanted to open some questions for discussion:
  1. Are calculation arc validation errors a common problem within documents generated by the XBRL community, or is this simply an issue that will resolve itself as Gepsio matures?
  2. Would it be beneficial, as Tom suggests in a post, for Gepsio to support various "levels of correctness" whereby, in a more lenient validation mode, validation errors are overlooked?
Your comments are welcome and encouraged! Simply add a comment to this blog post.

I will mention that, in the general case, Gepsio validates the document after most (if not all) properties have been populated. This implies that, if you place a try exception block around the code that loads an XBRL document into Gepsio, and the catch block catches an XbrlException instance that references a problem with the validation, your code may still be able to carry on with at least some of its work, since many of the XbrlFragment properties will be populated and ready for use. The XbrlDocument instance should, in the general case, be in a known, stable state that will allow for its continued use in code. (This suggests that Gepsio should distinguish between exceptions that keep the XbrlDocument instance in a stable state from exceptions that have destabilized the loaded object model - I'll consider that idea for a future version of Gepsio.)

Special thanks to Tom for trying Gepsio and for alerting me to the issue!