Collaboration and Content Strategies Blog

ODF Spreadsheet Bickering: What It Means to an Enterprise

Given that Microsoft's recent release of Office 2007 SP2 includes native support for the ODF file format, it was only a matter of time before Rob Weir (IBM) would find something he didn't like about it. On Sunday, May 3, he wrote a blog post entitled, "Update on ODF Spreadsheet Interoperability," saying that Microsoft had coded to the wrong behavior. He notes, "But I cannot fail to notice that the same application -- Microsoft Excel 2007 -- will process ODF spreadsheet documents without problems when loaded via the Sun or CleverAge plugins, but will miserably fail when using the "improved" integrated code in Office 2007 SP2. This ain't right."

Doug Mahugh (Microsoft) issued a returning salvo on Tuesday, May 5, in the form of a blog post entitled, "ODF Spreadsheet Interoperability." When Doug walked through Rob's documented steps, he found that Office 2007 did a better job of rendering the OpenOffice.org-created spreadsheet than Lotus Symphony (e.g., Days to Go equals "102" [Excel] rather than "of:B4-B3" [Symphony])."

I recommend that you read both blog posts, in that they highlight the complexities of coding to an ever-evolving open standard. However, look at the blog posts as an educational exercise--try to understand the arcane details, but don't get taken in by them. While the vendors would like you to believe that, "We're right--and they're wrong," the takeaway is the larger picture of, "ODF interoperability isn't here yet." Let me explain.

Some Un-educated Guesses about Office 14

Blogger: Craig Roth

This seems like a perfect time to post up some un-educated guesses about what will be in Office 14.  It's the perfect time because Burton Group hasn't been briefed on it yet.  Normally we would have been by now, but after numerous scheduling conflicts our briefing has now been rescheduled several times since the end of 2008.    Usually we are briefed by the vendors we cover well in advance of major announcements which helps us prime our content pipeline, but it also puts a freezing effect on guessing due to the non-disclosure agreements.  This leaves me an opportunity to make some lemonade from those lemons.  Since I haven't been officially educated on O14, I can feel free to publish guesses without fear that I'm giving away secrets!

That's a round-about way of saying these are all purely guesses on my part.  My teammate Larry Cannell already posted some gleanings about SharePoint 14 after the FAST conference.  Here are my guesses on the productivity side of Office 14:

• Breaking down some barriers in moving content to/from the web: Copy/pasting from websites to Office and back shouldn't be so messy and linkages should remain.  Again, OneNote has foreshadowed some of this and Microsoft has already acknowledged this will be addressed
• Better leveraging / integration of OneNote: The more you dig into OneNote, the more you see that it is not just a note-taking tool for students and home use, but a quantum leap in content creation from Word.  Microsoft hasn't pushed its value because they have trouble explaining it.  I'm going to place a bet that O14 will lift OneNote's profile, although still not to the level it should be
• Tighter SharePoint integration with the productivity side of Office: I expect the web editors to be leveraged to allow editing of workspace documents in place, much like IBM Lotus Notes does by leveraging Symphony.  I also expect better (think "wiki-like") versioning capabilities when modifying documents stored in SharePoint
• Better use of XML schemas: The OOXML spec allows for some very nice schema usage (tagging document sections, being able to split a document into different pieces) that Microsoft didn’t take advantage of in Office 2007. Making those capabilities more visible will make it easier for enterprises and third-parties to programmatically create and reuse document parts
• Better tagging across the suite: Uses of tagging in web 2.0 tools (blogging, tag clouds, social tagging) has far outpaced the underutilized, weak, free-form "keywords" and "category" fields in the Document Properties pane (quiz: do you know how to get to it in Office 2007?).  SharePoint enabled policies to be linked to the Document Properties panel, but capabilities for shared namespaces, tag clouds, and controlled vocabularies were absent from Office 2007.  I will place my last bet that O14 includes at least some of these tagging capabilities that are commonplace in other domains
• Web editors: Stripped down, Silverlight enabled versions of all your Office favorites.  Includes a mobile experience as well.  Some of this has already been announced or leaked, but the Silverlight part is just a guess
• Real-time collaborative editing: There are plenty of non-Microsoft products that do this now (like SubEthaEdit) and OneNote can already do this (to a lesser extent than the true RCE tools).  I expect more of it in the rest of the Office suite

