Stuff Michael Meeks is doing

The UK Government has solicited feedback on its (excellent) proposals. I've published my response here too to make it somewhat more legible.

Preamble

I was profoundly encouraged by the depth of understanding underlying the Cabinet Offices' recommendation to use ODF for the default format for saving UK Government documents, which I support enthusiastically. It can be viewed as HTML here:

Disclosure

• I was a Novell Distinguished Engineer, and Novell's representative on ECMA's TC45 during the initial OOXML standardisation work; however I do not speak for Novell.
• I serve on the board of The Document Foundation who create LibreOffice, but don't speak for them here.
• For much of the last decade I lead first Novell, then SUSE's engineering team on OpenOffice then LibreOffice. These teams did significant work on both ODF and OOXML.
• I am now General Manager of Collabora Productivity a UK based SME focused on enterprise support of LibreOffice in addition to development consulting around the product.
• I'm a UK citizen.

Summary

• The requirement to share information in ODF is a great strategic choice for the UK government; I wholeheartedly support the recommendations here.
• The emphasis on other open, or trivial formats for exposing information to customers in forms that are susceptible to easy analysis, scripting, etc. is great. Formats such as CSV, TXT and HTML provide an ideal form for users to consume government data.
• I believe that browser based editing is and is likely to remain immature, and thus the recommendation of ODF for information sharing by traditional means is an ideal solution.
• By mandating ODF, no user will be required to purchase software to have a high-fidelity interaction with their Government. This is not only due to the presence of excellent zero-cost ODF implementations, such as LibreOffice, but also a smaller scope of document features which ensures that multiple high-fidelity implementations are possible from various vendors.

ECMA, TC45, and OpenXML standardisation

• As a member of TC45, the remit of the committee producing ECMA-376 was emphatically limited to: full compatibility with the existing Microsoft XML file format as submitted cf. http://www.ecma-international.org/memento/TC45.htm i.e. it was a pure documentation task.
• As such, frustratingly, no significant changes to the XML representation were possible, despite trivial changes being desirable in several instances. The scope made it possible only to improve the documentation of Microsoft's submission.
• Large numbers of features in an Office Suite require their data to be stored in the file format. As such, it is possible to read a file-format description as a set of Office Suite features and capabilities.
• ECMA-376 is one such, extremely detailed, and amazingly comprehensive specification of a single vendor's feature-set and implementation in Microsoft Office. It codifies innumerable behaviours of a single proprietary application.
• Such was the remit of the ECMA TC.
• As an aside, this is no bad thing. It is useful to have an extremely detailed specification of Microsoft Office. Microsoft is to be commended for releasing that, and indeed moving to a more open, XML based format. It was enjoyable and worthwhile engaging with Microsoft in good faith and working together on the best possible disclosure of information relating to those formats. Microsoft applied some excellent and dedicated engineers to that process.
• Having said that, the result, as continued into the derived ISO standard (even in 'strict' mode), and as circumscribed by the remit of TC45 is an emphatically partisan description of the feature set of a single vendor's implementation.
• As such, those who mandate high fidelity interoperability between document editors using such a standard are essentially, as of the present time, mandating the use of Microsoft Office.
• This is due, primarily, to the very significant engineering effort required to get a high fidelity implementation of the standard.
• While this is something that LibreOffice participants continue to invest heavily into, with a reasonable degree of success, building on a legacy of Microsoft investment in that work; it is still the case that significant areas of the OpenXML standard find no supporting implementation in an Office Suite anywhere outside of Microsoft Office.

Open Standards and avoiding vendor capture

• Having seen how it is possible for a vendor to use the ECMA/ISO fast-track to essentially standardize every detail of their own implementation it is then interesting to contrast that with ODF.
• Clearly ODF has a heritage rooted in the OpenOffice code-base, however the work of the ODF TC at OASIS is emphatically not one of describing a single vendor's existing implementation.
• Instead at OASIS the standards process is truly open: multiple Office Suite implementers (including Microsoft) provide their views on everything pertaining to document representation. Everything is on the table for discussion, change and improvement in ways that impact both the textual specification, but also the implementations of that standard.
• In addition the ODF standard is itself significantly simpler and as such is far more susceptible to implementation; in consequence fostering constructive competition.
• This is popularly reflected in discussions of the contrasting size (in pages) of the competing specifications. Each page can be seen as requiring significant corresponding development work to implement the feature with a high fidelity.

