Download a printable version pdf format of    sun.pdf
Download Open Document format odt format of    sun.odt

Response for Sun Microsystems, Inc.

May 19, 2006

to ITD RFI - OpenDocument Format Plug-in for Microsoft Office Suite
Issued May 3, 2006

For programmatic questions, please contact:
Janice DePaulo
Sun Microsystems, Inc.
One Network Drive
Burlington, MA 01803
Janice.Depaulo@Sun.COM
Office 781-442-7347
 

For technical questions, please contact:
Douglas W.Johnson
Sun Microsystems, Inc.
One Network Drive
Burlington, MA 01803
Douglas.Johnson@sun.com
Office 781-442-0716
 

Sun Microsystems is pleased to provide our response to RFI 06-1 issued by the Information Technology Division. This document provides Sun's best current estimates for product functionality and availability, as requested by ITD. However, these remain estimates and are not contractual commitments to provide software, services or functionality on the stated time scales. We would be happy to provide additional information and further details on the efforts described here, at the direction of ITD.

I. Introduction

The office suite market has been characterized since its inception by closed, undocumented and proprietary formats, typically implemented in closed source, proprietary applications. The result is a high barrier to entry by potential competitors, as well as significant interoperability issues between different office applications and even subsequent versions of a single vendor's application.


 

Sun has made major investments in office suite technology as reflected in the StarOffice (SO) product and Sun's support of the OpenOffice.org (OOo) community. Critically important as well is the customer need to interoperate with the current dominant office suite format, the "binary office formats", denoted by file extensions .doc, .ppt and .xls, from Microsoft. Sun has correspondingly made a significant investment in developing software able to read and write these proprietary and undocumented MS binary formats.


 

Against this backdrop, Sun initiated a standardization activity in late 2002 within the OASIS standards organization to develop an extensible, XML-based, portable office file format. Key goals were to ensure the format was both platform and application agnostic, and to ensure there were no intellectual property barriers to implementation by anyone in any type of software, proprietary or open source. This effort produced the OpenDocument Format (ODF), an open and independent format that enables both competition among office suite providers, and permits innovation and extension above this standardized base. ODF v. 1.0 was ratified as an OASIS standard in May 2005, and subsequently approved as an ISO/IEC standard in May 2006.


 

The most obvious benefit of an XML-based, fully open and unencumbered office suite format is the creation of a level playing field for office suite providers, allowing choice, competition and innovation. But a second, potentially more important benefit, is that it permits these structured office documents to be integrated into an enterprise Service Oriented Architecture. This allows web-mediated and automated access to the myriad of information stored in these formats.


 

II. Sun's Proposed Solution

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 major advantage of solution a. is to allow standalone operation when network connectivity is unavailable, as with a disconnected laptop. Another key advantage is that the fully standard and operational SO/OOo installation can be used directly at any time for office document creation and manipulation. On the other hand, solution b. involves substantially less code on each user desktop, and is designed to allow interactions with the server conversion capability from web interfaces or applications other than MSO. It provides a more flexible interface for supporting a variety of modes of operation, including conversions for formats other than MS binary formats, batch operations, and other SOA-type functions.


 

A Sun partner has deployed a web site which uses our converter software infrastructure for conversion of MS binary files to pdf via a web interface. This infrastructure is the same product as in the proposed server solution, except the focus here is on ODF conversion rather than pdf. The site is at

http://www.soconverter.com/soc.nsf/webpages/convert_e.htm

and gives an idea of how a web interface to a conversion service can work.


 

Each of these approaches may be desirable in differing circumstances and deployment models. They are non-interfering, and can both be used simultaneously in an environment, delivering the maximum flexibility and availability for users.


 

III Information Requested

Our responses are provided to each of the detailed ITD questions in this section. ITD's question appears first, followed by our response in bold. Where there is a difference for our proposed standalone and server solutions, the description notes that and indicates how they are different.


 

Existence of Parties, Projects, and Status

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?

