Digital Financial Reporting

XBRL often gets criticized for being complex.  Imagine that you had this simple set of data, a list of the U.S. states and their population.  What is complex about this (if you cannot see these files in your browser, try your view source option to see the file contents):

• XBRL Instance: This looks a lot like what someone who might create traditional XML would come up with.  (I know that there are many different ways this XML could be structured. That is just one commonly used way.)
• XBRL Taxonomy: This XML Schema looks a lot like what someone who might create a traditional XML Schema might come up with.  You can even validate this using an XML validator.

Anyone who can write an Excel macro could generate this form of XML. Why might you use this approach to creating your XML?  Well, you would be following a global standard rather than rolling your own form of XML.  XBRL provides a framework to work within rather than inventing your own.  There are other reasons one might consider this approach.

Eventually you will start asking some questions, or you should ask some questions.  How would you verify the data to be sure that the populations of the states add up to the total US population (see that total in the PDF).  Well, if you added a calculation linkbase XBRL could provide you with that functionality.  For example, if the calculation linkbase were provided you would get a validation report which looks something like this.  Sure, you could write your own proprietary validation routine...but that takes time and money.  Also, because you used your proprietary validation you will not be able to share that with anyone else because it is proprietary.

Another thing you might want to add to your XML is labels for the element names so you don't have to deal with things that look like "WestVirginia" (XML element names cannot have spaces), but rather "West Virginia" which most users might prefer.  No problem, you could write your own way to add labels to your XML and not use the label linkbase which XBRL offers.  What about providing USPS codes for the states such as "WV", and abbreviations like "W. Vir.", and other such labels.  And what about multilingual capabilities.  Sure, you could add all this to your XML.

Do you see my point here?  There are two.  The first point is that you could use XBRL without the linkbases.  That would make your implementation of XBRL significantly less complex, almost like tradional XML.  You would be constrained slightly in terms of what you can do, you would have to follow the approach of creating XML that the XBRL framework requires.

The second point is that you will run into issues such as how to validate computations.  That is why XBRL has XBRL calculations and XBRL Formula, not because people wanted to make XBRL more complex, but rather because the real world of business reporting has numbers and those numbers have relations.  XML Schema validation cannot handle the validation of computations.

Basically, if you rolled your own XML, you would end up creating a lot of the functionality which XBRL already has.  That is why the functionality is in XBRL, because the business people creating it needed the functionality.  Business reporting is complex. XBRL has to serve the real needs of everyday business reporting.

You don't need to use all the features of XBRL.  Start with only an XML Schema.  Experiment.  When you realize that you do need something like the calculation linkbase or label linkbase, you can add them later.  When you realize that you do need XBRL's extensibility, it is there waiting for you to discover.

Besides, XBRL is a global standard.  It is a framework.  Sure, it takes a little more dicipline to use XBRL than just writing your own XML.  That can be a good thing, or that can be a bad thing.  You can decide based on your needs.