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

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.

Point 7

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. 

The table 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 file format. 

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. 

Point 8

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

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

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

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      voting members 

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

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. 

Point 9

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. 

Probably a 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.” 

So the 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. 

Point 10

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

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. 

Information 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 Known Issues page on the Open XML/ODF Translator Add-ins for Office web site). 

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

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

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

While we 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 that need. 

In reference to the comment about scripts and macros, those capabilities became extensions in Office 2007 and OOXML because Microsoft deprecated them due to security concerns. 

Point 11

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. 

Point 12

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.

Comments

[Rob Brown]

Guy,

While I applaud you for responding to the ODF Alliance, your responses suffer from the same omissions and lack of objectivity that the original report suffered from.

In point 8, you are asserting that Sun wields unacceptable power over ODF. The ODF Alliance showed the structure of the OASIS committee and made the telling point that "ODF 1.0, the standard, is owned and controlled by OASIS".

Yet you expect people to believe you and un-named "vendors", and you ignore the most important point of all: "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. "

This point is the main reason that I am rejecting OOXML. It will lead to a different kind of lock-in: while having a veneer of "openness" and "standardisation", MS Office will define the standard, and other software will always be playing catch-up. This will not be too much of a problem for ecosystem products from the likes of Altova and Mindjet, but will greatly hinder products which compete directly with MS Office itself.

Why did you ignore that point in your response? Are you happy that OOXML will always be whatever Microsoft decides that it should be, and sure that their decisions will always put their customers first (rather than their business aims)?

In point 10, you are still suffering from your confusion between file formats and applications. Of course there are fidelity issues with the Open XML/ODF Translator Add-ins for Office, because that product is still immature, but it will improve. Meanwhile, OOXML is still changing and its future is undecided. What are the translators trying to translate: MS Office 2007 documents? OOXML(draft) documents? OOXML-1.0 (as yet unpublished)?

With your comment "Specifications for Microsoft’s binary file formats have been available for free since 2006", what relevance does that have to the ODF spec published in 2005?

Meanwhile on the application front, OpenOffice has for a while been in many cases a better tool than MS Office, for opening legacy documents. Even leaving aside Microsoft's breathtakingly arrogant decision to kill their own legacy files with Office 2003 SP3, issues with Office versions opening documents from previous versions are well known. Or were you unaware of that? I can provide examples if you'd like.

In point 12, you are dismissive of the Swedish vote-rigging incident. I find it very, very troubling, and I welcome the EU's decision to open an investigation into Microsoft's behaviour.

As a side-note:
In point 7, your "table complexity" argument completely misses the mark. Look into object-oriented design, and note the meaning of "abstraction". As an example, when building an object of type "car", you may choose to use an abstraction called "wheel", with characteristics like diameter, width, material etc. It is then useful to use that "wheel" as the basis for your tyres, steering wheel, gearbox gears, or whatever; for each higher-level object you add extra characteristics as appropriate.

There is no "subjective architectural call" here: the use of a single "table" abstraction in ODF is completely valid. If the OOXML designers have used a different model then that's fine, but it's no basis for stating that ODF is limited by its design.

Not that my opinion carries any weight at all, but here's my vision of file-format nirvana: ODF is established as The One document format standard, and the OASIS committee which owns it is populated by Microsoft, Sun, IBM, Novell, and stakeholders from the wider industry. Microsoft Office competes on its quality, unprotected by file format lock-in and anticompetitive behaviour. Note that Microsoft would still make truckloads of money in this model;
their market presence and momentum, plus the fact that they can make good software when they need to, will guarantee that.

[Stefan Gustavson]

Brief summary: "You are stupid." "No, you are stupid, Stupid." "No, you."

I'm sorry, but my comment is just: *YAWN*
A public debate is only effective if people actually listen. This should ideally include also the parts in the discussion.

[Sead Alispahic]

Guys, the argument that view should force model what to do (spreadsheet table is more complex then word-processing table, so model for spreadsheet must be more complex than for wp) is the same as building in options in your television to force transmission tower to broadcast in black-and-white if you have b&w TV receiver.
If model allows for something, it does not mean that your view application must implement it. It can, but it doesn’t have to. I hope that you can now understand why it is OK to have model that will be used by view differently in different application. ODF does not care if your application does not implement [PUT_YOUR_FEATURE_HERE], because it is up to your application to implement it, or not. If the broadcast is in colour, and you have only b&w TV set, you will see b&w broadcast. That is model-view sort of architecture and that is a feature, not a fault.

After that i did not read the rest. I can imagine what is in it, if this is what we should expect.

[Andrew Russell]

I'll pick on one part of your argument alone, I will leave the rest for others:

To continue your 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.
A correct design is to design a 'pluggable/extensible' architecture so that the infrastructure supports complexity 2 natively allowing pluggable extensions for the content (boilerplate complex=2) functionality (functions complex=2) and view (formatting complexity=3) logic. So each part of the whole is understandable and has easy points of intersection with the others and the complexity is bounded as they are designed to not be interdependent.
Consider how to later implement a 'maths' document format or hybrid document format or enhance your word document to allow any allowed spreadsheet function, do you want to re-implement all this functionality or re-use and compose the independent and largely orthogonal parts of the whole. The OOXML documentation clearly favours an excess of words over easily composed component parts (how many thousand pages is it, and how much excess verbiage).
Yes, Microsoft does program their applications using this escalating complexity method, it doesn't mean that we all have too. We don't all have the thousands of programmers to program something like Vista, and that very project seems likely to fail to archive more market share than its predecessors.