Blogger: Guy Creese What
follows is part 3 of Burton Group’s response to the ODF Alliance’s response
to our “What’s
Up .DOC?” overview report on ODF and OOXML. This post
covers points 13-18. Points 1-6 are covered in Part 1
(which includes a short preamble); points 7-12 are covered in Part 2.
To make it easier for readers, we’ve listed the ODF Alliance
comments in italics, followed by the Burton Group replies in a
Blogger: Guy Creese
What follows is part 3 of Burton Group’s response to the ODF Alliance’s response to our “What’s Up .DOC?” overview report on ODF and OOXML. This post covers points 13-18. Points 1-6 are covered in Part 1 (which includes a short preamble); points 7-12 are covered in Part 2. To make it easier for readers, we’ve listed the ODF Alliance comments in italics, followed by the Burton Group replies in a non-italicized font.
At the bottom of page 17, the
authors present a list of prior protocol and API disputes with Microsoft, such
as VIM, IDAPI, OpenDoc, etc., and suggest, “In these and other earlier
encounters, when Microsoft's competitors sought to collectively compete with
Microsoft by leveraging standards, the everybody-but-Microsoft standards have
generally failed to achieve significant market momentum.”
The examples given are ancient history.
Also, note that VIM (1993), IDAPI (1992) and OpenDoc (1992) were not formal
standards. The report fails to note that the market has evolved in the past 15
years and that that customers are better educated in the liabilities of vendor
lock-in, and are now more aware of the important role that open standards play
in ensuring interoperability. Whereas 15 years ago, it was enough to require
the use of COTS software, today procurement is increasingly requiring the use
of open standards.
In our opinion, it would be far
better to look at the example of Internet and web standards to see how
Microsoft's competitors, and Microsoft itself, have succeeded. ODF has the
potential to be the same competitive force for office productivity
applications, using the same standards-based approach.
earlier attempts by groups of Microsoft competitors to establish control in key
domains through consortium standards are pertinent to the ODF/OOXML debate. In
our experience, enterprises spend money to embrace standards only when they
feel that proprietary formats significantly constrain business action. With
Microsoft Office’s large market share, the constraints are minimal, as
virtually every partner that an enterprise would do business with can read and
write Microsoft’s longtime binary formats, and increasingly its OOXML formats
as well. In short, many enterprises do not see the need to move to ODF to gain
interoperability, as in their view they already have it (albeit by using a de
facto standard). That said, some organizations are worried about depending on a
de facto standard, and so are demanding standards-compliant solutions, of which
both ODF (ISO) and OOXML (Ecma) are options.
it would be helpful to see more information from the ODF community on why ODF
is a better fit for customer requirements, and less positioning based on the
assumption that Microsoft will invariably seek to inappropriately or illegally
subvert standards processes.
On page 18 the authors introduce a
section by saying, “If productivity application evolution had peaked around the
feature set of Office 97, and if there weren't exabytes of files captured in
earlier Microsoft Office file formats, it's possible that ODF could have
succeeded as a global standard for productivity application file formats.”
This point is not argued, it is just
asserted, without any supporting evidence. We suspect that many of the
arguments being made today in the report for Microsoft and against ODF would
also have been made in 1997 had we been in that situation then. The network
effects were smaller, but they were big for the time.
are by definition subjective; we stand by this projection in question, and
believe there is ample room for innovation in productivity applications.
Later on page 18 the authors state,
“OOXML will be more pervasive than ODF for several reasons. It's a better
form-follows-function fit for most productivity application usage patterns”.
This is a bold claim without
argument or analysis to back it up, as far as we understand it. On what basis
is the assertion that more than 50% (“most”) uses of documents cannot be
represented in ODF? We believe, for example, that the entire Burton Group
report could be represented in ODF without any loss in fidelity. Do the authors
believe that more than 50% of the documents in use, today and legacy, are more
complex than their 37 page report?
established the context for our projections and recommendations – Burton
Group’s customer audience, which is primarily composed of large commercial,
government, and higher-education organizations. We believe these large
organizations do indeed routinely exploit beyond-the-basics capabilities in
word processor, spreadsheet, and presentation applications. The context for
Burton Group’s overview, incidentally, is a good example of a non-revisable,
print-oriented context, one we believe is well suited to the PDF file format.
Further on page 18, the authors
note, “OOXML will gain market momentum as vendors such as Altova and Mindjet
introduce products that support OOXML. Altova, the leading vendor of tools for
XML-focused developers and designers, added OOXML to its XMLSpy product line in
This statement misrepresents market
momentum by citing niche application support. While they may be fine products,
will it really be the case that an XML programmer's editor and mind map
software will drive the adoption of an XML office document format like OOXML?
Will someone in a university or a business office adopt OOXML as a word
processor format because they can edit it in Altova? That would be remarkable,
considering the relatively small percentage of all end users who edit XML at
that level. MindJet already supports the legacy binary Office formats. By what
mechanism does MindJet supporting OOXML cause someone to move to OOXML?
Certainly, if a user wants to move to OOXML, having this support removes a
potential obstacle to migration. But it alone can do nothing to cause market
momentum. We believe, in fact, that many users will simply stay with the .doc,
.xls, and .ppt formats if they wish to use Microsoft formats, as was
recommended by the recent Becta report in the UK.
We did not
say these applications would “drive the adoption” (be the main force); we said
they would increase market momentum (add speed to an already moving body). Our
point was to note the power of a surrounding ecosystem that is OOXML-compliant.
The presence of Office 2007 has already started the creation of OOXML
documents; the ability of many tools to accept or generate OOXML files will
make the use of OOXML more attractive, especially as enterprises recognize that
XML formats allow them to programmatically work with documents much more easily
than they could in the past. That’s why we don’t believe enterprises will stay
with the legacy .doc, .xls, and .ppt formats—XML-based formats (whether ODF or
OOXML) are intrinsically more useful than their binary counterparts.
initial stage of adoption, both ODF and OOXML are on a level playing field, by
dint of being XML formats. However, over time, if complementary
applications—whether they’re an XML editor, a mind-mapping tool, a report
generator, etc.—support OOXML and do not support ODF, then the network effect
starts to take over and OOXML will gain market momentum as enterprises decide
that the OOXML ecosystem is larger—that their interoperability and programming
options are less limited. While there are more office suites that are
ODF-compliant than OOXML-compliant, OOXML seems to be winning the ecosystem
battle, because these ecosystem vendors (characterized as niche vendors by the
ODF Alliance) are implementing OOXML support (and postponing ODF support) based
on customer demand. (As a rough comparison, here is a list of OOXML-compliant
products; here is a list of ODF-compliant
products.) In talks with us, Altova co-founder and CEO Alexander Falk noted
that Altova had not seen customer demand for ODF; Gareth Horton of Datawatch
noted the same thing in a comment
on a blog post: “There was no interest from our users. In the future, that may well change,
and we will duly implement ODF. Until that becomes a decision we can make on a
sound financial basis, we can't expend development time on it.”
Page 19 says that “ODF represents
laudable design and standards work. It's a clean and useful design, but it's
appropriate mostly for relatively unusual scenarios in which full Microsoft
Office file format fidelity isn't a requirement.”
The authors here contradict their
own argument. On page 8 they stated, “In many cases, the productivity
application file is ephemeral, used only to present and capture user actions
for business transactions that are ultimately captured in enterprise systems
rather than stand-alone productivity application files (that is, the files are
destroyed when the transaction is complete and captured in other systems of
record).” We believe, and follow the practice of, authoring a document in ODF
and publishing it as a PDF file. For us this is a not an “unusual scenario” nor
does it necessarily involve “full Microsoft Office file format fidelity,”
Further, what does “full Microsoft
Office file format fidelity” even mean? This seems like a circular argument,
that ODF is only useful in cases where you are not using Microsoft Office file
working to compile a detailed list of interoperability issues, but for now
reiterate the context we established for the report: large enterprise
organizations that routinely engage in workflow scenarios that entail sharing
Office file formats both inside and outside the company. Because most
organizations are using Microsoft Office (and hence OOXML in the long run), we
view using ODF (and hence introducing OOXML to ODF and ODF to OOXML translation
processes) as a needless step that may introduce information loss. Examples of
potential information loss in going from OOXML to ODF within a word processing
document include the loss of image rotation, text wrapping in tables, and text
watermarks. Examples of potential information loss in going from ODF to OOXML within
a word processing document include the loss of hidden sections, text blinking, and
table columns (ODF supports up to 8, 192 columns; OOXML supports up to 63). For
a more detailed list of translation issues, see the Known Issues page
on the Open XML/ODF Translator Add-ins for Office web site.
On page 21, the authors claim, “Even
Adobe's own Buzzword service will likely add support for OOXML—again, if only
for Office 2007 file compatibility.”
This tells only half the story,
again. Adobe has stated publicly that it plans on adding ODF support. The
cherry-picking of statements, ignoring positive facts about ODF, while
speculating on positive futures for OOXML, is puzzling and goes against the
paper's claimed position of objectivity and vendor neutrality.
This was an
inadvertent omission on our part. Adobe is well known as an ODF advocate—it
serves on the OASIS OpenDocument Technical Committee—and in the course of
writing this section we assumed Adobe would be supporting ODF. We should have
made that assumption explicit. Because ODF support was a given to us, that’s
the reason for the phrasing, “Even Adobe’s own Buzzword service will likely add
support for OOXML…”. We thought it notable that a vendor strongly identified
with ODF and PDF would also be supporting OOXML.
In fact, a
test version of Buzzword (Preview 7) already supports OOXML, according to a thread in the
the Buzzword Discussion Forum. While Adobe has officially announced that Buzzword
will support ODF, it doesn’t appear that such support is in the product yet.
There are also issues not raised
that cause concerns. For instance, why is there no discussion on accessibility
issues raised by the disability community with respect to office documents?
These issues have raised worldwide consciousness of the impact of information
technology decisions and standards on the lives of people with disabilities. We
hope it is not because the authors did not wish to acknowledge either (1) the
issue's importance, or (2) that ODF v1.1 has established a new high water mark
for document formats, a high water mark that should not be allowed to recede
with the acceptance of anything less from any other office document format.
For accessibility concerns, we also believe Microsoft’s recent success with the DAISY Consortium (see, e.g., https://www.disabilitycoordinationoffice.com.au/content/view/881/295/) is a useful example of how OOXML can be used to advance accessibility for all productivity application users. We certainly didn’t mean to discount the importance of accessibility.