Via Bob Sutor’s Open Blog, news that a French Government report is recommending that all government publications be made available in ODF format. It also encourages their European partners to do the same when exchanging documents.
More, from InfoWorld.
I am back from KDE’s aKademy 2006 held this year on the campus of Trinity College in Dublin. Tuesday the 26th was “OpenDocument Day” and we heard from a variety of speakers on that topic.
The keynote was by Barbara Held from the EC’s IDABC (Interoperable Delivery of European eGovernment Services to public Administrations, Businesses and Citizens), giving a good overview of their important work.
Then through the remainder of the morning and early afternoon we heard a variety of “lighting talks” on various ODF-related topics. You can see the full list and the posted presentations here, but I’d like to highlight a few of them here.
Prof. Lotzi Bölöni from the Networking and Mobile Computing Laboratory at the School of Electrical Engineering and Computer Science of the University of Central Florida presented on the work he and his students are doing to create a comprehensive test suite of ODF sample documents. Each sample document is keyed to the relevant ODF specification page, and each comes with screen shots showing how that feature renders in OpenOffice.org and KOffice. This is an excellent tool for verifying interoperability of the implementations and also for identifying any ambiguities in the specification.
Tim Eves from SIL International presented on their charitable work with producing writing systems for minority languages as well as the fonts and software to support these encodings. Since FOSS word processor like KOffice and OpenOffice will often be used in such contexts, it is important to understand what additional font feature support might be needed in ODF to support this work.
I gave a presentation entitled “A Standard ODF Object Model” proposing an Open Document Developers Kit (ODDK) to enable application developers to become productive quickly with this format. If you’ve read my previous write-up on the topic at XML.org then you know the gist of it. The enthusiastic response I received to the presentation indicates (to me at least) that the time is ripe for such a toolkit. I was followed by Florian Reuter who talked about “ODF Processing Toolsets” and the idea of an ODF InfoSet in a presentation that echoed and extended my ideas. We didn’t plan it that way, but our ideas complemented each other well. While discussing these toolkit ideas with the other conference attendees we found out that KOffice has been evolving in this direction as well, with some toolkit-like API planned for version 1.6 with their Kross scripting framework. I had also just recently heard, from Michael Brauer via Sun’s new OpenOffice team blog that Sun has been thinking about a toolkit as well, in their case thinking how their UNO runtime API could be used.
To give you an idea how how quickly this is moving, when I got back to Westford and checked my email, I already had a note from KOffice’s Marketing Lead, Inge Wallin and KDE’s scripting guru Sebastian Sauer with some Python code demonstrating a templating scenario with an invoice in an ODF spreadsheet document. This was all accomplished, it seems, in the length of a flight from Dublin to Boston. Jet-speed application development, anyone?
So this is great news, that everyone is working on code that can help enhance the application developer’s experience with ODF, and enable ODF innovation beyond the editors, along the lines of the 20 patterns of use I outlined earlier. Microsoft is well-known for their commitment to developer tools and support, so we have our work ahead of us to match that level of focus. For inspiration I recommend this short video clip of Steve Ballmer.
October is almost here. The last quarter. This is the time of year I start thinking of next April 15th and what I can do this year to reduce my taxes via by recognizing some capital losses, making charitable contributions, etc. It also makes me think about taxes in general and how much the tax filing process has changed over the years.
I’ve been a taxpayer in Massachusetts since 1988 or so. At first I filled via paper returns. This invariably involved started with a trip to the Post Office or Library to pick through the stacks of forms to find the ones I needed, and then to make a return trip the next day when I found out that I missed a schedule. I would typically get two copies of everything: one to do the draft work in, and one to file. Quantum Electrodynamics, the music of Arnold Schoenberg, James Joyce’s Ulysses — these were all easy and made sense compared to doing taxes.
Sure, I could have just carted my paperwork off to an accountant and let him deal with the mess. But I’m opposed to that in principle. Taxes are paid by everyone and everyone should be able to do their taxes. Something is wrong with the tax system, democracy, or both if a Harvard grad is not able to figure out his own taxes. But sometimes it was a struggle.
Eventually, in the mid 1990’s (my recollection) the Massachusetts Department of Revenue (DOR) started to support online filing. Initially this was via a proprietary, state-issued, Windows-only client that worked with a dial-up modem connection. It was advanced for the time, but still bare bones, and clunky. I actually still did most of the form by hand, and entered in the numbers into the UI for the final calculations and submission.
Things got interesting a few years ago when the DOR stopped issuing their own client. Instead they promulgated standards for on-line tax submission, issued developer guidelines, a compliance test suite and started certifying vendors who wished to write compatible tax filing software. You can see the software guidelines here.
Now, there are some that say that government mandated standards are evil, that they stifle innovation, remove choice, hurt the consumer, etc.
[G]overnments should not freeze innovation by mandating use of specific technology standards
— Policy statement from Microsoft’s “Freedom to Innovate” network
So it is interesting to see what happened in Massachusetts after they issued standards in this area.
Today, Massachusetts residents have a choice of 11 applications for filing their state income taxes, at all price points. These range from free filing for qualified low-income residents, to low-cost web-based applications for simple returns, to rich client-side solutions for more complicated filings. The full list of compliant filing software is here.
So, in this case, the state-mandated standard did not lead to lack of competition or innovation, but rather led to a thriving market of filing solutions, at a variety of price points and feature sets. The tax-paying public benefited with increased choice of products and feature sets. The DOR benefited with returns that could be processed at lower cost and lower error rates. And software vendors benefited by the creation of a new market in tax preparation software.
This lesson is something to bring to mind the next time you hear the contrary FUD about standards and innovation.
I recently gave a presentation where, in passing, I enumerated a variety of usage patterns for ODF, demonstrating that it had wide applicability beyond the traditional heavy-weight office-like editors. This diversion in the presentation was well-received then, so I offer you a fuller version of these points in blog form.
I am interested in other patterns of use you might have, especially ones that do not overlap the above.
The exercise of producing the above list made it clear in my mind that many of these items should be given more consideration than they traditionally have. For every document created in a heavy or lightweight editor, there may be many other much smaller applications which will need to read the document down the road.
By analogy, this blog entry was created an editor, but the number of readers, indexers, aggregators, etc., that will touch it in downstream processing will far exceed, in number and processing cycles, the effort spent in writing it. So ease of processing, especially ease of reading, is an important consideration for designing and evaluating an XML document format.
As mentioned in a previous post, OASIS and the ODF Adoption TC have set up a web site at http://opendocument.xml.org to act as central resource and repository for ODF information, as well as to be a focal point for the ODF Community to discuss items of importance.
I’ve just contributed my first item there, an essay/proposal about something I’ve been thinking about for a long time now — how to make application developers love ODF. I call it an Open Document Developers Kit (ODDK). You can read the proposal here. Please direct any comments to this discussion thread at XML.org.