Fire and Motion: What OpenXML Means to IBM and Lotus Notes

Hi Jonathan

Please let me know how you come to the conclusion that ODF is a proprietary format. Who owns it? How is it dressed up to be an open standard? Pls let me know. Please give as much details as you can to convince me that it is not OPEN.

Did you know Openoffice released odftoolkit.openoffice.org/ which you can use to make your own applications?

That is a fair question, so I'll try to explain how I reached that conclusion.

First the term proprietary. By that I mean to a product, not a company. This is key because it doesn't matter who happens to "own" the format, what matters is whether or not developers can work with it.

Consider the reasons people say OpenXML is proprietary:

1. Historically it is an XML version of the MS Office format.
2. As we reported earlier, there are creditable accusations that OpenXML interoperability is impaired because Word uses flags that are not fully described in the spec.
3. Though the spec is now in the hands of ECMA, it is still heavily influenced by MS Office.

Now consider ODF:

1. Historically it is an XML version of the StarOffice/OpenOffice format. In fact, it was at one time called OpenOffice XML.
2. As we reported earlier, there are creditable accusations that ODF interoperability is impaired because OpenOffice uses proprietary configuration values that are not in the spec.
3. Though the spec is now in the hands of ISO, it is still heavily influenced by OpenOffice.

To your average developer, what's the difference?

As a journalist, my job is to try to cut through the marketing and rhetoric and give you a fair report. And my report currently stands as this, "The whole ODF/OpenXML controversy is just a ploy by MS to retain its market share and IBM to take it away."

Look at the other players. WordPerfect didn't hesitate to promise both ODF and OpenXML support. Novell is adding OpenXML support to OpenOffice, so users of it are going to be taken care of. Technologically it is no more interesting than JPEG vs GIF; it is only when you follow the money that it becomes important.

As an average developer, I see a difference - there is (so far) only one conforming implementation of Office Open XML which means I have to go to a single vendor. With ODF there are several implementations - some of which may diverge slightly from the spec, but at least I can see the issues and have a choice. In fact, it may be that the latest version of Office diverts from the Office Open XML spec, but as it's a single, closed implementation I cannot judge that for myself.

BTW, I'm confused by your point that supporting Office Open XML would require a major rewrite of Notes, while at the same time you mention that WordPerfect and Novell are able to add it almost overnight (or at least promise support without hesitation!). If adding support for Open XML requires a word processing team to 'start over' then it can't be a good spec.

Finally, if ODF was lacking in certain areas then why didn't Microsoft help bridge the gap?

As a developer myself, I would prefer that there be only one word processing program. That would really reduce the amount of compatibility testing for my own code. But joking aside, I see your point.

BTW, I'm confused by your point that supporting Office Open XML would require a major rewrite of Notes, while at the same time you mention that WordPerfect and Novell are able to add it almost overnight (or at least promise support without hesitation!).

Supporting both ODF and OOXML places Corel in a unique format-neutral position, independent of Microsoft, Adobe and other vendors' efforts to propagate their respective standards. This format-neutral approach allows Corel to focus directly on addressing the needs of customers, whose adoption choices will determine which formats will become most relevant. Corel is the only vendor to take such an approach.

ODF was lacking in certain areas then why didn't Microsoft help bridge the gap?

Then Microsoft went and changed to format. It is not a minor change either; it will require a major rewrite of Notes.

Hi Jonathan,

seriously, I think the potential incompatibilities due to a few flags in either ODF or OpenXML are highly exaggerated. OpenOffice places a few minor hints in the ODF container, OpenXML has a few vaguely defined flags for backwards compatibility. I don't think this is really going to matter any time soon, because there are so many other obstacles to full interoperability.
Sure, ODF is easier than OpenXML, so full compliance should be easier. But at a time when even spreadsheet formulas are not defined in the ISO standard, how long to you think it will take before you can take an ODF document from one app and print it congurently from another? So who cares about a few minor flags anyway?
Same thing with OpenXML. They have deeper specs, but full compatibility its probably still a long way to go for any competitor, including WordPerfect. There's just so much to implement. So how much of a problem are flags that give hints for some legacy word-2000-and-older documents?
Just FUD, either way.

Besides that, I agree. ODF is heavily influenced by OpenOffice too. It's just a more logical choice for other Office apps, for two reasons:
- lean and mean standard, with less backwards-compatibility and features to care about, therefore easier to implement
- MS is the one competitor every office app fights (including OSS!). so why prefer their standard?
Some disliking of MS may play a role too, but that's probably not as important in the decision process as internet forums suggest.

However, in the end this will all be irrelevant. Any office app that wants to be taken seriously will have to support OpenXML (and not just 10 features of it), or customers with existing documents will ignore them. That's good for MS, and it's easy to see why IBM would rather have it the other way round.

I fully agree, Kit. They could have a seperate team do the parsing and writing and just add a new filter. The core team would not have to be interrupted.

The logical model of OpenXML is the same as in the binary formats. Also, the XML stuff has been around for years in the form of SpreadsheetML and WordprocessingML. If IBM wants that fast, they will find a way. They just chose to play it out another way.

"OpenOffice isn't a commercial product. If they delay a release, no one gets hurt in the pocketbook."

You really think Novell and Sun have no financial stakes in OpenOffice? I don't believe you are one of the persons who think that large OSS projects like Linux or OpenOffice are implemented by unpaid hobbyists.

Novell just chose to do it in the generic way MS started with: Build a converter that directly converts between ODF and OpenXML. That should be much harder than adding and OpenXML filter to an app that already supports Microsofts binary documents. Because for direct conversions you'd have to deal with semantic differences, a problem that is already solved when building on a finished binary import.

"ODF was lacking in certain areas then why didn't Microsoft help bridge the gap?"

As you pointed out, ODF is built on OpenOffice's format. Also, MS had already started to build their own, huge format. Why would anyone expect MS to do this? They'd have to find a way to get their stuff into a (then) minor competitor's format, argue about every change in the OASIS group, just to finally end up with a larger percentage of MS Office features in ODF, but probably not all of them.
Also, the result would be that ODF would pretty much look like OpenXML looks now. It's huge and bloated because it needs to be, and I have a hard time imagining ODF proponents agree that ODF should become this.

Really, these arguments make no sense if you think them through. If we want a lean and mean format that is not burdened with backwards compatibility and every single feature that MS office has, it should look like ODF does today. If we want full fidelity with existing docs, it probably has to look like OpenXML. Two goals, two ways. It's just not as easy as in, say, GIF vs. PNG, where one format is clearly better than the other.