The XBRL International Standards Board at have recently published an interesting document that calls for input on ways to evolve the XBRL specification over the next decade. They identify 3 key goals:

1.         making the standard easier for developers

2.         making XBRL information more comparable across taxonomies

3.         making XBRL information easier to consume alone or in combination with information expressed in other standards

Your input on reaching these goals is sought via a well-thought out questionnaire. Now I’m too lazy to fill in questionnaires and I’m not involved in XBRL development but have a few ideas of my own.

I think one of the biggest challenges facing XBRL, and indeed any largely ‘technical’ specification, is connecting the abstract with the concrete or applying the technology to the real-world. So what I would like to see is:

An XBRL Dictionary for Managers

Just a simple regular dictionary format little e-book that just lists say the top 1000 ‘terms’ in XBRL and provides the main tag and closely linked tags for the term and a brief description of use. The kind of thing you might keep on a shelf and refer to now and then even if just for fun. Not a taxonomy document but a conventional dictionary.

A SQL API

Most XBRL data originates from ERP/Reporting systems that use SQL databases so before worrying about OWLS and RDFs why not focus on a SQL abstraction layer that makes getting data from a source RDBMS into a target XBRL instance easier? If this kind of thing can be done via UML models that business analysts and the like can work from, so much the better.

Use Case Drillthroughs

There’s nothing like visual use cases for clarifying how something works. I’d like to see a top level rendered report like an income statement or balance sheet with successive drilldown layers that show tags, possible error paths, source data etc. so that a practitioner can see with a few clicks just how the whole thing hangs together.

Cross Taxonomy Benchmark/KPI Mapping

Taxonomy differences across jurisdictions are a killer for delivering one of the key benefits of XBRL – comparative benchmarking. A mapping layer between jurisdictions for the a set of ‘most used’ tags would be very helpful in enabling the next generation of comparative benchmarking software that depends on XBRL.

XBRL Content Broker Hub

A centralized XBRL content broker hub with a published Web Service API – not a just an RSS feed – would do a lot more to democratize XBRL filed data and make it available to a wider range of consuming applications. For example, I’d like to see ERP systems being able to query this service directly and pull in competitor/peer group data to enable continuous benchmarking at the operational system rather than reporting system level.