a 'mooh' point

clearly an IBM drone

Microsoft Office 2007 - now with ODF-support

On October 22nd a long awaited email popped into my mailbox  - news of the release of first beta of Microsoft Office 2007 SP2. The reason for me longing to get my hands on this piece of software (and I have, in vain, tried to squize each and every single Microsoft employee I could to get it earlier) was not that it is a Service Pace for my current office application. Nor is it that I should now expect a more stable software package, because I am not troubled by instability in my everyday work with Microsoft Office.

My interest is caused by the fact that Microsoft Office 2007 SP2 includes support for ODF 1.1, and to be frank, it is not really because Microsoft has now chosen to support ODF natively in Microsoft Office - I am sure most would agree with me that they should have supported ODF a loooong time ago.

No, what will be interesting to see will be what it will mean for interoperability via ODF.

It's the standards, stupid

It has long been a public secret that you were walking in egg-shells when exchanging ODF-documents between ODF-supporting applications that are not somehow based/cloned from OpenOffice. Of course it is possible to exchange "BUI-documents" (yes, it is a acronym I have invented for this. It means Bold, Underline and Italics and represents rather simple documents without too much fancy pancy stuff in it.) but the best experience is when using OO spin-offs.

This makes perfect sense. When using the same program, you will get the least amount of problems. This is in essense the text-book/Page1 elevator pitch for Microsoft Office sales people

And this is exactly why ODF-support in Microsoft Office 2007 is interesting - it is the first major productivity application not based on OpenOffice that promises native ODF-support.

Now some people seem to think that as long as you use an open standard like ODF, PDF or OOXML, "interoperability" is somehow included. It is as if they are trying to apply some sort of Kant'ish "Das ding an sich"-thinking when they argue that achieved interoperability is somehow an intrinsic, guaranteed feature of an open standard. The funny thing is that every time I hear these arguments I always try (or fail, rather) to find a nice way of saying that they have understood squat of the problem and that they should try to work seriously with the subject at hand before speaking so bluntly about it.

The truth is of course somewhat different and this is why I genuinely applaud the work done with the OIIC in OASIS. The truth is that an open standard enables or facilitates good interoperability and that this potential is bigger for an open standard than for a closed standard. It is clear that both ODF and OOXML provide for better interoperability than the proprietary binary DOC-formats, but reversely the binary DOC-formats are also proof that fairly good interoperability is also possible when using non-open document formats. The world is not - once again - black/white, because it is clear that an open standard is not a requirement for interoperability - but it certainly helps a lot.

My point here is

Interoperability is not created by the standards. It is created in the applications based on the standard

All applications have bugs/quirks

This is the reason this is not about the standards - rather, it's about the applications. We are now in the situation that we have two big players supporting ODF (to a varying degree). But they will propably do it in different ways. We are now in a situation where we no longer have the luxury of the major ODF-producing/consuming applications being built on the same engine. My expectation is therefore that we will experience interoperability-problems with the ODF-applications, because Microsoft Office will likely do some things differently than the OpenOffice-clones (but comply to the ODF-spec at the same time).

This is why I asked Microsoft these two questions when I attented the first DII workshop in late July 2008 (they recently held another one but I did not attend).

1. How have you handled the possibility of using application specific settings in ODF?

