While you’re waiting, don’t save in OOXML format

Print Friendly

While all the drama is unfolding before the OOXML Ballot Resolution Meeting in Geneva at the end of February and the subsequent 30 day period while countries can still change their vote, I thought I would point out something that I assume is fairly obvious to most people:

Saving your documents in OOXML format right now is probably
about the riskiest thing you can do if you are concerned with
long term interoperability.

First, the “official” ECMA OOXML that was submitted to ISO is not what Microsoft implements in Office 2007. So unless your application reverse-engineered Office 2007’s support, you’ve got interoperability problems right there.

Second, the ECMA spec is over 6000 pages long, there were thousands of comments, and thousands of pages of proposed resolutions to those comments. And that’s just from Microsoft. Others will go to the BRM with different proposals, and further ideas may come up there. Not everything may be addressed at the BRM.

Nobody has the vaguest idea what OOXML will look like in February or even whether it will be in any sort of stable condition by the end of March. Major features may be deprecated. Completely different solutions may be proposed. And at the end, the whole thing may be rejected, just as it was done in September.

So that OOXML format that you are saving files in right now is dead and will be replaced, unless Microsoft decides it won’t bother implementing what comes out of the ISO process. Indeed, if the ballot finally fails, I’m not sure what Microsoft will do with all the suggested comments.

But, you might say, don’t worry, because surely Microsoft will provide a converter for my current OOXML files to the new OOXML format. To this I say why are you wasting your time saving in a format that is hard to share right now and you know is going away? If you must use a Microsoft format, by all means use the traditional binary formats. Others can read them today and you know there will be support for them later, even on other platforms.

Another point is that while we are talking about interoperability, who else do you think is going to provide long term complete support for this already-dead OOXML format that Microsoft Office 2007 uses today? Interoperability means that other applications can process the files fully and not just products from Microsoft. I would even go so far as to go back to those few OOXML files you have already created and save .doc, .ppt, and .xls versions of them for future use, if you want to make sure you can read them and you don’t want to commit yourself to Microsoft’s products for the rest of their lives.

