[OpenSpending] XBRL for Local Government Financial Reporting: A Response to Friedrich from the Father of XBRL

Sat Sep 14 19:54:43 UTC 2013

I shared Friedrich's article with Charles Hoffman, the father of XBRL.  He
sent me a very thoughtful response by private email, and allowed me to share
it with this list.  Much of this content will appear on Tabb Forum in the
next week or two.

Marc

>From Charles Hoffman:

XBRL has unfortunately earned the reputation it has because of (a) flaws in
the way some regulators implement XBRL and (b) misunderstands of the
business people promoting XBRL.  This is very consistent with what Gartner
calls the "hype cycle".  See this:
http://irwebreport.com/20110309/xbrl-investor-relations/

The following are the realities and truths which should be considered
summarized as succinctly as possible. (You can see the details here on my
blog:

http://xbrl.squarespace.com/journal/2013/3/1/achieving-meaningful-exchange-o
f-information.html )

POINT #1: Achieving meaningful exchange: 

"The only way a meaningful exchange of information can occur is the prior
existence of agreed upon semantics, syntax, and workflow/process rules."

This video made available by HL7 explains this in more detail:
http://xbrl.squarespace.com/journal/2010/8/29/into-to-hl7-video-can-help-you
-understand-xbrl.html 

POINT #2: Formality

If you consider POINT #1, the "rules" can be somewhat of a bottomless pit.
A balance needs to be achieved between practicality (something actually
works) and "formality" (spending so much time creating rules and making
things so complex that no one could ever use the system).  A practical
balance needs to be achieved.

POINT #3: Expressiveness

While it is true that CSV has been around a long time, it is easy to use,
there is lots of support..CSV is not very expressive.  CSV is a "flat"
tabular structure, two dimensional.  Information is "n" dimensional (could
have many dimensions). An OWL ontology is WAY, WAY more expressive in terms
of creating rules to make sure the information is correct (i.e. POINT #1),
but it is much more complicated because of that expressiveness.

POINT #4: Complexity

While "complexity" can never be removed from a system, the complexity CAN be
moved. What I mean by this is that while it is hard to create something like
an OWL ontology, computer software can shield business users from the
complexity in many, many different ways.  One example is the use of
"patterns".  Another is using "application profiles". Another is using the
80/20 rule in terms of creating business rules to assure information
quality.  I could go on and on about this and show you many, many examples.
Fundamentally this all boils down to the this one fact: "XBRL software
vendors" are building the wrong software; they have built XBRL technical
syntax editors instead of "digital financial reporting" applications or
"digital business reporting" applications.  This problem is understood by
some software vendors who are now building the correct software, others are
understanding, everyone will be forced to move in this direction due to
market pressure.

POINT #5: Guidance-based, semantic-oriented, model-driven, business report
authoring enabled by "semantic web" technologies

Authoring business reports in the future will be as different as the
difference between creating a photograph when you used a darkroom filled
with smelly and chemicals as contrast to using "Photoshop".  What you can do
with a business report will also be as different as what you can do with a
photograph printed on a piece of paper and a photograph expressed digitally.
The key is "metadata" and applications which understand and therefore
leverage that metadata.  For example, Microsoft Word knows ZERO about
creating a financial report.  Nothing.  Guidance-based, semantic-oriented,
model-driven financial report authoring tools (think TurboTax) will have:

.           Knowledge baked in

.           New knowledge can be inferred/added

.           Agility to adapt to ever-changing conditions

.           Semi-automated data integration

.            Machine intelligence 

You may not be able to imagine these applications, or maybe you can.  But
when you see an application working correctly, leveraging a rich set of
metadata (which you cannot even express using CSV files), it will be very,
very easy to grasp these ideas. Read the documents linked do on this blog
post:
http://xbrl.squarespace.com/journal/2013/1/2/smart-dataapplications.html 

XBRL is only part of a much, much broader trend of digital business
reporting and digital financial reporting.  That is part of an even bigger
trend, "digital".  Electronic medical records is an example of the much
broader trend.  Electronic medical records has many of the same issues as
what the SEC is trying to do with XBRL-based financial filings.  The
accounting profession and SEC is much, much further down the path than
electronic medical records from what I can see.  Electronic medical records
(EMR) are not "interoperable" or exchangeable between systems yet (XBRL is).
There is no international standard for EMR (there is for financial
reporting, XBRL).

Generally, people are having the WRONG DISCUSSION!!!  They are discussing
syntax (i.e. CSV, JSON, XML, etc.) and they SHOULD be discussing "how the
heck are we going to articulate and management semantics".  THAT is the
discussion which needs to occur.  This is VERY, VERY useful stuff.  This is
not about saying that CSV is bad and that XBRL is good.  They are two
different tools for different problems.  Using the wrong tool to solve a
problem is bad as well as inappropriately using a tool is bad!

The "Government Linked Data Working Group":
http://www.w3.org/2011/gld/wiki/Main_Page. That is another approach:
RDF/OWL.  Not good or bad, just different.

The goal as I see this is success.  Success means (for business people) cost
effective, easy to use, effective, robust, reliable, repeatable,
predictable, scalable, secure (when necessary), auditable (when necessary),
practical, business information exchange by business users between business
systems.  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/openspending/attachments/20130914/618e9687/attachment.html>