Column catchup: XAML and XBRL

Two more of my weekly Strategic Developer columns have spooled up at Both discuss XML dialects, but the two dialects are written by very different kinds of people. XAML, Microsoft's eXtensible Application Markup Language, is for software developers. XBRL, the eXtensible Business Reporting Language, is for accountants.

Why Microsoft should open XAML

Here's a crazy idea: Open-source the WPF/E [Windows Presentation Foundation/Everywhere], endorse a Mono-based version, and make XAML an open standard. Why? Because an Adobe/Microsoft arms race ignores the real competition: Web 2.0, and the service infrastructure that supports it.

The HTML/JavaScript browser has been shown to be capable of tricks once thought impossible. Meanwhile, though, we're moving inexorably toward so-called RIAs (rich Internet applications) that are defined, at least in part, by such declarative XML languages as Adobe's MXML, Microsoft's XAML, Mozilla's XUL (XML User Interface Language), and a flock of other variations on the theme.

Imagine a world in which browsers are ubiquitous, yet balkanized by incompatible versions of HTML. That's just where RIA players and their XML languages are taking us. Is there an alternative? Sure. Open XAML. [Full story at]

XAML, uniquely among XML dialects for GUI layout, is a .NET language that, like C#, works with the .NET Framework and compiles down to Common Language Runtime instructions. That's why opening XAML in any meaningful way would also require a rapprochement between Microsoft and Project Mono. I'm not going to hold my breath waiting for that to happen. But still...what if?

XML for business reporting gains momentum

Two years ago I wrote an unflattering report on XBRL (eXtensible Business Reporting Language), an emerging standard that aims to improve the speed, accuracy, and transparency of business and financial reporting. I applauded the goals, as we all should in the wake of Enron and other scandals, but worried about the complexity of the 151-page XBRL specification, its aggressive use of esoteric features of XML, and its reliance on accounting "taxonomies" defined by committees. I've too often seen these kinds of ambitious efforts stumble and give way to simpler approaches. SGML gave way to XML, for example, and while XML itself offers many advanced features, its most successful application -- RSS -- uses none of them. Would XBRL wind up being used mainly by what one wag called a "master race" of consultants and accountants? [Full story at]

In last week's podcast, XBRL's inventor, Charlie Hoffman, assured me I'm not the only one to express these concerns. Just this week, for example, when the SEC announced its Request for Proposal for the development of XBRL-based software, Dave Winer echoed them:

Sounds like the SEC is wanting to re-invent RSS?

Although I felt and to some extent still feel that way about XBRL, I have a much more complete understanding of the issues after researching, recording, and editing the podcast. It runs way longer than the others in my series, almost 70 minutes (edited down from 90), but I think the material warrants that lengthy treatment. Charlie Hoffman doesn't want to reinvent RSS, he wants to reinvent accounting, and he speaks as an accountant not an XML geek.

Former URL: