Why do we need Micro-XBRL ?

Those preparing business and financial reports care what they look like. MicroXBRL allows reports to be created in XHTML, with the XBRL embedded inside the page. A single, simple *normative* style sheet allows the conversion of that page into an XBRL document that can be consumed by systems that present the data to analysts and investors.

Current Efforts Are Difficult

A range of rendering initiatives have suggested requiring those publishing reports in XBRL to also publish technical instructions that allows the XBRL to be rendered in human readable form. Here's this idea in graphic form:

The problems with these kinds of approach are:

• They require software to define rendering instructions in a form only used for XBRL.
• They probably require business users to think about rendering in a fairly abstract manner.
• They are unlikely to ever meet all of the rendering needs of business users.
• They probably require specialist rendering processors.

MicroXBRL looks at the problem from the other direction

In XBRL circles (and many XML circles) there is a famous diagram that describes how you create XBRL once, and use it many times. Perhaps that diagram is the root of our problems. Taking XBRL and adding rendering metadata to it to transform it into a human readable format is tough. Taking XHTML and embedding the information that you need to turn it into XBRL is *much* simpler.

Our simple, unoriginal idea, is to format the report *exactly* the way the users intends, and reliably transform that report into XBRL.

Just to repeat, it's a human readable version of the report that can be reliably transformed into XBRL:

The advantages of this approach are:

• It allows software to take advantage of existing rendering capabilities (ie: HTML)
• The ubiquitous "Show Source" feature of modern browsers encourages and should accellerate the creation of XBRL business reports in this format.
• The use of a normative stylesheet, using standard XML (XSLT) processors means creating the XBRL instance out of the XHTML is basically free, and can be standardised. This may prove valuable for assurance review purposes.
• Potentially (it is one of the questions for analysis and discussion) it is possible to analyse the MicroXBRL and create a set of rendering instructions that don't rely on XHTML, for use within proprietary reporting engines, allowing business intelligence tools to recreate the rendering based on the instance document and those instructions, without needing to understand XHTML.