Australian Whole-of-Government Common Operating Environment Policy and OOXML

AGIMO boots OpenOffice but Libre Office reboots OpenOffice?

By Rick Jelliffe
January 28, 2011

Two big stories this week: AGIMO's COE and LibreOffice.

AGIMO is the Australian Government Information Management Office. They are the ones who set policies such as requiring govt web page meet the W3C's WCAG 2.0 guidelines for accessibility, or that open source must be considered equally for procurement, and so on.

They have recently set the cat among the pigeons with the new policy on setting the minimum bar technologies that any Standard Operating environments must provide: the Common Operating Environment. There seems to be many comments along the lines that AGIMO is requiring that government documents use OOXML (Ecma 376), however my reading is that the COE does not do that at all.

What is interesting about the COE document is that it does not mention any product or vendor: it is entirely couched in terms of standards support.* So ISO ODF, Ecma 376, ISO MPEG 4 part 2, and so on. Most significantly, there is no mandating that these are preferred formats for use. The key sentence is

25 A component which is based on a mandatory standard must be included in the SOE image and built in accordance with the platform specific build documentation.


The debate about which open formats should be used inside and outside government is a different one that the issue of which formats a COE must support in order that there is always at least one reliable way for any two SOEs of 2011 to interoperate. I think governments should mandate ODF for external communication and allow an equal playing field for ODF and OOXML (IS29500 Strict) as the preferred position for 2015. The COE is about minimal standards—the pragmatics of fitting in with current infrastructure—, not aspirations or strategic technologies, as far as I can see.

Why choose OOXML instead of RTF of DOC? The answer seems to be in the N-1 policy:

All applications used as part the COE (the System, Core Services and Standard Applications) must be the current and supported version (known as N) or its immediate predecessor (known as N-1). N refers to the major version of an application,

So why choose OOXML instead of ODF? The reason seems to be simply one of weight: 86% of government desktops use MS Office (with no plans to switch suites anywhere that AGIMO could identify). I am not sure that is convincing on its own: I think considerations such as feature set hysteresis must play a role too, given that MS Office supports ODF too. It disappoints me that ODF is not on the COE list too.

Why choose the ECMA 367 OOXML rather than IS 29500 Transitional? Alex Brown asks this question in a blog entry this week, and AGIMO's John Sheridan explains the rationale here: The Office 2007 format is based on the ECMA-376 1st edition and the Office 2010 default format is based on the ISO/IEC 29500 "transitional" standard. Alex points out that things are not so straightforward, that among the improvements in IS29500 are ones which relate to describing Office 2007's data better.

I think Alex is right, but I am not sure that the level of conformance and feature support between suites (whether ODF or OOXML) is at a level of maturity where it would make much practical difference: AGIMO might be better to keep the version of ECMA 376 unspecified.

(The decision by ISO to put OOXML Strict into new namespace has given ODF a breather in the death march to complete ODF 1.2: an extra two release cycle of MS Office before the longer-term standard OOXML gets its foothold. See Doug Mahugh's We will include write support for Strict no later than the initial release of Office 15— is that still the plan? Everything that rises must converge, I hope.)

Rather than looking at what the COE counts in, it is better to see what it counts out: it counts out office suites that support ODF but not read-write of OOXML. In effect, AGIMO is taking a strong stand against the OpenOffice/IBM line (that interoperability is helped by not supporting common formats we don't like) and for the Libre Office approach. OpenOffice's grumbling late support for reading OOXML, let alone writing it, comes across as contemptuous of users.

Which brings us to the second big story: that the first LibreOffice has been released and is available for download. Many of us involved in open source became increasingly concerned about the tendency of corporations to try to keep control with semi-open projects: Java and OpenOffice have both been stifled by this approach. The cracks showed with OpenOffice with the GO-OO distribution, that seemed to succeed in harnessing new features fast, with less politics.

I think Libre Office deserves a serious look, and seems to be the kind of reboot that plays to open source's strengths (participation) rather than its sometimes weakness (political correctness.)

* With the glaring exception of mentioning the PKWARE ZIP standard: this is simply not an open standard. ZIP is such an important component, that there should be an open standard for it, and certainly one that makes it clear to implementers what the large patent-free subset is. In the absence of a real open standard, a proprietary document of a partially patented technology is being used. It only fits in by some heroic squinting.


You might also be interested in:

News Topics

Recommended for You

Got a Question?