by Diane Mueller
Within the XBRL consortium, there is widespread agreement on the importance of developing a wide user base for XBRL content and fostering adoption of the standard. the inevitable mandate of XBRL’s use for US SEC filings, and the ripple effect that this is having on application development for the financial sector, has sent financial software application developers scrambling to accommodate their client’s filing preparation requirements and looking for opportunities for leveraging XBRL metadata on the consumption & analytical applications development side of the financial supply chain. The community needs take advantage of particular moment in the regulatory spotlight and promote wider adoption by making it easier to develop financial applications that leverage XBRL.
The complexity of the XBRL 2.1 specification and the modules that have sprouted up to support it’s extended application is definitely a stumbling block for most financial software applications developers to entering this market. As with any new standards-based endeavor, developers need access to the right enabling technology, development tools and runtime software that can automatically overcome technical issues without passing the burden of deep specification knowledge to the developer.
There are a few niche vendors that have produced XBRL processors and these, for a price, are available with various proprietary commercial licenses for developers to incorporate into their applications. Some developers have opted to ‘roll their own’ and develop their own in-house XBRL parsers and validators with varing degrees of consistency and success. These have often proven costly to maintain as the development teams must keep a constant watchful eye on new developments with in the standard such as the Dimensions, Versioning and Formula modules which while not changing the XBRL 2.1 Base Specification have had and will have a great impact on the complexity and variety of the XBRL instances and taxonomies being published now and in the future. This brings up the issue of software interoperability across vendor XBRL platforms, even with the current roster of XBRL processors available today, all issue different error messages, and leverage different architectures, offer varying interpretations of the XBRL specification and it’s modules. There is not yet a single leader in this market space nor is there even anything close to the W3C’s canonical HTML Validator (http://validator.w3.org/) available. The W3C’s effort to host and deliver validation tools dramatically helped to improve and ensure the quality of the web content, and saves a lot of time and effort for web developers around the world.
Other XML consortiums have made similar efforts and delivered toolkits such as the DITA Open Toolkit: a implementation of the Darwin Information Typing Architecture (DITA ) specification. The Toolkit’s transforms makes it easy to give applications the ability to manipulate DITA content (topics and maps) into deliverable formats like web (XHTML), print (PDF), and online Help. It is a set of Ant- and Java-based, open source tools that provide a "reference implementation" for processing DITA maps and topical content to multiple output formats.
XML Developers already rely heavily on Open Source projects like the Apache Software Foundations' XERCES – a validating XML parser – that makes it easy to give applications the ability to read and write XML data. A shared library is provided for parsing, generating, manipulating, and validating XML documents using the DOM, SAX, and SAX2 APIs.
If we are help foster the growth and proliferation of XBRL content and services across the financial sector, we need to make it easy for developers to overcome the burden of deep specification knowledge and deliver the metadata-enhanced XBRL content financial applications that the market expects to see emerge rapidly to justify the burden of having to file with XBRL and deliver on the promise of XBRL as a technology.
A few attempts have been made to foster Open Source implementations of XBRL tools and API. The US SEC made it’s web-based XBRL viewer software available on Source Forge.com and a few developers have taken advantage of this and added functionality into their websites. Sadly, this project has a number of dependencies, has not been well-maintain and does not support the use of Dimensions which is a pre-requisite for the US GAAP taxonomy. It will be interesting to see if the US SEC repeats its past donations practice again when they complete their internal upgrades.
There are a few other vendor donations to SourceForge of old code that also do not support the new US GAAP taxonomy and have no or limited resources committed to maintaining the code base. As often happens in the land of SourceForge, it has become a dumping ground for old code and forgotten pilot projects.
There are a few projects that have promise like Geoffery Shuetrim’s Java XBRL API that have inspired a lot of interest and should if, properly fed and cared for, result in the first comprehensive Open Source XBRL engine for developers available.
But as with the DITA Open Toolkit, the W3C Validator, and XERCES parser – the consortium or foundation backing the standard’s adoption has had to support the development of these tools in order to help move the adoption of the standards forward and to promote interoperability amongst the vendor community.
The XBRL consortium has taken the first small step towards by posting a solicitation for Proposals for which the work product will be made available as an open source project upon successful completion. The first of hopefully a steady stream will be a project to develop a XSLT 2.0 stylesheet to extract a valid XBRL 2.1 instance document from a well-formed HTML document with valid embedded Inline XBRL (iXBRL) content. This reference implementation will both be a good example of how to work with the iXBRL specification (yet another new XBRL module) and give a boost to the web developer community by giving them a small piece of the enabling technology required to get into the XBRL financial application development game.
To move the XBRL technology adoption curve forward significantly, the XBRL Consortium would get more bang for it’s buck by funding and hosting of an XBRL Validator and the development of an Open Tool Kit for XBRL that includes a series of Transformational XSLT (Inline XBRL, HTML, XBRL, RDF), APIs for searching, analyzing and presenting XBRL data and APIs for both reading/writing XBRL.
There will always be a market for proprietary XBRL engines with purposes specific goals, but breaking down the barrier to adoption by making the right-enabling technology available in a single one stop shop with the XBRL consortium as the host in the same manner as the W3C, Mozilla and Apache foundations have done would go a long way to ensuring software interoperability, reducing the current burden of deep specification and developing a wide user base for XBRL content.
