Gaps in XBRL Specification, XBRL as a Standard

XML has been around for a long time and is universally accepted as the way to share data between applications. However, one of the main problems in using xml to share data was to describe to business users what each of the XML tags represented in terms that they could understand. This was typically done (if indeed it was actually done) by creating a separate document – either paper or electronic – that contained the explanations of what each tag was. This created a new problem of keeping the separate document up to date and accessible to everyone who needed it when they needed it.

XBRL and metadata
XBRL solves this problem by attaching the information required by business people to the XML itself. This certainly solves the accessibility problem and helps with the updating issues by putting the documentation front and centre when updating taxonomies. Though this does not force the documentation to be updated but makes it harder to “forget” to do it.

XBRL provides several mechanisms for attaching this metadata

  • Balance attribute for its Debit/Credit characteristics;
  • Unit of measure attribute;
  • Periodicity elements for the date(s) the data relates to;
  • Entity and scheme identifiers for who the data relates to; &
  • Label and Reference linkbases for textual documentation.

Arguably it is the textual information that is of most use to business users and there is no limit to the amount of such information that can be provided.

Issues with metadata defining of textual information in XBRL
However, the XBRL specification does not prescribe 2 important things about the textual information:

1. The information provided in metadata need not uniquely describe the concept to a human: The efficient processing of data by a computer requires that the associated XML tag is unique. Humans have no less a requirement when they need to process the information. XBRL does not require that the metadata associated with an XML element be also unique – perhaps it should.
2. No specification on WHERE this information is to be found to ascertan the uniqueness of concept:
In order to determine if the metadata is unique, a human or a computer needs to know where that information is. It could be in either or both of the Reference and Label linkbases; and within those, it could be in any of an unlimited number of arcroles, or combination of those. As with anything, the more places you have to go looking for the meaning, the harder it is to find.

XBRL provides enormous benefit to users over and above what XML provides in relation to informational metadata, but the benefit is diminished with difficulty in locating it. So how do we lock in this XBRL benefit?

How to gain insights on XBRL data with metadata
One way would be to give humans equal footing in the specification by declaring that the combined contents of the Label and Reference linkbases MUST be unique for each unique element id. It could go further by stating that this combination of documentation metadata SHOULD clearly and unambiguously describe the business concept represented by the element id to the intended audience.  The XBRL Specification provides several Label roles for defining concepts but stops short of insisting upon their use.

That solves problem 1 but does not address problem 2 – where to find it.

XBRL has steered clear of being prescriptive on the uses of the mechanisms it allows, so we can deal with where to find the human readable meaning of concepts by additional metadata about where to find the metadata – is that metametadata?  

The new “Taxonomy Packages” specification deals with a similar issue – where to find the entry points to a taxonomy. Either this, or a similar mechanism could be used to provide pointers into the Discoverable Taxonomy Sets (DTS) for software to locate the unique combination of human readable information to present to users. This could take the form of a small mandatory XML file within the DTS that contains the linkbase reference(s) and roleURI(s) that, when combined, provide unique metadata for every concept.