It seems to be a majority opinion that there is some sort of rendering issue with XBRL.  I have a different view.  It has been my experience that rendering XBRL is actually not all that challenging.  This document was generated from an XBRL instance document using XSLT to generate XSL-FO, and then the XSL-FO was sent to an FO processor to generate the PDF rendering.  I have no real problem with that rendering.  Also, I was the one who created this, not a developer who really understands how to create XSLT who probably could have done a better job.

The issue with rendering XBRL is really a meta-data issue. 

Generally, there is not enough information within a taxonomy to enable the desired renderings.  Three other things get in the way also.  The first is inconsistencies in the taxonomy make it harder to render instance document information.  The second is that taxonomies tend to be modeled around a presentation perspective rather than a more appropriate data modeling perspective.  And finally, taxonomies tend to be build in huge chunks, as opposed to smaller components which help software render instance documents build against the taxonomy.

In fact, a well modeled taxonomy can also solve the problems related to creating a consistent taxonomy, it can solve issues related to users properly extending the taxonomy, and in addition it enables rendering information contained within instance documents in a manner human readers can understand the data.

A really good example of what I am talking about can be seen in the samples provided with XBRLS which you can see here. 

So what is the key here?  The key is a modeling layer.  Being a CPA and not having an IT background I may explain this a little incorrectly; but the essence is that the same things should be modeled in the same ways within a taxonomy.  A modeling layer is somewhat like a template which guides the creation of a taxonomy.

The US GAAP Taxonomy uses this modeling layer type of an approach.  It is about 98% there.  But, it needs to go the final 2%.  Two things will be achieved by doing this.  The first is that it will have a complete modeling layer and the second is that because of the modeling layer, the taxonomy will be more consistent.

Let me give you a few examples.  You may have noticed things such as [Table], [Domain], [Member], [Line Items], and [Roll Forward] in the US GAAP Taxonomy.  The US GAAP Taxonomy Architecture document even discusses some of these, see section 3.3 Tables, Line Items, Axes and Domains; also 4.5 Implementation of Tables discusses this.  And if you look at the taxonomies, you will see more examples of this.

I created a little view of one extended link of the US GAAP Taxonomy.  You can take a look at this here.   To view this, open the file in your browser (Internet Explorer, but you have to have the Microsoft .Net Framework 3.5 installed (you have this if you are using Vista, but you can download and install it if you are still on XP).

In that file, notice all the colors.  Notice how consistent the colors are within the assets and liabilities section of the balance sheet.  But in the equity section it is significantly more inconsistent.  It could be consistent.

The bottom line is that if taxonomies in general, and the US GAAP Taxonomy in particular, had just a little more meta data; then the following can be achieved:

1. More consistent taxonomies can be created because that meta-data can be used to enforce the consistency.
2. The consistency and the models (templates) used to create that consistency can also be used to enforce quality extensions of the taxonomy.
3. Effective renderings for human consumption can be generated (for example, one style sheet or other process could be used to effectively generate a human consumable rendering for SEC filing.
4. Using the taxonomy becomes easier because users can deal with the taxonomy (when creating the base taxonomy, creating extension taxonomies, creating instances, and analyzing instances) at the modeling layer and never have to go down into the XBRL layer.

It takes a little more than just the models, the models also have to be good organizations and good modeling of the data.

Another reason that a data oriented view of the taxonomy is important is that it is easy to agree on.  The data is the data, it is rather straight forward.  But how to present that data has a many, many different options as many, many people have many, many different views of what the best presentation is.

Further, if this is not done the following will occur.  The first thing is that application developers are going to have to somehow assign this meta-data to the taxonomy somehow, outside the taxonomy, probably in code.  This will be expensive, it will not be reusable on other taxonomies and it will have other negative ramifications as it fights the symptoms, rather than solve the problem.  You will also still have the extension issues and inconsistencies in the taxonomy to deal with.  Rendering the extensions will be even more of a challenge, as the software developers will have to take each and every filing, and the inconsistencies they posses (as there is not way to currently control the inconsistencies).

I would love to be wrong about all this, but I think I see this correctly.