A language analogy

• The structure and content of both ODF and OOXML documents is described using what is ultimately an XML language.
• As such, it may be interesting to compare the OOXML standard to 'Classical Greek' - a highly inflected, extremely complex language which, to add insult to injury is frequently written in capitals with no inter-word spacing.
• Aside from those who have mastered the delightful intellectual challenge such a language presents, its full depth is sadly inaccessible to many.
• ODF in contrast could be seen as more of the 'English' of document content standards: taking inspiration and heritage from many different languages; it is significantly simpler to learn, and communicate with.
• The UK Government laudably works hard to present document content in 'Plain English'. Transposing this same concern for wide accessibility into the underlying document structure would be an appropriate way to extend access to all technical format consumers and producers.
• The argument that a large number of existing documents are structured in an unfortunate and vendor specific form should be an imperative to speed their transition to something more accessible; not an argument for retaining the status quo: where a veneer of document interoperability is achieved by using a single vendor's product.
• The translation analogy has a further application - which is that of needing an authoritative version. It is good to allow users to request documents translated into other formats in response to a specific request. As with any translation though, it is important to have a canonical original document format which should be ODF.

The importance of ODF as a single document standard

• An important role of standards is to enabling genuine competition in this important space, which in turn can drive down cost.
• By mandating only ODF, this benefit will be realised, via a widely based, open standardisation process with input from many implementers and consumers of productivity software.
• While a request for standards 'choice' by including OOXML seems superficially attractive, adding OOXML would be to remove the requirement for a truly open, vendor neutral standard.
• The existing proposal does not fall into the trap of re-inforcing the status quo by allowing a vendor specific standard with only a single high fidelity implementation.
• The existing proposal already wisely provides users with the choice to request a translation of their document to another format.
• Encouraging individual Government departments to make a choice for their users of a standard that would require users to have expensive software that can handle any of the significant, and often arbitrary complexity of OOXML documents would be unfortunate. Indeed that would nullify any competitive benefit of a truly open standard.
• This can, perhaps, be seen in the MOD's aversion to ODF, despite this being an accepted NATO standard for document interchange.
• As such, I believe that the impact of arguing for a 'choice' of standards in itself leads to a lack of choice. It is by far preferable to have a choice of implementations of ODF.

Macros expose implementation details

• While I agree that simple macros often form a useful part of document workflows, macros are typically profoundly problematic. As such it is great to see the requirement that: "Macros should be avoided wherever possible, particularly when sharing documents."
• While LibreOffice provides reasonable support for simple VBA macros, and naturally has built-in Python / Basic and other scripting support - these are not standardized in either ODF or OOXML.
• In the case of VBA inside OOXML macro enabled files, the macro text is stored in several binary streams with partially documented formats, making the round-trip interoperability of macros extremely problematic.
• Macros, as programs, tend to propagate very significant details of the specific implementation of a given document format and its structure in various ways.
• Limiting the requirement to use Macros in documents for interchange wherever possible is to be applauded.
• Textual macros are usually rather better from an interoperability perspective than operating system specific COM and ActiveX components that can be embedded into OOXML documents.

Device and platform choice

• ODF is usable across a large number of devices and platforms
• LibreOffice has an excellent ODF implementation supported on Windows, Mac and Linux, it also has promising prototypes for iOS and Android; although other ODF applications are available for mobile platforms.
• LibreOffice is also provided by Roll-App as a browser based on-line office solution for other operating systems and device form factors.

Conclusion

• In conclusion, the Cabinet Office's proposals have great merit, are balanced and well rounded.
• If implemented, they would allow Officials within government to work efficiently, while ensuring that Users do not have costs imposed upon them.
• It is my belief that these proposals, when implemented will also stimulate investment and innovation around the Office Productivity space, and exceed the expected benefits.