The first fruit of the recently announced Novell/Microsoft interoperability agreement arrived on Dec. 4, with Novell's announcement that its version of the OpenOffice productivity suite will now support the Microsoft Office Open XML format. The release candidate of Novell's modified version of OpenOffice.org 2.02 is now available for Windows for free download by registered Novell users.

I can embed a COM component in an ODF document just as easily as I can embed one into an OOXML document, in both cases potentially tying that document to Windows if, for whatever reason, other platforms don't have the facillities to run that component.

Nothing in ODF excludes the creation of documents containing proprietary elements, just as nothing in OOXML mandates using proprietary elements.

The argument of the one-way street is disingenuous because it is mainly a matter of other office suites not offering feature parity and instead depending on the 5% or 10% theory. The people pushing ODF keep trying to turn Microsoft's feature advantage into a disadvantage. For the many people actually using Office in business processes and as a development platform, and even regular end users that have a need for certain features not available elsewhere, this criticism falls on deaf ears.

//in both cases potentially tying that document to Windows if, for whatever reason, other platforms don't have the facillities to run that component. //

Misses the point entirely. Continues with "disingenious".

For ODF, all platforms are "permitted" to implement all of the required "facillities to run that component". It is entirely open, free to implement as there are no encumberances, either within the ODF spec itself or within any of the dependent facilities. Anyone is permitted to implement SVG, PNG or OGG, these are all open and unencumbered.

That is not the case at all for Open XML via its attendant dependencies.

If a Windows platform does not have a given facility (such as, for example, the ability to render SVG), then that is because Microsoft do not want to support open standards. It is not because Microsoft are not permitted to support SVG on their Windows platform.

If, OTOH, a Linux or OSX platform is missing a given facility (such as, for example, the ability to use ActiveX controls or to run Visual basic macros), it is because these facilities are Microsoft proprietary, and Microsoft do not allow anyone else to implement them, and they are restricted to Microsoft platforms only.

Therefore, via "inheritance" of the dependencies, Open XML is not open at all, whereas ODF in contrast is "open all the way down".

Open XML is indeed a "one way street", without any doubt at all. My very strong recommendation remains, DO NOT SAVE YOUR DOCUMENTS IN OPEN XML FORMAT.

Why do you continue to ignore that I can include an AX control in ODF and achieve the same situation you continue to promote as unavoidable in OOXML. There is no difference. I include a proprietary component in an open format, thus potentially blocking full fidelity rendering on another platform, making ODF just as much of a one-way street.

Thanks for this very illuminating series of posts and links. It makes the facts of the situation very clear, and the strategy behind Open XML equally clear. It reminds one a bit of the saga of Office on the Mac. You've always had Office for the Mac. You can swap Word and Excel documents with your co-workers. At least, you've had quite a lot of Office.

What you cannot get is just enough to stop the platform being a viable business competitor to Windows. But evidently not enough to stop people claiming that Office is multiplatform, which in the important sense, it is not.

The strategy is the same. Its disappointing that the standards bodies didn't grasp the point, which is a very clear and simple one.

You don't have to be any kind of zealot to be attached to the ability to move your documents from one vendor's application to another. I've had three totally convincing experiences. One was with two versions of Access, another with multiple versions of Word, a third with a proprietary database package which shall be nameless, which was implemented in a way that put any sort of usable data exports beyond the ability of anyone who couldn't write code. In each case the suggested solution was upgrade. In two cases you couldn't just upgrade the package, but were trapped into a cascade of upgrades.

There is really no excuse for claiming that documents saved in Open XML are being saved in any sort of open format. It is just false.

Now, whether Novell or OpenOffice should support this new closed standard? Probably. Just don't claim its open, its not.