My topic tonight is a set of RFI responses that surely must be an oxymoronic first: they make fascinating reading(fascinating?  RFI responses?).  Moreover, they offer the opportunity to go on something of an Easter egg hunt for anyone that wants to pick and prowl through them looking for this surprising bit of information or that, or who wants to weigh what is unsaid (and guess why) as much as to assess what has been claimed, and whether the respondent can actually deliver.  Oh - and there's the occasional polemic thrown in as well.

What's all this about? Well, as I reported in early May, the Massachusetts Information Technology Division (ITD) posted a "Request for Information" (RFI), soliciting information on plugins to convert documents created in ODF compliant formats into Office documents. The goal was to find the kind of conversion tools that could ease the ITD's transition of its more than 50,000 desktops from a primarily Microsoft Office-based environment to one that would rely only on ODF-compliant software.  Absent such plugins, it would not only be necessary to convert all of those desktops simultaneously, which would be a much larger and more expensive endeavor than doing a more orderly phase-in, but the entire switch-over would need to await adequate accessibility features for the ODF suite chosen for deployment.  But with such tools, normal desktop upgrades could be switched over to new desktops preloaded with ODF software, and training on all new programs could proceed in an orderly and efficient fashion.

Yesterday the ITD posted the, six from software vendors - and one from Microsoft.

The six plugin responses make for are an interesting read, and it would be very time consuming to thoroughly report on all of the interesting concepts, suggestions and hints that can be found in them, as well as to highlight the differing conclusions that each submitter offers (for example) on the degree and type of assistance that would be needed from Microsoft. If you're in to such things, you can have quite an Easter egg hunt browsing through what can be found here, how it is presented, and how various developers come out. 

For example, on the question, “Whether [ODF to Office] exchange[s] can be performed directly through the “File Open,” “File New,” and “File Save/Save As” menu options in Microsoft Office or their Microsoft Office 2007 equivalents, or whether a different translation mechanism would be required (please describe),” the ODF Foundation concludes:

Yes. Microsoft Office applications do provide a mechanism to natively mount an ODf exchange via the “File Open”, “File New” and “File Save/Save As” menu options. They provide for an implementation to be completely transparent and non disruptive up to the level of Microsoft Office resp. ODF-based business processes.

Sun, on the other hand, responds as follows:

To the best of our knowledge, the MS-provided option to integrate the converter software into the MS Office menu choices exists only for Word, and depends heavily on undocumented MS Office interfaces. Accessing the conversion software via these particular menu items may be possible, but we anticipate it would lead to a fragile implementation that could be disrupted by MS Office patches or other code changes.

For Excel and PowerPoint, integrating the converter software into the MS Office menu choices, would require reverse engineering of the operation of MS Office, and intercepting the calls to initiate the desired conversions. While this may be possible, we again expect it would lead to a fragile architecture that could be disrupted by MS patches or other code changes.

Our preferred approach is the utilization of additional menu items or toolbar command buttons, enabled with MS documented interfaces.

The type and degree of effort expended vary widely as well. For example, two of the responses are folksy, short emails that completely ignore the detailed questions in the RFI, offering their author’s own brief summaries instead.  Matthew Cruikshank, in New Zealand, began his as follows:  “There’s some conversion software I maintain called Docvert <http://docvert.org> which transforms MSWord or ODF files into any XML or HTML.”

The one from Phase-N Response’s Adam Kennedy was even more casual, reading in part:

Hi Tim [Vaverchak, the ITD Manager, Open Source]

I think we might have spoken about a month about the Office plugin we were working on.  Although the website might be a bit out of date now, we’ve had a design for a very easy solution to the plugin problem for quite a while….But we keep hitting snags on the whole “deployment” angle.  Apparently it’s beyond the capability of a mere mortal to get this server installed and running….

It’s almost laughable at this point, except that apparently not from your point of view….

The other responses are less ironic, but more detailed and directly responsive to the RFI.  One, from Tonic Systems, relates to a converter intended only to address PowerPoint slides, while XML ToolWorks, from Media Entities, of Waltham, MA, currently converts only Word documents (but could be rapidly extended, according to the developer).  The Media Entity product would cost $99 per plug in, and ME would want $125,000 in funding to complete its development.

Not surprisingly, the most detailed response, and the most complete solution (two, in fact) is presented in the Sun Microsystems submission, which reads in part as follows:

Sun proposes two solutions to address the need for support of the ODF format from within MS Office (MSO). Both solutions use the SO/OOo software as the conversion engine, and differ only in how that software is deployed. These approaches are described very briefly below, with additional details in section III, responding to each of questions in the RFI.

Solution a., best described as a standalone solution, employs a fully functional SO/OOo installation on the user’s machine. Access to the conversion capability in SO/OOo from MSO is via a menu item or toolbar selection which initiates the conversion activity.

