Following last week's critique of XBRL, I had an interesting email exchange with David vun Kannon, a manager in KPMG's financial services practice and one of the editors of the XBRL spec. The dialogue went far beyond what InfoWorld's letters column could ever accommodate, so with David's permission, I'm reproducing it here.
David vun Kannon:
I feel your analogy was inadequate and the "too complex" criticism misses the point. XBRL isn't designed to be hand-written, and that level of simplicity is not a virtue in the design space it targets.
As one of the designers of the XBRL specification, I sympathize with your desire for a simple XML format for the exchange of financial and business reporting data. But as your article's lead paragraphs point out, the world of accounting standards is wickedly complex. The design scope of XBRL had to address that complexity, as well as the use of financial data in all kinds of tax and regulatory filings worldwide. Did you really expect something simple from that target?
Here's a recipe for a "simple" financial reporting format:
- assume a single accounting framework
- assume the framework never changes
- assume one currency
- assume one language
- mix content and presentation
- assume businesses will change how they report to fit your design
The above recipe actually works for single application languages where there pis one dominant consumer, such as the IRS' XML format for tax filings. But the world doesn't need a thousand different financial reporting languages. That is the "stovepipe application" thinking that misses the forest for the trees. That is why XBRL is trying to provide a unifying framework.
It is nice to know that your blog can get by using RSS. However, Reuters and Dow Jones can't, and I doubt InfoWorld runs on RSS. For them, there is NewsML. Ever read the NewsML spec? Looked at the latest version of FpML, for describing financial derivatives? An "apples-to-apples" comparison of XML languages would compare XBRL to these languages, because of the breadth of the business problem they are each trying to solve.
There are thousands of companies that report financial results according to US, international and local rules, as well as separate tax reporting. If you wrote every blog entry in four separate languages, with an eye to satisfying a different set of picky editorial rules for each, your blog analogy would be more appropriate.
The companies with financial reporting needs that are similar to your blog example will be served by software, such as Microsoft's Excel add-in now in beta, that manage the complexity for them.
The number of developers that will have to face head-on the complexity of the XBRL spec is low. You can write an XML Schema without delving into the depths of the XML Schema spec. Only the writer of an XML Schema validator has to do that. Similarly, developers at businesses can write XBRL instance and taxonomy documents using tools. Only the developer of XBRL support software has to go the limit with understanding the spec.
Jon Udell:
> It is nice to know that your blog can get by using RSS.
> However, Reuters and Dow Jones can't, and I doubt InfoWorld
> runs on RSS.
As a matter of fact InfoWorld does, in a variety of ways. I'm not convinced Reuters and Dow Jones couldn't either, as RSS is now modular and extensible.
> For them, there is NewsML. Ever read the NewsML spec?
Yep. And it's not small, I agree. I'll also agree that modular extensions to RSS that would bring it to parity with NewsML would yield complexity equal to that of NewsML. However the key difference, in my view, would be a lower activation threshold and smoother growth curve -- i.e., the ability to start with something simple and concrete, and evolve to the more complex and abstract.
> Only the developer of XBRL support software has to go
> the limit with understanding the spec.
The "tools will manage the complexity" argument is always compelling, but also always worrisome to me. Over and over again I've seen stupidly simple formats and protocols triumph over highly-engineered counterparts, especially when -- as I believe is true in the case of XBRL -- the goal is widespread, if not universal, adoption by a broad constituency. We'll probably just end up agreeing to disagree, but I've noted with great interest the evolution of XML specs, in the Web services realm, away from the monolithic and towards the granular and "composable." This seems to me a fundamentally correct way to attack complexity. And XBRL seems monolithic, not composable, hence my reaction.
David vun Kannon:
As background, a paper I gave at XML Europe a few years ago on the design of XBRL 1.0 is still available on the web at http://www.gca.org/papers/xmleurope2000/papers/s26-01.html. While the particulars of XBRL 1.0 have become dated, the motivating sections are still relevant. You might also want to note how much smaller/simpler the 1.0 spec is, compared to 2.1!
I've had to think about the issues you raise since 1999 and the design of XBRL 1.0. There are many different aspects to the complexity problem, including scope of the business problem and choice of base technologies. For instance, I'm asked relatively frequently "Why don't you use RDF?" as if RDF was pixie dust that could be sprinkled on a problem to make its complexity go away. Complexity is conserved.
BTW, a link to your column has been posted to the xbrl-public Yahoo Group. As the only public (non-member) Yahoo Group for XBRL, it attracts most of the newbies and naysayers, and the latter are happily adding to the thread agreeing with you. For the sake of the former, I've posted my response to you over there as well.
I agree with your points on modularity. XBRL is designed so that the simple is simple and the complex is possible. Believe it or not! The "Hello, World" test for a single financial fact is<xbrl namespaces for XBRL, XML Schema Instance, and US GAAP taxonomy go here> <us:assets contextRef="c1" unitRef="u1" precision="18">7</us:assets> <unit id="u1">ISO4217:USD</unit> <context id="c1"> <period><instant>20041231</instant></period> <entity> <identifier scheme="http://www.duns.com/D-U-N-S"> 1234567890 </identifier> </entity> </context> </xbrl>It is hard to point to any part of the above as unnecessary, though most votes go to the precision attribute.
So the use of XBRL by a company is modular, and can expand in a gradual, modular way. I'm not sure if the 2.1 spec is organized quite the way a primer should be. Also, while XBRL is committed to modular expansion into the future, the current spec and conformance suite are monolithic. During the last version design phase, I argued for profiles that would let tools or validators claim conformance to XBRL while not implementing the whole spec. This didn't make the cut. But a properly written intro to XBRL would show the natural breakdown of the parts of the spec and how different parts (different linkbases for example) can be used independently.
I think a big influence on why the spec isn't "officially" modular is that XBRL has succeeded most with global financial regulators, who have typically wanted all the bells and whistles. Indeed, they want modules that aren't finished yet, such as the Formula Linkbase I am designing now. This adoption process has damped the "small is beautiful" psychology and grass roots momentum dynamics that drive some specs to wildfire rates and levels of adoption. Web pages and blogs were pioneered by individuals, not businesses or government departments. True bandwagon dynamics for XBRL will wait until the SEC (the 800 pound gorilla of regulation) requires using XBRL (for external financial reporting) and until the Excel add-in becomes widely available (for internal management reporting and financial consolidation).
So I think we agree far more than we disagree. XBRL is an undoubted challenge to developers. Its linkbases are the first use of out-of-band hyperlinking. For developers used to working with numbers, it is surprising that so much of accounting is navigating a hypertext!
XBRL was advised by Tim Bray in a recent conference keynote to take six months off (or more) and stop inventing/using bleeding edge technology. It hasn't happened, of course, but the market is starting to catch up the spec.
David is right to point out that a government-mandated reporting format is an unlikely source of grassroots innovation. But this evocative statement -- "it is surprising that so much of accounting is navigating a hypertext" -- does make me wonder. Years ago I worked on the first incarnation of a business information product (which still exists) that blended financial reports with news, biographies, and other contextualizing information. It was a read-only product delivered on a write-only medium, CD-ROM. Back then there was no other choice. Now we produce some kinds of hypertext almost as naturally as we consume it. Will we be able to paint financial information on the universal canvas, mixing it with text, charts, math, and other XML brushstrokes? For the sake of our ability to step back and see the big picture, I hope so.
Former URL: http://weblog.infoworld.com/udell/2004/05/10.html#a993