Skip to main content

Popularity Report

Total Popularity Score: 0

Loading...
Loading...
Loading...
Loading...
Loading...
Loading...

Rank

URL Tag Cloud

Groups (2)

  • document-wars

    Document Wars

    8 members,364 bookmarks

    Document Wars covers the portable XML document battle between OpenDocument, Office Open XML, and CDF, the W3C's Compound Document Format. The relationship to the Grand Convergence of desktop, server, device and web systems will be decisive, with application independence and universal interoperabili

  • opendocument

    OpenDocument

    19 members,376 bookmarks

    A collection of comments and discussions concerning OpenDocument and the challenge presented by Microsoft's Office Open XML.

Bookmark History

Saved by 1 people (1 private), first by anonymouse user on 2007-11-19


Public Comment

on 2007-11-19 by garyedwards

Uh?  The ODF failure in Massachusetts doesn't count as evidence that ODF was not designed to be compatible with existing MS documents or interoperable with existing MSOffice applications?

And it's not just the da Vinci plug-in that failed to implement ODF in Massachusetts!  Nine months later Sun delivered their ODF plug-in for MSOffice to Massachusetts.  The next day, Massachusetts threw in the towel, officially recognizing MS-OOXML (and the MS-OOXML Compatibility Pack plug-in) as a standard format for the future.

Worse, the Massachusetts recognition of MS-OOXML came just weeks before the September 2nd ISO vote on MS-OOXML.  Why not wait a few more weeks?  After all, Massachusetts had conducted a year long pilot study to implement ODF using ODF desktop office sutie alternatives to MSOffice.  Not only did the rip out and replace approach fail, but they were also unable to integrate OpenOffice ODF desktops into existing MSOffice bound workgroups.

The year long pilot study was followed by another year long effort trying to implement ODF using the plug-in approach.  That too failed with Sun's ODF plug-in the final candidate to prove the difficulty of implementing ODF in situations where MSOffice workgroups dominate.

California and the EU-IDABC were closely watching the events in Massachusetts, as was most every CIO in government and private enterprise.  Reasoning that if Massachusetts was unable to implement ODF, California CIO's totally refused IBM and Sun's effort to get a pilot study underway.

Across the pond, in the aftermath of Massachusetts CIO Louis Guiterrez resignation on October 4th, 2006, the EU-IDABC set about developing their own file format, ODEF.  The Open Document Exchange Format splashed into the public discussion on February 28th, 2007 at the "Open Document Exchange Workshop" held in Berlin, Germany.

Meanwhile, the Sun ODF plug-in is floundering in Belgium and Denmark pilot trials now under way.

What Andy Updegrove needs to do is provide some evidence that it is possible to implement ODF where MSOffice workgroups rule.  Announcements of good intentions are starting to ring a bit hallow.  We need to see some successes.

There is another side to this problem.  For the past five years, the OASIS ODF Technical Commitee has brushed aside all efforts to improve ODF interoperability with Microsoft Office documents, applications and processes.  If ODF is the "single file format" solution IBM claims it to be, then someone is going to have to do something about the 550 million MSOffice desktop that cannot convert their documents, applications and processes to ODF without suffering intolerable fidelity loss and costly disruption to business processes.

Five years without interop progress between ODF and MSOffice is a bit much.  But now we have Sun's Simon Phipps suggesting that maybe this will challenge will be considered in ODF 1.3 or 1.5 (or why not ODF 12.3?)

Meanwhile, Sun continues to insist that ODF was not designed for interoperability with Microsoft documents and applications.  Therefore Sun argues, the world needs mulitple file formats, including ISO approval of MS-OOXML.

Don't believe me?  Check out the Sun ANSI - ISO vote in favor of MS-OOXML.  A vote they submitted with this comment from Sun's Jon Bosak:

We wish to make it completely clear that we support DIS 29500 becoming an ISO Standard and are in complete agreement with its stated purposes of enabling interoperability among different implementations and providing interoperable access to the legacy of Microsoft Office documents.”

The one thing we know for certain is that ODF cannot be implemented in workgroup environments driven by MSOffice.  So why not try converting existing MSOffice documents to CDF WICD Full? 

And who's the looney toon suggesting that someone is trying to use CDF WICD Full as a native file format for MSOffice?  The da Vinci Group believed it was possible to convert MSOffice documents to CDF WICD Full.  How is this different from an export from MSOffice to CDF WICD Full? 

The Foundation steps into the fray claiming that hey, if the da Vinci Group can convert MSOffice docuemnts to CDF WICD Full, then why not convert ODF documents to the same CDF profile?  At least at the web platform level much if not most of the current ODF interoperability problems will be lessened.  It's not a desktop application to desktop application play, but what's wrong with a web platform solution?  End users are going to end up there anyway.

As with any tempest in a teapot, it's the threat to big ego's with identities and purpose of being bound to ODF success as a universal file format that roils the waters.   Somebody somewhere has to put down the keyboard, step out of the blogoshpere, and start providing real world pragmatice solutions. Otherewise, those 550 million desktops will have no other choice but MS-OOXML going forward.

This isn't rocket science.  It's pragmatism in the face of mounting evidence that ODF was not designed to meet the needs of MSOffice workgroups needing to convert to XML.

~ge~


on 2008-05-30 by garyedwards

Marbux sets the record straight. These are the facts: Putting Andy Updegrove to Bed (without his supper) ..... http://www.universal-interop-council.org/node/4

Readers (0)