Formatting XBRL for Presentation

XBRL is, in some ways, a funny kind of XML language. It doesn’t make much use of the capabilities within XML Schema to express relationships such as order, hierarchy, and so on. Viewed strictly as XML, XBRL looks pretty flat, without a lot of contextual constraints.

But that’s nonsense, of course. Financial documents are highly constrained and contain intricate interrelationships. XBRL expresses these relationships within "taxonomies"–special XBRL constructs that define business "concepts" and that relate these concepts to each other. The relationships can, in fact, be really complex …more so than would be possible within a strict XML Schema definition.

Once consequence of this decision to define the bulk of XBRL semantics outside the range of standard XML semantics is that XSLT (XML Stylesheet Language Translator) doesn’t work very well as a way to transform XBRL documents into something that humans can read. Since XSLT cannot "understand" the information in the XBRL taxonomy, XSLT does not have the information that it needs to present the "facts" in an XBRL instance in a way that reflects the taxonomy relationships.

So, how do people produce formatted output from XBRL today? In a Wednesday morning session at the 11th International XBRL Conference, Raymond Lam of BlastRadius explained that the usual solution is to hard-wire all the necessary contextual information into the XSLT rules. The result is an XSLT stylesheet that contains nearly as many separate template rules as there are separate facts to be presented. Bummer.

BlastRadius put on a couple of presentations at the conference about the work they are doing to fix this, and make it possible to use XSLT in a more efficient way. Their approach involves inventing yet another special XBRL construct which they call a "formatting linkbase." The formatting linkbase provides an additional layer of indirection–and mapping–that connects the concepts identified in a taxonomy to elements that XSLT can get hold of and use.

The advantage of setting up the linkbase is that you can then write XSLT stylesheets that are smaller, simpler, and, best of all, more reusable. BlastRadius demonstrated use of a formatting linkbase, in conjunction with XSLT, to produce reasonably nice looking output. The BlastRadius team said that they were at the conference to see what the response from others in the XBRL technology community would be to this proposal. BlastRadius has applied for a patent for this work, but would consider putting the work into the public domain if there was enough response and interest.

Although this was not the intent, the demonstration also proved to be a nice illustration of the difference between XBRL and some other, more text-centric XML applications. It turned out that one of the most difficult parts of the financial report to produce and format in XBRL was the management discussion and analysis (MD&A), which tends to include a lot of running text. Among other difficulties, the BlastRadius team noted that mixed content is not allowed in XBRL, making it difficult to preserve the font changes and emphasis that appeared in the original, printed version of the MD&A.

From the standpoint of Gilbane Report readers in publishing businesses, the difficulty encountered in producing reusable stylesheets and good looking output may come as a surprise. It certainly underscores the focus on machine-to-machine processing that is behind much XBRL development. I also think that it ties into some other, larger problems and issues.

A few days ago I wrote about the use of XBRL for assurance–just what to you audit? Just what is the "official," or "normative" copy of your financial statements? There are clearly some–including the SEC–who are interested in seeing whether the XBRL version can be that normative, official representation–the one that is audited and saved. But …if there is no reasonable way to produce formatted, human readable presentations from XBRL, what impact does this have on XBRL’s future as the representation that you audit and archive?

Incidentally, I would be delighted to learn that I am missing something here. Either in terms of products (someone else has a great solution to XBRL formatting), technology (Bill, you really have this all fouled up … it’s really very simple …), or application (Bill, formatting for human readers is just not important, because …). Write me or comment here if you see something that I am missing here …

Comments

There is something missing, as your last paragraph asks. While it is quite possible to create nice, clean human presentations from XBRL data, that isn’t the problem most people focus on. Instead, they want to recreate the exact look and feel of the PDF from which they backed out the numbers in the XBRL, using only the data captured in the XBRL instance and taxonomies. Sorry, but that is not going to happen. There are lots of formatting decisions, such as whether to use running text or a table for a series of numbers, that aren’t captured in the XBRL because they are basically ad hoc decisions. No doubt you could try to capture all of these decisions in additional XBRL, but it would be a real mess. What Quark Express does is not going to be easily captured in XSLT massaging XBRL. The presentations that are easy from XBRL data are “draft” quality in the eyes of the art directors of the world. I can live with that.