Document Wars

What efforts are you talking about? The last time any effort was made to accomodate interoperability was in 2003 with the establishment of the ODF "Compatibilty clause" (Section 1.5). "Despite some efforts by the two camps, ODF and OOXML are, for the most part, not interoperable, meaning documents that are created in one format cannot be successfully read by applications based on the other format......" Section 1.5 authorizes the use of "foreign elements" and "alien attributes". These techniques were specifically written into ODF for handling unknown characteristics of existing MSOffice documents (binary and/or xml) on conversion to ODF. Since the Section 1.5 addition in 2003, every other suggestion to improve interop between ODF and MSOffice documents has been rejected by the OASIS ODF TC and Sub Committees. There are three problems with Section 1.5. The first is that there is only so much that can be done with foreign elements and alien attributes. There are still remaining compatibility issues relating to the basic structures of lists, tables, fields, sections and page dymnamics. The OpenDocument Foundaiton spent over a year trying to get approval for five generic elements relating to these structures, without success. As i said, there has not been a single successful comatibility - interoperability effort since 2003, although many have been proposed. The second reason for the failure of Section 1.5 is that OpenOffice only partially implements the "Compatibility Clause". OOo only recognizes "foreign elements and alien attributes" with text spans and paragraphs. The third reason is that "compatibility" is optional in ODF. The clause does not have any teeth. Applications can implement only those aspects of the spec they feel like implementing, and still be in total "compliance". This creates serious interop problem not only for MSOffice plug-in comverted documents, but also renders as

This article discusses how Microsoft might change their ways and save the company. This particular quote concerns Microsoft support for standards, and their fight to push MS OOXML through ISO as an alternative to ISO approved ODF 1.0.
The thing is, ODF was not designed for the conversion of MSOffice documents, of which there are billions. Nor was ODF designed to be implemented by MSOffice. ODF was designed exactly for OpenOffice, which has a differnet model for impementing basic docuemnt structures than MSOffice.
So a couple of points regardign this highlight:
The first is that IBM's Lotus Symphony is NOT Open Source. IBM ripped off the OpenOffice 1.1.4 code base back when it was dual licensed under both SSSL and LGPL. IBM then closed the source code adding a wealth of proprietary eXtensions (think XForms and Lotus Notes connections). Then IBM released the proprietary Symphony as a free alternative to the original Open Source Community "OpenOffice.org".
If Microsoft had similarly ripped off an open source community, there would be hell to pay.
Another point here is the mistaken assumption that users can easily switch from MSOffice to an on-line product like Google Docs or ZOHO "without having to rip our and replace their entire desktop infrastructure."
This is a ridiculous assumption defied by the facts on the ground. Massqchusetts spent two years trying to migrate to ODF and couldn't do it. Every other pilot study known has experienced the same difficulties!
The thing about Web 2.0 alternatives is that these services can not be integrated into existing business processes and MSOffice workgroup bound activities. The collaborative advantages of Web 2.0 alternatives are disruptive and outside existing workflows, greatly marginalizing their usefulness. IF, and that's a big IF, MSOffice plug-ins were successful in the high fidelity round trip conversion of wor

It's impossible to harmonize two application specific file formats. The only way to establish an effective compatibility between ODF and OOXML would be to establish a compatibility between OpenOffice and MSOffice.
The problem is that neither ODF or OOXML were developed as generirc file formats. They are both application specific, directly reflecting the particular implementation models of OOo and MSOffice.
Sun and the OASIS ODF TC are not about to compromise OpenOffice feature sets and implmentation methods to improve interop with MSOffice. Sun in particular will protect the innovative features of OpenOffice that are reflected in ODF and stubbornly incompatible with MSOffice and the billions of binary documents. This fact can easily be proven be any review of the infamous "List Enhancement Proposal" that dominated discussions at the OASIS ODF TC from November of 2006 through May of 2007.
So if Sun and the OASIS ODF TC refuse to make any efforts towards compatibility and imporved interop with MSOffice and the billions of binary docuemnts seekign conversion to ODF, then it falls to Microsoft to alter MSOffice. With 550 million MSOffice desktops involved in workgroup bound business processes, any changes would be costly and disruptive. (Much to the glee of Sun and IBM).
IBM in particular has committed a good amount of resources and money lobbying for government mandates establishing ODF as the accepted format. this would of course result in a massively disruptive and costly rip out and replace of MSOffice.
Such are the politics of ODF.

