Google: OOXML 'insufficient and unnecessary'

Google: OOXML 'insufficient and unnecessary'

Summary: The search giant claims Microsoft designed Office Open XML 'purely around the needs of Office' and says it should be rolled into the rival ODF format

TOPICS: Tech Industry

Google has claimed that Microsoft's proposed Office Open XML document standard is unnecessary and should be rolled into the rival OpenDocument Format.

In a Monday post on Google's official blog, open-source programs manager Zaheda Bhorat said the issue affects everybody who uses editable documents.

"A document standards decision may not matter to you today but, as someone who relies on constant access to editable documents, spreadsheets and presentations, it may matter immensely in the near future," wrote Bhorat.

Document formats are shifting towards the use of the Extensible Markup Language (XML), which allows types of data to be defined and tagged within documents. The OpenDocument Format (ODF) has already been ratified by the International Organization for Standardization (ISO), but Microsoft's alternative, Office Open XML (OOXML), is currently undergoing its second attempt to gain ISO approval.

Google's technical analysis of the OOXML specification — which notoriously runs to 6,000 pages of code, compared with ODF's 860 pages — has led the company to believe that "OOXML would be an insufficient and unnecessary standard, designed purely around the needs of Microsoft Office", Bhorat claimed.

OOXML is this week being debated for the second time by ISO, having failed to gain approval in a preliminary vote held six months ago. A ballot will not be held during the meeting, but the various national standards bodies that voted in September are being invited to adjust their positions, if they wish, by the end of March.

Read this


Leader: World not open to Microsoft promises

Microsoft has promised more openness, more freedom. It looks like more of the same...

Read more

"We join the OpenDocument Format Alliance and many other experts in our belief that OOXML doesn't meet the criteria required for a globally-accepted standard," Bhorat wrote. "As ISO member bodies around the world work on possible revisions of their vote previously submitted, the deadline of 30 March approaches fast. I invite you to pay close attention and heed the call of many for unification of OOXML into ODF."

A Microsoft spokesperson defended OOXML by saying that its customers "have told us their data needs can't be addressed by a one-format-fits-all approach".

"Everyone wants to use their data in slightly different ways," said Microsoft's spokesperson. "Furthermore, multiple standards can foster a healthy, competitive industry. By developing tools like the [Office] Open XML-ODF translators and making them widely available, we are promoting customer choice, which is our top priority."

Topic: Tech Industry

David Meyer

About David Meyer

