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.