To Render or Not to Render XBRL

By Diane Mueller
September 26, 2008 | Comments: 4

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.

You might also be interested in:


An extremely interesting post. Readers might be interested in Walter Hamscher's discussion of Inline XBRL for the Hitachi XBRL blog. See questions (9) and (10) of An Interview with Walter Hamscher (Part IV) at

Bob Schneider
Data Interactive (Hitachi XBRL blog)

Interesting to note the differences between XBRL's path toward styling (visualization) the path followed earlier by plain-old-HTML -- though with far more complex and critical data. We're going to see this struggle more often with other kinds of critical data as large institutions, particularly governments, begin to offer straight XML for processing into particular renderings (and orders) by organizations operating at arms-length.


I'll state again here what I stated at the XBRL conference earlier this year - I believe that both the query and the render aspects of XBRL should be seen as orthogonal issues in the XML space that have strong dependencies on the environment being used to query or render.

For instance, on the rendering side it makes far more sense to utilize an XSLT (or better XSLT2) transformation along the lines of that used by DocBook in order to present a "default" document that could be presented by, just as DocBook uses an XSLT to create a default rendering to XSL-FO (for PDF rendering) or XHTML (for web rendering). Such a transformation would have a large number of parameters that would be used for modifying this default formatted output that could be set by the appropriate tools.

If you added extensions to your XBRL specification, then all you would need to do would be to write extensions to the corresponding XSLT that would subclass the behavior of the corresponding templates.

By doing this, you provide a starter template that people could modify, without trying to build presentation directly into the business model. Additionally, this would make it possible for people to create alternative transformations that could be implemented by someone who was wishing for more customized output than could be handled via the normal mechanisms without forcing that person to maintain default "presentation" information in the model instance itself.

The query side (and the corresponding functional mechanisms) may work in a similar manner by utilizing XQuery as the "standard" mechanism for performing queries upon existing XBRL documents. There are a number of advantages to this - besides providing a language that works well with XML content, it's possible to write XQuery extension functions - this means that could in fact define the interfaces for various functions, such as:
xbrl-finance:compound-interest($principle as xs:currency, $interest as xs:currency, $period as xs:double) as xs:currency

then can indicate that the specific implementation of these functions would be vendor dependent. would establish a formal API set of these functions, and anything that falls outside of the mandate would be defined within a secondary namespace, making it easier for vendors to supply their own additional functions.

Beyond the immediate and obvious benefits of this approach it also makes it easier to establish some mechanism for constraint modeling, possibly in conjunction with a language like Schematron.

If you'd like I can expand these proposals into an article down the road.

Very interesting and informative article Diane. I would concur with Kurt's suggestions regarding presentation. In the last few months whilst meeting with HMRC and corporate clients, we've discovered that the requirement to have the rendered inline document in the companies' own template is occurring more and more. This indicates that whilst the requirement by HMRC is just to have a simple rendering (for an inspector to read), the wish to have the output looking like the inbound pdf with graphics, logo, customized tables etc is still high on the organisations list of "must haves".
Richard Metcalfe

News Topics

Recommended for You

Got a Question?