Blogger: Guy Creese
What follows is part 2 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 7-12. Points 1-6 are covered in Part 1 (which includes a short preamble); points 13-18 are covered in Part 3. 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.
Page 13 says, “In terms of
productivity application model concerns, ODF is primarily focused on content
and presentation domains, and it is far less useful for scenarios requiring
advanced structure and behavior capabilities. For example, ODF (currently in a
1.1 revision) supports a single table type for use within document,
spreadsheet, and presentation applications.” The authors fail to make a
convincing argument here, in our opinion. Taking a benefit of ODF and declaring
that it is a liability, but without any argument, is puzzling. Most experts
would say that, structurally, a table in a word processing document, a
spreadsheet and a presentation share a number of factors in common that express
their “tableness” such as an addressing mode by row and column, the ability to
adjust row heights and column widths, the ability to have background colors,
text content, etc. Good analysis and and elegant design, (an art not a science,
but still one with established norms) calls for common abstractions to be commonly
represented. So the fact that ODF has a single table model is a virtue of the
format, not a liability. Note that there is nothing that requires the
application to make a table in the user interface appear the same in all three
applications. ODF is only defining the underlying storage model, and a table is
a table is a table. There is no need for making this more complicated than
necessary. Conversely, examining why a single standard unnecessarily includes
redundant representations of the same basic concept in three different areas
would be very useful, if it can be justified. It would lend balance to the
arguments presented. Such redundancy would tend to make a standard much longer
than expected and increase the development complexity, unless you already
happen to have an implementation.
issue is a subjective architectural call; we do not believe there is one and
only one model for tables used in word processing, spreadsheet, and
presentation productivity application domains. While there are baseline
capabilities common to all styles of tables, a table within a word processor
typically has less functionality (e.g., basic formatting, rudimentary
summation) than a set of cells within a spreadsheet application (more
sophisticated formatting, complex formulas that generate the numbers displayed).
Given the different expectations that users have of tables (depending on which
application they’re using), we believe argues for separating the underlying
designs. In our view, the overriding goal is to support the way people work—largely
driven by habits developed when using Microsoft Office, like it or not—rather
than have a design that suboptimizes expected behavior or overcomplicates the
To take an
example, let’s assume that word processor table complexity is a 5, spreadsheet
table complexity is a 10, and presentation table complexity is a 3. For a
universal architecture to effectively work across all three applications, the
specification needs to support a 10 score—adding needless complexity to the
word processing and presentation formats. An alternative is to support a 5
score—which then shortchanges functionality within the spreadsheet application.
Separating out the table specification for these three applications strikes us
as an effective way to achieve “form follows function”: avoiding needless
complexity within the file format specification while at the same time
delivering sophisticated enough payloads that will support expected application
behavior. We also believe ODF’s model will eventually evolve to be specialized
for the different domains to a point at which it’s not very useful to point to
a simple root table.
Further on page 13 the authors
state, “...it's essentially impossible to get ODF proposals approved if they're
not also supported in OpenOffice.org, and further noted that Sun closely
controls OpenOffice.org (much as it also holds control over Java).”
This is demonstrably false, and the
use of unnamed “vendors” as sources does not eliminate the need for doing basic
fact checking on such claims. Rumors and innuendo do not objective analysis
First, on the control aspect, note
that ODF 1.0, the standard, is owned and controlled by OASIS, a standards
consortium of over 600 member organizations. Sun is just one company among many
members. Indeed, for most of the development of ODF, Microsoft was on the Board
of Directors of OASIS.
Second, OASIS is a corporation. It
is legally bound to its Bylaws. There is no arbitrary control by member
The ODF TC is co-chaired by an IBM
employee and a Sun employee, and is regulated by the OASIS TC Process document,
which is publicly readable by all 8 and has clear rules of procedure and
The ODF TC has three subcommittees.
The Accessibility SC is co-chaired by IBM and Sun, while the Formula
Subcommittee and the Metadata Subcommittee are each chaired by individual
members of OASIS who are not affiliated with any large corporations.
Voting rights in the ODF TC, for accepting or rejecting features, is currently as follows:
- Sun – 3 voting members
- IBM – 4 voting members
- Individuals – 3
This can easily be verified at the
OASIS ODF TC website.
Is sharing the chair position on the
TC and on 1 of 3 subcommittees considered “closely controlling”? Is having 30%
of the votes considered “closely controlling”?
As for proposals being accepted into
ODF, we note that all three major features for ODF 1.2, RDF metadata,
OpenFormula, and enhanced accessibility, are new proposals which have not been
yet implemented in OpenOffice. Moreover, the ODF TC is currently processing a
set of features requested by the KOffice open source project. So the assertion
that it is “essentially impossible” to get new features into ODF if they are
not already supported by OpenOffice is not true. This error is unfortunate and
needs correcting through rigorous fact checking, as do the others, in our
Oddly enough, this particular error
occurs in several places. A search of the report for the word “control” shows
it used six times, once in reference to “Chinese communists” and five times in
reference to Sun Microsystems. Note, however, that no mention is ever made of
the strong direct control Microsoft asserts over OOXML, its having sole
chairmanship of the Ecma TC45, and its having secured a committee charter that
prevents any changes to OOXML that are not compatible with Microsoft Office.
Again, we're puzzled by the
inaccuracy on one hand and the lack of balance on the other.
We were not
expecting to be told that Sun had significant sway over the standard, but several
people told us that (spread across more than one ODF-oriented vendor), which is
why we noted it in the report. As the ODF Alliance notes, IBM and Sun—two of
Microsoft’s most powerful productivity application archrivals today (as well as
partners to Microsoft in myriad other domains, e.g., Web services-related
standards initiatives)—collectively control 70% of the votes in the ODF TC
which determines if proposals will be accepted or rejected. This suggests there
is ample opportunity for conflicts of interest.
On page 14 the authors state, “Note
that it wasn't possible for Microsoft to embrace ODF during this period, as
Microsoft's investment in XML file formats was long underway before ODF became
an OASIS standard in 2005 (and because of Microsoft's need to maintain
compatibility with earlier Microsoft file formats).”
This contradicts the author's own
presented timeline. The ODF Technical Committee was created in OASIS back in
2002. There was clearly ample opportunity for Microsoft to join and influence
the evolution of ODF. Since Microsoft was on the OASIS Board of Directors, they
had significant opportunity to both know about and participate in what was
happening in the development of ODF. It's unfortunate that they chose not to
lend their expertise to this industry community effort.
better phrasing on our part would have been, “Note that it wasn’t possible for Microsoft
to embrace the ODF standard during this period, as Microsoft's investment in
XML file formats was long underway before ODF became an OASIS standard in 2005.
After the ODF standard was approved, Microsoft didn’t embrace it due to its
desire to maintain compatibility with earlier Microsoft file formats.”
possible adoption of ODF by Microsoft splits into two phases. Microsoft’s first
XML features in Office appeared in Office 2000, a vast development project that
was underway (1998) four years before Sun released OpenOffice (2002), the
productivity suite that contained the file formats that became the genesis of ODF.
Put another way, ODF as a standard didn’t exist even as a gleam in someone’s
eye until November 2002—and ODF didn’t become an OASIS standard for another two
and a half years (May 2005). Therefore, it was impossible for Microsoft to
include ODF support in Office 2000, Office XP, or Office 2003, since ODF didn’t
exist at the time. The first opportunity for Microsoft to include ODF in one of
its office suites was in Office 2007—and it didn’t do so at that time because
it felt ODF didn’t contain the necessary payloads to support the Office
functionality that its large installed base expected.
Page 16, says “Since ODF is less
compatible with the earlier binary Microsoft file formats than OOXML, file
format translations involving ODF can result in the loss of file fidelity, a
constraint that limits ODF's utility for organizations that need to support
file-based workflow involving Microsoft and non-Microsoft applications.”
The statement that ODF cannot
represent the contents of legacy documents with full fidelity is false.
Further, it ascribes a fault to ODF as a format that is really an application
ODF, using the defined extensibility
mechanisms in the ODF standard, can represent everything in Microsoft's legacy
binary formats. What in practice makes this difficult is that the proprietary
legacy document formats are poorly documented and have been historically
withheld from competitors. On the other hand, OOXML itself cannot represent all
legacy formats without extensions. Extensions are required for features such as
scripts, macros, DRM, etc., as the authors point out earlier in the report in
reference to .XLSM documents. But if ODF can use extensions, it is just as
capable of representing legacy binary formats as OOXML is.
loss because of file translation can be due to inadequate payloads in the file
formats, as well as due to application issues. However, no matter what the
underlying engineering reason, organizations still hate to look at Document B (a
translation from Document A) and recognize that something was lost in the
translation—or even worse, suspect that something was lost. And as of today,
there can be information loss when translating between the two formats (see the
page on the Open XML/ODF Translator Add-ins for Office web site).
for Microsoft’s binary file formats have been available for free since 2006 (as
long as the requester was willing to send an e-mail to Microsoft; see KB 840817). With
Microsoft moving towards putting them up as a download, that will make the
process even easier, and we expect that higher fidelity adapters/translators
will be available in the future.
definition, models are abstractions of complex things. A model’s core
capabilities—note we said “core”—are described by what’s in the model, not by
what is possible through extensions. While extensibility is good and desired,
this is typically reserved for optional or less important features.
example, a pilot can take an airplane not designed for taking off and landing
on water and modify it to fulfill that need by removing its wheels and putting
on pontoons. However, that modification would be time-consuming and probably
expensive. We would claim that a seaplane (that includes both wheels and
pontoons in its design, and the ability to select one or the other) is a richer
model for flying around landscapes dotted with lakes. So, while it’s true that
both planes can handle the requirement, we suspect that a pilot flying hunting
parties around in Minnesota would view the seaplane as the better design for
his specific needs.
appreciate that extensions make ODF more capable of handling Microsoft’s binary
formats, we would contend that OOXML is better designed—from the beginning—for
reference to the comment about scripts and macros, those capabilities became
extensions in Office 2007 and OOXML because Microsoft deprecated them due to
Page 17 says of the OpenDocument
Foundation, that “It was unable to successfully address requirements for
capabilities related to workflows with Microsoft Office applications, however,
and parted ways with the OASIS ODF-TC after it failed to gain approval for
several proposals designed to make ODF more capable for addressing
full-fidelity file format operations involving Office clients.”
This statement is misguided in its
omissions. First, the authors failed to note that the ODF TC evaluated the
Foundation's proposals at great length, and were not persuaded that these
changes would in fact bring the fidelity benefits claimed by the Foundation.
Second, even some former Foundation members, when put to a vote, disapproved
the proposal. Third, the vote was not against interoperability. It was an
evaluation by the technical experts on the TC that the proposal would not work.
This was clearly a controversial
issue. Why was only one side presented? Where was the balance? Where was the
confirmation from multiple independent experts?
It would have been interesting for
the report to give a historical examination of compatibility of Microsoft's
legacy document formats between the various implementations of Microsoft's own
software. Have users always had full-fidelity compatibility between these
releases? Also of interest might be an analysis of what happened to users who
decided to employ Microsoft's Office 2003 XML format, now deprecated.
We did not
suggest the parties then representing the OpenDocument Foundation were unable
to have a review of their proposals; we simply noted that they were
disappointed to fail to gain approval for their proposals. Also, it is not the
case that only one side was represented in our analysis; we spoke with several
ODF advocates, and incorporated extensive feedback we received from vendors
including IBM, Novell, and Sun before publishing the final document.
On page 17, the report says,
“Despite all of the debate and controversy surrounding ODF and OOXML, it's
important to recognize that the standards organizations are working as
designed, and that both the standards and the organizations are constructively
evolving as a result.” And later on that same page, “It's likely ISO will
revise its procedures to prevent similar disruptions in the future, so in some
respects the OOXML episode will produce some useful stimulus/response
improvements within ISO.”
This statement misses the point. The
question is not whether the organizations' procedures are perfect or not. No
matter how well intentioned a process is, loopholes can always be found.
Sometimes they are small, sometimes they are huge, but in all cases exploiting
those loopholes is nothing less than contradicting the spirit of the process.
The authors fail to consider the numerous articles highlighting how those
loopholes have been exploited, and the spirit of the process subverted by
stacking committees, by offering marketing consideration to business partner
members who voted in favor of OOXML, and by overloading fast track processes
with proposals that are of extraordinary and unsuitable length.
The statement that this is all
useful and constructive because it will be a stimulus to improvement within ISO
is patronizing of ISO. It ignores the basic issue: wouldn't it have been better
to have avoided the extreme exploitation of process loopholes and followed the
path of previous interpretations of the spirit of the processes as others have
done in the past? Also see the article “Sweden's SIS Declares OOXML Vote
Invalid - Will Change Vote from Yes to Abstain – Updated.”
We noted the Swedish Microsoft employee incident in the overview, and we don’t believe the actions of a single Microsoft employee operating outside Microsoft corporate policies is reason to conclude Microsoft’s overall intentions for OOXML are somehow inappropriate. On loopholes, that’s another subjective call, but since Microsoft competitors managed to establish control over a standards initiative with potentially dire consequences for one of Microsoft’s most important business domains, we are not surprised that Microsoft (legitimately, albeit with what some consider to be poor standards etiquette) exploited the loopholes. As we noted, we assume ISO will update its procedures to eliminate the loopholes in the future.