follows is Burton Group’s response to the ODF Alliance’s response
to our “What’s
Up .DOC?” overview report on ODF and OOXML. At the outset, we’d like to
clarify some things before getting into the point-by-point responses:
- The utility of a model is assessed relative to stated objectives in a given domain; a modeling endeavor never has a simple right or wrong answer (page 18 of our overview). A key part of this debate is the subjective assessment of how important Office file format interoperability is—we believe it will be very important for most enterprises—and that Office file format interoperability was not a goal for the group that designed ODF.
- Standards initiatives participants are often at least partly politically motivated, generally with significant business issues at stake. That’s certainly not new to the ODF/OOXML debate.
reviewed the current versions of the published standards, so the
intention to more completely integrate ODF with RDF in the future is
not an immediate consideration for enterprises making format decisions
today. Burton Group believes that ODF 1.2 is a much richer and useful
specification than previous versions, and we will update the overview
to reflect that when ODF 1.2 is approved.
to the ODF Alliance points follow. To keep this post from being
horrendously long—and since we haven’t finished all the responses at
this point—we’ll post
them in series. This post covers points 1-6. 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 5 says "...[L]ibraries and large businesses, faced with storing and using years of Microsoft Office legacy documents, will prefer OOXML, as OOXML can more faithfully recreate the look and metadata (such as spreadsheet formulas) stored in Microsoft's binary file formats."
This statement confuses file formats and applications. Surely, OOXML cannot faithfully recreate the look of anything. It is a file format, not an application. Microsoft Office is the application that interprets OOXML, and it can also render legacy binary file formats, except when Microsoft decides to remove support for them, as Microsoft recently did with Office 2003 SP3. There can be further problems when Microsoft decides not to support legacy features, such as when they removed support for Visual Basic scripting in Office 2008 for the Macintosh.
The authors fail to note that no other application supporting OOXML has been able to faithfully or fully recreate the look of Microsoft's legacy binary documents. So the statement that OOXML--a file format--is the solution for rendering legacy documents is simply false.
issue here is the sophistication of the payload that the file formats
can carry. A better phrasing within the report would have been,
"...[L]ibraries and large businesses, faced with storing and using
years of Microsoft Office legacy document, will prefer OOXML, as OOXML
can more faithfully transfer the information needed to create the look
and metadata (such as spreadsheet formulas) stored in Microsoft's
binary file formats." We
agree on the need to clearly distinguish between applications and file
formats, but OOXML is much more expressive than ODF. For example, OOXML
specifies formulas; the current standard of ODF does not. OOXML has a
much more sophisticated way of expressing graphics; ODF has difficulty
passing along the information necessary to fabricate complex vector
graphics such as pentagons and chevrons. It’s true that both formats
are defined in XML, and that they can thus be extended, but we believe
it’s important to note that OOXML is a more expansive model to start
with, since extensions mean more complexity for application developers.
The comment about Microsoft dropping support for legacy file formats in
Office 2003, incidentally, is a good example of blurring the
distinctions between applications and file formats (and, since
Microsoft made the changes – since relaxed – to improve security, it’s
difficult to find fault with Microsoft’s goals in that context).
5 asserts that OOXML will win because, “...OOXML is an extensible
standard. It allows vendors and enterprises to extend the standard
within an OOXML-defined framework... This built-in ability to augment
the OOXML standard is a safety valve for future innovation,
allowing new features to be added without forcing vendors to invent yet
another separate file format or wait for standards bodies to give their
does the report argue that OOXML is preferred over ODF for
extensibility reasons, but fail to mention that ODF's extensibility
features are just as rich? This lack of balance is disconcerting. ODF
has extensibility features that are just as powerful as OOXML's, and,
is more important, ODF's features are based on existing industry
standards, such as the W3C's RDF and XForms. Further, it is not clear
to us what the statement about not waiting for standards body to give
their approval means. Surely the authors are not suggesting that we
repeat the problems of some earlier efforts where multiple “user
defined extensions” to a standard meant that we really didn't have a
standard at all?
that the custom XML extensions Microsoft developed in conjunction with
Ecma International are unimportant, while neglecting to mention that
one of the cited ODF extensibility features has not yet been approved
(RDF is planned for ODF 1.2), does not seem objective to us. In
addition, the frequency of user-defined extensions will be in part a
function of the expressive scope of the model; since OOXML is much
broader in scope, we believe it will need fewer extensions. In fact,
ODF 1.1 and 1.2 could be classified as “catch up” specifications,
needed to add features that OOXML already supports (e.g.,
accessibility, detailed spreadsheet formulas).
Page 5 also discusses OOXML's
support for “custom schemas” and suggests that “OOXML is more ecosystem- and
application-oriented than ODF.”
think it is unwise to consider exclusively Microsoft's particular
“custom schema” feature. We should instead ask what the underlying
business problem is that we are trying to solve. For example, if you
wish to programmatically update a stock price in a document (what the
paper suggests is solved by custom schemas) then there are many other
approaches, from custom spreadsheet functions, to document
transformation, to DOM manipulations, to tagging, to mapping to an XML
database, and so on. The underlying problem is how to take what is
ordinarily unstructured document content and impose an organization's
structured view on it. Suggesting that only Microsoft's custom schema
support solves the problem, while ignoring ODF's support for
alternative and standards-based approaches to the same underlying
business task, is misguided, in our opinion. In particular, the paper
fails to note ODF's XForms support and how it can be used to enable
users to add data to a document in a user-defined schema and then
submit it to a web service. XForms is a W3C standard. Here again, a
sense of balance is missing, as is consideration of fully capable
modern programming techniques that employ ODF to solve real business
This point is a mischaracterization of what we said, as it implies that the use of custom schemas is the sole reason for saying, “OOXML is more ecosystem- and application-oriented than ODF.” As readers of the report know, the complete sentence, “In short, because OOXML is more ecosystem- and application-oriented than ODF, most vendors and enterprises will see it as more useful than ODF,” applies to all three points we made in that paragraph, not just one.
The paragraph starts by noting, “Within the larger market, OOXML will lead,” and then lists three reasons for that assertion. First, Microsoft Office 2007 defaults to saving documents in OOXML format, so given Microsoft Office’s dominance, the vast majority of documents that enterprises create over time will automatically end up as OOXML documents. Second, OOXML is designed to allow vendors and enterprises to extend the standard within an OOXML-defined framework, rather than redefining the standard. Third, we note that OOXML’s “overlay” custom schemas will “…more easily perform tasks such as programmatically updating a ‘Stock Price’ element or corporate logo within a document, compared to ODF’s method of serially inspecting and updating the document itself.” While there are always many ways to programmatically solve a business problem, the options that the ODF Alliance suggests are not limited to the ODF format—they could be applied to OOXML documents as well—which gets us right back to the distinctions between ODF and OOXML.
While XForms is a type of custom schema, it is not a separate mechanism to the side like the OOXML design, so it adds additional parsing and processing to the process. ODF proponents must think that the overlay mechanism has value, as it is included in the yet to be approved ODF 1.2 standard.
To summarize, we believe that “most vendors and enterprises will see
[OOXML] as more useful than ODF” because: (1) millions of OOXML
documents will be generated over time by Office 2007 and so it’s the
path of least resistance, (2) OOXML offers built-in extensibility, and
(3) the overlay custom schema mechanism consumes less processing
resources than the competing ODF XForms mechanism.
Page 5 says of the OOXML standard,
in a section pointedly called “What's In a Name?: Innuendo,” that “IBM and Sun
reference it via its Ecma name of “Office Open XML” (as reminder of its origins
in the proprietary Microsoft Office file formats).”
This is a curious statement, but there is no need to suggest the name is used for some propagandistic purpose.
Many people call the standard “Office Open XML” because that is in fact its
correct name, both in ISO, and in Ecma, and even its legal name as used by
Microsoft in their own Open Specification Promise.
Speaking of names, nothing is said
about Microsoft choosing a name for their specification which was obviously
destined to cause continued confusion with ODF's first implementation, Open
section was put in for two reasons: as a literary device to help readers
remember which acronym is which, as well as to allude to the “Battle of the
Names” that has characterized the ODF/OOXML debate. (Two examples: Gary
post in which he names OOXML MSECMAXML, and Ephraim Schwartz’s note of the
battle lines in “ODF
vs. OpenXML”). In fact, the ODF Alliance’s assertion that Microsoft picked
a specification name “obviously destined to cause continued confusion with
ODF’s first implementation, Open Office” is a perfect example of the jockeying for
name ownership that has characterized the behavior of both sides of this debate.
(Microsoft’s attachment to the word “open,” as well as the ODF Alliance’s implying
that the ODF-based office suite had first dibs on the Open Office name.
Actually, Wang Laboratories concatenated the two words first, with its
OPEN/office e-mail solution in the 1990’s.)
course of talking to our clients about ODF and OOXML, it became very clear early
on that business-oriented CIO’s and others unfamiliar with the standards had a
hard time remembering which acronym stood for which standard. Although we
called them ODF and OOXML in early drafts of the document, midway through we
changed the nomenclature in the report to ODF and Open XML. Microsoft’s
“branding” of Open XML seemed to have taken hold in the business community, and
we felt that piggy backing on that term would cause less confusion for our
enterprise readers. However, when we sent out a draft of the report for review by
IBM, Microsoft, Novell, Sun, and others, we were surprised by the strength of at
least one vendor’s objections to our using the “Open XML” term in the document.
This vendor called it “worrisome,” and rather than just commenting on it,
unilaterally replaced all mentions of “Open XML” with “OOXML.” Given that the
Ecma name for the standard is OOXML, we decided to go with acronym names for
both standards, so we wouldn’t be accused of naming favoritism. Once Microsoft
heard that we’d changed to using “OOXML,” they came back asking us to reinstate
“Open XML,” which we refused to do. Given that experience, buttressed by blog
postings that highlight that such name jockeying is not an isolated instance, we
thought that a short reference to the “Battle of the Names” was worthwhile, and
would help clarify which acronym went with which camp to our enterprise
Page 12 says, “...[M]any Microsoft
competitors have attempted to exploit the transition to open, XML-based file
formats in order to more effectively compete with Microsoft Office. While some
of its competitors have very little hope of establishing successful products
that directly compete with Microsoft Office, they may still seek to disrupt
Microsoft's business by making Office less profitable, thus depriving Microsoft
of opportunities to use Office profits to subsidize product development efforts
in other market segments.”
The report seems to suggest that it
is somehow improper to compete against Microsoft. We find that view puzzling
and confusing. ODF vendors are not “exploiting” the transition to open,
XML-based file formats. They were the source, the vanguard of the transition to
open, XML-based file formats, having initiated standardization of ODF within
OASIS over 5 years ago. Also, according to the authors' own statements earlier
(bottom of page 6), OpenOffice has had 100 million downloads compared to
Office's 500 million estimated users. How can it be said that there is “very
little hope of establishing successful products that directly compete with
certainly do not believe it is inappropriate to compete with Microsoft.
However, given that Microsoft Office has over 90% market share, we think that
displacing Microsoft Office with another productivity application software
suite will be an uphill battle. In fact, we think the greater long-term threat
to Microsoft Office will come from SaaS-based solutions that sidestep the ODF
vs. OOXML debate by storing documents in the cloud. Microsoft is not oblivious
to this shift, and helps explain the rise of its “software plus services”
mantra. Furthermore, we did not assert that there will be no successful ODF-centric
vendors competing with Office; we noted, for example, that Novell is likely to
have robust market opportunities for its version of OpenOffice.org, especially
on client platforms Microsoft does not support. One hundred million free downloads
is certainly an impressive number, but far less so than 500 million paid client
licenses; a download does not always imply an active user, while a paid license
generally signals a stronger level of commitment.
Page 13 says, “ODF is currently
somewhat simple (and simplistic) compared with alternatives such as OOXML”.
The rather negative term
“simplistic” is asserted with no backing argument or evident motivation. In our
opinion, this does little to establish a sense of objectivity in the report. We
might also ask when did “simple” became bad thing in a standard? XML is simple.
HTML is simple.Moreover, Simple Mail Transfer Protocol (SMTP), Simple Network
Management Protocol (SNMP) and other essential IETF standards are explicitly
named that way because of their simplicity.
In our opinion, the best word to
describe these global standards and ODF is not “simple,” but rather “elegant.”
There are considerable liabilities associated with unnecessary complexity:
increased development and maintenance costs, increased difficulty to program,
more complex (and therefore possibly negative) security implications, and
generally buggier implementations. A more balanced approach would have examined
the negative effects of a more complex standard. “As simple as possible, but no
simpler” was Einstein's advice, and is worth heeding. You can always build
complex applications from simple pieces, but you cannot easily build simple
applications from complex pieces.
On “simplistic:” while Wikipedia states “The word ‘simplistic’ often means beyond simple, as in way too simple. The word is often used offensively and not with kind solitude” (http://en.wikipedia.org/wiki/Simplistic), dictionaries (such as The American Heritage Dictionary as quoted by Answers.com -- http://www.answers.com/simplistic), provide more detailed definitions, e.g.,: “The tendency to oversimplify an issue or a problem by ignoring complexities or complications” (Answers.com). Given the stated purpose of the ODF group was to create a robust XML model for file interoperability among productivity applications, we believe the decision to not support trading files with Microsoft Office, the application used by the vast majority of information workers, was simplistic. We also believe the decision not to specify a robust formula language in ODF 1.0 was simplistic. (In that case, the ODF specification doesn’t offer simple pieces—it offers no pieces.) We agree with the Einstein quote (“… as simple as possible, but no simpler”) and believe, at least within the context of addressing complex enterprise IT requirements, ODF is too simple.