Interoperability by Design

We’ve all heard the interoperability hype. Let’s see what is actually there.

First, we start by looking at the many ways in which documents are integrated into the Windows/Office platform. Any fluent user of this platform will use many of these capabilities on daily basis. These are basic features which have been around, in some cases, since Windows 3.0, maybe earlier.

Windows shell integration

Double-click on a document on the Desktop or in a folder and it loads into the appropriate application. Double-click on a Word document and it loads in Word.

Right-click in a folder and choose “New XXX” to create a new XXX document in the specified folder. So, “New…Microsoft Office Excel Worksheet” creates a new, blank Excel document.

Right-click on a document, choose Properties and on the Summary tab you can view metadata for that document.

Recently-edited documents appear in the “My Recent Documents” under the Start menu.

Documents referred to in web pages, via URL links will render in an inline Office session in the browser.

Documents are indexed by the Windows search engine.

Office integration

Ability to File/Open, File/Save and File/New a document via the familiar menu options.

Ability to set a file format as the default file format for the application.

Ability to use the familiar keyboard shortcuts, Control-O and Control-S to open and save documents.

Ability to forward a document to someone in an email and for them to be able to launch the a document by clicking on it when received via email.

Ability to password protect a document.

Ability to post a document to a web folder or to a SharePoint server

It must be noted that none of the above integration points are allowed by the ODF Add-in for Word, the much-touted translator for which Microsoft provides the, “Funding, Architectural & Technical Guidance and Project co-coordination”.

Instead what we get is a new menu option added to the Word 2007 Office menu:

Note that this is parallel to, but not included in the Open menu where the formats that Word natively understands are accessed. Although the option presented here says, “Open ODF”, it should more properly be called “Import ODF”, for reasons which will be clear shortly.

After selecting an ODF document to open, the following progress bar is given while the conversion takes place:

This is followed by a warning dialog listing elements which may have been lost in conversion:

No option is given for disabling the above message from displaying. It should be noted that when converting from a legacy binary document to OOXML, Word gives a similar conversion warning dialog, but their version can be disabled by checking a “Do not ask me again” dialog.

Once loaded, the user will find that their document is no longer an ODF document. It has been automatically converted to a read-only OOXML DOCX file as the title bar reveals:

So any future operations the user performs on the document, such as mailing, saving, posting to a web server, etc., will be in OOXML format. The only way to get back to an ODF format file is to manually and explicitly go back to the Office menu, go to the ODF submenu and choose to save it to ODF format. At that point you will be presented a default name based on the DOCX temp file name, not the original name. In this case, it suggested “sampler_tmp1.odt”.

The “Save as ODF…” dialog will default to the directory last used to save a file, not necessarily the same as where your document was loaded from. So to save you must first navigate to your original document, select it and choose “yes” when warned about overwriting an existing document, and then the document is converted back into ODF format.

If you do further work on the document in Word, in that same session, and then want to save again, you must avoid the natural tendency to do a Control-S or to save the document when prompted when existing Word. These methods all will lead to a Save As dialog, suggesting an OOXML format, which will prompt you to rename the document since it is read-only. But it will not offer you the choice of saving to ODF format. The only way to ensure that you are saving to ODF format is to use the above steps, going back to the ODF menu, etc.

You cannot create a new ODF document from scratch in Word. If you try to create a new document and save it to ODF format, you will get an error message, telling you that you must first save the document. You must save the document before you can save it? Yes, you must first save it to a temp file in a natively-supported format like DOC before you can save it as ODF.

The difficulties are complicated when you have documents accessed by other means than the Word menus. Imagine that you receive an ODF document in an email which you want to edit and return to the sender. The following steps would be required:

Manually detach and save your hard drive the ODF document from the email, since you will not be able to launch it directly into Word from your email client. Remember where you detached the document.

Manually launch Word, since you will not to get Word to launch by clicking on the ODF document you just detached.

From the ODF menu, choose to open the ODF document. Navigate to where you detached the emailed document and select it. Around 30 seconds later the document will be automatically converted to an read-only temporary OOXML document.