David Meyer is a freelance technology journalist. He fell into journalism when he realised his musical career wouldn't pay the bills. David's main focus is on communications, as well as internet technologies, regulation and mobile devices.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Google has invested in competing format

    Unlike what the article claims this is still the first time that ISO is dealing with the standardization. There has been an earlier vote in this process but that was more an intermediate vote and those votes are still valid now but can be altered based on improvement that are currently made in the standardization process.

    It should be noted that Google has built its Google apps around the competing ODF format which is simpler which has less functionality than the OOXML format. Therefore Google apps cannot compete on functionality to applications using the full posibilities of OOXML.
    Especially things like the easy business data integration possibilities in OOXML which are lacking in ODF.

    So it is in Googles interest to be against the standardization of a format that they are not supporting themselves.

    Also interesting is that the ODF format was srtandardized premature to be faster then OOXML. It is therefor not finished yet. OASIS that maintains ODF suggests that a next version of ODF (1.2) that is more complete could become ISO standard in summer of 2009 at the earliest.
  • Document standards

    Customer choice is the antithesis of a standard - if there are two "standards", there is no standard.

    ISO has already has a document standard. It may well be good for this to evolve and take on board new capabilities, but it would be counter productive to allow additional "standards".

    The document formats we have used for years have been driven by the proprietary, commercial needs of the supplier. The usual standardisation in businesses on the MS Office formats has been driven by the overwhelming commercial success of Office in destroying the competition - buy Office or you cannot edit the file.

    The world has moved on and we now have the opportunity to have standards for the benefit of users rather than a forced "choice" of a specific product to a particular company's commercial benefit.

    I do not mind whether the document standard is based on ODF or MS Office, but it is of fundamental importance that there be just one standard, and that it is fully open so that any office product can support it.

  • Questioning Google

    Given that Google apps are based on the ODF standard, a rival to Microsoft
  • Microsoft's Argument is Ridiculous

    In this case and others, such as HTML or electrical sockets, the claim that multiple standards will foster competition simply is not true. It's a international document standard, useful for archiving public documents and such, assuring that they will always be freely accessible.

    If Microsoft's customers need something better, fine. Put it in Office 2009, make it the default format and call it OpenDRM or whatever. Who cares? In addition to this, Microsoft can still support the already existing ISO certified document format, ODF.

    I thought Jim Zemlin, the Executive Director of the Linux Foundation had a funny quote:

    "It's akin to Microsoft going to the United States Congress and proposing alternative bumper heights."
  • Very nice Albert

    So you think Google could have based Google apps on a proprietary, closed undocumented Microsoft format.
    I do not know if that had made Microsoft very happy or very unhappy,
    It would have made Google very stupid, however.

    I think you should read a lot more.
    Try They have followed the whole story from the beginning.
    For instance:

    With some cutting and pasting.

    Here is the conclusion.

    >> If the eligible members of ISI/IEC JTC1 vote not to approve OOXML, then OOXML will still be an Ecma standard, and all of the benefits to Microsoft customers and developers will still be preserved. Microsoft will also reap the principal benefits that OOXML can provide for it: its developers will be more likely to continue to support Office, and new developers will doubtless become motivated to become part of that environment. In short, a vote against OOXML does not deprive either the marketplace or Microsoft of the value of OOXML having been made public, and all of the changes already made by Microsoft will still bear fruit.

    >> But if the National Bodies vote to approve OOXML, what then?

    >> If they do, OOXML will achieve titular parity with ODF in the eyes of legislators around the world, most of whom will lack the existing knowledge and the time and interest to learn whether there would still be a reason to prefer products that implement ODF over OOXML. Presumably, the high water mark of interest in ODF would have passed, and the credibility of ODF-compliant products, as well as the importance of open document formats in general, would begin to recede from public and legislative view.

    >> Microsoft, like any other publicly held company, would then have no incentive at all to consider moving even one step farther down the path to openness with OOXML than it had on the date of the vote, except to the extent compelled to do so by the European Commission
  • The rest of the text in the previous talkback

    The rest of the text

    >> If industry (and not just Microsoft) wishes to preserve its freedom to act, and indeed if the formal global standards infrastructure itself wishes to retain a role in the process of creating Civil ICT Standards at all, then each would be wise to consider the fact that a vote against OOXML is a vote not just to serve the public interest, but also a vote to preserve the right of self regulation. While ISO and IEC lack the treaty recognition of the ITU, they have traditionally enjoyed quasi-governmental status nonetheless. With that privilege comes responsibility to serve the public, or to lose the credibility of their imprimaturs entirely.

  • Microsoft double-tongued

    Really. A Microsoft spokesperson said that customers have told them that their data needs can't be addressed by a one-format-fits-all approach? I just started giggling and laughing at that! Come on! Microsoft HAS pushed a one-size-fits all approach! That IS what Office represents! That IS what Windows represents! Here we go, let's pooooooouuuuuur in the features! You don't need anything but Microsoft products! No, it's "Our size fits all," or "One size to rule them all."

    What Microsoft doesn't like is not being in control. If they can get OOXML pushed through then they can use the usual "embrace, extend, eliminate" methodology to marginalize ODF and anyone else attempting to implement OOXML support. Remember Java? I'm sure they'll try it anyway, but if OOXML is approved then they can do it using approval as pretense.

    And, "Multiple standards can foster a healthy competitive industry"? Really? How? And does ODF not support any kind of extension? At all? Let's see. It's XML...

    And they promote "choice" by providing translators? Hah! No, they maintain control. Somehow the translators are released a bit later than the official new OOXML revisions put into Microsoft's products. Hmmm. How did that happen? Huh. Musta been an accident...

    Microsoft uses the same playbook over and over and over again. Hopefully the approval committee will understand that.
  • Google motivation

    I was stating the motivation for Google to be against the format. They are using a competing format that is less feature rich. That is why Google is against OOXML becoming an ISO standard, because then Google will have to compete more against office software that has features Google apps cannot provide (at least for a while).

    You suggest that google cannot use OOXML but the specs are publicly availiable for more than a year now and google. Also google is able to interprete the old binary office formats of which the specification are a lot less good than OOXML spec.

    The ODF format Google is using cannot supply the needs for a faithfull representation of most current document so when converting to ODF you will loose information. The OOXML format does allow faithfull represnetaion of the data in current MS Office files after conversion. This is very important for many of the current Office users which have billions of existing Office documents. Also the OOXML format is a lot more feature rich than ODF and can support the features currently used in MS Office. To support the features in MS Office in a simpler format like ODF it would require extensive MS extensions to ODF which would cripple ODF for any other users. Even now it is difficult for the different ODF implementation to interprete OpenOffice propriety features in ODF. This would become a lot more difficult if ODF documents were to consist more of propriety extensions than official standard complient code.

    Btw, referring to the consortium info is like referring to the Linux foundation as Andy writing that blog is a director of the Linux foudation and a laywer working with IBM in an anti-ooxml crusade. He is also aprticipating in the anti-ooxml meeting in Geneva at the moment sitting in a panel with IBM VP Bob Sutor.

    So the consortiuminfo blog, I read as an IBM blog (of course it very visibly often directly referring to the blogs of IBM employees like Bob Sutor)
  • ODF useless for Microsoft needs

    [quote]In addition to this, Microsoft can still support the already existing ISO certified document format, ODF. [/quote]

    ODF's limited spec can't support all MS Office features unless Microsoft goes on a major entending trip. Also the format does not contain performace enhancements like OOXML does. So using ODF for Microsoft would mean very a controversial extending of ODF (I can hear the protest already) and still having to use a format that performes a lot less (especially in large spreadsheets).

    It would mean downgrading MS Office. Nice for MS Office competitors who are unable to compete with Micrsoft on implementing Office software
  • Which OOXML features in particular can't ODF support?

    I am hearing the statement that OOXML is more featureful than ODF a lot, but the only actual examples of extra functionality that people ever care to name are Digital Restrictions Management (DRM) ones. And DRM is something that I wouldn't miss one little bit. (Hint: Someone has always come along and broken each DRM scheme, e.g. CSS and AACS for DVDs. So all that DRM has ever really been good at is thwarting interoperability.)
  • insufficient and unnecessary standard, designed purely around the needs of

    You can debate the differences between the open ODF, and the partially open OOXML, from now to eternity. Fact is Microsoft has had enough time to spread enough money around , or to make the appropriate threats to get OOXML approved as a standard. They will continue to slow innovation and force an unwitting public to use their products, as they choke out the competition.
  • XML in spirit isn't going to be as efficient as binary

    Whoa! Albert, XML by nature is not going to be as efficient as a binary encoding, assuming you follow the spirit of XML. Sure you can do a base64 dump of binary and stick tags around it for example, but that isn't really XML's intention. I've written an XML/object translation library and I know of what I speak.

    So what are they doing to "speed up" large spreadsheet loading and saving, or anything else? Tags are tags, and the encoding/decoding needs to write/interpret them. The only way to speed up XML interpretation is to get rid of tags by encoding multiple pieces of information for a particular tag. That introduces portability problems for obvious reasons and defies the intent of XML.

    By the way, the controversy over extending things never stopped Microsoft in the past. Again, remember Java?

    Lastly, how would it mean downgrading MS Office? If they want speed, use binary. If they want portability, use XML. Those two really don't mix. It's a trade-off. Do both. Doing "performance enhancements" in OOXML, which I suspect is tag-glomming, is NOT proper XML.
  • OOXML is fully open

    You suggest ODF is more open than OOXML but in reality they are equally open.
    Allthough Sun and IBM having had a clear majority of votes in the OASIS TC on ODF for 5 years is mayby less open than MS having only a single vote in Ecma and the IBM/Sun powerbase in OASIS was shown in their refusal to add elements that would allow better compatiblity with existing office documents because those element would not fit in OpenOffice.
    Or in purpously NOT using the W3C MathML 2.0 schema in ODF because OpenOffice does not support MathML 2.0 yet even though the ODF specs states that ODF implementations should support v2.0.
  • Features not in ODF

    Just to name a few:
    * ODF does not allow for compatibility with existing office binary files so that you cannot faithfully convert those to ODF files
    * ODF does not have the easy integration of custom (business) data that OOXML provides
    * ODF does not have performance enhancements to allow for fast processing of for instance large spreadsheets
    * ODF does not allow integration of Math and Office tags which OOXML does. for istance OOXML can track revision changes in math formulas
    * ODF has much more limited grafical support than OOXML
    * OOXML package files contains relationship information which show all interpackage and external dependencies. If you want to change an URL in an OOXML file you need only change the relationship information and not scan the entire file to look for all places the URL might be (as you would in ODF).

    And there are a lot lot more, but you would need a real expert for that
  • OOXML performance explained

    [quote]So what are they doing to "speed up" large spreadsheet loading and saving, or anything else? Tags are tags, and the encoding/decoding needs to write/interpret them. The only way to speed up XML interpretation is to get rid of tags by encoding multiple pieces of information for a particular tag.[/quote]

    OOXML uses a lot smaller tagnames for the most common tags. This allows for faster unzipping and less use of memory than an ODF file in parsing the XML against an XML schema.

    OOXML spreadsheet files optionally allow for tracking which cells have formulas in them. This means that when you load a spreadsheet file with 10 million data field and only 100 formulas fields the spreadsheet implementation knows immediatly which cell with formulas need to be recalculated without checking all fields for formulas at least once like an ODF spreadsheet implementation would have to.

    OOXML packages have relation ship information showing all internal and external dependencies within an OOXML package. This mean you need only scan a minor fraction of the OOXML file to get this information whereas in an ODF file this info could be spread all over the file and requires parsing of all parts in the package.
  • Thank you for an intelligent response.

    Thank you, Albert, for an intelligent response, and for taking the time to do so. So let's discuss this. I'll try to keep it short and to the point.

    Tag name length is a matter of debate to be sure. XML by nature, however, is intended to allow for text editing. Too short names introduce possible confusion over intent, and possible name rangling in the future over additions. Having a tag like "CannonicalCellContents" is ridiculously long, but having a tag like "C" is ambiguously short.

    That's why, in my opinion, discussing XML efficiency in terms of tag length is a red herring. XML is what it is, and truely there is a fadishness about it. That is why, again in my opinion, if one is concerned about tag creation/parsing performance, one should go with a binary format. It's not like one cannot create portable binary. Lua does it. I've worked with the byte code and it handles nuxi issues just fine. I'm sure Java does as well. I'd be for BODF (Binary ODF). The design also isn't particularly complicated. (Again, look at lua.)

    As for formula tracking, I understand your point, although I'd have to see the tracking mechanism to be able to discuss this intelligently. On the other hand, I'm assuming that with OOXML you need to read in the whole document before doing any processing since tags in general can occur in any order, so what you are really describing is the internal representation of the document, and that doesn't have to have much of any relationship to the XML at all. The real issue here is whether there is any unnecessary duplication of tag values in the XML for formulas. If there is, then a reference mechanism should have been put into ODF, and that is certainly something that could be presented to the committee.

    Lastly, as for relashionship information, again I'd have to see the scheme, but again, if it isn't outlandish/Microsoftish that could also in some way end up in the standard. You said that with ODF it is spread all over the document. Depending on how this is used, this implies that some XML structure rearrangement should have been done. And again, that is a reasonable thing to present to the committee. In the end, structured documents are databases, and are subject to the same indexing issues as databases.

    To conclude, however, both the formula issue and relationship information issue you present are abstract issues, and a design should be approached from that standpoint. I suspect the problem here is that it wasn't.
  • Of course ODF isn't backwards compatible with old Microsoft formats?!

    How could it ever be? Are you expecting bug-for-bug compatibility? Are the binary Microsoft formats even documented? Besides, not even today's MS Office is backwards compatible with all the old Office formats so that's hardly a new issue. Basically, you leave the job of converting old documents to new formats to conversion tools, and you are probably right to fear that only Microsoft can write a 100% reliable conversion tool from any of its old formats to ODF. But this is actually a criticism of *Microsoft* rather than ODF itself.

    And how on Earth do you expect a *file format* to have "performance enhancements"? How does a file format even "perform"? I think you are confusing the format with a program that *implements* that format.

    I wouldn't expect ODF to incorporate Office tags either; I just expect to be able to use ODF to represent a document that I wish to create.

    As for the rest of your items, they are a bit vague. E.g. "easy integration"? "More limited grafical[sic] support"? I'm not familiar with the intricacies of either ODF or OOXML, but "more limited" could just be a euphamism for "doesn't support a boatload of useless bells and whistles".
  • But does even Microsoft Office use OOXML?

    These people say that even MS Office 2007 cannot create documents in OOXML, which makes the format about as useful as a chocolate teapot:,1000001161,39348275-39001068c-20091749o,00.htm,1000001161,39348275-39001068c-20091752o,00.htm,1000001161,39348275-39001068c-20091755o,00.htm

    Talkbacks from this story:,1000000121,39348275,00.htm
  • Office and OOXML

    The way I look at this particular issue is that Microsoft would be insane to build OOXML into Office, since it hasn't been ISOd yet - and may require alterations to gain that honour. Then again, if they were really as confident about its wonderfulness as they claim, you'd think it'd be in there...
    David Meyer
  • Then why add "read" support for OOXML to Office either?

    What is it supposed to be reading? Just empty files?