The Office Productivity Standard Wars Heat Up

Share via Twitter Share via Facebook Share via Linkedin Share via Reddit

Well, whoever said that standards were boring needs to really reevaluate that perspective: things are getting downright crazy in the battle of Office productivity standards. Sun’s Tim Bray weighed in on the topic yesterday, and Microsoft’s Obasanjo and Scoble angrily fired back. Sun’s Simon Phipps then went on to examine Microsoft’s covenant in more detail, and like Andy, had a few concerns – and Sun itself actually fired off a letter about some of these concerns to Governor Romney and his staff. Meanwhile, David Berlind reports that Larry Rosen – one lawyer who definitely gets open source – is giving the covenant at least a provisional thumbs up.

What’s my opinion on the covenant and submission to Ecma? Well, not materially different from what I said last week. As I told two different vendors this morning and one of the major Boston dailies this afternoon, I don’t know if the covenant ensures that the format is open yet, and I’m fairly confident no one else does either. People will say they do, but they can’t. The reason is that legal documents – IMO – have much in common with code: they’re complicated, prone to unexpected errors/loopholes, and should be subject to a great deal of scrutiny before they’re accepted. We’ve already seen this with the ODF: some of you might recall that after examining the format in detail, Microsoft’s Brian Jones expressed some concerns with Sun’s IP rights within the format, which led to this. I have neither a favorable nor unfavorable view of Microsoft’s covenant, because better minds than mine have not had sufficient time to go over it in detail. Whether or not you believe that Microsoft would intentionally cripple the covenant is besides the point (I think they’d be foolish to try, given the scrutiny it’ll be under): loopholes can make their way into such documents regardless of intent, just as bugs appear in code. So my take is: let’s wait and see. The stakes here are too important to be giving anyone the benefit of the doubt.

Two other important notes from two Friends of RedMonk, who I assume would rather I did not name:

  1. In last week’s note, I asked for feedback on the formats themselves, and one respondent – who, for context, works for an organization with little appreciation for Microsoft – submitted the following comment [redacted to protect the individuals involved]:

    Talk to any Office suite developer and they’ll tell you that the MS Office XML formats are substantially better than their ODF counterparts. When I was in XXX recently, I caught up with XXX who had very colourful words to say about the ODF spreadsheet stuff. According to XXX, the formats weren’t designed by people who really understood the issues facing users of each document format (ie. developers building applications on the format).

    As I told one ODF oriented vendor this morning, I make no claims to the truth of these claims, but I do think they merit discussion. Given that many ODF advocates frequent this space, I wanted to solicit that feedback: what do you think of these comments?

  2. On the other hand, another respondent pointed out the following interesting Ecma tidbits. If you head over to Ecma’s site, and flip through the charts here to page 20, you’ll discover the following on a slide entitled “What is Ecmas’s value?”:
    • Balances Technical Quality and Business Value:
      • Quality of a standard is pivotal, but the balance between timeliness and quality as well: Better a good standard today than a perfect one tomorrow!
      • Offers a path which will minimise risk of changes to input specs
      • A safe haven for IPR

    While I’m fully in agreement that standards should not be polished to a sliver – held out in hopes of some mythical perfection – if I were an ISV hoping to contribute or work with Microsoft I’d be somewhat concerned about the second bullet.

Whatever happens, it’s clear that the coming weeks and months should be very interesting to follow from an office productivity standards perspective.


  1. “Talk to any Office suite developer and they’ll tell you that the MS Office XML formats are substantially better than their ODF counterparts. When I was in XXX recently, I caught up with XXX who had very colourful words to say about the ODF spreadsheet stuff. According to XXX, the formats weren’t designed by people who really understood the issues facing users of each document format (ie. developers building applications on the format).”

    Could XXX give us some examples, please?

  2. Right on. This discussion has been dragged for what, 6 monthes? At least, since the MA announcement and NO ONE ever provided with ONE example of anything. Cooks use measurements like a “bit of”, we’re supposed to be engineers, be specific!

  3. The formula issue is the only specific example I’ve ever seen. It’s a reasonable one, but it’s being addressed.

    Are there are any others? The unnamed person you quote offers nothing.

    OTOH, I think there’s perfectly valid technical arguments to make on the other side. See here for one take:


    I gave some context on the article here:


    I contributed to it because I frankly got tired of hearing the anti-ODF FUD.

  4. The Groklaw article argues fairly persuasively that ODF is a cleaner XML format that makes life somewhat easier for XML cognoscenti to work with it as opposed to the Office 12 format. That’s only one dimension of “perfectly valid technical arguments”, however. The long discussion of mixed content is a case in point: Mixed content is familiar to HTML/XML geeks, fairly easy to work with via XSLT, but tedious to work with in XML APIs such as SAX/DOM and a nightmare to represent in the relational model or with ordinary programming language objects.

    I’m not part of the MS Office team, but I believe that the developers that they are targeting are not the *internal* MS developers but *external* developers who need to do ordinary things like write small apps that complement MS Office or write integrations with enterprise systems and databases. In all those scenarios, reducing the impedance mismatch with OO languages and RDBMS is a more important technical goal than alignment with the mainstream XML technologies.

    The other technical issue that Tim Bray’s posts and the Groklaw article ignore is the importance of data as well as text in an office document. “Almost all office documents are just paragraphs of text, with some bold and some italics and some lists and some tables and some pictures” http://tbray.org/ongoing/When/200x/2005/11/27/Office-XML. That’s certainly true of the majority of actual Word, etc. documents out there, but not true of the ones that are going to be processed by 3rd party developers. Ordinary text/table/image documents are pretty much exclusively for human consumption; it hardly matters what XML or (X)HTML format they’re in so long as there is a stylesheet to render them in a reasonable human-readable form. The more interesting documents, and the ones I hear Brian Jones and Jean Paoli talk about, are what one might call operational business documents, with a combination of human-readable text and machine processable data. As I understand it, the technical design of the MS Office formats focuses on the needs of documents that contain live *data* from external sources or create *data* for downstream processing. I don’t get the sense that this was a major design consideration for ODF, as shown by their use of the document-oriented RELAX NG schema language rather than the more data-oriented W3C schema language that MS Office supports.

    Finally, I’ve heard Brian Jones address the question of why the Office XML default formats are so ugly: It’s because they’ve learned over the many years that they’ve been working with HTML and XML representations of Office documents that the most important criterion that real users value is the user experience in the office application. Users want the document to “remember” where they left off editing, what the zoom level they had previously set, and so on. All that makes for ugly markup, but it can be safely ignored by those with no incentive to dive deep into the documentation to figure it out. That “state of the editor when the document was saved” information would be lost in translation to PDF, ODF, or whatever anyway.

  5. Jaime and Konijn are right. We’ve been hearing lots of unsubstantiated claims about ODF being “technically insufficient”, but no one has yet to point out any specifics to back up this FUD.

    If you’re a ruthless monopolist with a long and sordid history of corrupting standards to further your control over the marketplace, this kind of FUD is almost too easy. Besides, the ruthless monopolist has a very different approach to file formats than one would find with open source and open standards initiatives. The monopolist is forever seeking ways of tying, bolting and binding the file format to specific applications using arbitrary and quite artificial software dependencies. The open source – open standards effort of course tries to separate the file format from the applications. Software dependencies, especially the binary kind, are the kiss of death for an open, portable, cross platform, application independent file format.

    So what we have here are two very similar XML file formats, ODF and MSXML, that spawn from two very different objectives. The ruthless monopolist tries to lock their MSXML to the Windows XP stack, ever finding new and inventive ways to bolt end user information and information processes into a cascading entanglement of interdependencies binding the Windows XP desktop to suites of XP servers. There is nothing independent or portable about MSXML. Okay, so they submit the spec to ECMA. Aside from all the legal gotcha’s and intentionally vague fine print, Microsoft has moved their point of control from the specification to the packaging format. Of course by doing this they can now claim that MSXML complies with current marketplace demands for a truly open XML implementation. But by shifting their control point to the packaging, a whole new set of complaints will ensue. How much longer can this endless game of whack-a-mole to go on?

    Want proof that MSXML breaks the XML promise? Not even the mighty monopolist can perfect a transformation between MSXML and ODF, and that breaks the most basic promise of XML – the promise of highly inter operable interchange of information. If it’s real XML without the dependencies, then show us by perfecting a clean, clear transformation.

    Yes, it is true that MS Office and open source cross platform champions OpenOffice.org and Mozilla have reached “parity” as far as desktop productivity environments are concerned. This parity is generally described as having 80% or more of the feature set, but having 100% of those features most used and most important. Let’s say for the sake of a good argument that OOo has 95% of the MS Office feature set 🙂 The missing 5% might be superfluous features that no one uses, but nevertheless, one could honestly argue that OOo the application is comparatively “technically insufficient”. Okay, so the next step is to lay out the missing 5% of features, analyze them for their importance to specific information processes needed by users, and determine a bang for the buck ratio. OOo probably would win this comparison 95% of the time (if not for the endless flood of FUD). But the monopolist could still say that OOo is “technically insufficient”.

    But here’s the thing. The “technical insufficiency” of OOo has nothing to do with claims that ODF, the file format, is “technically insufficient”. ODF was designed to be application independent, with the recognition that some applications will need to reflect in the file format highly focused but “limited” application services. Other applications like OOo and MS Office, will need the file format to cover the entire desktop productivity environment as well as the highly interactive collaborative computing space.

    ODF was designed to be both scalable and eXtensible. The file format is able to handle the comparatively limited needs of highly focused, single purpose applications, the very broad universal transformation layer needs of legacy systems being merged into SOA’s, and, the needs of that global googlespace where desktop productivity environments are rapidly evolving to mesh with highly interactive collaborative computing efforts.

    If the “technically sufficient” aspects of MS Office can be expressed in MSXML, i damn guarantee you that they can be expressed in ODF. As Tim bray said, “That’s what namespaces were invented for”. The X in XML stands for eXtensible.

    Does this mean that the vaunted MS Office developers are “technically insufficient”, quite unable to understand XML? No. It simply means that the monopolist business objectives are focused not on interoperability, but on maintaining control of the marketplace, keeping the upgrade treadmill churning by artificially tying applications to proprietary file formats, and continuing the anti competitive extortion of obscene profits.

    Based on their bastardized implementations, one could easily argue that MS Office developers don’t understand HTML, and are “technically insufficient”. When Microsoft set out to murder Netscape, and claim the Open Internet browser space for their own, they raced to submit new HTML features to the W3C. They needed that “Open Standards Compliant” imprimatur. As soon as they no longer needed that stamp of compliance and good citizenship, Microsoft forked off with a bastardized entanglement of HTML extensions and implementations that broke the Open Internet into two separate camps. One side of the Open Internet was owned and controlled by Redmond. The other side set adrift, wondering how this could have happened.

    XML is the Web 2.0, and what the monopolist is trying to do now is really not that much different from what they did to HTML and Java. Yes the stakes are much higher. The players are different. But it’s the same ole “embrace, eXtend, eXtinguish” game plan.

    After all we’ve been through, and all the reprehensible things we’ve seen, who in their right mind would trust the monopolist to finally be doing the right thing?

    Besides, in the long run none of this treachery, deceit, and gotcha whack-a-mole will matter. It’s not about the desktop. It’s about the Open Internet. The XML file formats are just a means of bridging desktop productivity environments into the Open Internet and the age of interactive collaborative computing. Whether you’re working on a local SOA, or a global Service Oriented Open Internet Architecture, it’s still the same. Like other legacy information systems, the effort is to include legacy desktop productivity environments.

    As one wag cleverly stated, “Microsoft is stuck on C Drive”. They can’t seem to break the personal computing orientation and make that leap to the Open Internet. Their dilemma is perhaps due to the fact that they have yet to figure out how to seize, control, and “own” the Open Internet. But they keep trying. MSXML is just the latest effort.

    So who is it that has figured out the Open Internet? Google has. Instead of trying to control the Open Internet, Google set out to organize mankind’s information using the Open Internet. They’ve been so successful at this that it’s hard to separate Google organization services from the Open Internet. They have accelerated the speed at which information moves across the global infogrid, they have greatly increased accessibility to that information, they have exponentially increased the volumes of information available, and, they are ever seeking more clever ways to escalate interactive participation – which increases the value of information.

    ODF has the potential to deliver Microsoft to Google, and do so on a silver platter. The reason is that XML is directly in the business objective line of fire for Google. For Microsoft however, XML is the end of monopolist control over information.

    If you’re in the business of organizing Open Internet ready information, XML is it. From the universal metadata model, through the highly structured presentation and content model, to the bridge between XML:RDF where tagging of “conceptual relationships” becomes possible, ODF is going to transform vast volumes of information – perfectly structured for Google to apply the awesome power of their processing and storage capabilities. If ever there will be a moment in time where Moore’s Law merged with Metcalf’s Law, this is it. This is Google’s game to win or lose. If they choose ODF, it’s all over but the shouting. It won’t matter what ECMA, ISO, Massachusetts, or even what the W3C does. With the Open Internet, it’s not about the desktop marketshare. It’s about the information.


  6. I’m not really sure what specifically either of these formats can do about the data integration issue, Mike. If you read this presentation from ODF designer Daniel Vogelheim from a few years back, it seems they were explicitly concerned with some of those issues too:


  7. Thanks for the link to that document. I’m afraid I don’t see any discussion of the use case I was talking about – documents that contain and/or update live data from enterprise systems, and not just human-authored, human-processed text.
    Did I miss that? I do see some discussion of “binary” data, but that is Base64-encoded in ODF AFAIK, but that is a non-starter for most non-geeks.

    I don’t pretend to be making a detailed technical analysis of why one format or the other is better for this use case. I’m just pointing out that Brian/Jean talk about the data-oriented business document scenario a lot, and Tim focuses on documents that are just text and markup in making his argument that ODF should be the one and only “standard” in this domain. I’m also pointing out that the choice of RELAX NG makes ODF well-suited for “text” documents, but doesn’t have the wide range of tool support for data-oriented work (e.g. binding XML to programming objects or database tables) that mainstream developers rely on.

  8. We’re back to that “data” point again I see, Mike. Thing is, office productivity apps for documents. The data uses you’re talking about are to do with Microsoft’s future product plans, not with ordinary uses by ordinary customers wanting ordinary documents to be compatible between software packages and not corrode with age. Data access is interesting, but a corner case. And it seems to me to be well covered by appropriate use of appropriate namespaces.

  9. Thatnks for confirming my suspicion that active, data-containing documents aren’t really a design point for ODF. That *is* a corner case given the vast number of plain ol’ memos and static reports authored with wordprocessing tools. I think we probably could agree that MS Office is overkill for such documents, although it will be interesting to see whether the Office 12 UI innovations make this kind of thing significantly easier to author than it is in previous MS products or the current OO/StarOffice UI.

    But be careful taking this argument too far 🙂 As we’re happily discussing over on xml-dev, (X)HTML + CSS works just fine for this kind of simple, static, everyday document, and there are a bazillion commercial, open source, or free beer products available to produce (X)HTML. Furthermore, HTML is undeniably the most popular standardized document format in the world. If you don’t worry about the “corner cases” that HTML doesn’t cover, ODF doesn’t have much of a leg to stand on either.

    But more importantly, the data-oriented corner cases are quite significant in a goodly number (if not percentage) of real-world customer scenarios that Jean Paoli is very happy to tell people about. Do you really want to argue that these aren’t worth supporting? Likewise, “information integration” of enterprise data and documents is almost certainly as much of a growth industry behind the firewall as “mashups” of public data are in “Web 2.0”.

    All I’m arguing, and I think all the MS Office people are arguing, is that people should be encouraged to use the right tool and format for the job and not try to fit everything into a single “standard” and lop off the corner cases. (X)HTML has a role to play for sure, ODF will probably develop a significant base as products that support it are actually deployed, the Office 12 formats will almost certainly be considered sufficiently powerful, open and standard for a large segment of the market, and there’s always things like DocBook available for real high-end documentation needs. Furthermore, customized XML formats that meet a specific organization or industry’s needs will be increasingly used, IMHO, as XML tools mature enough to make this feasible for non-geeks. All these should be allowed in the toolkits of enterprise and government developers, even if any one of them could cover all but some “corner cases.”

  10. I think we should all go back on this comments section and read Dare and Mike’s comments.
    Dare’s point is a valid one but, it’s already being addressed so, it will became a benchmark on how ODF will stand the test of time and the stress test of a real world deployment with, IMO, is almost as important has a good design.
    On another hand, Mike’s comments is, by far, one of the more interesting comments about how ODF people should behave.
    Some of you may know I’m a Sun reseller and a strong defender and believer so, no independency is implied here.
    If you look at the last 3 or 4 documents about Sun Messaging Server, they all say pretty much the same thing: “Sun Mess. server is better than Exchange”. the same way Ferrari doesn’t compare itself with an ox car, Sun is killing it’s own product with that comparison. Let’s look at this and try to learn.
    My take is that anyone reading this already read a lot of comments on this issue. My opinion is that we have to address 2 markets.
    Some of our users, until now, didn’t had an editable document format that would assure them that 10 years from now, a document made today would still be readable and editable with the same formats as today. Notice that the word Microsoft doesn’t even apear in my last sentence. It’s not a coincidence, it’s simple economy, there is a need (reading and changing documents 10 years after they were made) and, there is now a solution – ODF. Microsoft doesn’t play in this game, so, Stop making this about them, it isn’t.
    As a general format for office documents, there is competition between MSXML and ODF but, once again, the answer isn’t about mentioning the obvious. Gary, do you really think anyone here doesn’t know about the Embrace, Extend and Extinguish policy of Microsoft? Old news, move over.
    MSXML is tied with Office 12 so, the first point stands, what about Office 13, Office 14 and so on, will they support THE SAME MSXML? Will Microsoft put that in a legal binding?
    Security is also a growing concern for many users, does ODF supports Macro signing? what security tools does ODF support?
    finally, with an application (and platform) independent format, very little in the corporate world remains to lock someone in Windows / MSOffice. I think no one can deny that Openoffice was one of the prime factors of Linux in the Desktop adoption, ODF will take user independency a step further.
    Like with any fight against Microsoft, the fight can only be won by facts and educated people, don’t even try winning it with FUD, Marketing or by shouting out louder, you’ll louse, big time. Educate people on why ODF’s design choices were made, what problem do those choices try to solve and, then, move over to the application level and discuss how applications implement the format and what customer value do they offer.
    For developers, the same point stands. Assuming (with, I don’t give ANYWAY for granted) that it’s easy to implement an application parser for MSXML than it is for ODF, the fact remains that anything that uses MSXML will have to be changed again for Office 13, 14 and so on while what is done for ODF will still be usefull years from now

  11. Nobody’s addressed Mike’s point about preserving application state (“where you left off”) in ODF. In fact, OO.o stores this information within the zipfile in “settings.xml”.

Leave a Reply

Your email address will not be published. Required fields are marked *