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 …