One of the interesting long running conversations in the XBRL technical community has been the discussion of what the market wants and needs in terms of rendering XBRL content. For a long time, we debated whether or not XBRL data would ever be rendered. The main camp on one side of this many-sided conversation held fast to the belief that XBRL data would only ever be transmitted from machine to machine and would never be seen by the human eye. However, there was a counter-argument that accountants and regulators (who only recently put down their pencils and paper to switch to spreadsheets and keypads), would still have serious trust issues and would at least need to see the XBRL content rendered in order to audit and sign-off on the content before submitting or publishing the data to various stakeholders. In the end, the trust issue has driven the market and caused the XBRL technical community to scramble and resolve some tricky issues regarding rendering the quite complex and subtle flavor of XML that XBRL has become over the past 10 years.
Financial reports have a long and checkered history and the value-proposition of XBRL is that it will help disambiguate some of the obfuscation that goes on in the reporting of financial data to the public, ensuring accurate, high quality valid information to feed the voracious supply chain that consumes the stuff. As I watch, the meltdowns on Wall Street and the effects of the mortgage crisis and listen to mud-slinging in the election campaigns, I can't help but hark back to Enron, WorldCom and Arthur Andersen meltdowns that were some of the impetuses for the remaining Big 4 to get behind the XBRL technology bandwagon in the first place. I am quite pleased that Chairman Cox had the foresight to also get behind XBRL and incorporate its use into the modernization of the EDGAR system - sometimes the government does get it right.
The question of rendering centers currently on creating a 'canonical' rendering of a financial report . By 'canonical', we are referring to a specific visual presentation of the information. The idea behind this is that the preparing organization cares deeply about 2 things. First, telling their financial story accurately, and secondly, having it reviewed 'as reported' by the consuming parties - regulators, stakeholders, investor analysts and others. In today's current supply chain, the company's story gets lost in the normalization processes that take place when 3rd parties regurgitate the content from their aggregated databases and spoon feed the data to web portals in widgets and graphs that enable MSN Money, Yahoo Finance and other players to deliver eye-catching comparison tools and snippets of seemly accurate and real-time data to the unassuming consumers' browsers. In this regurgitation process - one company's 20 line items of assets may get rolled-up and normalized to be compared to another company's 10 lines of assets - drilling back down to the details is next to impossible for the mainstream consumer.
The preparing organizations spend enormous energies, resources, and dollars to get their financial reports out the door, only to see them pop up on the portal in simplified formats that don't tell the story accurately. So getting the 'canonical' rendering into the hands of the consuming stakeholders is an important aspect of financial report. In the Internet age, it's all about getting the 'eyeballs on the glass' approach - aka what our computer screens show us is what we believe, and enabling the applications we use to consume this content accurately is the key to successful business decisions. The XBRL technical community has addressed this issue in three approaches.
The first approach was the inclusion of the 'presentation linkbase' in the XBRL 2.1 Specification. The presentation linkbase describes presentational relationships between concepts in taxonomies. This information enables applications with XBRL parsing capabilities to 'render' a view of an XBRL instance document based on the order of appearance in the XBRL taxonomy. What this means in real terms is that the content in an XBRL instance document could be presented in the exact order of appearance that is prescribed in the XBRL taxonomy. This method was sufficient in the early stages of XBRL adoption when preparers' world views were similar to the taxonomy developers world view.
However, it quickly became apparent (especially in the US where the rules for filings are much more flexible than in other countries) that different organizations would want to present their information in specific order, formats, and layouts, and that these different orderings could have legal implications as well. For example, certain paragraphs in a Mutual Fund disclosure might need to precede other sections as they inform the consumer of important information that alters the meaning of the following paragraphs if it is not read in the correct order.
As more regulatory bodies around the globe adopted XBRL, it soon became apparent that some of the rendering information would necessarily be pushed to the instance document level. This is why the second approach was developed: Inline XBRL ("iXBRL"). iXBRL is a standard for embedding XBRL fragments into an HTML document. The main objective of Inline XBRL Specification is to allow XBRL data to be displayed in situations where the producer wants to preserve a specific visual presentation of the information, and the consumer wants to be able to validate the input data. iXBRL allows the preparer to provide documents that can be viewed in a browser while making use of XBRL tags which can be processed automatically by consuming applications. iXBRL-enabled applications allow the preparer to publish an HTML version of their financial report laid out and formatted as they wish the reader to review the information while still including all the XBRL-ness in the content underlying the HTML so that any applications that are XBRL-aware can consume the data accurately and avoid any transcription errors that would commonly occur when cutting and pasting from different applications. For example, when cutting and pasting numeric data from an NON-iXBRL HTML page into an MS Excel Spreadsheet, there is no metadata transferred to enable validation and the correct contextual information is NOT available for the consuming applications. With iXBRL content, the metadata is available to 'follow' the content to the consuming application. Typically, iXBRL is a publishing exercise from accounting and consolidation applications much like save as PDF or EXCEL. Inherently, this rendering methodology is tied to the individual financial document.
Although the iXBRL approach supplies a flexible and robust solution for the preparers, there are inherent issues of scalability and comparability for the consuming side of the supply chain. If every preparing organization has a slight variation on a theme and a regulator has to review thousands of documents or perhaps an aggregator with a portal wants to have a value-added specific visual presentation of financial information across multiple entities, creating comparative visualizations becomes problematic and reviewing each document individual although still part of the inspection process becomes a scaling conundrum the variations can be infinite.
In this case, a third more portable approach is required which leverages the XBRL taxonomy much like a presentation linkbase - but enables the addition of formatting and layout information to be included as well. This approach is called the 'rendering linkbase' and is currently under-development by the XBRL technical community. In May 2008, JustSystems contributed the intellectual property rights for this linkbase approach to rendering XBRL to the XBRL consortium and a first draft of a Rendering Linkbase specification is expected to be released in mid-October 2008. The rendering linkbase will allow formatting and layout information to be designed once and applied to multiple XBRL instance documents that share the same taxonomy. Conceivably, an XBRL taxonomy could have multiple purpose-specific rendering linkbases associated with it, for example an auditors' view with a layout that highlights certain aspects of a financial report in red that must be inspected, or an investors view that focused on bottom-line aspects of the financial report and caused those to appear in the beginning of a report rather than at the end of each statement. This approach enables the consuming applications to provide a broader spectrum of visualizations beyond the 'canonical' renderings.
As each organization in the supply chain ponders their own rendering and visualization needs, the implications of each of these three approaches need to be taken into consideration as the data being published and filed will be visualized in all three methods. Regulators must take heed to ensure that they review the preparers' canonical (as reported) views as well as meet the needs of a voracious mass consumer market that wishes to see both the canonical view and to interact with the XBRL content in new and innovative ways that the market will come to demand as the flexibility and power of XBRL becomes more readily apparent.