Back to the index
| previous | next |
To discover or not to discover, ...
Published on 06/10/2006
Overview
A new extension of the XBRL specification has been officially recommended by XBRL International. The extension fills an important gap. Unfortunately, the extension also introduces a range of new complexities. One of those complexities relates to the information discovery mechanism that is central to the usage of XBRL.
But it is just one small attribute ...
XBRL International has long envisaged a process whereby that core specification is extended with modular add-ons that increase its ability to meet the needs of those engaged in business reporting.
Since the XBRL 2.1 specification was recommended, XBRL International has been insistent that new capabilities be provided by modular extensions using the existing linkbase functionality. This insistence is sensible in that it gives developers confidence that software developed for XBRL 2.1 will not need to be altered as new extension specifications emerge. Developers expect be able to continue to use the DTS discovery library, the XLink library and the XML Schema library that they have assembled to work with the XBRL 2.1 specification.
On September 18, 2006, the first such modular add-on reached the status of recommended specification. It deals with the documentation of additional detail about the entity described in an XBRL report and the scenario under which it is reporting. It is generally referred to as the Dimensions specification.
The dimensions specification makes such re-use surprisingly difficult. For example, it has introduced an a new meta-data discovery mechanism, the typeDomainRef attribute. Modularity has only been recovered by augmenting the dimensional specification with an additional error checking requirement forcing any discovery of new information via the typeDomainRef attribute to be redundant.
The discomfort associated with this feature is most evident in the surprising decision not to use the XLink syntax for the link expressed by the typeDomainRef attribute. XLink is used for every other link in XBRL. It is challenging not to interpret this syntax choice as a way of playing down the compromise to the core XBRL specification that this link represents.
So how to move forward?
If you find yourself in the unfortunate position of having to write software that uses the new dimensions specification, what is the best way to work around this new complexity?
One way would be to process the typeDomainRef attributes in a second pass. First, perform DTS discovery in the usual manner, ignoring the content of the typeDomainRef attribute altogether. Presumably this will not require any changes to the XBRL processor that you were working with before you ran into the dimension specification. Then in the second pass, work through all of the typeDomainRef attributes in DTS that you discovered and make sure than none of them actually reference an XML fragment that is not already part of your DTS. Not a particularly appealing strategy perhaps, but at least it does not imply a code change to the original DTS discovery logic.
| previous | next |