As you know ODF has (and now also OOXML after BRM #¤"¤%¤#¤#&"#¤#"¤#¤%, thank you very much!) the so-called "config-item-set"-elements, which are used by the current ODF-implementations to store application specific behaviour. The problem with these elements and attributes is that they are not specified in the ODF spec, so there is really no obvious way to figure out what to do with the binary printer-blob that Lotus Symphony stores in ODF-documents produced by it. The short reply from Microsoft was: "We don't use it" and if you open the settings.xml-file in the ODF-package, it is empty. This is all fine and dandy - only problem is that you risk loosing information when exchanging documents.

2. How have you handled known bugs, features in other, major ODF-applications?

All applications have bugs - including ODF-supporting applications, so my question was perfectly legitimate. Again the answer was: "We don't handle it". With this answer Microsoft gets in line with alle the other application manufacturers that don't handle their competitor's bugs. There is e.g. a "bug" in KSpread's implementation of formulas (specifically the LOG-method). This is not handled by OpenOffice.org - even though it is fairly well known.The consequence is that strange things might happen when exchanging spreadsheets between KSpread and OOo Calc.

It didn't really matter before, 'cause not that many people use KSpread - but this picture is about to change with ODF-support in Microsoft Office 2007.

The bigger picture

I you will allow me to use one of my favorite, stupid expressions, then let's for a moment "step into the helicopter to see the bigger picture".

Because I believe that Microsoft's implementation of ODF will mean interoperability-problems using ODF-files in the short term. But I also think that it will mean better ODF-support on a broad scale - in the long run.

I have previously dealt with the MathML-support of OpenOffice.org which is slightly buggy. The ODF-spec says this about mathematical content:

Mathematical content is represented by MathML 2.0

And that's it.

As you might remember, the problems with OOo's MathML-support are due to the fact that OpenOffice.org requires a DOCTYPE-declaration in the MathML-object to display it. Also it seems that OOo will only display a certain kind of MathML. I have documented this in a previous post, but the short story here is that a simple mathematical equation in an ODF-document created using Microsoft Office 2007 SP2 will not display in OOo 3.0 nor Lotus Symphony 1.0 The ODF-file is perfectly valid and so is the MathML-fragment (tested using jing and the RelaxNG-schemas for ODF 1.1 and MathML as well as the MathML-tool from W3C, Amaya).

This example serves to illustrate my point: Microsoft's implementation of ODF will mean better support for ODF in the long run, because it forces existing problems in the applications to surface - and they can then be fixed.

And a small note for the trigger-happy ones: This is not due to the fact that Microsoft has implemented ODF - merely it is due to the fact that we will now have a new, major implementation of ODF to exchange documents with.

The problems described above have propably existed for years but no-one have noticed since most people use some kind of OpenOffice-clone for creation and display of ODF-documents. Now, on the other hand, errors in the applications (including in Microsoft Office) will be very obvious and the pressure to fix them will be much bigger. I also predict that Microsoft will have to speed up the release cycle of updates to their productivity-applications supporting ODF - at least when it comes to hotfixes of known problems. I don't think anyone will settle for bi-annual service packs for fixing trivial errors with big impact on productivity and interoperability.

Only remaining question now is: when will SP2 make it into Microsoft Office 2007? When it snows in Seattle?

(btw, I watched Grey's Anatomy yesterday, and according to them, it does snow in Seattle from time to time!)

Comments (7) -

Great food for thought, Jesper.

And yes, it does snow in Seattle: farm4.static.flickr.com/.../...10_f65d8e58d7_o.jpg

Well, you are behind on OIIC.  The Google page was not part of the official start-up effort.  The OASIS Interoperability and Conformance (OIC) TC is now up and running: www.oasis-open.org/.../tc_home.php?wg_abbrev=oic

It would be good to look there for the latest charter, membership, and the start of discussions.  

The October Document Interoperability Initiative (DII) workshop in Redmond was pretty interesting.  I am still working at getting my head around it.

Rick Jelliffe

Good points.

But I think "the only problem is that you risk loosing information when exchanging documents" goes to far. But sugar such as printer drivers is not "information" of the document, it information for your printer.

The receiver probably has a different printer than the sender. So that information only is probably only of use when the same user re-opens the document, presumably in the same application.

Cry no tears for blobs of sugar that die far from home.


I followed the mail list discussions when the charter was prepared but quickly started to suffer from information overload.


Thanks for the links to the TC website.


But sugar such as printer drivers is not "information" of the document, it information for your printer.
The example I gave was just to illustrate the situation. As you know, other OO-clones use the config-item-sets extensively to store information that are indeed relevant to the layout of the document.

The Lotus Symphony example is also funny, because I remember IBM complaining, amongst others, that the possibility to store application specific printer settings in a specific place in OOXML (I think it was the DEVMODE-controversy) had no place in an open standard. And then they do exactly the same when generating ODF-documents - only in an IBM Lotus Symphony specific place not specified by ODF.

Sounds pretty reasonable at last... However, I object on one aspect:
'It is clear that both ODF and OOXML provide for better interoperability than the proprietary binary DOC-formats,'

The old binary formats have a further role to play. Ironically they provide for pretty good interoperability although that it against the teachings of the xml church. Basically because implementations of various vendors are mature. I have many non-it-savy friends who complain bitterly about docx interoperability issues. That is of course a user perspective and would apply equally to odf files.

Kspread is indeed insignificant although I have a high appreciation for its developers given the ressources and capacity available. I also like the interface innovation of the next KOffice version. Still some time to maturate and not ready for most users.

Who knows, maybe the desktop as such will soon be insignificant as an application place as they move to the cloud. At least that is what the recent industry announcements seem to suggest. Or a Neandertal man trend? The near future will tell.

Hi Andre,

However, I object on one aspect:
'It is clear that both ODF and OOXML provide for better interoperability than the proprietary binary DOC-formats,

I think the point you missed was that I was talking about whether open standards by themselves lay the foundation for better interoperability than closed standards - I am sure that we can all agree on that.

It is also clear that we today get the best interoperability using a closed standard, DOC-files. But as you say, this has nothing to do with the DOC-format itself - it has to do with market maturity and that competitors to Microsoft Office had been working with it for more than 10 years.

Comments are closed