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!)