Burton Group's Response to the ODF Alliance (Part 1)

What 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: 

1. 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.
2. 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.
3. We 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. 

Responses 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. 

Point 1

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.

The key 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). 

Point 2

Page 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 approval.” 

Why 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, what 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? 

Implying 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). 

Point 3

Page 5 also discusses OOXML's support for “custom schemas” and suggests that “OOXML is more ecosystem- and application-oriented than ODF.” 

We 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 problems. 

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. 

Point 4

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 Office. 

This 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 Edwards’ blog 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.) 

In the 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 readers. 

Point 5

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 Microsoft Office”? 

We 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. 

Point 6

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.

Comments

[Stephane Rodriguez]

Point 1

"OOXML is much more expressive than ODF."

Does shared formulas and other optimization artefacts brought from the dark ages of the 8086 days is the expressiveness you are talking about? XML was never meant to be a binary stream!

As for graphics, when you will be done supporting DrawingML three years from now, and start spending two more years every little dirt of VML, only to find your way through the redundancies, perhaps you can start thinking of rendering graphics.

"Microsoft made the changes – since relaxed – to improve security, it’s difficult to find fault with Microsoft’s goals in that context"

If security trumps compatibility, the only logical step for Microsoft is to block the ability to open a .xls spreadsheet...for security reasons. New Excel vulnerabilities are discovered every month.

And, since a number of binary blobs from .xls files are brought to .xlsx files as is, one might want to wonder if .xlsx spreadsheets should be blocked as well.

Point 2

"Implying that the custom XML extensions Microsoft developed in conjunction with Ecma International are unimportant"

You can't add your own XML within existing XML parts. It simply corrupts the file. What you can do is add independent parts that Microsoft calls "Custom XML", whose implementation is in fact partial at best. In Excel and Powerpoint, Microsoft hasn't designed a way to bind the data to that internal Custom XML part. Your only recourse is to use Word.

There goes your ability to update stocks thanks to "Custom XML".

"OOXML is much broader in scope"

To the point you can insert/reshuffle any MIME payload in the file. Does not this contradict the security concerns that were mentioned in Point 1 ?

"Detailed spreadsheet formulas"

What you call detailed spreadsheet formulas is Excel's user online help. Applications supporting ODS spreadsheets have a user online help too, why don't you mention it for the sake of fairness?

Point 3

"OOXML is more ecosystem- and application-oriented than ODF"

Definitely not. Word defines its own world (styles, formatting, layout logic, formulas, ...), at odds with Excel, which defines its own world (styles, formatting, layout logic, formulas, ...), at odds with Powerpoint.

An ecosystem would share most of the Office elements, leaving a small part to specifics. Oddly enough, that is what ODF does.

The only part of Office documents that Microsoft tried to share in their ECMA proposal is the drawing parts, and they failed miserably. They now have to make 1000+ pages of VML deprecated. In a 1.0 proposal, that's unheard of.

In case, by ecosystem, Burton Group means "development platform", suffice to say that there is no 64-bit edition of Office 2007, and that important parts of Office 2007 haven't been developed for a number of years (such as VBA), making it impossible to adapt to today's and future needs.

Point 4

"Given that experience, buttressed by blog postings that highlight that such name jockeying is not an isolated instance"

Especially when "Open XML" implies that XML is closed, or at least closer to Microsoft's proposal.

The game in "Open Office" versus "Office Open" terms just illustrates how both scared and jealous Microsoft is of anything open, as in open source. (It also shows they understand dirty SEO tricks somewhat.)

Point 5

"OOXML debate by storing documents in the cloud."

OOXML is not about storing documents. On servers, it's supposed to be actively part of business processes with parts stitched and dynamically mixed according to needs. There is only one problem, what Microsoft Office application instances do at run-time when you edit the files just isn't there anymore if you do this by hand (with your own program), which kills the integrity of documents. Microsoft understands this very well, that's why their media blitz is all about "more compatible than everything else".

Point 6

"The word simplistic often means beyond simple, as in way too simple."

Does this imply that OpenOffice Write (the equivalent of Microsoft Word) is just some kind of Notepad application, and that it cannot save .doc documents back and forth without substantial loss?

If that's not what you mean, that sure sounds like it is.

For the record, OpenOffice Write/Calc/Impress work very well with .doc/.xls/.ppt documents.