(III) Multiple Implementations
An open document format can and will be designed into many different software applications without practical, technical, legal, or other impediments.
From a different perspective it is fair to say that an open format has the characteristics that attract multiple implementations. If one had no other way to tell, the format specification with the greater number of complete implementations likely follows open principles more rigorously and will better deliver information free-flow between applications and platforms.
Additionally, software patent restrictions provide a drag on a format's re-implementation in software. They stifle software choice and increase the structural cost in the economy of working with documents.
Although ODF originated as the native format of OpenOffice.org, it has been adapted to an open process and is designed for open re-implementation in any software:
- ODF's multi-vendor support
ODF was conceived for implementation in many software applications without limitation as to which party or how many can implement it. One of the principal objectives as specified in the OASIS ODF Technical Committee charter is to have as many implementations as possible and, indeed, multiple implementations of ODF exist today. Currently OpenOffice.org, StarOffice, KOffice, Lotus Notes, AbiWord, Google Docs & Spreadsheets, Zoho Writer, AjaxWriter and other applications work with ODF documents. As pointed out previously, multiple implementations of ODF existed prior to its submission to ISO.
- ODF's reuse of existing standards
ODF makes use of as many existing open software standards as possible, which both improves the specification's quality, shortens re-implementation production schedules, and permits conformity with the wide range of W3C XML tool sets. This respect for existing standards makes re-implementation of the ODF format attractive, efficient, and feasible, and it provides for an efficient standard specification process and a more compact specification document.
- ODF's covenant not-to-sue provides necessary assurance
ODF is developed and maintained by a technical committee whose members are obligated to a royalty-free policy. The originator of ODF, Sun Microsystems, provides a simple covenant-not-to-sue, which covers any of potential Sun patents used in the development of ODF implementations (although none have been asserted yet).xi The ODF specification is allowed to be fully implemented in both commercial and open source software without legal impediment. Additionally, ODF has been certified by the Software Freedom Law Center as free of legal encumbrances that would prevent its use in any free or open source software.xii
OOXML is a single-vendor format that presents obstacles to implementation in software other than products offered by Microsoft for which the format was designed:
- OOXML is not fully implemented in any application
The Ecma TC 45 charter states the goal in its Programme of Work, "To Produce a formal Standard for office productivity documents which is fully compatible with the Office Open XML Formats." Microsoft Office 2007 is currently the only application that provides a partial implementation of OOXML, while no application exists that is a reference implementation for the formats Ecma TC45 has submitted to ISO.xiii
- OOXML fails to reuse existing standards
OOXML ignores a number of open standards that are available and should be used, including SVG for drawings and MathML for equations.xiv Failure to reuse existing standards increases the cost and difficulty of third-party implementation and the frequency of the document formats' code-level interactions with proprietary features in Microsoft operating systems and applications.
- OOXML's IPR covenant offers limited protection
The patent-protection pledge in Microsoft's Open Specification Promise only protects what is explicitly specified in the standard. The Promise states that the company will not sue anyone for implementing the explicit parts of the OOXML specification; however, there are numerous implied, referenced, and undocumented facets and behaviors of the OOXML formats which, if implemented by another entity, would risk "intellectual property" (patent) violations against Microsoft software. Additionally, there are serious gaps in the promise not to sue:
- The Promise does not cover any material that is referenced, but not described in detail, within the specification. Even if the referenced material is required for an implementation, no patent rights extend to the implementer. For example, numerous sections, including those sections which require replicating the behavior of proprietary Microsoft products, do not appear to be described in detail and therefore are not covered by Microsoft's Promise. Additional necessary Microsoft proprietary technologies not described in detail include OLE, macros/scripts, encryption, and DRM. Microsoft has not stated a position on whether any patent rights associated with these technologies will be made available on terms acceptable to ISO.
- The Promise is limited to claims "..that are necessary to implement only the required portions of the Covered Specification." [emphasis added]. The Promise does not cover optional aspects. To the extent that the implementer includes "excluded optional portions (or non-required elements of optional portions)" that are in OOXML, the implementer would be unlicensed to any Microsoft patents covering those items and vulnerable to patent infringement allegations. For example, password features for WordProcessingML may not be required but are described in the specification (188.8.131.52, page 1,158). From a practical perspective, all optional aspects of a format are necessary for a full implementation to function effectively across the wide range of possible software behaviors.
ODF has already achieved multiple implementations and has therefore achieved success with this criteria. In contrast, the patent "promise" of OOXML is insufficient. The embedded uncertainty and gaps in coverage hold back the formats' practical and legal implementability. That's why OOXML does not have multiple implementations today, and it should not be expected to have them under Microsoft's present approach to protecting developers against patent violations.
(IV) Interoperability Across Different Systems
Perfect interoperability across different systems means a format can be fully implemented in any application, regardless of the platform or system on which that application operates. Every respective system would be able to access a document's content and layout parameters to provide perfect document fidelity to the original. While neither ODF or OOXML offers perfect interoperability, we can judge each one's performance based on its proximity to perfection as well as its potential to reach a high practical level of interoperability for business processes.
It is sufficient that an open document format should be easily read, authored, and edited from within different system environments and across different applications. Content should be transmitted without loss, and presentation layout should be rendered with fidelity by alternative applications operating on different platforms.
ODF-supporting applications are available on all major computing platforms such as Windows, Linux, Solaris, AIX, Mac OS, and a variety of web-based online document-editing applications, like Google Docs and Spreadsheets. Users can create documents with the wide variety of ODF-supporting applications on any of these platforms and exchange them with users working on different platforms.
Simple documents are being exchanged with high levels of fidelity today. For example, OpenOffice.org can open, read, and edit simple text documents originated in Koffice or AbiWord. While certain formatting problems can occur (typically with more complex documents), loss of content is infrequent in single-trip file transfers.xv Content and layout fidelity in roundtrip document exchange in collaborative work group situations (passing a document back and forth repeatedly) is imperfect but can be improved; there are no technical impediments to achieving better if not perfect roundtrip performance between all ODF-ready applications of the same vintage.xvi
OOXML presents problems for document interoperability across multiple platforms.xvii Shortcomings exist in four areas: 1) platform dependencies; 2) application dependencies; 3) inadequate specification; and 4) poorly-designed XML. While not meant to be an exhaustive list, the problems highlighted below reflect the dependencies upon the Microsoft Windows operating system(s) and Microsoft Office application(s) that pose the most obvious and significant threat to OOXML's interoperability:
- Platform dependencies of OOXML
Certain platform dependencies of OOXML are features that can only be implemented or optimized for Windows. Document files containing such features will break or not function the same way in non-Microsoft environments. Examples include:
- DevMode, a method Windows uses for handling information about printer or display settings, is one such operating system dependency carried within OOXML documents. Consequently, printer initialization, display and other settings may not work in an OOXML file that is transferred into a non-Microsoft environment.xviii
- GUID, a proprietary Microsoft Windows and .Net implementation of the UUID standard for applications to coordinate and identify resources within an operating system, is another hidden system dependency tying OOXML files to the Microsoft environment.xix
- 3.2.29 "Workbook Protection" (page 2,698xx) defines an encryption algorithm by including several pages of C-language source code, code which appears to have byte-ordering dependencies and will produce different results on different machine architectures.
- "Clipboard Data" (page 5,905xxi) defines a schema type that can encode clipboard format values for Windows and the Macintosh, but doesn't seem to allow for other operating systems.
System dependencies like these make it unappealing, difficult, and in most cases impossible to conduct work productively without Microsoft software.xxii These examples are not exhaustive.
- Application dependencies of OOXML
OOXML documents' collaborative functionality and integration with e-mail and other applications depend upon further purchases of additional software from Microsoft.xxiii The following capabilities are not available to OOXML files when they are accessed by software other than Microsoft software:
- VBA macros contained in OOXML documents will not run when outside Microsoft applications.
- An enumerated list of border art means that every application that wishes to fully comply with the standard must somehow license the use of those graphics.xxiv
- "Disable Features Incompatible with Earlier Word Processing Formats" (page 2,252xxv) explicitly states that OOXML only considers the needs of Word 97-2003.
- "Disable Features Not Supported by Target Browser" (page 2,120xxvi) is designed to optimize for various version of Internet Explorer and disregards Internet Explorer's main competitor, Mozilla Firefox, as well as other alternative browsers.
- Inadequate Specification
To the extent that a format feature is only partially specified or not specified at all, other vendors' products will not be interoperable with it. Examples include:
- The OOXML specification does not specify how macros or scripts are embedded in OOXML document.
- "autoSpaceLikeWord95" (page 2,161xxvii) merely defines semantics in reference to a legacy application whose behavior is nowhere specified.
- OOXML preserves certain file data in binary form based upon legacy formats not disclosed to outside developers.xxviii
- The implementation of OOXML for spreadsheets in Office 2007 (Excel 2007) also makes use of data in binary form.
- Poorly Designed XML
Engineers in the field agree there are certain practices with respect to the use of XML from which it appropriate not to depart. Otherwise, the notion of a standard format for accessing data across disparate systems is defeated once unique techniques are put to use in particular environments which do not translate to others. OOXML disregards sensible XML practices in the following ways:
- OOXML requires bitmasks (see "Conditional Formatting Bitmask," page 2,478).xxix Commonly agreed proper XML implementation would never employ bitmasks. For example, XSL Transformation ("XSLT"), a useful method for translating from one legitimate XML dialect to another, lacks bitwise functionality, making the use of bitmasked data impossible to access outside the Microsoft fold.
- OOXML carries forward a known legacy bug affecting date and time for spreadsheets (page 3305-6xxx). This standardization of a famous old mistake (originating in Lotus 1-2-3) for the stated purpose of "backward compatibility" requires that spreadsheets treat the year 1900 incorrectly as a leap year. This gives wrong dates according to our standard Gregorian Calendar and affects other software that interacts with Microsoft documents.xxxi
- OOXML's naming conventions are sub-standard. Proper XML demands adherence to established conventions in the naming of Attributes as well as Child and Parent Elements. OOXML's inconsistency throughout its specification causes confusion and increases the difficulty of implementing the format (see specification section 184.108.40.206 "settings (Document Settings)", page 2,020xxxii, where it says,"EOOXML has poor XML Element names").xxxiii
ODF is independent of any particular platform or application, whereas OOXML is either dependent upon, or optimized for, a catalog of Microsoft software applications and platforms and does not function fully with non-Microsoft software. The practical effect of such dependencies is that the use of OOXML by individuals or within work groups will require the purchase of licenses of Microsoft operating systems on both the desktop and the server as well as Microsoft Office 2007.