Digital Financial Reporting

In 2004, Rene van Egmond and I wrote a white paper called Comparing XBRL and Native XML. That information made its way into the book I wrote, Financial Reporting Using XBRL, in 2006 (see section 4.11.2). Both iterations where very helpful trying to grasp what the differences between XML and XBRL were and explaining these differences to others. These comparisons pretty much had an "XML versus XBRL" bent. In retrospect, I have come to realize that the XML versus XBRL approach to comparing the two was not necessarily the best approach.

Here in we are in 2009 and I have an updated version of the analysis of XBRL as contrast to XML. XBRL is an approach to using XML and a layer on top of what most XML languages generally provide.

• XBRL is XML. XBRL uses the XML syntax. Therefore, XBRL can leverage the entire family of XML specifications.
• XBRL expresses semantics (meaning) in a standard format. XML only articulates syntax. For others to do what XBRL does with XML, you would basically have to reinvent what XBRL has already created.  Because these semantics care expressed in a standard format they can be exchanged.
• XBRL allows content validation against the expressed meaning. Because the meaning (semantics) are expressed, it is possible to validate XBRL instances against that meaning.  And XBRL has created standard mechanisms for performing this validation, such as calculations and XBRL Formulas.
• XBRL separates concept definitions from the content model. Typically with XML languages, the concept definitions and the content model are mixed together. Further, XML provides you with only one implicit set of relations (because it has only one content model) and the definition of those relations is mixed with the definition of elements and attributes. XBRL, on the other hand, uses an atomic approach (flat XML content model) in defining concepts and moves the expression of relations away from the XML schema. This separation of concept and relation definition leads to the next benefit of XBRL, you can express more than one set of relations and each of those sets of relations can be explicitly identified as being for a specific purpose.
• XBRL can express multiple hierarchies of explicit relations. Because XBRL separates concept and relation definitions, you can define more than one hierarchy of such relations. Further, the hierarchies of relations defined are explicit rather than XML's implicit content model.
• XBRL provides prescriptive extensibility. XML's greatest strength is also its greatest weakness. XML is extensible everywhere, in every direction. XBRL is extensible in a specific, prescriptive, and therefore predictable manner. As such, the extensibility is usable without modifying software for the extension. You can think of this as XBRL always having the same "shape".
• XBRL easily fits into relational databases. XML can be made to easily fit into a relational database. Because of XBRL's separation of concept definition and relations and because the extensibility is predictable giving XBRL a consistent shape, XBRL taxonomies and XBRL instances are significantly easier to model within a relational database as compared to more traditional approaches of using XML. This is particularly true if you use a well-thought-out strategy to create your XBRL architecture. Getting XBRL into and out of relational databases is important because there are a lot of relational databases that XBRL must interact with.
• XBRL provides a multidimensional models. The multidimensional model is being used by online analytical processing systems (OLAP) type systems, providing flexible presentation of information and the ability to "slice and dice" information. Business intelligence systems in particular is one big user of the multidimensional model. Although XML can be made to fit into a multidimensional model in many cases, doing so can be a struggle. XBRL can fits quite nicely into the existing applications, such as these business intelligence applications, which make use of the multidimensional models. Like with fitting into relational databases, this is particularly true if you use a well-thought-out strategy and create your XBRL architecture to do so. Alternatively, you could use an existing architecture and application profile that's specifically intended to fit into an application which makes use of the multidimensional model. Getting information into applications which make use of the multidimensional model is important because more and more applications, such as business intelligence applications, are leveraging the characteristics of the multidimensional model to provide flexible (think "interactive") presentation of information.
• XBRL enables "intelligent", metadata driven connections to information.With XBRL, connections to information can be created by business users adjusting metadata rather than by requiring technical people writing code. As such, rather than building multiple point solutions, XBRL enables the creation of effective and efficient solutions that allow extendibility and don't require programming modifications to connect to new information or new information models. Again, this is because of the prescriptive manner of XBRL's extensibility, the "shape" of XBRL is always the same. With XML, every new connection pretty much has to be enabled by a programmer writing code because XML only communicates technical syntax and does so at the data level, not the meaning level, of information and because the shape of different implementations of each XML implementation can be so varied.

It would be great to get the perspective of people from the XML community which have gained a good understanding of XBRL to hear their view of this comparison.

It seems to me that it should be possible to draw some "line" and better understand when XBRL is a better solution to a problem and when creating a specific XML language is a better approach.

Steve Levin and I did a one hour webcast for O'Reilly last week.  You can view the webcast on YouTube here, you can get the slides here.

The presentation is only slightly technical when we get into discussing how XBRL builds on XML and is appropriate for both technical and business people trying to understand XBRL and answers the questions:

• What is XBRL?
• Why is XBRL different than XML?
• Who is using XBRL?

The presentation is about an hour in length.

Wiley Publishing has made it public that they are publishing XBRL for Dummies.  Note that this is not a promotional version, but the real deal, already on Amazon.com and coming to a book store near you soon!

The authors of the book are myself and Liv Watson.  If you don't know Liv, she has been involved with XBRL from the beginning of XBRL International in 1999 and was one of the people which helped XBRL go global.

I am trying to pack as much useful information as possible for business readers into the book.  I am doing my best to condense my 11 years of working on XBRL including hundreds of conference calls, meetings, working with others in creating the specification, working with others creating taxonomies, and generally learning practical approaches to making XBRL work into the book.  The book will be packed with the best useful resources I have come across.

In addition to Liv Watson, helping out on this project are:

• Cliff Binstock
• Marc van Hilvoorde
• Rene van Egmond
• Christine Tan
• Eiichi Watanabe

The book is targeted at the business reader who has no experience with XBRL.  The authors and contributors have a very good balance between technical and business perspectives and bring this to writing XBRL for Dummies.

If you want to be sure some specific important topic is covered in the book, if you have a good software product you would like to be mentioned, if you have anything you might like to contribute which would help business readers better understand XBRL, or if you have an excellent resource you would like the book to point to...please drop me an email.