This ComputerWorld article is referenced by the State of New York in their request for information

Mary Jo takes on the recently released Burton Group Report comparing OOXML and ODF. Peter O'Kelly, one of the Burton Group authors, once famously said, "ODF is a great format if you live in an alternative universe where MSOffice doesn't exist!" This observation speaks to the core problem facing ODF and those who seek to implement the ODF standard: ODF was not designed for the conversion of MSOffice documents. Nor was ODF designed to work with MSOffice applications. Another way of saying this is to state that ODF was not designed to be interoperable with MSOffice documents, applications and bound processes. The truth is that ODF was designed for OpenOffice/StarOffice. It is an application specific format. Both OOXML and ODF do a good job of separating content from presentation (style). The problem is that the presentation - layout layers of both ODF and OOXML remains bound to specific applications producing it. While the content layers are entirely portable and can be exchanged without information loss, the presentation layers can not. Microsoft makes no bones about the application specific design and purpose of OOXML. It's stated right in the Ecma 376 charter that OOXML was designed to be compatible with MSOffice and the billions of binary documents in MSOffice specific binary formats. The situation however is much more confusing with ODF. ODF is often promoted as being application, platform and vendor independent. After five years of development though, the OASIS ODF TC has been unable to strip ODF of it's OpenOffice/StarOffice specific aspects. ODF 1.0 - ISO 26300 had three areas that were under specified; meaning these areas were described in syntax only, and lacked the full semantics demanded by interoperable implementations. Only OpenOffice and StarOffice code base applications are able to exchange documents with an acceptable fidelity. The three under specified areas of ODF are: Lists (numbered), F

..... response to Robert Crocker concerning Mary Jo's article, "Independent study advises IT planners to go OOXML". 3.2.2. So this is well documented? Robert Crocker - 01/14/08 : Mind explaining these functions to us then? - Section 2.15.3.6 page 2161, autoSpaceLikeWord95. - Section 2.15.3.26 page 2199, footnoteLayoutLikeWW8. - Section 2.15.3.31 page 2209, lineWrapLikeWord6. - Section 2.15.3.32 page 2210, mwSmallCaps. - Section 2.15.3.41 page 2225, shapeLayoutLikeWW8. - Section 2.15.3.51 page 2245, suppressTopSpacingWP

good article from Eric Lai of ComputerWorld. Written on the eve of the infamous Barcelona OpenOffice.org developers conference, Eric argues that OOo isn't a real open source community. Instead, OOo is a owned and operated by Sun.
One of the more important control points Sun insists on is that of commit rights and project managers. Only Sun employees have these rights and can hold these important positions..
The more important point is made by Marbux (below: ODF is an application specific format designed exactly for OpenOffice. While other applications might partially implement ODF, interoperability and successful ODF document exchange require the OOo code base!
From Marbux: This is the only article I've found to date where IBM (Heintzman) flat out says IBM wants changes in OOo licensing, more in line with the Eclipse and Apache licenses. See pg. 2. Significant because it feeds the meme that IBM's own ODF-based development goal is proprietary closed source built on the OOo code base, e.g., Symphony, et cet.
And that has huge signficance once you realize that ODF is not the real standard; the OOo code base is the real ODF standard. Look around the world and you see that ODF adoption decisions by governments are all in reality decisions to go with StarOffice, OOo, or OOo clones. I haven't, for example, seen a single instance where a government decided to ride with KOffice. Why would they, with the interop issues between KOffice and OOo? The fact that OOo's code base is the real ODF standard will figure strongly in the comments. Couple it with Sun's iron-fisted control of the OOo code base, and you have vendor lock-in with a Microsoft partner.
But with 70 developers committed in China, where developers salaries are inexpensive, IBM will soon be in a position to threaten to fork the OOo code base using proprietary extensions. Is that their real tactic to force changes in licensing and gov