Digital Financial Reporting

The comprehensive exampledigital financial report provides a good opportunity to better understand what an infoset is and how it is useful. What I will show here is that these intermediate infosets break the XBRL problem into two separate and distinct problems.

Here is a summary of the infosets I generate for the comprehensive example.  Provided are an HTML human readable rendering so you can see what the info set looks like, an SEC style infoset which uses the SEC logical model terminology, and a Business Reporting Logical Model (BRLM) style infoset which uses different terminology.

• Fact tables: Human readable (HTML), SEC style infoset (XML), BRLM style infoset (XML)
• Relations: Human readable (HTML), SEC style infoset (XML), BRLM style infoset (XML)
• Report elements: Human readable (HTML), SEC style infoset (XML), BRLM style infoset (not available)
• Business rules: Human readable (HTML), SEC style infoset (Coming soon), BRLM style infoset (not available)

From these infosets I created this Recap/examination utility. That recap/examination utility is nothing more than a reorganzation of the information within those infosets.  Well, I guess there are a couple other things I use.  I do use a valiation output report for calculations validation, business rules validation, and XBRL syntax validation. So, perhaps one might include those in the infoset.

Where do these infosets come from? They are generated by an XBRL processor.  Now, these infosets are not generated directly from an XBRL processor.  What I do is take the XBRL processor generated infoset which is rather technical in nature, not organized as I wish, and otherwise not what I desire; and I reorganize what the XBRL processor generates using XSLT.  This is a daunting task, and you definitely need an XBRL processor to do this correctly.

But once you have the infosets, the "problems" that you need to solve to make this information useful has nothing to do with XBRL any longer, it is a totally different problem and you don't need an XBRL processor at all.

For example, this is my rather lame attempt at rendering the information contained within the digital business report: rendering. This is what the information might look like in a printed document. That printed version is my target.  Not the "bold" or different sized fonts or other helpful formatting, but rather the formatting of the meaning of the information.  One needs a minimal amount of rendering to put in fact table into a usable, workable form.  Doing this has nothing to to with XBRL, it is all about recognizing the infoset.

In generating that rendering, I did not use XBRL at all.  Never had to touch anything related to XBRL.  It is all about organizing that fact table info set using the fact table, the relations, and the report elements.

My next step with that recap/examination utility is to solve the balance of the rendering issues.  There are two things I am not taking into account correctly because they are beyond my current programming skill level.  The first is leveraging the information model in the generation of the rendering.  You can see how the different information models should be rendered by looking at these metapatterns and business use caserenderings. I could probably figure this out, but I think I am going to seek out someone with programming skills to help me.  The second thing I need to do is deal with multiple [Axis] on columns and rows correctly.  If you look close at the renderings of the comprehensive example, there is only one [Axis] on each column and one on each row.  This is not the case with the metapatterns and business use cases.  Correcting these two issues will provide me with the renderings I am looking for.

I am not going to undertake the "interactive" piece of the rendering puzzle, making it so you can pivot the rendering like an Excel pivot table or how the Firefox add on pivots the rendering.  I will leave that up to people who really know what they are doing, too hard for me to.

So there you have it, the power of infosets.