If you do simply want to commit yourself to Microsoft’s products for the rest of your documents’ lives, just make sure everyone else who needs to read them will do the same. But then that’s a very different discussion from worrying about interoperability.


  1. So I suppose we should view people’s OOXML documents as Microsoft marketing novelties; just like we should view copies of IBM Lotus Symphony as IBM marketing novelties.

    Spreading your own OOXML documents is doing Microsoft’s marketing for Microsoft.

    Spreading IBM Lotus Symphony http://symphony.lotus.com/ is doing IBM’s marketing for IBM.

    I know who pays my salary, and therefore what I’ll do. Here, friends, all. http://symphony.lotus.com/software/lotus/symphony/invitefriends.jspa . Consider yourselves invited.

    This may all be slightly confusing to some who have the 20th-century view that ‘software’ is a product. That would be a view from the days of OS/2, 1-2-3, WordPro, and Freelance Graphics. We’re solidly ‘new millennium’ now, and the new generation of Services Scientists needs room to grow.

  2. Chris,

    Using, or recommend a product is more than marketing. Using is definitely an “Endorsement”. Recommending can be classified as an “Endorsement”, if it is only the celebrity endorsement sense. ;)

    Using a product predispose you to certain data format and do constitute marketing for the data format in that sense. In that, I agree with you.

  3. @Chris

    I’m not quite sure what to make of your post, it seems off topic to me. You seem to be suggesting that OOXML is important to software as a service. I certainly agree that we want documents that can be generated and consumed by software services as well as by traditional office suites. But to my way of thinking, this view reinforced Bob Sutor’s points. We need document formats that support exchange. MS OOXML is interoperable between two users with Microsoft Office 2007, that seems a rather narrow view of interoperability. Mr. Sutor is also pointing out that a documents saved in MS OOXML will probably not conform to ISO OOXML, so if you use MS OOXML you will have to address a format change IF MS does adopt ISO OOXML.

    Software-as-service requires common formats. By common, I mean both shared and significant market share. It is pretty clear to me that OOXML is failing on the ‘shared’ criteria. What is surprising to me is that it is also failing on the ‘market share’ criteria as well. There is a great deal of uncertainty about OOXML. It is pretty clear that Bob Sutor has an interest in emphasizing this uncertainty, so we should take his comments with a grain of salt. But that doesn’t mean we should completely discount his arguments either – his track record is pretty solid so I am inclined to take his arguments seriously. Besides, if you are Chris Ward, Commercial Director for Microsoft Digital Advertising Solutions, I also have a reason to take your arguments with a grain of salt.

  4. Hmmm….. interesting insight. Thanks for this.

  5. I guess if you’ve already integrated OOXML in your life, hope that there is backwards compatibility for it in the future Microsoft products. Luckily, Microsoft has a proven track history of being very backwards compatible despite many failures.

  6. While I agree with some of the points made in this post, I don’t see how saving files in the regular binary formats is going to save you anything. Either way, you will have to convert to the “official” OOXML format or (even better) to ODF. The goal is long term compatibility and I don’t think there’s a solution to that right now, unless you want to save as a text file.

    Also, the current OOXML formats can be used by Office XP, Office 2002, Office 2003, and Office 2007. If you have an older version of Office, then you just need to install the compatibility pack available here: http://www.microsoft.com/downloads/details.aspx?FamilyId=941B3470-3AE9-4AEE-8F43-C6BB74CD1466&displaylang=en.

  7. I’m sure this won’t come as a surprise to anyone, but I think this is a fairly off-base conclusion for Bob to draw. Standards specifications change – or they die and go away. ISO ODF is a mere subset of what ODF in OASIS is now. That is not a bad thing, nor should it suggest that anyone using OpenOffice is somehow taking a risk with their documents. Open XML will change through the process in JTC 1 (as it did during the Ecma process), and it will continue to change over time through the ongoing maintenance of the specification.

    For all of the hyperbole that Bob and his staff have spread about what good standards work is, or is not – I should think he would be happy with the fact that the dispositions process has been handled in a well-disciplined, engineering-driven fashion. ALL comments, not just the no votes, ALL comments have been addressed in the dispositions. The NBs have had access to the comments as completed in logical groupings – and now there will be a BRM to consider those.

    That said, there is no inherent risk to software users from the fact that the specification will change over time. Translation works…it has worked in the past…and it will work even better in the future based on the capabilities to work effectively with XML-based technologies.

    Sorry – I don’t agree with your post Bob. BTW – Happy New Year.

    Jason Matusow

  8. “In a sense you could say anybody who has got OOXML in their data center today sort of has an undisclosed balance sheet liability”


  9. Gregg: I think the binary formats will, of necessity, be around for a long long time because of the network effects. I specifically did not mention ODF, and was just giving advice relative to saving in the OOXML v1.0 formats (that are implemented in MS Office) vs. saving in the binary formats. I don’t think Microsoft will be able to remove support for binary formats any time soon. Indeed, overcoming the network effects of the old formats to get adoption of the new formats will be a significant problem, I believe.

  10. Mikey: I’m not sure “hope” should be in involved in your document strategy. As to great track records etc., I’ll leave that to others to decide and comment on.

  11. Jason: Yes, standards change over time, but we’re talking about a potentially very radical, wholesale change to OOXML while it is still in the standards process compared to what you folks have implemented in your product. My advice still holds: wait and see what happens and use the binary formats today if you want to use a Microsoft format. This is not v.1 of a standard to a v.2 situation. Since there are several alternatives to saving in OOXML form today (and I just discussed one of yours), the risk level is just too high, I would say, to suggest people save in format that is already deprecated.

  12. You’re blowing this out of proportion. Microsoft has and continues to do a good job of supporting the myriad revisions of its formats. For instance, not only does Word 2007 read all versions of the DOC format, from 1.0 (circa 1990) onwards, but it also supports Word 2003’s now-unused WordprocessingML and even the OOXML produced by its betas! Similar capabilities hold for the other components of the Office suite. In addition, Microsoft has made batch conversion tools available for OOXML. They’ll likely update those tools once the BRM has passed. That means IT administrators will be able to migrate all OOXML documents that have been created in the relatively short period since the release of Office 2007 (approximately one year) to the new standard in one fell swoop.

    And even if the currently implemented form of OOXML is moribund, what are DOC/XLS/PPT? They’re downright DEAD!

  13. Jason,

    Whenever I see something you have written on this subject you refer to Open XML as if this is something going through ISO. XML is open by definition (see http://www.w3.org to get all of the information you might possibly need regarding XML). I feel that what you actually refer to is Microsoft Office binary dump to XML, or MS office XML. Could you please stop using the inaccurate and confusing Open XML expression?

    Thank you.

  14. I’ll start right out by stating I’m a believer in the much more transparent ODF file format. Microsoft is great at marketing itself while coercing, bullying, and buying out its competition. MS just can’t compete on a level playing field. As for this OOXML matter, so many people look just at the now. Even going back to just the early 90’s, when Bill Gates was still calling the Internet a fad, there was a major player in the word processing market that was most certainly not a MS product — WordPerfect. For so many people to assume that Microsoft will keep it’s monopoly status is a little short-sided. There are a number of factors involved in this OOXML fast tracking issue, but one of the important items the EU is looking at is a long-term solution to archiving history. Seeing as how Microsoft intentionally makes version compatibility a major headache, it’s a shame the bureaucrats in the US are willing to take MS payoffs instead of taking into consideration what future generations will have to deal with.

  15. It took me a while to recover from the shock of realizing that for decades the world has misunderstood the value of standardized markup. However after accepting the safety of binary formats and the dangers of XML, I am now wondering whether it is safe to continue using HTML. I heard it was changing and since it is sort of like XML, is it just as dangerous?

    Please, just give it to me straight – spare me the marketing.

    Nick Carr (not that Nick Carr)

  16. Stephane Rodriguez

    One of the points worth discussing IMHO is that, even though Microsoft is trying to game the national bodies with a pledge to stricter file format conformance (remember, the scope in ECMA 376 says “conformance is prurely syntactic”, meaning that interpretation is all up to you, the specs is just a bunch of suggestions), Office 2007 has no Save As OOXML. This Save As would be a strictly conformant Save.

    Why is it that I am not surprised?

    You can already bet on Office 2009 lacking such Save As too.

    By analogy, take a look at what the Internet Explorer team is doing with their backwards compatibility religion : http://www.itwriting.com/blog/?p=484

  17. As other commentators have pointed out standards change and evolve over time, if only as issues become clearer and understanding deepens. Assuming we take your argument in this post then surely the same applies to ODF? Certainly I have seen ODF changes in applications, OpenOffice for example, is full of interesting document changes.

  18. Paul, As I have pointed about before, this is not about making minor evolutionary changes from version to version of an existing standard that is widely supported. This is about an existing format that could be radically changed before it becomes an international standard, if it even does. Given that the binary formats are available, if someone decided to go that route, I continue to assert that using OOXML as it is today is simply taking too much risk.

  19. “Open XML will change through the process”

    don’t understand this… WTF are you talking about “open XML”? , is there any binary XML or something like that?

  20. So we’re at a junction in the development of the ‘industry’.

    There have been junctions before.

    Once upon a time, all the computers worth their salt ran EBCDIC http://en.wikipedia.org/wiki/EBCDIC character sets; System/360 http://en.wikipedia.org/wiki/IBM_Floating_Point_Architecture arithmetic; and SNA http://en.wikipedia.org/wiki/Systems_Network_Architecture networking.

    Nowadays, when you design one from scratch, you use ASCII http://en.wikipedia.org/wiki/American_Standard_Code_for_Information_Interchange character sets; IEEE http://en.wikipedia.org/wiki/IEEE_754 arithmetic; and TCP/IP http://en.wikipedia.org/wiki/TCP/IP_model networking.

    I think the most recent mass-produced design from scratch is probably the Sony Playstation 3 http://en.wikipedia.org/wiki/PlayStation_3 , or ‘Cell Broadband Engine’.

    In all those cases, standards defined by vendor-neutral standards bodies have superseded single-vendor standards. EBCDIC, S/360 float, and SNA still work, and work very well; but it’s a right pain if you want to interoperate between the kinds of machine.

    Would ISO (or IEEE) issue a standard for EBCDIC, S/360 float, or SNA ? Maybe, but it would be rather pointless. They work the way they work; IBM’s not likely to change them; nor is anybody else.

    Why did IBM implement EBCDIC, S/360 float, and SNA ? I imagine, looking back, it was that there was business to be done; clients to be served; and things had to work somehow. One lot of engineers, working for one vendor, designed them that way. There were changes … developments … of EBCDIC, S/360 float, and SNA ; but they all ‘just grew’ in respect of that one vendor’s perception of market requirement and technology capabilities.

    So, the history is that when the ‘rest of the industry’ get together for a consensus standard, it’s a chance to readdress things fundamentally. To get to vendor-neutrality; something that everyone can live with because they contributed to. The growth in the industry is growth on top of the consensus standard.

    A huge number of people, working for all sorts of unrelated businesses and management chains, got together and said “ISO 26300 is what we can live with, what we want to build on”.

    Will ISO stick to its position ? Microsoft’s document format is functional; of course it’s functional. But getting it to interoperate with any other vendor’s system or solution is as tricky as getting SNA to interoperate with TCP/IP; I would venture to say “impossible in the general case to do it exactly”.

    And we do have other vendors. Microsoft doesn’t own IBM. Nor does it own Google. Nor does it own all the university students, teachers, engineers, scientists, and government employees who keep giving us open-source contributions such as Linux. You can’t get 100% of the market. OS/2 may be gone, but Apple OSX and ‘stray animal’ Linux are there.

    Interesting times.

  21. > WTF are you talking about “open XML”?

    Marcelo, it is in fact a binary implementation fake-XML, created by Microsoft, for the purposes of continuing the MS-Office vendor lock-in in the face of successful competition from all the “office” applications that use the Open Document Formats. OpenOffice.org, Koffice, Abiword, etc.

    Microsoft is running _scared_, pulling out the dirty tricks to try and maintain their dominance. Thus the misleading name “OpenXML” which is nothing of the sort.

  22. There are many independant appplications that can consume the binary formats. This includes Microsoft Office and Open Office…=> this is limited interoperability because Microsoft has not explained how to perform the format proper, but it is still some level of interoperatibility. This is especially true since one of the applications are open source and free of charge.

    There are one single application that reads current office files, that is Microsoft Office. It seem reasonable that Microsoft should benefit from providing converters from current OOXML files into future versions. On the other hand it seeem equally reasonable that Microsoft must have understood that Ooxml was not ready for the Fast Track procedure. Until Microsoft implement ODF natively in Office and drop the misleading marketing about OOXML there is very little reason to trust Microsoft.

    Still the important point here is that interoperability of OOXML is not proven until a independant consumer of the current office format exist. The likelihood that anyone will produce a converter from Office current format into other alternatives seem pretty slim. Bob Sutors recomendation is obviously quite sound advise for anyone that are stuck with not using ODF.

  23. @Richard Callan

    Thanks for calling a spade a spade. Microsoft have been frantically trying to sew the seeds of the “Open” meme with respect to their MS “Office Open” XML format. Because I don’t consider Microsoft’s strategists to be stupid (deluded or conscienceless, yes, but not stupid), I can only assume that the ad/co-option of the words “Office Open” (which, to the uninitiated, might understandably be mistaken for “Open Office”) is disingenuous at best. An attempt to cloud the waters. And the fact that Microsofties invariably (corporate policy anyone?) refer to it by the rather presumptuous shortened version of “OpenXML” is a further attempt to pollute the “open” namespace with their specious lock-in leaning rubbish.

    Let’s spread the word. It’s MSOOXML format for MS Office 2007 and beyond. It’s got a lot to do with convincing governments (who are threatening to defect to ISO standard file formats like ODF) that Microsoft are “open” and ISO standard now, too. But in fact, they’ve got no intention whatsoever of adhering to this MSOOXML format. They’ll ensure that their implementations of it are slightly different (or “incomplete”) relative to the specification. And they’ll claim “it’s really hard to implement a spec with so many ambiguities!” as they have been doing all along with the W3C web specs and IE6 and 7 (I’m watching IE8 with interest)…

    Ultimately, interoperability isn’t about open standards. It’s about motivations and incentives. The ODF world is free from monopolies at the moment. As such, implementors of ODF have an incentive to strive for full implementation – but more importantly, they have an incentive to strive for PRACTICAL INTEROPERABILITY. Microsoft as the incumbent monopolist has no such motivation with its MSOOXML. It can create one or more slightly broken implementations of MSOOXML, all the while trumpeting itself as “standards compliant” – at least to the same degree as KOffice or AbiWord or OpenOffice or StarOffice or Symphony is. Or at least that’s what their marketing glossies will say. But that’s not what they’ll mean. They’ll try to leverage THEIR implementations of MSOOXML – which will the defacto standard.

    The really clever part of this – and all credit to Microsoft for coming up with something so brilliantly devious is this: huge amounts of open source and commercial developer time will be taken up by people trying to implement MSOOXML (based on the published standard) to offer MS Office compatibility… and – get this – they’ll be no more compatible with MS’s OOXML implementation than OpenOffice’s .DOC, .XLS, .PPT, etc. are compatible with MS Office’s legacy binary formats.

    If people realise this and stand behind ODF, and shun MS’s OOXML as Bob suggests, the world will be a better place, and Microsoft will eventually have to lose face by being forced to offer integrated ODF compatibility on par with its own format. By the way, if they say they can’t do it, they’re lying. They don’t WANT to do it – because it’s a lot easier to compete with yourself than with other companies.


  24. Dave, you couldn’t be more wrong about OpenDocument, incentives, and interoperability. The ODF spec has precisely zero interoperability conformance requirements. It’s a blank check for application and vendor-specific extensions with not even a superset profile specified for interoperability purposes let alone subset profiles. Moreover, there are no restrictions on implementing applications destroying markup created by other conforming applications.

    I’ll save the long-winded explanation and let Thomas Zander, the lead developer for KDE KOffice’s word processor, explain it to you in plain language:

    “One thing I have always dreamed to be possible is that when I write a doc in KOffice I can then open it in OOo to use that one feature that’s useful to me and then save it and continue in KOffice without loosing lots of data.

    “Its still a dream, of course. Most features are lost on opening and saving it in OOo, but its a nice goal[.]”


    Consider the history of just one KDE introperability proposal on the ODF Technical Committee, to have the OpenOffice.org unique document settings markup fully specified in the ODF standard:

    ■ Original KDE proposal from David Faure in 2005. http://lists.oasis-open.org/archives/office/200511/msg00048.html
    ■ Action items: (Document settings), resubmitted two years later by David Faure. http://lists.oasis-open.org/archives/office/200703/msg00209.html
    ■ Follow up from Michael Brauer (Sun Microsystems) needed. http://lists.oasis-open.org/archives/office/200704/msg00005.html
    ■ Action items: Michael Brauer – follow up on document settings, in progress. http://lists.oasis-open.org/archives/office/200704/msg00043.html
    ■ Action items: Michael Brauer – follow up on document settings, in progress. http://lists.oasis-open.org/archives/office/200705/msg00075.html
    ■ Action items: Michael Brauer – follow up on document settings, in progress.
    ■ Action items, Michael Brauer – follow up on document settings, in progress.
    ■ Next TC minutes: Action item disappeared.

    The action item was not restored until recently, after I began publicizing the failure of virtually every interoperability proposal that had been submitted to the ODF TC. But there is still no action on the item. In the meantime, the only specification of such application-specific markup lies in the OOo source code, where only tag names and not their functionality are identified. See e.g., lines 169-211 at http://oo.org/source/sw/sw/source/ui/uno/SwXDocumentSettings.cxx

    Microsoft has been roundly and deservedly criticized for putting application-specific document settings markup in the OOXML specification. Is ODF somehow superior because it allows the creation and use of such custom markup without any specification whatsoever? Here is what it says in the ODF conformance section:

    “Documents that conform to the OpenDocument specification may contain elements and attributes [extensions] not specified within the OpenDocument schema. Such elements and attributes must not be part of a namespace that is defined within this specification and are called foreign elements and attributes.

    “The various elements may have arbitrary attributes attached …

    “There are no rules regarding the elements and attributes that actually have to be supported by conforming applications, except that applications should not use foreign elements and attributes for features by the OpenDocument schema.:

    ISO/IEC:26300-2006 OpenDocument section 1.5. http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html

    Short story: ODF “interoperability” is a complete and utter myth and the OpenDocument TC isn’t exactly excited about making the myth come true. “Open” and “interoperable” are *not* synonyms, whether that bit of disinformation comes from Microsoft or anyone else. When ODF advocates criticize OOXML on grounds of non-interoperability, it’s no more than the proverbial pot calling the kettle black.

Comments are closed