MS: "OpenDoc too slow!" IBM: "MS Open XML too heavy!"

MS: "OpenDoc too slow!" IBM: "MS Open XML too heavy!"

Summary: Have mud. Will sling.According to ZDNet UK's Ingrid Marson, Microsoft is saying that the OpenDocument format is too slow: "The use of OpenDocument documents is slower to the point of not really being satisfactory," Alan Yates, the general manager of Microsoft's information worker strategy, told ZDNet UK on Wednesday.

TOPICS: Open Source

Have mud. Will sling.

According to ZDNet UK's Ingrid Marson, Microsoft is saying that the OpenDocument format is too slow:

"The use of OpenDocument documents is slower to the point of not really being satisfactory," Alan Yates, the general manager of Microsoft's information worker strategy, told ZDNet UK on Wednesday. "The Open XML format is designed for performance. XML is fundamentally slower than binary formats, so we have made sure that customers won't notice a big difference in performance."

Meanwhile, in post headlined Specs should lose weight, not gain it, IBM's director of open standards and open source Bob Sutor says Microsoft's alternative to OpenDocument is too heavy:

There’s starting to be a real buzz if not shock about the latest draft of the so called ECMA “open XML” spec weighing in at a hefty 4081 pages. If you do take a look at it, be prepared to wait a while because the PDF is 24.4 Mb in size. Broadband required....These numbers alone should be enough to make the point that there will be very few perfect complete implementations, if any. It’s also a measurement of just how bloated with features any software that implements it would have to be. Bear in mind that I said “bloat” and not “wonderfully featureful.” Is this real evidence of why people are moving to more elegant “keep it simple” solutions? Maybe Microsoft needs this to cover everything they have ever thrown into their proprietary products. Maybe the rest of us don’t.....For comparison, the OpenDocument Format standard from OASIS is 706 pages (3Mb PDF)....Now we have to be careful with numbers and not simply say that one or the other spec is simply better because it is bigger or smaller. That said, I think looking at the specs will show you that the ECMA spec is much, much bigger than ODF.

First, they argued about which one is more open.  Then, came which one is an international standard (soon, both will be).  Now, size matters. Speed too.  Any guesses where this he said/she said will go next?

Topic: Open Source

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
  • Compliance

    The real "rubber hits the road" issue is compliance testing. With both camps positioning themselves to become Governmental purchasing requirements, they're going to eventually run into the issue of validation suites.

    A good example is [url=]the W3C's CSS Validator.[/url]

    One problem with a large specification is that validating against it almost always runs into a case of either "you can't fail" or "you can't pass" depending on how permissive the spec is.

    Pass the popcorn -- I'm watching this one from the sidelines.
    Yagotta B. Kidding
  • WOWE, imagine that, MS and IBM throwing rocks

    at each other. Yeah, that's never happened before.

    But not to worry, the posters will be along in a moment to cheer on their favorite team shortly and David will get the desired hits on his blog thing...
    • A plague on both their houses

      Sometime soon they will realise that this whole XML thing is waste of time and effort that was basically obsolete at birth.

      But not before they have both sold you a whole set of "solutions" to the problems that you only have because of XML and IBM and Microsoft's perverse enthusiasm for this archaic, cumbersome, inefficient and ill thought out monster.
  • MS Frames "Performance"


    You're sophisticated enough to note how Microsoft is framing the "Performance" question. They are hammering the message, 'our customers want performance.'

    Well, I venture to say that if they paused to ask any single one of their customers, what they want is to be able to open and read documents.

    The framing of the "Performance" issue is nuanced, specious messaging.
    • In today's Dan and David Show...

      We talk a little bit about this. What does it matter when I have some dual core 4Ghz system on my desktop. Is it matter of milliseconds? These debates are beginning to feel meaningless to me. At the end of the day, adoption of solutions is what will count and while the opendocument camp appears to have more compliant solutions lined up than the open xml camp, lack of an SDK so that snapping ODF compliance into just about anything is the one thing that will slow adoption.

      • No, it's a matter of minutes

        "Yates cited a study carried out by that compared 2.0 with the XML formats in Microsoft Office 2003."

        Yates is obviously referring to my research.
        This has the series of benchmarks
        This is where Sun confirms the numbers

        We're not talking about a few milliseconds, we're talking about milliseconds with MS Office compared to a minute with ODF using if the hardware is a new dual-core processor. Hardware should NEVER be a substitute for good programming. At this point it sounds like Sun blaming ODF and ODF blaming sun for the numbers. Customers don't really care who's fault it is, they just know that existing implementations of ODF sucks.
        • You're right, George

          Anyone who routinely uses 100 MB spreadsheets should use MSOffice, just as anyone who uses large text documents should use

          Every tool has its limitations.
          Yagotta B. Kidding
          • How so on large text documents?

            "just as anyone who uses large text documents should use"

            How so? If I was dealing with large text documents, I might be inclined to use a supper efficient text editor and neither MS Office nor OO.o fit this bill.

            BTW, large spreadsheet handling isn't the only problem with OO.o, it's way too bloated and way too immature.
          • Big text

            [i]How so? If I was dealing with large text documents, I might be inclined to use a supper efficient text editor and neither MS Office nor OO.o fit this bill.[/i]

            Try the same thing with a text doc that you did with a spreadsheet -- crank up a few hundred pages or so of random text as an MSWord document.

            It's rather well-known in writing circles that this is a good way to lose your thesis, novel, etc. I've run into it in standards work; it seems to be less of a problem if you run the document through something like OO.o to strip out the cruft but that's not guaranteed.

            As for text editors, try to do something like JESD-79 in one.

            Most of the accumulated knowledge about MSOffice file wierdnesses is like that -- it's not like there are debuggers or whatever.
            Yagotta B. Kidding
        • George, Don't Be Silly

          George. You're betraying your status as a card-carrying Microsoft shill.

          If you want to talk about quality of programming & design, you'll need to explain why the MSECMAXML specification document is 4,081 pages long and OpenDocument only about 700.
          • comparing apples and oranges

            I find your comparison of document spec. length and quality of code to be dubious. If you want to debate if Office software is bloated, that's one thing. I don't see the relationship to a document format though. Office supports a lot of features and underlying technology. The format was designed to accomodate that. ODF on the other hand was not. The committee that designed it designed the format to handle some features they thought would be a good baseline. They also left some aspects open for vendors to define. As I understand it one of these open ended areas was spreadsheet formulas. ODF provides no definition for them.

            I've read up a little bit on what ODF supports and doesn't support at this point, and after extrapolating and giving it some thought I figured that if MS were to put custom tags in for everything that Office supports, their ODF would probably end up looking as though it was some proprietary format MS had thought up. If you looked closely you might see the parts that are in the standard, but they'd be drowned out by the quantity of custom tags used to support all of Office's features. Just a guess.

            I think one thing Sutor said is true in that we probably won't be seeing small companies coming up with OpenXML-compatible products, at least until somebody provides an accessible API framework to handle it. Larger companies like IBM could handle it though.

            Demand plays a part in this too. If there isn't much demand for ODF-compliant products, it doesn't matter how short the spec. is, you're just not going to see that many of them. The standardization of ODF will at least be a boon to the Executive branch in MA and the Library of Congress, and whoever else is standardizing on it.
            Mark Miller
          • Correcting the record

            [i]The committee that designed it designed the format to handle some features they thought would be a good baseline.[/i]

            The Committee included representatives from all of the major document-conversion and content-management companies, including Boeing (which, little known, is a major enterprise consultant.) One of their requirements was that they be able to support all of MSOffice's feature set.

            The fact that they do it differently [1] doesn't mean that they don't do it -- it just means that they don't map syntactactically to Microsoft.

            [1] An example is the whole "border styles" issue. MS has a token for every border style they've ever used, leaving the application to interpret "97a2" as a particular graphic. ODF lets you just pop in a sample and do what you like. Same results, different syntax. One takes a lot more defining at spec time.
            Yagotta B. Kidding
        • Hardware as a substitute

          Unfortunately hardware has been considered a substitute for programming for the last several years. 4 years ago I had a conversation with a former co-worker about the speed tests MS had sponsored between J2EE and .Net. He told me that if a Java implementation was running slow, "you just add more hardware" until the speed is satisfactory. No biggie. Even when I would talk to people about .Net programming I'd often hear the phrase "memory is cheap", basically meaning you don't have to worry so much about how much memory your application uses. Understand we weren't talking about shrink-wrapped applications, but custom written business apps./systems.

          Personally I don't like the attitude. I like having a large amount of memory and disk space at my disposal, but I try not to be wasteful.
          Mark Miller
          • Mark you are a breath of fresh air

            THANK YOU! Someone has to say it!

            I buy more RAM and CPU for MY benefit to run faster, not for the programmers benefit program lazy so that my computer can run the same speed.
          • For a real thrill

            [i]Unfortunately hardware has been considered a substitute for programming for the last several years.[/i]

            Like at least 30.

            For some serious excitement, hunt down some apps from about 1986 written for MS-DOS 2.x or so on an 80286 CPU. I'd suggest Word 6; in many ways it was the best that Microsoft ever did.

            If you can ignore the grainy graphics (written for when a 640x480x16 display was bleeding edge) you'll be utterly shocked at how blazingly fast it is. Remember, it was written to be [b]usable[/b] on a machine with 1000 times less memory or CPU performance and a lot less than that in disk space.

            If that's not enough, track down an 8088 Flight Simulator. Cessna at Mach 17 doesn't do it justice.
            Yagotta B. Kidding
          • I have some memories of this

            I was not in the PC realm back then (I used Apple IIs and Ataris then), so I have no memory of Word 6 on a 286. Most people were running WordPerfect for DOS. And that was fast enough.

            [i]If that's not enough, track down an 8088 Flight Simulator. Cessna at Mach 17 doesn't do it justice.[/i]

            I do remember this only because computer stores used to run it. Flight Simulator was nice for showing the graphics capabilities of a machine, but not for showing its performance. I tried playing with it and crashed every time. :( Usually it was because the slow framerate always made me overreact. The framerate was pathetic, as it was on every machine it played on (Atari, Commodore 64, and Apple II as well). Flight Simulator didn't start running at a passable speed until the higher speed 286 and 386 machines came out. The early machines had a hard time handling 3D graphics, period. Probably the best 3D games that came out in the early days were from Lucasfilm Games: Ballblazer, Rescue on Fractalus, and another one I can't remember. They actually designed them to be playable on very slow hardware.
            Mark Miller
          • I should add...

            Back in the early days you refer to I was not out in the technology business. I was in school. But I know that the general attitude was not "memory is cheap", because everyone knew it was not. Many people had computers with 4K, 16K, or 32K of memory. That demanded that people code efficiently. There was no way around it. Memory was damned expensive.

            And when Flight Simulator was first released (by a company called SubLogic) there was no faster microcomputer hardware to run it on. The 4.77 Mhz PC was it. It was impossible to "add more hardware". And besides in the PC realm programs were limited to 640K RAM, at least until DOS extenders were invented. The most memory anyone had on a high end PC when IBM first came out with it was 128K. You were "da man!" if you had that much RAM. Nevermind if you never used all of it...
            Mark Miller
        • It's a matter of importance


          If that time is so crictical to you than do your editing in Excel and publish to ODF when you're done and want to allow anyone besides the MS conglomerate to be able to access and manipulate your data. Kind of like the final step of publishing to PDF that monster document done in Framemaker.
          Robert Crocker
  • Bob Sutor of IBM is a farce

    I posted a comment asking when IBM would open source DB2, Lotus Notes, WebSphere and guess what - my comments were rejected.

    If Bob Sutor is such an advocate of Open Source, Open Documents, shouldnt his web site also be open. What is he refusing to answer about a simple question of mine.

    IBM wants SUN to open source java. IBM put a lot of pressure on SUN to open source SUN's software assets. How about IBM open sourcing DB2, Lotus Notes, WebSphere before asking SUN to open source any of their software assets.
    • not to mention

      IBM talks about MS needing to support ODF in the name of being open.

      How about IBM being more open about their intentions. Looks like to gain market share with an inferior product they dont mind playing politics.

      Not to mention how come they dont answer questions asto why they wont open source DB2, Lotus Notes, WebSphere and Rational Case Tools and software.