The second solution, b., is similar except that the SO/OOo software is installed on a server, but is still available via MSO menu options as for solution a. This installation option would also enable a web services approach in which office files can be converted entirely independent of any application. Any web-based service or HTML interface could be configured to utilize the conversion service.

The Sun response also identifies a Website set up by a Sun partner, using the Sun converter software infrastrucutre to convert Microsoft binary files into pdf format. That Website is here.

The Sun response says that the converter would be available under the LGPL, and would work only in connection with a StarOffice or OpenOffice installation. It also states that pricing for the plugin and related support has not yet been determined.

Perhaps the most interesting aspect of the Sun response is this opinion that Sun offers in the course of answering the question “What kind of technical information would the respondent require from Microsoft in order to successfully develop an ODF translator plug-in that was very well integrated with Microsoft New, Open, Save, Save As functions?”

…Much improved fidelity and integration of ODF and MS binary formats could be achieved with public, documented and unencumbered specifications for this functionality. However, there will remain a number of Windows-only features of the MSO binary format that simply cannot be represented on non-Windows platforms.

While we have not performed a complete assessment of the MS XML reference schema submission to Ecma, there appear to be many such features embedded in the format. In other words, it appears that a fully compliant application implementing MS XMLRS can not be implemented on non-Windows platforms. We believe this is also the case for a variety of proposed MS Office 12 functionality, including encryption features, digital rights management, etc.

In other words, even though the MS XMLRS may be fully unencumbered through patent grants and a convenant not to sue, a number of the features and functions that the MS Office applications implement remain proprietary, private, and are not available for implementation by other developers.

The litmus test to apply is whether, even in theory, a competitor could develop an application that implements the entire set of features and functionality represented in the current MS binary format or MS XMLRS, in a platform independent manner and without infringing on MS intellectual property. We believe such an implementation is not possible, thus necessarily limiting the fidelity of MS binary to ODF conversion.

However, to answer the question…

Ah yes!  (Now what was that question?)  Sun is taking advantage of the opportunity here to say more than the ITD needs to know, and more of what Sun would like the market to conclude, presumably concluding that this set of RFI responses is likely to receive more than the usual amount of attention.  And perhaps fair is fair, given that Microsoft’s own response touts its submission of its OpenXML formats to Ecma – which is also not directly responsive to the question.

Then there is the ODF Foundation’s response, which somewhat surprisingly (to me, at least) begins awith the following Q&
A:

1. What is the present state of efforts to create ODF plug-ins or converters for Microsoft Office, whether undertaken by respondent or others through projects with which the respondent is familiar?

This information is available under the terms of a confidentiality agreement.

What does that “O” stand for again?  And why could no information on the status of development efforts be offered, given that Gary Edwards had instantly provided Pamela Jones at Groklaw with the followoing detailed status update when the RFI became public:

The OpenDocument Foundation has notified the Massachusetts ITD that we have completed testing on an ODF Plugin for all versions of MS Office dating back to MS Office 97….The testing has been extensive and thorough. As far as we can tell there isn’t a problem, even with Accessibility add ons, which as you know is a major concern for Massachusetts.

Seems to me the formal response could have been a bit more detailed, given how much was already in the public record.  As you scroll down the Foundation’s submission, many of the responses that follow either reiterate the requirement for a confidentiality agreement as a precondition for disclosure of further information, or are more gnomic than illuminating.  Hmmm.

Finally, of course, there is the Microsoft response

(submitted by Alan Yates), which is quite an intriguing read in its own right. Not surprisingly, the Microsoft response does not offer to supply a plugin, and therefore most of the responses are simply “N/A.” Those responses that do appear are general statements of already well known Microsoft policy and references and links to prior statements and mechanisms.  Tellingly, Microsoft does not answer the questions that it is most equipped to handle: those that ask what type of cooperation and information would be needed in order to create a useful plugin. Instead, Microsoft answers “See below” to these questions.   Unfortunately, all that’s below are generic statements such as this:

Microsoft has extensibility options for adding components to Microsoft Office that are well documented and supported. Here is a selection of openly available links to technical articles about various ways to add menu items and addons to Microsoft Office, with some samples, across versions, leading up to Office 2007:

In short, to my reading at least, there is nothing in the Microsoft response that the ITD would not have already known, or could have determined from a brief review of its Website.  At worst, a tease, and at best, a non-response that could be claimed to represent cooperation.

But rather than going on forever and spoiling the fun, take your own look through the various responses, and see what you think.

Perhaps there’s the seed of a new Da Vince Code to be found in this most unlikely of all places.

For further blog entries on ODF, click here

subscribe to the free Consortium Standards Bulletin
(and remember to Buy Your Books at Biff’s)