Group items tagged

A "touch limited in scope"? Youv'e got to be kidding. ODF was not defined to be compatible with the billions of MSOffice binary (BIN) documents. Nor was it designed to further interoperability with MSOffice.
Given that there are over 550 million MSOffice desktops, representing upwards of 95% of all desktop productivity environments, this discrepancy of design would seem to be a bit more than a touch limited in scope!
Many would claim that this limitation was due to to factors: first that Microsoft refused to join the OASIS ODF TC, which would have resulted in an expanded ODF designed to meet the interoperability needs of the great herd of 550 million users; and second, that Microsoft refused to release the secret binary blueprints.
Since it turns out that both IBM and Sun have had access to the secret binary blueprints since early 2006, and in the two years since have done nothing to imptove ODF interop and conversion fidelity, this second claim doesn't seem to hold much water.
The first claim that Microsoft didn't participate in the OASIS ODF process is a bit more interesting. If you go back to the first OASIS ODF Technical Committee meeting, December 16th, 2002, you'll find that there was a proposal to ammend the proposed charter to include the statemnt that ODF (then known as Open Office XML) be compatible with existing file formats, including those of MSOffice. The "MSOffice" reference was of course not included because ODF sought to be application, platform and vendor independent. But make no mistake, the discussion that day in 2002 was about compatibility and the conversion of the legacy BIN's into ODF.
The proposal to ammend the charter was tabled. Sun objected, claiming that people would interpret the statement as a direct reference to the BIN's, clouding the charter's purpose of application, platform and vendor independence. They proposed that the charter ammendment b

Will harmonization work? I don't think so. The problem is that the DIN group is trying to harmonize two application specific formats. OpenOffice has one way of implementing basic document structures, and MSOffice another. These differences are directly reflected in the related formats, ODF and OOXML. Any attempts to harmonize ODF and OOXML will require that the applications, OpenOffice and MSOffice, be harmonized! There is no other way of doing this unless the harmonized spec has two different methods for implementing basic structures like lists, tables, fields, sections and page dynamics. Not to mention the problems of feature disparities. If the harmonized spec has two different implementation models for basic structures, interoeprability will suffer enormously. And interoperability is after all the prupose of the standardization effort. That brings us to a difficult compromise. Should OpenOffice compromise it's "innovative" features and methods in favor of greater interoperability with MSOffice and billions of binary documents? Let me see, 100 million OpenOffice installs vs. 550 MSOffice installs bound to workgroup-workflow business processes - many of which are critical to day to day business operations? Sun and IBM have provided the anser to this question. They are not about to compromise on OpenOffice innovation! They believe that since their applications are free, the cost of ODF mandated "rip out and replace" is adequately offset. Events in Massachusetts prove otherwise! On July 2nd, 2007, Sun delivered to Massachusetts the final version of their ODF plug-in for MSOffice. That night, after reviewing and testing the 135 critical documents, Massachusetts made a major change to their ETRM web site. They ammended the ETRM to fully recognize OOXML as an acceptable format standard going forward. The Massachusetts decision to overturn th

Exactly! This is also the reason why ODF failed in Massachusetts! Reducing the interoperability or functionality of of any workgroup related business process is unacceptable. Which is why IBM's rip out and replace MSOffice approach as the means of transitioning to ODF is doomed. The Office 2.0 (er 3.0) crowd is at a similar disadvantage. They offer web based productivity services that leverage the incredible value of web collaboration. The problem is that these collaboration services are not interoperable with MSOffice. This disconnection greatly reduces and totally neutralizes the collaboration value promise. Microsoft of course will be able to deliver that same web based collaborative comp[uting value in an integrated package. They and they alone are able to integrate web collaboration services into existing MSOffice workgroups. In many ways this should be an anti trust issue. If governments allow Microsoft to control the interop channels into MSOffice, then Microsoft web collaboration systems will be the only choice for 550 million MSOffice workgroup users. The interop layer is today an impossible barrier for Office 2.0, Web 2.0, SaaS and SOA competitors. This is the reasoning behind our da Vinci CDF+ plug-in for MSOffice. Rather than continue banging the wall of IBM's transition to ODF through government legislated rip out and replace mandates, we think the way forward is to exploit the MSOffice plug-in architecture, using it to neutralize and re purpose existing MSOffice workgroups. The key is getting MSOffice documents into a web ready format that is useful to non Microsoft web platform (cloud) alternatives. This requires a non disruptive transition. The workgroups will not tolerate any loss of interop or functionality. We believe this can be done using CDF+ (XHTML 2.0 + CSS). Think of it as cutting off the transition of existing workgroup business p

Bingo!

Rather than replace MSOffice, why not move the desktop bound business processes to the web? Re write them to take advantage of web collaboration, universal connectivity, and universal interop.
Once the business processes are up in the cloud, you can actually start introducing desktop alternatives to MSOffice. The trick is to write these alternative business processes to something other than .NET 3.0, MS-OOXML, and the Exchange/SharePoint Hub.