We are describing two options for an ODF plug-in or converter:



  1. A "plug-in" based on the StarOffice or OpenOffice.org application: This approach requires that a standard, fully functioning StarOffice or OpenOffice.org instance is installed in addition to MSO. StarOffice or OpenOffice.org are then used to convert the OpenDocument formats (.odt, .odp, and .ods) into their MS Office binary document format counterparts (.doc, .ppt and .xls) and vice versa. The conversion takes place as part of a load or save operation, which is invoked by a menu item or toolbar command button that the installation procedure adds to MS Office. A more detailed description appears in our response to item L.

    There are no essential technical differences between this solution when based on OpenOffice.org or StarOffice. Although some minor differences exist between the two products, the only relevant difference here is the differing service options available for the two products.

    The StarOffice/OpenOffice.org application remains fully functional, and may be used independently of MS Office.

    The OpenOffice.org application is shipping in version 2.0, Sun Microsystems, Inc.'s StarOffice in version 8, and therefore both are ready to use. The required user interface functionality has been evaluated from an engineering perspective, but not yet implemented. We note our estimates for resources required for completion in item N.

  2. MSO ODF support based on a conversion server: Sun has substantially completed development of a server based converter (StarOffice server) for translating MS Office binary document formats (.doc, .ppt and .xls) into their OpenDocument format (ODF) counterparts (.odt, .odp, and .ods). This server software, which is based on StarOffice, has already been deployed by customers in Germany and is very close to a release for wider distribution. The StarOffice server can be either accessed via a web (HTML) interface, or, for ITD's purposes, a set of MSO toolbar/menu interfaces which operate as described above. The essential difference is that the conversion takes place on the server.

    The required user interface functionality has been evaluated, but not yet implemented.



Since both approaches are based on OpenOffice.org/StarOffice, both solutions provide the same conversion quality. Further, both solutions can be used in parallel without interoperability issues.

In the following, if not otherwise noted, the terms "converter software" and "plug-in" refer to both solutions.

  1. Whether an open source project, an independent developer, a vendor, or a group of vendors is currently developing, planning to develop, or interested in developing an ODF plug-in or converter for Microsoft Office 2000, Office 2003, and the upcoming Microsoft Office 2007, capable of reading and saving ODF documents. Please provide the identity of such open source project, independent developer, vendor or vendors, their address, names of principals, and a description of their experience in projects of similar technical difficulty.

    Sun is interested in making the converter software available to MA. The software, regardless which of the above solutions is preferred, enables all of the conversions available in the StarOffice 8/OpenOffice.org 2.0 products via a web based interface or an MS Office toolbar or menu item extension. This conversion capability, identical to that in SO8/OOo2, provides translations between the MS Office 2000 and 2003 binary formats and their ODF equivalents. As MS Office 2007 is not yet released, and the associated format is not yet specified, we can not claim support for that version. However, past experience would suggest that at least import support for the file formats of Office 2007 would be available for StarOffice and OpenOffice.org, and consequently also available in the conversion software being described in this RFI.

    Sun is the major contributor to the OpenOffice.org project, including in particular the MS Office filters which are the basis of the proposed converter software.

    Sun is the vendor of the OpenOffice.org based StarOffice software and the conversion server.

  2. Who owns the intellectual property associated with current and planned efforts to build an ODF plug-in or converter?

    Sun Microsystems, Inc. owns the copyright of the OpenOffice.org source code, which is licensed under LGPL.

    Sun Microsystems, Inc. owns the intellectual property associated with the server based converter software, and would own as well, the proposed MS Office ODF conversion interface code outlined in this RFI.


 

