Spin Spin Sugar

OK, forgive the random Sneaker Pimps reference and I promise we will move off this topic of ODF politics we've had the past week or two, but I wanted to call out something that Stephen McGibbon pointed out to me today. He mentioned this blog post he made on Monday entitled Spinning out of Control. Stephen pointed out that in the press release for the ISO approval of ODF, the following statement was made:

Billions of existing office documents will be able to be converted to the XML standard format with no loss of data, formatting, properties, or capabilities. This will facilitate document contents access, search, use, integration and development in new and innovative ways.

Now, I'm not sure if this was just an exaggeration, or if they meant that ideally in future versions of ODF it will be the case. It's clear though that as the spec stands now, it's not the case. There are clearly a number of areas either left unspecified, or specified to a more limited level than what people are already doing today in their documents. I'm not talking about future innovations, but basics that have been around for years. I know that pushers of ODF like to say this is just FUD, but really it's just a fact. Look at the spec. If the goal is to guarantee perfect fidelity with the existing base of Microsoft Office documents (which would be implied by the "billions of documents" statement), then there is still a long way to go.

Now, maybe fidelity with the existing base of Microsoft Office documents was a non goal. In reading through the newsgroups, it's pretty clear that the initial goal of ODF was mainly targeted around fidelity with the existing OpenOffice 1.1 format that was created by Sun. This is stated pretty clearly by David Faure who is a voting member on the OASIS Open Document Technical Committee:

The format is heavily based on the requirements, constraints, and experiences of *Sun* customers and KOffice users and developers though, and nothing says that those requirements are totally different. But for sure we didn't target *Microsoft*'s customers. The art of implying something without actually saying so...

"Almost no material changes" is certainly exaggerated, but yes, ODT is mostly bsaed on OO-1.1, it wasn't completely redesigned;

I think the key here is for everyone to just be clear on the goals. The ODF format is based on Sun's StarOffice, and Open XML was based on the Microsoft Office formats. Both have the goals of being open, both have been submitted to standards bodies, and both have a commitment from the donating companies (Sun and Microsoft) that there will be no licensing restrictions and anyone is allowed to freely use the formats. A big difference though is that the ODF folks took a slightly different approach as far as when to declare draft 1.0 complete. There are even features that OpenOffice supports that aren't yet defined clearly in the spec. The Ecma draft on the other hand pretty clearly defines everything, which then allows people to implement as much or as little of it as they want.

A recent statement that really left me scratching my head around this though was made by Gary Edwards up on Stephen's blog post. You may remember Gary as the guy who was under the impression that there was a mythical binary key in the Office XML formats. Gary is a member on the ODF Foundation and has been talking a lot about the add-in they built to open and save ODF in Microsoft Office. I still haven't had a chance to look at the add-in, as it's been kept pretty secret, but Gary has really promised a lot. Here is what he said on Stephen's blog about ODF not being full fidelity with the existing base of documents:

You're wrong. The OpenDocument Foundation plug-in will deliver near perfect fidelity for ODF documents produced by MSOffice. Our fidelity is near identical to the fidelity achieved when converting MS binaries to MOOX.

Maybe you need to pay more attention to the trials going on in Massachusetts. Oh, that's right. Microsoft isn't participating in those trials. Based on the piss poor fidelity of your translator project, i wouldn't participate either if that was the best i could do.

The truth is that it doesn't matter to us if it's billions of documents or ten documents. If that document can be loaded into any version of M$Office from 1997 to 2007, we can convert it with near perfect fidelity. At least as good as your own conversion within MSOffice to MOOX.

Perhaps you need to worry more about your own credibility than that of the ODF Community. We're doing just fine thank you,

Oh yeah, one other thing. Accessibility add ons to MSOffice work just fine with ODF. There is no performance differential between ODF and MOOX within MSOffice worth worrying about. There is no differential in how accessiblitiy applications are handled. So what was your complaint again?


I really don't understand this. First off maybe he isn't aware that the translator project we announced is currently in a very early prototype stage and is completely open source. It will continue to improve over the coming months. I understand people usually expect stuff that we announce to be further along, but we wanted this to be done in the open so anyone could comment and contribute.

I also thought that everyone was in agreement that the ODF format was not yet to a point where it could fully represent the existing base of Office documents, but Gary seems to say their tool can somehow get around this limitation. I don't know how deep Gary has looked into this, but it's simply not possible unless he and the ODF Foundation have already added significant extensions to the ODF standard. I haven't seen these new extensions documented anywhere. The OASIS ODF technical committee claims it's still over a year away from defining spreadsheet functions and tables in presentations, and no mention of solutions to the international numbering issues or even simple things like character highlighting.

Gary also doesn't seem to understand the performance problems with ODF. It has nothing to do with performance once the file is loaded. The problems are with how long it takes to read and write ODF files since they decided to use a generic table model to represent full spreadsheets.

So, while I think the ODF spec is a great representation of the OpenOffice file format, it's just not anywhere close to the Ecma spec in terms of representing Microsoft Office documents. And since we already have billions of documents in that format and hundreds of millions of customers, we absolutely have to keep our focus on the Ecma spec for now. We are also helping to build transformations between the two formats, which really helps to show the beauty of working with documented, open, XML formats.