Make your editing changes.

Export the document back to ODF format using the ODF menu, either writing over the original file you extracted from the email, or to a new temporary file. Remember where you exported the ODF document to.

Go back to your email application and attach the ODF document.

If this had been an OOXML document (or any other format that Microsoft really supports, like RTF) it would have been much simpler:

Double click on the attachment in your email to automatically launch in Word

Make your editing changes

Use the Send/Email menu option in Word to send the email

As you can see the ODF support provided by the Add-in is very unfriendly.

Compare this to the OOXML support Microsoft added for older versions of Word via their Compatibility Pack. The OOXML support is tightly integrated with the UI, in a way users would find familiar and easy to use. But the ODF support is very shallowly integrated, amounting to little more than a menu item patched in.

One wonders if Microsoft’s intent was really to annoy users? That would best explain the available evidence. It is simply not credible that anyone at Microsoft believes that they are listening to customers or providing interoperability with a feature that defies real-world use. What customers did they talk to that said that this Add-in was even remotely adequate?

Since Microsoft is the one providing the, “Funding, Architectural & Technical Guidance and Project co-coordination” one would think that they would contribute more in the area where they are uniquely qualified to assist, the full and native integration of the ODF support into Office.

Wrt to Windows integration, there’s two more integration points :– Document thumbnail (picture stored inside the file which allows to speed up the view building in Windows explorer). Provides significant perceived performance compared to all other documents.– Microsoft has used Windows Update to distribute worldwide a shell extension making sure that, when someone with no Office 2007 installed is sent an Office 2007 file and opens it, (s)he gets a user-friendly dialog that includes an explanation and a link to the download site. Instead of the typical useless file association error message one would normally get (i.e. when opening a ODS spreadsheet with no OpenOffice installed). (Anecdotically, see the recent post on Zdnet from Jeremy Alison on the subject, as well as the response to his post by a MS employee…on Zdnet as well).

Of course, the trial version of Orifice 2007 ships with every new PC, making sure being sent an Office 2007 is the best possible experience. It’s good when a single vendor defines the meaning of DEFAULT apparently…

@Anonymous, If you look you’ll see that the ODF Add-in is at version 1.0, and Microsoft is constantly talking about it as their interoperability answer for ODF. So it is reasonable to look at the add-in provided and ask whether it can be recommended.

All software is “work in progress”, open source or proprietary, but all programs must be judged by the state they are in now.

Remember that Microsoft is one with the expertise in Office/Windows integration, not me, and not Novell. So if the Add-in is found to be lacking in their particular area of competency, then this is something worth knowing.

It seems that when it came time to integrate their OOXML support in older versions of Office, that they were able to do this completely and rapidly. Since Microsoft has a record of making inferior API’s available to 3rd parties while leaving more efficient and more capable interfaces for their own private use, this is also worth noting.

Of course, separate converters are needed for text documents, spreadsheet documents and presentation documents, which multiplies by 3 the number of needed converters (I already count 18 converters).

Now imagine that OOXML 2.0, ODF 2.0 and UOF 2.0 are available. You then need to maintain bi-directional converters between 6 different formats, for each of text, spreadsheet and presentation documents (I now count 90 converters to be maintained by each Office suite).

This will be a “paradise” for users, with so many files formats and converters to choose from !

“Since Microsoft has a record of making inferior API’s available to 3rd parties while leaving more efficient and more capable interfaces for their own private use, this is also worth noting. “

Rob, the hidden API issue has long been a red herring of the anti-Microsoft brigade. The thing, though, is that since at least 2001 the APIs used by all Microsoft software in Windows have to be fully documented according to the Consent Decree. There may have been some crufty and insufficiently documented pieces before, but for a long time now it’s simply illegal for that to be the case.