Mode of Operation; Ease, Transparency, Economy of Use

  1. Whether such a plug-in would be capable of exchanging textual (Word), spreadsheet (Excel) and presentation (PowerPoint) documents, whether in legacy or XML formats, to and from ODF, and rendering such documents using Microsoft Office.

    The converter software is able to convert between ODF and MS binary formats, in both directions, between text, spreadsheet and presentation documents.

  2. Whether this exchange 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).

    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.

  3. Whether the plug-in can allow Microsoft Office to save to ODF as the default format.

    Enabling "save to ODF" as the default format, in a robust fashion, requires information about the MS Office application that is not generally available. Without that information (but see item R), our solution is to provide a "Save as ODF" menu item or toolbar button which initiates the server converter process, resulting in the document being converted to the appropriate ODF and saved with the specified name in the specified directory. The MS Office document can additionally be saved in an MS Office format, e.g. for backup or comparison reasons.

    We also believe that the new menu items are accessible by mnemonic keystrokes, as this is how most users (and also blind users) will likely invoke it - by mnemonic.

  4. What limitations, either in terms of fidelity of exchange, type of document, or user operation, should be anticipated for such a plug-in or converter?

    The core converter software for both solutions is identical to that used in SO8/OOo2, which will in turn have identical file format fidelity to the solutions proposed here.

    Note that the design of ODF as a cross-platform file format, compared to the Windows/Intel platform-specific MSO binary formats, guarantees that MS Office may create files that are simply not convertible to ODF. E.g. this is the case when embedding COM objects, or ActiveX controls (which require a Win32-enabled OS) and for which no equivalents exists on Solaris, Linux OS or other non-Windows platform. Additionally MS Windows-only features appear to also be included in the MS Office XML Reference Schemas (XMLRS), as submitted recently to Ecma TC45 for consideration.

    Furthermore, MS Office may have features that do not have a direct counterpart in OpenOffice.org and StarOffice. A conversion (or saving) of such features is not possible in all cases, although see item S.

  5. Against what ODF conformance standards would such a plug-in or converter be assessed?

    The OASIS OpenDocument Format specification v. 1.0 is the reference for OpenDocument behavior. OpenOffice.org 2.0 and StarOffice 8.0 are designed to fully and accurately implement this specification, and any variance would be considered a bug and addressed via our normal maintenance process.

    Sun is also committed to support accessibility enhancements currently under discussion in an OASIS OpenDocument TC sub-committee. Because of the close relationship between the server software and SO/OOo, the enhancements would be supported in the conversion software at the same time they become available in the SO/OOo applications themselves.

  6. What level of visual fidelity, onscreen and in print between Microsoft binary or XML formatted documents and ODF documents could be achieved?

    A pixel by pixel representation of arbitrary MS Office binary or XML documents in the OpenDocument format is not possible for a variety of reasons. These include

    1. the undocumented and unstructured nature of the MS Office binary formats (propagated into at least the draft of MS Office XML Reference Schemas currently submitted to Ecma TC45);

    2. different feature sets and macro languages in the MS Office and StarOffice/OpenOffice.org applications;

    3. OpenDocument has been designed as an vendor neutral file format for office applications, and supports the vast majority of MS Office documents; however, MS Office documents may contain features that are can not be supported by OpenDocument, either for technical or intellectual property-related reasons.

    These issues are discussed further in items R and S below.

    Note however, that very substantial fidelity and conformance has been achieved for the vast majority of MS Office binary stored documents. For the few areas in which the automatic conversions are inadequate, migration tools are provided by Sun, and migration support is provided by Sun partner companies.

  7. How difficult would it be to install and use an ODF plug-in or converter?

    In our proposed solution a. (standalone), each user machine would require installation of StarOffice or OpenOffice.org. This is identical to the current SO8/OOo2 products, allowing ITD to fully assess that installation process.

    For solution b., the server-based converter software, the server side installation is only slightly more complex than the installation of the OpenOffice.org/StarOffice product itself. Note that the server based converter could also be installed locally, as yet another option for server independent operation.

    The server-based option results in a significantly smaller footprint on the clients.

    For both solutions, there would also be a relatively small MS Office (or client-side) add-on installation that enables the service-based hooks with MS Office.

  8. What training would be needed, if any, to correctly use the plug-in or converter?

    The proposed user interface solution (assuming no MS cooperation) would entail a small difference in file saving procedure, requiring the user to select a separate menu item or toolbar button to save to ODF. Presumably MS cooperation and information (see items R and S) would enable a wider range of choices and enable more seamless document save and open operations for ODF files. Insufficient publicly available knowledge about private MS internal APIs for MSO for these functions prevents prohibits definitive statements on how seamless an integration may be possible.

  9. The contemplated mechanics of how such a plug-in or converter would be installed and would operate in practice. Diagrams and or screen mockups would be helpful in clearly describing the proposed solution.

    The following description is for the StarOffice server based solution. The sequence of events for the standalone solution is the same, except that document are not transmitted to a server, but rather SO/OOo is called directly.

    The "save" operation would operate via a menu or toolbar item, "Save to ODF", which would lead to the following sequence of events.

    The MS Office document would be stored in the MS Office format in the selected target directory in MS binary format.

    A background process would be started which transmits the saved MS Office document to the server based converter for conversion to ODF.

    The ODF equivalent of the document is returned by the server software and is saved in the target directory with the same name, but using the appropriate file extension.

    The original MS Office document is either kept or deleted, depending on preference.

    The "read" operation for an ODF document would proceed in an essentially reverse direction, where a "File Open" on an ODF file would send the ODF document to the converter, which upon conversion to MS Office binary format would save it in the target directory and open it into the currently running MS Office.



  10. What are the anticipated end-purchaser acquisition and maintenance costs for such a plug-in or converter?

    The acquisition and maintenance costs for our converter product have not yet been determined. Service options would be available, but pricing is also not yet determined.

    OpenOffice.org is an open source product. Service options are available from Sun Microsystems, Inc. and others.

    StarOffice is a Sun Microsystems, Inc. product. Its price depends on the number of licenses that are purchased. Service options are available.