One final caveat: While I think all of these are good, this is not my list of what could and should be done with Office.  What I've guessed above are more incremental improvements except for the web editors.  I'll leave some more radical ideas on how to revitalize the Office productivity franchise for another posting.

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

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.

Point 13

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. 

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

In general, 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. 

Point 14

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. 

Projections are by definition subjective; we stand by this projection in question, and believe there is ample room for innovation in productivity applications. 

Point 15

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? 

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

Point 16

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 2007.” 

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. 

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

Point 17

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

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

Point 18

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. 

Closing Comments

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., http://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.

 

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.

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

Blogger: Guy Creese

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. [Update: points 7-12 are covered in Part 2; 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.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.

Some Counterpoint to Our ODF/OOXML Report

Blogger: Guy Creese

There's been some disagreement with our ODF/OOXML report, to put it mildly. Unfortunately, many of the criticisms are from people who have not read the report and are reacting to second- and third-hand interpretations of it.

In happy contrast to this "I'll react to the headline" mode, there have been some thoughtful discussions of the issues:

• Leadership by Numbers: A blog post by an IBM/Lotus/Linux/Java consultant in the DC area who characterizes himself as "leaning strongly towards ODF."
• ODF Alliance: The ODF Alliance has published a counterpoint to our report, and based on comments from OASIS and a branch of OpenOffice.org, does a nice job of summarizing an opposing viewpoint.
• Erwin's StarOffice Tango: A blog post by Erwin Tenhumberg, a marketing manager at Sun, entitled, "Dispelling Myths Around ODF."

If you are interested in the ODF/OOXML debate, we encourage you to read our report in its entirety, as well as the counterpoint resources above. We interviewed people at Adobe, Altova, IBM, Microsoft, Novell, and Sun in the course of putting it together, and they all offered feedback/corrections before we published it. However, it is still our opinion, and others disagree. From our point-of-view, the best thing that can happen as a result of this report is a civil, rational discussion of the issues--and not the religious war that this debate has often nosedived into.

For those who have asked when we plan on updating the report, we plan to in the next quarter, with an eye to (1) accepting or rebutting arguments made by others, (2) taking into account the result of the ISO vote, and (3) clarifying points that people misunderstood or misinterpreted.

Response to Ars Technica's Article on the ODF/OOXML Report

Blogger: Guy Creese

Five days ago Ars Technica issued its view of the Burton Group ODF/OOXML report and made it clear that they disagreed with its findings, going with the headline, "Analyst group slams ODF, downplays Microsoft ISO abuses."

We've had some questions from Burton Group clients and others about the article, so I thought it would be worthwhile to go through where we agree, where we disagree, where Ars Technica mischaracterizes what we said, and where it's wrong.

First, a point on which we agree:

• Microsoft's Large Market Share Will Have an Impact: Ars Technica states,  "Statistically, the large market share of Microsoft's office suite will likely ensure that OOXML becomes the industry de facto standard...." We agree. As we state at the beginning of the Analysis section, "... many enterprises are not that caught up in the standards debate; they just want to use what works for their needs. Microsoft Office 2007 defaults to storing documents in OOXML format, so, by migrating to Office 2007, many companies will let Microsoft make the decision for them."

Areas where we disagree:

• Microsoft Doesn't Want to Foster Interoperability: Ars Technica states, "...the veracity of Microsoft's stated intentions to foster interoperability shouldn't be accepted at face value." It's a fact that Microsoft has historically used proprietary file formats and capabilities to gain market advantage over competitors. However, this attitude is dysfunctional in today's more standards-centric world, and we believe that Microsoft--ever the hard-nosed realist--recognizes that. Microsoft has changed its stripes in the past when it made business sense to do so. In the early 1990's it was not partner-friendly, somewhat similar to Apple's go it alone strategy; in the late 1990's it realized that expanding the partner ecosystem would in the long run make it more money, and so it built a large partner network. While Microsoft is not as ODF-friendly as Ars Techica would like it to be, it is definitely getting away from a proprietary lock-out strategy. Mary Jo Foley noted in her blog on January 17th that, "Microsoft is going to put the binary-format documentation on the Web; make a binary-to-OOXML conversion tool available as an open-source license on SourceForge; and make the documentation available under its Open Specification Promise (which is basically MicroSpeak for a pact not to sue)."
• Microsoft Is Consistently Gaming the Standards Process: Ars Technica says, "...there is unequivocal evidence that Microsoft bought votes for OOXML in Sweden and there are compelling allegations that the company has done so in other countries." We noted the Swedish episode in the report, but disagree on the question of degree. The Ars Technica headline, "Microsoft ISO abuses," gives the impression that they are systemic and widespread; we think they are isolated instances. What viewpoint you take probably depends on the story playing in the back of your mind. We think Microsoft is too much of a hard-headed realist to jeopardize votes and market perception by packing the court; others figure Microsoft is just plain evil and has been effective at hiding its nefarious activities. Same set of facts, two different interpretations.
• Sun Is Unfairly Attacked: Ars Technica said, "...the report aggressively attacks Sun with allegations that are completely speculative and unsubstantiated." Multiple interviewees in the ODF camp told us that it was virtually impossible to get anything into ODF in the early days if it wasn't also in OpenOffice.org: that despite all the talk about ODF being open, it was apparently a case of a vendor pushing its own agenda--the same charge that is typically leveled at Microsoft.

Areas where Ars Technica mischaracterized what we said:

• No Mention That ODF and OOXML Will Eventually Give Way to Standards Supporting Hyperlinked Documents: This was probably the most important point we made within the report, and one which Ars Technica neglected to mention.  As we note at the beginning of the Analysis section, "Software as a service (SaaS) productivity applications are bringing mashups and dynamic web-based documents into the enterprise, challenging the long-held idea that a document must be monolithic and static. Over the next decade, standards being put forth by the World Wide Web Consortium (W3C) may ultimately dominate the document standards domain...."
• Google Apps Report Was a "Scathing Condemnation": Ars Technica says, "...Burton Group issued a report with a scathing condemnation of Google's enterprise productivity suite...." True, we advised our enterprise clients not to adopt it yet, as it was lacking in areas such as role-based administration and records management. However, I wouldn't characterize this paragraph within the report as a "scathing condemnation": "Because the solution is weak compared to best-of-breed point solutions, it will not displace many already installed applications. However, it will appeal to organizations that are comfortable with the SaaS delivery model and are looking for basic features and nothing more, as well as organizations making their first steps in trying out ECM
  and collaboration solutions. In addition, it will serve as a collaboration add-on to Microsoft Office, which is how Google uses it internally." Interestingly, the adoption curve has played out as we called it--large enterprises have stood on the sidelines, with a few of them trying it out in departments, while some SMBs looking for a low-priced alternative to Microsoft Office have adopted it.

Areas where Ars Technica is wrong:

• Burton Group Makes Money Installing SharePoint: Ars Technica says, "Burton Group earns revenue from consulting on enterprise collaboration software installs (think SharePoint) and likely has its own agenda." While Burton Group has a consulting arm, it helps clients draw out a strategic IT roadmap, based on the client's environment and preferred architecture. We do not install software for clients. We do work for Java-centric clients; we do work for Microsoft-centric clients. True--we do have an agenda, which is to advise clients on what would be best for them in a vendor-neutral way. Given that 30% of the client calls into our Collaboration and Content Strategies practice have to do with SharePoint 2007, it would be foolhardy for us to ignore and not write about what Microsoft is doing in this space. However, SharePoint 2007 does not do everything well--the blog and wiki support is pretty dismal, and don't even think of using it for digital asset management--and we tell clients that.