|
Column catchup: XAML and XBRL
Two more of my weekly Strategic Developer columns have spooled up at
InfoWorld.com. 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 InfoWorld.com]
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 InfoWorld.com]
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.
|