Timeframes, Level of Effort, Resources, Technical Details, Risk

  1. In what timeframes would such a plug-in or converter be completed, available for testing, and available for deployment? Please describe availability in terms of the following matrix, and please describe anticipated functional levels clearly:


 


 

Developer Code Complete

Available for Customer Testing (Beta)

Certified as compliant with ODF Standard

Available for Customer Use

Functional Level (Describe) (Release 1.0)

2 months following start of MSO interface effort.

2 months following start of MSO interface effort.

Implements ODF v1.0

3 months following start of MSO interface effort.

Functional Level (Describe) Release 1.x

To Be Determined

TBD

TBD

TBD


 

  1. For updates to the converter software, please see answers to questions H and T.

  2. How many as-yet unspent person months on the part of respondent, or others through projects with which the respondent is familiar, would be involved in an effort to achieve the objectives outlined above?

    The essential and critical part of ODF support in MS Office is the conversion capability itself. Development of this capability for OpenOffice.org took several person years. The development of a plug-in that utilizes the OpenOffice.org conversions is relatively small and can be accomplished within the two month time noted above.

  3. What external (sponsor, investor, customer) resources that are not currently available or committed to the respondent would be necessary to achieve the functional release timeframes described above?

    The engineering capability for performing the work identified in items N and O is available within Sun, and is currently committed to this effort. As you may know, however, Sun has recently appointed a new CEO, and resource planning and associated staffing commitments are currently under review.

    Sun is strongly committed to this effort, and we would be happy to discuss the specifics of our resource planning with ITD at any time. Also, we are not opposed to accepting and coordinating external support directed at particular operational functionality or accelerated completion and testing of the interface and related work, it is simply not factored into our estimates above.

  4. Describe the language in which such a plug-in or component would be written, and any tools that would be required to develop it, or extend its functionality.

    The vast majority of OpenOffice.org is written in C++, parts in Java. The tools required to build OpenOffice.org are documented at the following OpenOffice.org web page:

    http://tools.openoffice.org/dev_docs/build_windows_tcsh.html

    For building the Microsoft Office specific parts of the plug-in, a .NET environment is required.

    Extensibility for the server based converter is not provided, we anticipate that the web interfaces provide sufficient flexibility and access to the conversion functionality.

  5. How much and what kind of cooperation from Microsoft would be required of a team creating an ODF translator plug-in that was very well integrated with Microsoft New, Open, Save, and Save As functions?

    The programmatic interfaces controlling access to these interfaces are neither public nor documented by MS. As with all private and proprietary interfaces, these are subject to change at any time and for any reason, including patches as well as major and minor revisions to the application. Consequently, any reverse engineered information used to integrate menu item or "File Save", "File Open", etc. would be fragile and subject to malfunction on a continuing basis.

    In order to properly and robustly integrate ODF read/write functionality into MS Office, the interfaces for accessing those functions would need to be revealed by MS, along with a commitment to support them for the required period of time.

    Note that it is our understanding that MS Word provides a public interface to allow inclusion of additional file format options under the "File/Open" and "File/Save as" menu items. This interface is documented for Word 97, but not for current versions of MS Office. We believe this provides a relatively safe method for incorporating ODF read/write functionality in MS Word. However, no such interface is available for MS Powerpoint or Excel, complicating the development of ODF functionality for those applications.

  6. 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?

    As noted above, the MS binary formats have two types of functions that create substantial problems in conversion to the structured, platform-independent, XML-based ODF format. The first class of issues are the inclusion of Windows-only features and functionality. This includes such items as ActiveX or Win32 controls which are not implemented on other platforms. The second class consists in general of proprietary and undocumented programming features such as Word macros and spreadsheet macros and formulas. These features are private MS technology that presents a high barrier to full interoperability between ODF and MS binary formats.

    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; should MS provide documented, public and implementable specifications for these currently proprietary and IP-protected technologies, we would anticipate increased fidelity in MS format conversions to ODF.

  7. What level of effort and costs are estimated to support the plug-in on a going forward basis to maintain compatibility with the latest format versions over time?

    The conversion software is based on OpenOffice.org. It can be expected that OpenOffice.org will be adapted to reflect all changes to the OpenDocument format that are relevant to the OpenOffice.org application.

    The maintenance costs for an OpenOffice.org based converter software regarding new OpenDocument format versions are anticipated to reflect the typical download and installation costs of such software. In case OpenOffice.org is installed and maintained on the same system, no additional maintenance costs are expected.

    For StarOffice, Sun is supplying regular product patches as part of service contracts, and can be applied to existing installations. A re-installation is only required for major versions. The maintenance cost of a StarOffice based converter are therefore those of StarOffice itself. Should StarOffice be installed and maintained on the same system, no additional maintenance costs are expected.

    For the StarOffice server based conversion software, Sun is supplying regular product patches as part of service contracts. These patches can be applied to existing installations. A re-installation is only required for major versions. The maintenance cost of a server based plug-in are therefore those of the StarOffice server software itself.

    Please note that upgrades of the MS Office software may cause additional maintenance costs associated with the user interface code.

  8. What are the business, financial and technical risks associated with such a project?For the reasons provided in the answer to question J, it may happen that the visual fidelity of the conversion is below the average for single MS Office documents.

    The conversion software is based on file formats and interfaces controlled by Microsoft. Although we do not have any indications that the file formats and interfaces will change in future versions in a manner that will break the conversion software, we cannot make any statements regarding if and how well the conversion software will operate with future versions of Microsoft Office

  9. Compare the level of effort for creating an ODF-translator that will work with (1) Office 2000, (2) Office 2003 and (3) Office 2007 (based on currently available information)

    Differences in the effort for Office 2000 and Office 2003 are not known. A statement regarding Office 2007 cannot be made at this time.



    General
     

  10. Please provide any other information you believe to be important and germane to the purposes of this Request for Information.

    Sun is describing two different solutions in this RFI response. In our opinion, a key benefit of the OpenOffice.org/StarOffice standalone solution is that it allows a gradual, phased transition to the OpenOffice.org/StarOffice application. We consider these applications to be the premier OpenDocument format applications.

    A key benefit of the StarOffice server based solution is that the central conversion service can be used by an MS Office application, as well as by a web front end, other web service clients or another word processing application such as Wordperfect.

    We believe that the best choice for ITD depends on a variety of factors such as robustness of the network, architecture of the server environment, work flows and other specific requirements. We would be happy to work with ITD to identify the most appropriate solution for ITD and executive branch agency needs.

5/19/2006 Sun Microsystems, Inc. - odf Plug-in RFI Response 14