An XML spreadsheet parable

Amidst the controversy over XML formats for office documents, it's important not to lose sight of the fundamental benefits that accrue simply from using XML. Michael Tiller has a nice ancedote that drives home the point. Here's the setup: a small engineering firm, Excel expense reports, each must be dispensed on demand to an employee and coded with a unique number. And here's what Michael did:

I took the Excel spreadsheet she gave me (in .xls format) and wrote it out in Microsoft's new Excel XML format. Then I uploaded it to the Zope server and turned that XML into a Page Template. Then, I could apply any TAL transformation I wanted to it.

Very cool.

So, I created a very simple Gadfly database that keeps track of expense report requests so that each one would get a unique ID and then I wrote a tiny Python script to generate the unique ID based on the state information in the database. Once all this was in place, I just added a very simple set of TAL directives to the original template and voila...each request generates a unique Excel document. [Michael Tiller: XML, web services, and business processes]

TAL is the Zope Template Attribute Language. It's used by Zope-based content management systems, like Plone, to enable XML or XHTML documents to function as CMS templates. The output of a transformed template is, of course, normally a web page. Here it's a spreadsheet.

Michael notes that downlevel Excel clients can't read it but, when Office 12 makes XML the default format, this downlevel support should appear for pre-Office 2003 versions.

The Plone scenario is, of course, just one of a million different ways to skin this particular cat. That diversity of options is huge win, regardless of how the format tussle plays out.

What I like about this tiny example is that it nicely represents how spreadsheets are mostly used in the real world -- to do simple things, like add columns in expense reports. Whether or not Microsoft decides to officially support the OpenDocument format, it's hard for me to imagine that transformations between it and Excel's SpreadsheetML -- for all the basic functionality, at least -- won't be trivial and ubiquitous.

Granted, I've internalized the idea of XML transformation to the point where I tend to regard two formats related by a transformation as, effectively, the same thing. But that's precisely the point. It's just data. Exposing it as XML matters more than how exactly we do that.

Former URL: