OOXML is too hard to implement … even for Microsoft

Print Friendly

Over on CNet, Ina Fried has an article “Microsoft again delays Mac XML converters” and says, in part:

The software maker said that it plans on March 11 to deliver the first update to Office 2008 for Mac, delivering several key fixes. At the same time though, it has again pushed out the release of converters needed by users of Office 2004 to read documents saved in the new XML file formats used by Office 2007 for Windows.

“The team is mobilized to get Office 2008 updates out as soon as possible,” Microsoft said in a blog posting. “As a result we are pushing back the release of the final Open XML File Format Converter Update to Office 2004 for Mac.”

You know, they can cover this up with all the usual sorts of excuses that people give when products are delayed, but the fact is that OOXML support in Microsoft’s own product, Office 2004 for the Macintosh, will have taken 18 months from the publication of the specification to delivery in the product, if it really does happen.

So various things could be true here:

  • Microsoft is not putting proper resources behind maintenance of Office 2004 for the Macintosh.
  • The software engineers working on Office 2004 for the Macintosh aren’t very good.
  • OOXML at 6000+ pages is just too hard a specification for expert software engineers working closely with the people who designed OOXML to be implemented easily and completely.

I don’t believe that Microsoft is starving Office 2004 for the Macintosh for resources, given the number of users there and Microsoft’s relationship with Apple.

Microsoft has great software engineers, as do many companies, so I don’t believe the second point.

I think the third point is exactly right. Providing full interoperability among products that need to support OOXML is evidently extremely onerous, and we haven’t even seen the successful end of it for one of Microsoft’s own products. What hope is there for others?

My answer: very little.


4 Comments

  1. I was wondering if it is also a problem that the Office for Macintosh code base was forked from the Office for Windows some time ago. They may have put some stumbling blocks in their own way with regard to down-level retrofits. On February 11, I heard Bill Gates talk about the reasons that the two office systems have deviated so much, not in the OOXML context though, but I didn’t take notes about it. (I would have thought that there’s be more common code at the non-UI-related level, but I wouldn’t be that surprised to find out that the deviations are enough to slow things down, especially in testing.)

    I also wonder whether and how the promised Office 2007 updates to allow transparent hosting of third-party formats will be prioritized and delivered in Office for Macintosh.

  2. Another option;
    MS has already decided that for upcoming versions of Office (all platforms) they will just invent a new fileformat anyway so the Mac version is not worth it.

  3. Bob, you’re right and Thomas’ option rings true, too, especially if we follow the “Fixed|Flow
    Document” ideas in the MS Office SDK

  4. Stephane Rodriguez

    There are many reasons why this stuff is late.

    Limited Mac BU resources. Courtesy Bill Gates feeling the threat of Mac OSX. Related : VBA cut off of Mac Office, to make it a second-class citizen.

    A lot of new code, especially migration code. And a new charting renderer.

    ANti-cross platform code. Native XML (libxml2) couldn’t be used so Mac BU had to port MSXML (the Windows XML parser) over, with all consequences you might infer from that for Mac developers using libxml2 in their applications. This information was publicly made on Mac BU blogs (but not with a lot of echo in Windows Office land…)

Comments are closed