Comments (51)

  1. Patrick Schmid says:

    I have read comments all over the place about the bad UI integration of the ODF translator add-in. I posted a discussion of this on my blog yesterday including what could be done to give ODF a more prominent status in the UI: http://pschmid.net/blog/2006/07/25/32

  2. Alex says:

    I thought I should include the next paragraph of David’s comment, which you helpfully snipped:

    "MS is just forgetting that the OD format was designed from the start to be as much independent as possible from the implementation of the office suite applications, and that’s why it was a great basis for a standard."

    The big difference isn’t when ODF was standardised. It was standardised when it was ready. The big difference is that ODF is designed in a generic manner, and the format represents the data. OXML has been designed for Office, and the format represents the data structures Office uses internally.

  3. BrianJones says:


    Thanks for including that, although I had already included the link to David’s full post so that folks could read the rest of what Dave said as well as the original question he was responding to.

    My point was that contrary to what a lot of people have claimed, the ODF format was designed by a much smaller group of people (primarily Sun engineers) working on StarOffice. That’s why ODF lacks a number of features that are present in other Office applications. I really wanted to make sure that it was clear that the goals of the two formats are very different.

    The OASIS committee work wasn’t started until after the format had already been designed. The committee (while it did make some changes primarily to tag names, namespaces) made the decision on a number of big issues to push the spec through to completion withough finishing those issues. This is why the claims some folks are making about ODF fully supporting legacy documents is false.


  4. Brian –

    Part of the reason you are seen as using FUD is that you seem to intentionally confuse the possible features in those billions of documents with the actual features.  I have worked for a major law firm that used Word extensively, and I doubt that 0.1 % (one tenth of a percent) of the Word documents created by that Firm use any feature that would not render perfectly under these tests.  MS Word in particular has many, many features that virtually nobody uses, so the issue isn’t just what could be done but what is done.  With Excel, that is probably somewhat less true, but it is still a relatively small (perhaps 10% to be generous) of the spreadsheets that do anything out of scope of ODF.  I do not have enough personal experience with PowerPoint to make even an educated guess at how many PowerPoint presentations use specialized techniques.

    This is not to say that a) ODF doesn’t need work, as it certainly does, or that b) the claims you quote aren’t meant to give an impression that is not quite correct, as they certainly are.  Nonetheless, if you can confidently say that there are billions of MS Word documents and Excel spreadsheets out there in the world, I can confidently respond that there billions of documents and spreadsheets which would render at least as well to ODF as to OpenXML.  Part of the reason is that Microsoft has not always cared as much as you seem to about fidelity with older formats, and I have even had to use other word processors such as WordPro to occasionally recover an MS Word document that is from an older version to convert it to an MS Word document that Word 2003 will read properly.  Microsoft’s claims that all previous MS Office formats will convert with complete fidelity to Open XML, or even to MS Office 2007 "native" formats are also extremely unlikely.

    I just wish both sides of this debate would quit with the over exaggerated claims for their side and the over exaggerated issues with the other side.  Just get on with making the best product/format you can and stop with the FUD, and that goes for both the ODF Alliance (of which I am a member) and Microsoft (of which I am a Business Partner and customer.

  5. Stefan Wenig says:


    converting a logical data model from a binary format to an XML format without ANY loss of data or structure is perfectly possible. In case of Office, the original format is quite complex, so there’s always room for mistakes, but the process is really straightforward. I believe there is no other option for MS than to try and achieve 100 % compatibility.

    ODF on the other hand has a different logical structure, and a conversion process has to match data to similar, but not identical structures. What this means is that

    – You lose parameters on the way (this is not just internal stuff, these are parameters that users modify)

    – You have to convert to other elements

    – The conversion process is usually based on trial and error: what’s the structure in the other format that makes the original data look most like the original document, although the mapping is not perfect?

    The effect is that your document does look different, even if you used only features that are generally available in both formats. Also, if you’re a hardcore template and stylesheet user, you’ll have a hard time tweaking a converted document, because the result of the conversion will not be what you’d have done had you been using that program in the first place. Worse, if you use macros that depend on the original structure, they are just not going to work!

    I hear Suse 10 ships with a OO.org version that understands MS Office VBA, so this is an issue for interoperability too. But even if macros were not supposed to be interoperable, ODF proponents have always been claiming that it’s an evil move of MS to create their own format instead of joining ODF, complete with all kinds of monopoly abuse accusations.

    A lot of these complaints showd up at http://blogs.msdn.com/jasonmatusow. ODF supporters repeatedly demanded clarifications about what exactly the problem would be when converting .doc to ODF. Jason was accused of lying quite a few times, by people who claimed that ODF is 100 % compatible. I had a discussion with a Sun guy on Jason’s blog who claimed that ODF had been created so much with MS Office in mind that there wouldn’t be any problems. The conclusion was always the same: MS did the wrong thing, and customers (especially from the public sector) should avoid the Open XML format and force MS to switch to ODF, because ODF has absolutely no disadvantages.

    At the same time, MS has not even started to attack ODF, the were merely making a point that they had good reasons to create a competing format.

    So, honestly, who’s creating the FUD?

  6. Bruce says:

    Stefan — the blame goes both ways; I think that was Ben’s point. But what Brian has been posting the past few weeks is pure FUD; factually correct, but quite misleading.

  7. BrianJones says:

    Bruce, how is it misleading? I’m talking about key pieces of technology that people use every day.

    Heck, look at the presentations the IBM guys have published around ODF. They are all stored as PDF, not .odp (the ODF presentation format). Why do they not save them as .odp? Well given that they use tables heavily in the presentation and tables aren’t supported in ODF, that’s probably the reason.

    I’m calling attention to the massively overly exaggerated compatibility that ODF supporters claim. No one has really looked at the deep details here and examined how the end user is affected. Everyone just looks at a few wordprocessing documents with heavy formatting and says "wow, it works". Well what about those spreadsheets that investment banks use to build their financial models? Or the presentations built by government agencies to provide briefing materials on a particular research area? These are really key scenarios that don’t work today with ODF.

    I guess you’re right, it should cause people who’ve already decided to mandate ODF to be a bit fearful, uncertain, and doubtful. But that’s not because of lies or even exaggerations. It’s because the ODF format is not yet complete. I think the OASIS ODF group is doing a great job, and in looking at the newsgroup postings there are a number of smart people there who really care about solving these problems. They haven’t done it yet though, and are still over a year away (at least). So it’s disingenuous for folks like the ODF alliance and Gary Edwards to claim that ODF is this magic bullet today, when that just isn’t the case.


  8. Francis says:

    It seems as though what separates ODF from OpenXML is not so much the format itself, but the tone of the respective formats’ proponents.

    Brian’s equability in entertaining and responding to the sometimes feverish pitch here is commendable. It’s also what keeps me coming back to this blog. Thanks!

  9. Bruce says:

    It’s FUD because you consistently make huge, unsupportable, generalizations based on small pieces of evidence. In every one of these posts you start with a legitimate observation, and then move on the point you really want to make: don’t use ODF.

    I’m not saying nobody on the other side does that, but that hardly excuses it.

    I think it’s fair to say that there will be interoperability trouble spots in BOTH of the formats, and the best way to solve them is to for the two groups to engage with each other, rather than to always look to score points in the blogosphere.

    I picked apart the new OXML/Office 2007 citation and bibliographic support on my blog, but I hope it’s clear I did this not to make MS look bad, but because I care deeply that you guys (and the ODF world too) get it right. And I hope you guys actually listen; you might regret it if you don’t.

    BTW, when I do presenttions I use either XHTML (typically for teaching) and  Keynote-produced PDF. Why? Because I think both solutions are superior in their domains than both PowerPoint and the ODF presentation apps!  So I think it’s problematic to use the fact that IBM happens to post presentations in PDF to reach any meaningful conclusion.

  10. BrianJones says:

    Bruce, I am attacking the public statements that the ODF pushers have made around the ability of ODF to represent the existing base of Office documents. It’s simply not true, and I don’t think anyone can argue that.

    They are spreading misinformation, and are actually getting governments to create policies mandating ODF. That is irresponsible, as ODF is not able to support a number of key scenarios people do today. You say that you use Keynote for creating your presentations (Apple of course is working closely with us in Ecma and you can bet that they are making sure that the Open XML format is fully interoperable). I’m not as focused on the application you choose, but on the format you choose. There is most likely no way that you could represent the majority of those keynote presentations in ODF, and that is my point. Instead of ODF, you need to use another format like PDF or XHTML. How can the ODF pushers out there claim that ODF is this silver bullet when it can’t be used in these common scenarios?

    Like I said before, the level of analysis here seems to have stopped at the base wordprocessing document. As you look at more complex international features in wordprocessors, and core functionality in spreadsheets and presentations, the house of cards starts to fall.

    I really appreciate all the valuable feedback you’ve given on Open XML, and I thank you for that. You have to understand though that much of what I’m talking about is related to the fact that there is a huge push by IBM and Sun to get governments to mandate ODF. That’s why I have to call attention to the fact that ODF isn’t really even done yet, and they are being dishonest when they make claims around the richness and 100% compatibility of ODF.

    We have always been very clear about the design goals of Open XML, and what it will achieve. I would like to see the same come out of the ODF camp. That’s why I included that quote from David Faure. It was a straight forward honest answer, and didn’t try to make the exaggerations I’ve seen from other parts of the ODF community.

    As I said before, there are a lot of smart people who have worked on ODF and continue to work on it. I don’t mean to offend them with my statements. Those folks should be proud of what they’ve accomplished so far, but they should also be upset at the pushers out there who are seriously over promising. They are putting ODF in a position where it will look bad.

    Why do these people constantly rip apart the Ecma process and the Open XML format? We have never once said that you can’t have both formats. We’ve never said that ODF doesn’t work in certain scenarios. All we’ve said is that there are a number of scenarios where Open XML is necessary, and it doesn’t make sense to mandate around ODF on its own. It’s clear that there are strong business interests on both sides here. I think the key difference is that the ODF camp is pushing really hard for exclusion of Open XML; while the Open XML camp is just saying that there are a ton of legitimate scenarios where Open XML is required. Allow for both formats. Participate in projects like the Open XML -> ODF translator. Stop trying to delegitimize the hard work that is going on in Ecma, and be honest about goals and shortcomings from both sides. Stop complaining about every step we take to be better about openness and interoperability. Would I start complaining if OpenOffice build in support for Open XML? No way… I’d be thrilled! Why do all the ODF pushers complain then when we respond to what everyone was asking us to do and start up an open source project to support ODF in Office. Is it perfect? No. But for crying out loud, it’s an open source project that is completely transparent and anyone can participate in. It’s also just in a prototype form with a ton more work to go so either participate or be patient.

    Neither format is perfect, and neither will be. Look at all the issues and lacking features in XHTML. It’s still one of the most valuable formats in the world though, and I don’t think anyone would argue that. All I’m asking is for the ODF folks to admit there are legitmate needs for the Open XML formats, and that the work going on in Ecma is a huge benefit to the community. We’ve taken what was essentially a locked up binary format that was used to store billions of the worlds documents, and we’ve XMLized it; fully documented it; started to build tools around it; and removed any licensing/IP issues. That’s a good thing.


  11. Bruce says:

    OK, Brian, fair enough on your final point. I agree; it *is* a good thing.

    FWIW, IIRC, the quote from David Faure actually disputed the notion that MS had earlier been pushing that ODF was essentially a Sun-only affair. I think you’re being a bit selective there. If you read farther down he said:

    "MS is just forgetting that the OD format was designed from the start to be as much independent as possible from the implementation of the office suite applications, and that’s why it was a great basis for a standard."

    BTW, read the ODF TC Charter for the design goals. I think they actually are straightforward, and straightforwardly different than your’s.

  12. Oscar says:


    I couldn’t agree more with your last point above. It is definitely a good thing. However you are talking about this issue as if there were no dismissive and biased statements from Microsoft about ODF, and about other competitors etc as "hobbyist" attempts.

    As an example you keep stating that ODF is based on Sun Staroffice format, selectively quoting David Faure’s post and ignoring the statements in the Openoffice.org XML project website as to what the initial goals were. At this stage of the debate you can not claim ignorance as this has been repeatedly mentioned in your blog.

    You work for Microsoft and there is quite a bit of history on how you compete in the market. At some point you will realise that biased statements like these actually discredit you in front of many people.

  13. BrianJones says:

    Hi Oscar and Bruce,

    Sorry if this hasn’t been clear, but the point of this post was to try to clear up where my criticisms lie. I actually truly respect the work going on in OASIS on the ODF Technical Committee. In fact, I want to apologize if any of the statements I’ve made in the past year have been offensive to those folks. I’ve tried to always be clear that I have no problems with ODF as a document format. I just don’t see it as a document format that would work for our needs.

    My big issue is with the folks making claims like I mentioned above. You have the press release on ISO making claims that I don’t think are achievable with the current version of ODF. The ODF Alliance is pushing folks to mandate only ODF, and I definitely have issues with that. I want for those folks to acknowledge what the goals of the OASIS TC were, since (as you mention) they have been fairly well stated for some time. Compatibility with the existing base of Microsoft Office documents was not a goal, and so the ODF Alliance/Fellowship/Foundation probably shouldn’t be claiming that it does that.

    Again, I apologize if I’ve offended any of the technical folks working on the formats or tools. I just need to show why Open XML is a needed format, and why the standardization in Ecma is so valuable.


  14. Gary Edwards says:

    "ODF is this magic bullet today"  

    Hey, that’s catchy!  Mind if i use it?

    Just to confirm your suspicions, the "interop eXtensions" proposal does exist and has been quietly making the rounds of OASIS ODF TC members.  The iX proposal itself comes out of our work in the Massachusetts RFi trials, where high fidelity “roundtripping” of ODF files is a priority.

    Yes, the conversion of Microsoft binary file formats has long been problematic for non Microsoft applications.  The Foundation’s ODF Plug-in however isn’t your normal “non Microsoft” application.  The plug-in works inside MSOffice applications, taking advantage of your excellent MSOffice Add On architecture.

    It turns out that converting MSBinaries to ODF from this inside position is a far more effective approach than most would think possible.  Still, to achieve the high fidelity roundtripping quality of ODF documents needed by Massachusetts (and perhaps anyone else wanting to transition to ODF), other ODF ready applications will want to consider engaging the interop eXtensions.  The consumers of ODF solutions certainly will want this high level of conversion and roundtripping fidelity across all ODF ready applications and document processing chains.

    This may be a difficult concept for you to wrap your mind around Brian, but the ODF Plug-in makes MSOffice a first class ODF ready application suite.  It’s so good, i actually think MSODF should be the reference implementation of the ODF spec, but that’s just me.  The interop eXtensions simply insure that all other ODF 1.2 iX ready applications are able to transparently exchange and round trip MSODF files with the same high fidelity that the ODF Plug-in enables in MSOffice handling of ODF documents.

    There is no doubt in my mind that the world’s digital information is going to move, sooner or later, into a portable document file format based on XML.  There are only a handful of contestants to consider.  The question of which of these few contestants will become the universal file format of choice remains to be seen, but that’s where things are heading.

    For ODF to make that universal file format claim, we know the challenge of being able to convert a legacy of binary bound information is a hurdle we must cross.  And do so with ease.  That means a conversion process that is completely transparent, delivers on high fidelity, results in excellent roundtripping, and is entirely non disruptive to the existing business processes and add on solutions programmatically bound to specific applications.  

    A tall order indeed.  Thanks to Massachusetts’ uncompromising insistence on the above criteria, we now know how to do this.  The rest, is as they say, a matter of execution.  Our delivery date is January 2007.  What’s yours?

    We know the ODF Plug-in can solve all the high fidelity issues of conversion.  We also fully believe that the interop eXtensions (ODF 1.2 iX) will solve the high fidelity issues of roundtripping ODF documents across a mixed environment of ODF ready applications; including the big Kahuna of ODF ready applications, MSOffice.  

    What about performance, an issue that seems to concern you greatly?  Reluctant as you are to disclose the truth, performance is nevertheless an application specific thing.  It has little to do with the file format.  

    Test an ODF document inside MSOffice, and test the same ODF document inside OpenOffice.org, and yes there is a performance differential entirely dependent on what it is your trying to do.  

    However, inside MSOffice, where the ODF Plug-in does it’s magic, there is no measurable difference between ODF and MSXML – MOOX documents.  As you well know, both Massachusetts and the EU IDABC have seen first hand the performance clock comparisons between MOOX and ODF concerning giant documents and spreadsheets in MSOffice.  (OBTW, you’re currently down over 13 seconds with a giant spreadsheet – but you and i both know this is an issue of tweaking the engines, and not in any meaningful way a show stopper for the average bear 🙂

    Since OpenOffice.org doesn’t support MOOX, there isn’t a way to even begin a cross application performance comparison of MOOX.   We can however do this routinely with ODF.  And we do, with great delight and entertainment i might add.

    About the submission to ISO.  I can understand your angst, but the smell of desperation is unbecoming.   OASIS ODF 1.0 met all of it’s stated objectives, including accommodating a number of late in the cycle requests from the EU.  They told us what they needed from ODF to qualify as an ISO submission that they would fully support, and we gave it to them.  ODF 1.0 also met all the basic requirements of more than a few independent production level applications.  Every aspect of the ODF 1.0 specification has been road tested in the real world under production level stress loads.   With more than five years of real world action, and multiple vendor, multiple purpose implementations, what more do you want?

    Oh.  You want perfection.  Me too.  Don’t get your panties in a bunch though.  We’ll get there.  I promise you, ODF is going to meet all your expectations and more.  Now, will MOOX meet all my expectations?  Like application and platform independence?  Will it be portable and useful across information systems and domains other than those provided by Microsoft?  Will the license be changed so that we can extend MOOX as needed?  Will i be able to take a MOOX document and replace the internal binding model with XForms, or Jabber, or a Java Connector model?  If not, what use is MOOX to a J2EE, Lotus Notes, or LAMP shop?

    But let me ask you something Brian, as the metaphorical representative of Microsoft, are you going to road test MOOX for five years, across multiple independent cross platform implementations before submitting to ISO?  Are you going to embrace and enable all the requests of interested parties like the EU and Massachusetts before submitting?  

    January 2007.  Are you going to be ready by then?  We will.


    OBTW, if you’re still all twisted up about the fabled binary keys, check with the original EU Valoris Report.  They were the first to make it an issue.  Stuck it right in your face too as i recall, demanding the keys be removed.  Good thing you complied.  It was the right thing to do.

  15. Dan says:

    Microsoft has refused to document their .doc format, intentionally trying to make it difficult for other applications to read it, just so they can tout thir new XML format as being able to better interoperate with the old formats.   In the past they have used the opacity of .doc to their advantage, creating slight differences between successive versions of the format to make people upgrade.  With this kind of behaviour, don’t you think it’s understandable that we are rather put off by Microsoft pointing to the obscurity of its .doc format (which is intentional) as a reason why its new XML format is better than ODF?  That’s basically what Microsoft is doing when it says that its XML is better at being compatible with the "billions of documents".  I’m sure if Microsoft were to fully document its proprietary formats rather than attempting to trap users’ data, folks would have no problem making sure that ODF was 100% compatible with MS proprietary formats, rather than 90 something percent.  And people might start to trust you a bit more rather than holding you responsible for the dodgy, anti-competitive tactics your company has carried out in the past (and continues to do).

  16. BrianJones says:

    Hi Dan, if you want to get access to the binary format documentation just e-mail officeff@microsoft.com. It’s available under the CNS, so all you need to do is provide some contact information I believe and you should be good to go. Let me know if that doesn’t work.

    Hopefully that format will soon be a thing of the past though, as the new XML formats support all the same functionality, but are much easier to program against.


    Hi Gary, thanks for your interesting thoughts.

    I’m not sure that you answered the questions I had, but that’s ok. I still am not clear on how you are representing the features that aren’t currently in the ODF spec. You mentioned some interoperability extensions, is that what you are using? Or are you saying that your tool doesn’t provide full support yet but once ODF version 1.2 comes out later next year you’ll be able to support it?

    Is there a way to actually get access to your tool? I’d really like to take a look.

    You asked a few questions of me, so here’s my attempt to answer:

    Q1: "ODF is this magic bullet today"   Hey, that’s catchy!  Mind if i use it?

    – I think you missed my point. Statements like that are what cause all the confusion in the first place.


    Q2: Our delivery date is January 2007.  What’s yours?

    – Not sure what you are referring to. Office 2007, or the translator project. The translator project schedule is up on SourceForge so you can see what the milestones and deliverables are. Where is the information on your project? Where can I download it?


    Q3: What about performance, an issue that seems to concern you greatly?  Reluctant as you are to disclose the truth, performance is nevertheless an application specific thing.  It has little to do with the file format.  

    – I’m not sure what you’ve been looking at but this is definitely not true. Obviously a format has a huge impact on the open and save times for an application. Why does OpenOffice’s Calc open an Excel Binary file orders of magnitude faster than it opens ODF spreadsheets? Try it yourself. The decision to use a generic table model to store spreadsheets has led to a format that is slow to open and save.


    Q4: Every aspect of the ODF 1.0 specification has been road tested in the real world under production level stress loads.   With more than five years of real world action, and multiple vendor, multiple purpose implementations, what more do you want?

    – Shoot, I’d at least expect a well defined syntax for spreadsheet functions, and tables in presentations. 🙂


    Q5: Now, will MOOX meet all my expectations?  Like application and platform independence?  

    – Absolutely


    Q6: Will it be portable and useful across information systems and domains other than those provided by Microsoft?  

    – We’re working with folks from both Novell and Apple on the spec. The formats are just as portable as ODF.


    Q7: Will the license be changed so that we can extend MOOX as needed?  

    – I love the stubbornness with the naming. There are a number of folks out there like you who like to call it "MOOX". It’s kind of like saying M$ I guess. Should I add an "S" for Sun and call it SODF? Or maybe SIBMODF? 🙂 Anyway, the spec is completely extensible. You can add as much stuff as you want.


    Q8: Will i be able to take a MOOX document and replace the internal binding model with XForms, or Jabber, or a Java Connector model?  If not, what use is MOOX to a J2EE, Lotus Notes, or LAMP shop?

    – Like I said, it’s completely extensible, so go for it!


    Q9: But let me ask you something Brian, as the metaphorical representative of Microsoft, are you going to road test MOOX for five years, across multiple independent cross platform implementations before submitting to ISO?

    – ??? what kind of road tests did you do? The only implementations I’ve seen don’t really interoperate too well. We’ve been working on XML within our formats since the late 90’s and have learned a lot. The folks we’re working with in Ecma have also worked on other standards bodies and they too are bringing a lot of great insight.


    Q10: Are you going to embrace and enable all the requests of interested parties like the EU and Massachusetts before submitting?

    – Anyone is free to join the Ecma TC. The latest member to join is the Library of Congress, and they’ve already had a bunch of great feedback.


    Again, thanks for the interesting comments. Please point us to the location where we can try out your tool. It would be awesome to try out!


  17. Gary Edwards of the OpenDocument Foundation stopped by the other day to comment on my post…

  18. Brutus says:

    Seems to me the ISO ratification of ODF was a farce.  All ISO did was rubberstamp a very incomplete spec, so ODF advocates can use that farcical ISO imprimatur as a weapon to convince (trick) governments into mandating the use of that incomplete spec.  The ECMA process that’s been used for OpenXML has been far more rigorous than the ISO "process" ("sham" would be a better word) used for ODF.

  19. Brutus says:

    Gary Edwards sounds like a raving lunatic slashdot refugee.  Anyone that uses the term "M$Office" clearly has no credibility.  And his conspiracy theories about secret binary keys and his rantings regarding the MS-sponsored ODF translator only proves that he’s lost it.

  20. Don Giovanni says:

    Alex, I’m sorry, but the statement "MS is just forgetting that the OD format was designed from the start to be as much independent as possible from the implementation of the office suite applications, and that’s why it was a great basis for a standard" is a flat out lie.

    As I said in when responding to an earlier entry to this blog:

    Here’s what http://xml.openoffice.org/ says regarding ODF and OpenOffice.org:


    OpenOffice.org XML file format: "The OpenOffice.org XML file format is the native file format of OpenOffice.org 1.0. It has been replaced by the OASIS OpenDocument file format in OpenOffice.org 2.0."

    OASIS OpenDocument file format: "The OASIS OpenDocument file format is the native file format of OpenOffice.org 2.0. It is developed by a Technical Committee (TC) at OASIS. The OpenDocument format is based on the OpenOffice.org XML file format."


    So, ODF is *based* on OpenOffice.org’s previous XML format.  ODF is not "nuetral" any more than OpenXML is.  ODF is simply the opened version of OO.o’s previous XML format and OpenXML is the opened version of Microsoft’s previous XML format.  ODF is not standing on any higher moral ground, contrary to the rhetoric of the ODF peanut gallery.

  21. Brian –

    Sorry, I really need to take issue with your first comment in response to mine.  Certainly, as you say "converting a logical data model from a binary format to an XML format without ANY loss of data or structure is perfectly possible.",  but which binary format did you mean?  As far as I have been told, it is the binary format which is to be released in MS Office 2007.  Are you suggesting that there have been no changes in that binary format since Office 2003/98/95?  Of course there have, so the question is not whether binary compatibility with a n XML format is possible, but whether binary compatibility with several quite distinct variations is possible with a single format.

    My company does data format conversions regularly, and I fully agree that ODF will not do a 100% conversion from Microsoft Word docs, much less some of the other Office formats.  On the other hand, I flat out don’t believe that Microsoft is any more capable of 100% conversion from all pre-existing .doc formats, although I certainly applaud both Microsoft and the members of the ODF Alliance for making 100% the goal.  It is just too common for Microsoft Word 2003 to not be able to render Microsoft Word 98 to believe that you can fully solve that problem.  You don’t even have that big an advantage over ODF, since your XML format seems artificially constrained to the binary format in Office 2007.

    So, I hope you prove me wrong, but I think it is equally prepsoterous for the ODF Alliance or Microsoft to claim 100% format fidelity.  I wish both sides would admit that and move on to more constructive areas, such as better future planning.  After all, we should care equally about the next several billion documents to be created.

    – Ben

  22. orcmid says:

    Gary Edwards hath scriven:

    "OBTW, if you’re still all twisted up about the fabled binary keys, check with the original EU Valoris Report.  They were the first to make it an issue.  Stuck it right in your face too as i recall, demanding the keys be removed.  Good thing you complied.  It was the right thing to do."

    I went to the Valoris Report that was linked to on Sam Hiser’s blog and I couldn’t find anything about binary keys in the report.  I asked there for a specific citation to a page, at least.  I’m asking again.   Where in the EU Valoris report is there anything about some key on Microsoft XML documents (the Office 2003 ones, as I don’t think the 2007 format were around for that report to analyze).  I am yet to have anyone show me a document that has such a thing.  Surely this is a simple empirically confirmable fact, yes?

    To paraphrase, "show me the key!"  

  23. Oscar. says:

    Don Giovanni, you just needed to click a bit further down the link you provide. These are the original goals of the Openoffice.org XML format:

    Our mission is to create an open and ubiquitous XML-based file format for office documents and to provide an open reference implementation for this format.

    Core Requirements (these items are absolutely required)

      1. The file format must be capable of being used as an office program’s native file format. The format must be "non-lossy" and must support (at least) the full capability of a StarOffice/OpenOffice document. The format is likely to be used for document interchange but that use alone is not enough.

      2. Structured content should make use of XML’s structuring capabilities and be represented in terms of XML elements and attributes.

      3. The file format must be fully documented and have no "secret" features.

      4. OpenOffice must be the reference implementation for this file format.

    Core Goals (these items are highly desired)

      1. The file format should be developed in such a way that it will be accepted by the community and can be placed under community control for future development and format evolution.

      2. The file formats should be suitable for all office types: text processing, spreadsheet, presentation, drawing, charting, and math.

      3. The file formats should reuse portions of each other as much as possible (so for example a spreadsheet table definition can work also as a text processing table definition).

    OASIS File Format Standardization

    XML file formats allow users to regain ownership to his/her own data, by allowing access and manipulation of office documents by arbitrary tools which support the file format. To make such capability ubiquitous, we believe it is necessary to standardize file formats. Thus, we have contributed the OpenOffice.org XML File Format to OASIS. The further development of the format now takes place in the OASIS OpenDocument Technical Committee.

  24. Cary Edwoods says:

    Brian, I take offence at your constant bickering about how OpenDocument format is essentially disabled ! This is offensive, not politically correct and downright unacceptable ! OpenDocument format is in no way "disabled" – it is "differently abled" !

  25. Gwyn says:

    Firstly, I use Latex, MSWord et al., and OOO.

    None of the current or proposed formats are, in my opinion, ideal.

    The problem lies in mixing the document’s data and the presentation of that data. The process of publishing should be after writing. This is what Latex part-way achieves. With MSWord and OOO, due to the WYSIWYG, formating as you type is the routine. Indeed, the presentation/publishing is almost done up-front. Ideally, the system used in LATEX of defining the documents elements, eg, date, author’s name, abstract, email, and then placing the elements in the published work as required by a template (the positioning depending on the template, eg, the author’s name may be near the beginning or at the end

    depending on whether it is a report or a journal publication). However, LATEX can also mix in a complex macro language formating commands and data structures. I think we should be looking more towards an xHTML/CSS structure enabling the post-formating of LATEX. The data-based xml then has the advantage of having meta-tags for entry of the document (if required, chopped up according to the tags) into a database, and also being "published" in several formats depending on the applied style-sheet. If I want to fix the way the thing looks then I need some format (PDF?) which is not readily alterable.  

  26. Alex says:

    Don Giovanni –

    Obviously, I don’t have to point out that I didn’t make that claim. Believe David Faure or not; you can’t pick and choose which bits of his statement you like and then make a call to his authority.

    I think it’s pretty clear that ODF is very much implementation-independent. The markup structure is heavily influenced by existing standards and re-uses existing standards. OXML does little of either.

    Obviously, we’ll have to wait until OXML is properly specified, but I would be willing to bet that the final draft has changed little from Microsoft’s original submission.

  27. Stefan Wenig says:


    the phrase you quoted was mine, not Brian’s. So let me try two answer the two points you’re making:

    "I think it is equally prepsoterous for the ODF Alliance or Microsoft to claim 100% format fidelity"

    That’s not true. You can put anything in XML without any data loss, as long as you design the XML schema with this requirement in mind. If you have a formal, computer-readable specification of the original (binary) format, you could even build a program that does just that.

    There’s no way you can even come close to this when you are mapping two existing formats that were not buildt with each other in mind. It’s just not true. (Of course MS didn’t use an automated process, so, as I said, there’s room for mistakes. But the two aproaches are still light years apart.)

    "but which binary format did you mean?"

    Since Open XML is the default format for Office 2007, I don’t think that MS has changed a lot in the binary format and adapted the XML format as an afterthought. So the reference for binary compatibility would be Office 2003. Any problem that Office 2003 has with reading binary Word 98 files will probably also be there when converting Word 98 files to Open XML.

    But that’s more or less a problem of the past. These quirks in backwards compatibility have already had their effects, and it’s just about as useful to complain about those as it is to complain about any other problem in the old binary formats. I mean, there’s a reason even MS want’s to get rid of them.

  28. Stefan –

    Sorry, I misread the author.  If you read what I wrote, I agree that you can have 100% format fidelity with a single binary format, but Microsoft is not claiming that.  It is exactly the issue of with earlier formats that causes me to claim that they can’t have 100% format fidelity.

    Also, you say the following: "Since Open XML is the default format for Office 2007, I don’t think that MS has changed a lot in the binary format and adapted the XML format as an afterthought. So the reference for binary compatibility would be Office 2003."

    There are two problems with this logic.  The first is that this assumes that there have been no revisions in the Office technology since the 2003 release.  I think Microsoft would jump to argue that that is not true.  If the Open XML format were really designed to the 2003 binaries, it would be just as difficult to force the changes for 2007 back into that format, as the alternative which is to force the 2003 binaries into the 2007 format.  You can’t both argue that the XML is directly taken from the 2003 binary format and that it is completely compatible with any changes since.

    – Ben

  29. orcmid says:

    I think there’s a confusion about the Microsoft Office binary formats (specifically, for Word, Excel, and PowerPoint, the first ones to be covered by Office Open XML) and features carried in that format.

    I believe it is accurate (but perhaps not apt) when Microsoft represents that the document format has not changed since it was first introduced (in Office 97 I think, but certainly by Office 2000, I’m too lazy to check).  This same binary format is available in Office 2007 and I am willing to believe that there is full roundtripping between the Office 2007 binary version and the corresponding OOX files.  (That is the stated intention but I am in no position to test for discrepancies that might exist in the beta implementation.)

    There are downlevel differences, whether intentional or unintended, and these have to do with features carried in the format.  The downlevel degradation is supposed to be graceful.  The prospect of encountering uplevel features was built into the early versions, according to the accounts I’ve seen, but it means that you can’t always roundtrip from a later version of Office to an older version and back again and have fidelity to the original.  (But if it works for the 80-20 ODF case, whatever it is, it probably works about as well in Office.)  The same will be true with the OOX converters when they are used with downlevel versions of Office, and Brian has reminded us of that.  (I am using the current beta with Office 2003 pretty much on a regular basis.)

    The same thing will happen when ODF is reved, as it surely will, and downlevel ODF implementations are "surprised."  Depending on how this is handled, any uplevel extensions will possibly be treated as foreign elements and, in accordance with the ODF specification, be ignored but preserved (however one can rationally do that on a practical case by case basis).

    So there is nothing happening here that is not already happening with ODF (except the lack of a floor specification and poor anticipation of up-/down-/cross-level issues will be painful for the early deployment of ODF on any significant scale in interchange settings).

    Irreverant side note:  I notice that the OpenOffice.org 2.0x that I run does a pretty good job of importing and then preserving basic features from the binary version of an Excel 2003 spreadsheet that I use every day.  There are some niggling roundtrip issues having to do with number formats.  On the other hand, if I save the very same spreadsheet in Excel 2003 Spreadsheet.xml, OOo imports it (using OpenOffice-specific extensions for the formulas) but fails pretty miserably to preserve the features and it won’t roundtrip successfully because of that.  Excel doesn’t have any problem re-importing the Spreadsheet.xml, so my document is not using any features that don’t roundtrip from Excel binary to Spreadsheet.xml and back.   So this experience has nothing to do with limitations of the formats.  Obviously, both formats can potentially go back and forth and roundtrip between Excel and OOo, because the .xml version doesn’t lack anything that the binary version has, in my particular case, and the binary goes back and forth pretty much undisturbed.  This just shows that the OOo conversion paths are not at the same level of quality with regard to different Excel formats.  It’s a reality and current-state situation, not the potential case.

    So when kvetching about the way-early not-even beta, function-incomplete status of the open-source OOX-OOF translator (if that’s what we should call it), one should be mindful that even non-beta release software has a tough time with full-fidelity-preserving conversions even when it is clearly possible in the case of specific documents (like whatever the non-specific 80-20 case is that people keep handwaving as good-enough for ODF).

    It’s all about reality. In the end, reality wins. (Based on loose analogy with the principle that nature will not be fooled.)  Of course, there is P. T. Barnum to be concerned about in the short term.

  30. Yuri T. says:

    Brian, this spin game is disgusting – I mean yours.  Sure there are .doc files that cannot be converted to ODF.  There will always be,  because YOU will ensure this.  The point is that there _are_ billions of documents that _will_ convert fine, and the percentage will grow over time.  (Hey, maybe the next version of ODF will even support Word macro viruses!)

    I’ve been having conversations with some friends who say "Microsoft is changing, Bill is gone, maybe the industry will come to trust them again."  Then I come across a blog like yours, and I think no, until people like you are around, the industry will never trust MS.

    Looks like "sudo apt-get install openoffice.org" finished, time to get back to work.

  31. Stefan Wenig says:


    you’re right, I didn’t read carefully enough.

    "The first is that this assumes that there have been no revisions in the Office technology since the 2003 release."

    I’m not assuming this. What I am assuming is that, starting with Office 2007, the primary development takes place in the XML arena, so additions would have to be retrofitted into the new binary format. What this means is that the Office 2007 XML format is 100% compatible to everything that office 2003 can read. that seems good enough for me. So, if some word 98 stuff can’t be read, you already have a problem today (unless you are still using word 98, in which case you are probably not a word power user anyway ;-))

    Fixing backwards compatibility issues with pre-2003 versions that surfaced in Office 2003 or even before would be a nice additional goal for Open XML conversion. But as I understand it, that’s not part of the story. Technically, it’s more a problem of the current binary reader engine than of the file format anyway.

    In Office 2007, binary formats are for backwards compatibility only, so I don’t get how compatibility to a new, extended binary format (which nobody should be using anyway) would matter. Everybody has been complaining about these binary formats forever (and for good reasons too). And now you are complaining that the new (default) format might not be compatible with a new, revised binary format containing features that cannot be read by old Office versions anyway?


  32. Stefan –

    No, I could care less about the new, revised binary format.  Yes, I am glad that Microsoft is moving to a more universally defined standard.  But how do you draw the conclusion that since "primary development takes place in the XML arena", that means that "Office 2007 XML format is 100% compatible to everything that office 2003 can read".  

    Is there any evidence or indication that Microsoft would really make the brand new, feature filled version of their software dependent on a four year old standard?  They may have a goal of 100% fidelity in conversions, but it seems at least plausible that they would base their 2007 XML format on their 2007 binary format (or vice-versa if you like), not on their 2003 binary format.  I don’t see how you can so confidentally make this assumption.

    – Ben

  33. Gareth Horton says:

    Dennis H. et al

    The mythical secret key has been a mystery for some time now.



  34. Fernando says:

    Come on, I´m sure that there is someone in the ODF camp more mature than Gary Edwards that can explain the hyperbolic claims made in the ISO press release. The silence so far from Sun and IBM has been deafening, not to mention ISO and OASIS themselves.

  35. I am curious whether any estimates have been made about how many billions of Word, Excel and Powerpoint documents there are out there.  This is significant because if there are, say, thirty billion, it might not be hyperbole at all to say that "Billions of existing office documents will be able to be converted to the XML standard format with no loss of data, formatting, properties, or capabilities.", because it is quite likely that even given a generous 80-20 rule, 80% of those contain nothing remotely difficult to convert to almost any other format.  It is fairly likely at least 20% of Word documents would translate just fine even to plain text, and 20% of, say, 20 billion, would still be "billions".  If on the other hand, there are only two billion such documents, this would definitely be hyperbole.

    This is not to defend the extreme claims that do come out of the ODF camp at times, but it does point out that the quoted claim may not be unreasonable.  Of course, I may be missing a nuance here.

  36. John Robins says:


    You may have a great time pocking fun at ODF. I don’t care about ODF.

    However, I would rather have you spend more time improving your own mess rather than criticizing somebody else’s.

    Microsoft’s XML format is a _giant_ mess with no consistency.

    The date problem I mentioned is just one out of many problems.

  37. Stefan Wenig says:


    What I tried to say is: I assume the 100 % goal is as compared to the current (i.e. 2003) binary format. I’m not saying this has been achieved, sorry if I was unclear. But I am claiming that it is a perfectly achievable goal if you can tweak the target schema, which the ODF converter guys cannot. That’s where I think major differences arise, and that’s why I think the statement is somewhat reasonable from MS and completely unrealistic from ODF.

    How can I be sure that compatibility is measured with the 2003 binary format in mind? I cannot. But older formats are unlikely, and the 2007 binary format is almost completely irrelevant, so it kind of has to be 2003, right? Maybe Brian can say something about that.

    I like your defense of the "billions of documents" statement, btw. So instead of outright lying, this would make it intentionally misleading. Imagine Microsoft making up stuff like that … and the response 😉


  38. Oscar says:

    Good point, Stefan.

    The problem is that is exacly what we are getting in this blog. Intentionally misleading.

  39. Oscar says:


    If you think OpenDocument is so bad why do you stop it being distributed alongside MS Office beta?


  40. Haben wir jetzt nach den sog. Browser-Krieg einen solchen um Office-Dateiformate? Im näheren sowie…

  41. Stefan Wenig says:


    Your twist the meaning of my statement and don’t even think it worth the trouble to explain your point. Brian gets paid for dealing with arbitrary statements like yours, so I guess that’s OK. I don’t, so please leave me out of your propaganda games.

  42. Oscar says:


    Apologies if i have offended you. I thought I was keeping with the general tone of this entry in the blog. Anyway, what my point was is based on my experience of both programs I think the impression Brian is trying to convey, ie. OpenDocument and Open Office are not 100% compatible with the existing installed base of office documents has at least as much spin as the claim of some guys in the other side of the fence.

    In my experience and for most documents I’ve used the formatting is kept to the degree I need. If I want perfect fidelity I wouldn’t trust Office either, I would use PDF.

    Where I think he may have a point is when you are working/collaborating with MS Office users on the same document. There again I have experienced some issues when upgrading to a new Office version is not done across the organisation.

    So I don’t see this as an engineering problem but as a market reality and perception problem. I can not argue whether fidelity is 97% or 101%, I can tell you that based on a fairly thorough use of both programs the level of interoperability you can achieve is more than satisfactory.

    As stated by other people in this blog, the reason is not even better is that existing binary documentation was not available under a license that most developers could work with, so they had to resor to reverse engineering. In that sense the new MS Office XML programs should be an improvement.

  43. Stefan Wenig says:


    we will have to see what the impact of incompatibilities between ODF and the .doc format is for various szenarios. If you just want to migrate with acceptable format preservation and effort, ODF might provide good enough migration support even for heavily formatted docs, although OpenXML will likely be better. On the other hand, for roundtripping, macro support or even excel formula support, it might be a pain. Also, average users may not have the skills or the time to correct transformation artefacts, so they’ll have to live with the results.

    Either way, there will be impacts, and the claim of "completely lossless transformation of billions of [ms office] documents" is plainly wrong, a.k.a as spinning. I still cannot see how correctly pointing this someone elses spinnning is spinning by itself. This line of argument sounds suspiciously like politician spek to me.

    As for compatibility problems between .doc and OpenXML – I think I’ve explained it more than once already, but let me summarize my point:

    MS controls the XML format and is therefore in a position to reach 100 % compatibility in theory. Mistakes can happen, but they can be avoided and/or corrected later.

    ODF is not designed for this kind of compatibility, therefore translator coders will experience problems that they cannot fix, no matter how careful and skillful they are.

    This is a very important distinction if you have to make a decision about which format to choose. And even more so if you are thinking about using ODF exclusively (and therefore banning OpenXML), as ODF supporters are often recommending. Microsoft would be nuts not to point out the problems that could arise from such a decision, but ODF supporters call these reactions aggressive, unfair and pejorative.

    I’ve heard what the ODF guys had to say about OpenXML before MS even started to point out the shortcomings of ODF, so this feels a little bit like election campagn propaganda to me: One party makes untrue/unfair statements, and as soon as the other party calls them on being unfair, they just accuse them of being unfair too for calling them unfair in the first place. In the end, nobody will know who started it anyway. Throw in some unconnected statements about past failings of MS, so you can establish yourself on a higher moral ground. Now, if the details are too complicated to follow, people will hopefully just believe you because MS cannot be trusted anyway, no matter what the facts in the current situation are.

    It might not be coincidence that Sun and IBM are focusing on politically led organizations with their exlcusive-ODF campaign, because chances are, nobody else who is not already in the anti-MS camp would care about all that political noise they are making.

  44. Oscar says:


    I was trying to understand the point you are making by excluding the "political", "propaganda", "higher moral ground", but I just got bored.

  45. Stefan Wenig says:

    That’s good, Oscar. Go play somewhere else.

  46. BrianJones says:

    I’ve been getting so much spam that it’s been really hard to keep up with some of the comments. It looks like I deleted a comment from Gary Edwards accidentally that pointed to that funny clip of Balmer jumping around. Here is the post Gary left:

    Gary Edwards has made a new post: re: Spin Spin Sugar.

    A raving lunatic?  Perhaps.  But not one without inspiration:


  47. Gary Edwards of the OpenDocument Foundation stopped by the other day to comment on my post " Spinning

Skip to main content