The hidden API card is stupid for another reason: you can always inspect a Windows PE binary for all of its dependencies and see which functions are being called. Microsoft ships a full set of debug symbols for all of its public entrypoints, so you could certainly look at what Office is doing and complain to the DOJ if Microsoft is doing something underhanded. The real answer is, however, that a lot of work went into producing Office and making it run well on Windows (which basically involved reimplementing all of the standard controls in an owner-drawn, windowless form. This takes a huge and reasonably talented dev team. You certainly can’t advocate banning companies from hiring a lot of programmers and putting them to work just because it becomes impossible to compete head on with them, can you?

It is not in Microsoft’s direct interest to make ODF a easy, native solution for Office, that much is clear. But OASIS would probably like to see ODF support in Office 2007, if you are interested in getting more support in your format (rather than merely using your format as a bludgeon to dethrone MSOffice). Windows provides many extensibility points and so does Office. You could talk to the Lotus SmartSuite folks to see how they integrate with the Windows Shell or have them ask Microsoft employees how that stuff works (they are, after all, ISVs for Windows and Office just like anyone else).

If you want your format/suite to defeat Word, you first have to coopt either the program itself to save to ODF or the OOXML format to open in your Word replacement. Both of these things have to be done (and they don’t have to be absolutely perfect… just “good enough”). Why not start competing and integrating, rather than constantly whining about how Microsoft is keeping your movement down? -nks

Nice try. However, the DOJ Consent Degree covered Microsoft middleware API’s, not MS Office. Not much help in this situation, is it?

Also, I note that EULA for Office has the explicit prohibition against reverse engineering. So you won’t be playing around with trying to find out the private API’s that way, will you?

But in any case you miss the point. Microsoft is the one going around claiming that their ODF Add-in shows their commitment to interoperability. I’m merely pointing out that the Add-in they have produced is not credible, is not acceptable, is not functional for the purpose that they are touting it. Whether I or any other open source contributor can fix it is not the issue. I’m not claiming that the Add-in is proof of my commitment to interoperability. Microsoft is.

If Micrsoft’s commitment to interoperability relies on other people to reverse engineer their own API’s or to raise complaints to the DOJ to get info, then this is not much of a commitment to interoperability, is it?

Try this process: 1. double click on an .odt file in the file manager (Vista or XP with no OOo installed) 2. You get the ‘Windows cannot open this file:’ dialog. Click OK to select ‘Use the Web service to find the appropriate program’ 3. This launches a browser pointing to the ‘Windows File Association’ site, which responds:

File Type: UnknownDescription: Windows does not recognize this file type.

There is obviously no real interest at MS for any real support of ODF.

And also, not to be picky, but you missed a save in your email example. Even if you start with ODF and want to save to ODF, if changes are made, you have to save as a MS native format before you can ‘save as ODF’

I just came over from Groklaw since the newspick there said you had screen shots. I see the screen shots of the dialog boxes, but I was interested in seeing whether the ODF converter mangled the document as it was importing it to MS Word. That is, showing how the document looked in OOo and how it looked in MS Word. Would you be so kind as to add a P.S. either showing how they looked or a general description of the same? Thanks.

The allegation of the hidden API issue is that Office makes use of secret functions in Windows to gain an edge over other applications that use the ‘regular’ windows functions.But they don’t. The Office team has developed enhanced versions of some Windows functions, however they are a part of Office, and not a part of Windows. Many non-Microsoft applications do the same. The difference is that the Office functions have been written seamlessly enough to fool people into thinking they must be part of the OS. (Of course having access to the source code of the original Windows functions helps a bit, but noone is suggesting they shouldn’t be allowed to reuse code in multiple applications.) The point is that any enhanced Office functions are are part of Office, written specifically for Office, distributed with Office, and seperate from Windows.

Back to the real point. Microsoft has made it clear many times over that they are not interested in anything that could compromise their Office monopoly, and any moves they make towards interoperability are little more than lip service to Government departments. They have created an add-on which is suitable only for occasional use, and not as part of a regular workflow. Lets hope the Governments don’t buy into it.

I know the presentation leaves much to be desired, but the content presented at the link below will demonstrate that Microsoft either 1) rushed o2k7 out the door before they “finished” their compatibility tools or 2) are making it an annoyance to stay on their own 97-2003 formats to force people to migrate to Office 2007 faster and thus adopt their new file formats faster: