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:
- 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?
- 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?
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!