Group items tagged

Short slide deck of Barbara Held's February 28th, 2007 EU IDABC presentation. She introduces ODEF, the "Open Document Exchange Format" which is designed to replace both ODF and OpenOfficeXML. ComputerWorld recently ran a story about the end of ODF, as they covered the failure of six "legislative" initiatives designed to mandate ODF as the official file format. While the political treachery surrounding these initiatives is a story in and of itself, the larger story, the one that has world wide reverberations, wasn't mentioned. The larger ODF story is that ODF vendors are losing the political battles because they are unable to provide government CIO's with real world solutions. Here are three quotes from the California discussion that really say it all: "Interoperability isn't just a feature. It's the basic requirement for getting your XML file format and applications considered"..... "The challenge is that of migrating our existing documents and business processes to XML. The question is which XML? OpenDocument or OpenXML?" ....... "Under those conditions, is it even possible to implement OpenDocument?" ....... Bill Welty, CIO California Air Resource Board wondering if there was a way to support California legislative proposal AB-1668. This is hardly the first time the compatibility-interoperability issue has challenged ODf. Massachusetts spent a full year on a pilot study testing the top tier of ODF solutions: OpenOffice, StarOffice, Novell Office and IBM's WorkPlace (prototype). The results were a disaster for ODF. So much so that the 300 page pilot study report and accompanying comments wiki have never seen the light of day. In response to the disastrous pilot study, Massachusetts issued their now infamous RFi; a "request for information" about whether it's possible or not to write an ODF plugin for MSOffice applications. The OpenDocument Foundation responded to the RFi with our da Vinci plugin. The quick descriptio

Andy Updegrove weighs in on the wave of ODF legislative failures first decribed by Eric Lai and Gregg Keizer compiled the grim data in a story they posted at ComputerWorld last week titled  Microsoft trounces pro-ODF forces in state battles over open document formats.


Andy believes that it is the failure of state legislators to do their job that accounts for these failures.  He provides three reasons for this being a a failure of legislative duty.  The most interesting of which is claim that legislators should be protecting CIO's from the ravages of aggressve vendors. 


The sad truth is that state CIO's are not going to put their careers on the line for a file format after what happened in Massachusetts.


Andy puts it this way, "
  

And second, in a situation like this, it is a cop out for legislatures to claim that they should defer to their IT departments to make decisions on open formats.  You don't have to have that good a memory to recall why these bills were introduced in the first place: not because state IT departments aren't a good place to make such decisions, but because successive State CIOs in Massachusetts had been so roughly handled in trying to make these very decisions that no state CIO in his or her right mind was likely to volunteer to be the next sacrificial victim.
As both Peter Quinn and Louis Gutierrez both found out, trying to make responsible standards-related decisions whe

Another call for the "convergence" of ODF and MS-OOXML, this time from the government technology magazine, GCN.com.

IMHO, there is a very steep technical barrier to both the harmonization and/or convergence of ODF and OOXML. The problem is that these file formats are application specific and bound respectively to OpenOffice and MSOffice feature sets and implementation models. The only way to perfect a harmonization or convergence file format effort is to dramatically change the reference applications.

With over 500 million MSOffice workgroup bound desktops in the world, changing that suite of applications is likely to break business processes with a global disruption factor that is simply unacceptable. OpenOffice on the other hand could better sustain such the needed layout engine changes, but estimates it will take 3-5 years to accomplish this.

Sun has often stated at the OASIS ODF TC (technical committee) that OpenOffice will not be bound and limited by having to mirror MSOffice features and implementation models. These arguments are often called application innovation rights.

In the past year alone, there have been no less than five ODF iX "interoperability enhancement" proposals submitted to the OASIS ODF TC members for discussion. The iX proposals are designed to solve the problem of high fidelity "round trip" conversion of MSOffice binary and xml documents with OpenOffice ODF documents.

Sadly, Sun and the other ODF application vendors fought and thoroughly defeated every aspect of these proposals even though the first three iX proposals were signed off on by Massachusetts ITD, and considered vital to the successful implementation of ODF there. ODF of course proved impossible to implement in Massachusetts. And without the iX interoperability enhancements, it is impossible for ODF plug-ins for MSOffice to perfect the high fidelity "round trip" conversion of existing doc

Eric Lai keesp pokign at that Massachusetts hornets nest. One of these days he's going to crack it open, and it will be back to square one for the ODF Community.  Still missing from his research is the infoamous 300 page pilot study and accompanying web site where comments and professional observations document a year long study concernign the difficulties of implementing ODF solutions and making the migration.  <br><br>

The study was focused on OpenOffice, StarOffice, Novell Office, and a IBM WorkPlace prototype.<br><br>

The results of the year long pilot have never seen the public light of day.  But ComputerWorld is one of the media orgs that successfully filed a court action to invoke the freedom of information act in Massachusetts.  How come they can't find the Pilot Study?<br><br>

At the end of the pilot study period, Massachusetts issued their infamous RFi; the request for information regarding the possiblity of a ODF plugin for MSOffice!  Meaning, the Pilot Study did not go well for the heroes of ODF - OpenOffice, StarOffice, Novell Office and WorkPlace.  Instead, Massachusetts sought an ODF plugin that would no doubt extend the life of MSOffice for years to come.  No rip out and replace here folks!<br><br>

~ge~

So, South Africa was watching closely the failed effort in Massachusetts to implement ODF?  And now they are determined to make it work? Good thing they left themselves a "pragmatic" out; "there are standards which we are obliged to adopt for pragmatic reasons which do not necessarily fully conform to being open in all respects."

Massachusetts spent a full year on an ODF implementation Pilot Study only to come to the inescapable conclusion that they couldn't implement ODF without a high fidelity "round trip" capable ODF plug-in for MSOffice.  In May of 2006, Pilot Study in hand, Massachusetts issued their now infamous RFi, "the Request for Information" concerning the feasibility of an ODF plug-in clone of the MS-OOXML Compatibility Pack plug-in for MSOffice applications. At the time there was much gnashing of teeth and grinding of knuckles in the ODf Community, but the facts were clear. The lead dog hauling the ODf legislative mandate sleigh could not make it without ODf interoperability with MSOffice. Meaning, the rip out and replace of MSOffice was no longer an option. For Massachusetts to successfully implement ODf, there had to be a high level of ODf compatibility with existing MS documents, and ODf application interoperability with existing MS applications. Although ODf was not designed to meet these requirements, the challenge could not have been any more clear. Changes in ODf would have to be made. So what happened?

Over a year later,

Want to know the real reason why IBM and Microsoft are going at it hammer and tong over document formats?  Here it is.  Lotus Notes is getting clobbered by the Exchange/SharePoint juggernaut. 

The article is old, but the point is well taken.  Today the Exchange/SharePoint juggernaut i sover 65% marketshare.  IBM is struggling to protect the Lotus Stack against an impossible foe.

The thing is, Microsoft E/S will ALWAYS have better integration with the MSOffice - Outlook desktop monopoly base (550 M and counting).  Most of this "integration" is due to the high fidelity exchange of documents in Microsoft's proprietary XML mode known as MS-OOXML.   Forget the charade that MS-OOXML is an open standard called Ecma 376.  MSOffice and infamous XML Compatibility Pack Plug-in do not implement Ecma 376.  The Pack implements MS-OOXML.

One key differnece between MS-OOXML and Ecma 376 us that MS-OOXML is infused with the Smart Tags components.  These are for metadata, data binding, data extraction, workflow, intelligent routing and on demand re purposing of docuemnt components.  In effect, MS-OOXML :: Smart Tags combines with proprietary .NET Libraries, XAML and soon enough Silverlight to replace the entire span of W3C Open Internet Technologies. 

Can you say "HTML"?

Okay, so why does this matter to IBM and the future of Lotus Notes?

The end game of the document format wars is that of a stack model that converges desktop, server, devices and web information systems.  The MS Stack uses MS-OOXML as the primary transport of accelerated content/data/multi media streams running across the MS Stack of desktop, server, device and web application systems.  It's the one point of extreme interoperability.

It's also a barrier that no non MS applicatio or service can penetrate or interoperate with except on terms Microsoft dictates. 

Intriguing?  Rob Weir knows full well that the Foundation proposed this exact same feature set as part of the da Vinci Plug-in design for Massachusetts, July of 2006!!!!!!!!!

The Complete Feature list of the da Vinci plug-in for MSOffice that was proposed and signed off on by CIO Louis Gutierrez in early August of 2006 was well known by IBM's representatives who were working hand in hand with us at the time: Rob Weir, Don Harbison and Doug Heintzman. 

Louis Gutierrez had asked IBM and Oracle to create a "benefactors Group" to overcome the challenge that Massachusetts ITD did not have a budget.  IBM and Oracle selected Google, Sun, Novell, Intel, and Nokia as key benefactors.  The group was provided with the complete feature set and roadmap for da Vinci development. 

The da Vinci roadmap was the schedule announced by Louis Gutierrez in his mid year report, August 17th, 2006.

The da Vinci plug-in feature set, in order of priority, consisted of:
ODF iX Approval at OASISPlug-in for MS WORDAccessibility Interface for all ODF documents in MS WordPDF - ODF iX Digital Signature containerPlug-in for MS ExcelInteroperability Wizard for OpenOfficePlug-in for PowerPointXForms InterfaceThe roadmap we provided Louis and the "benefactors" was sceduled out with deliverables, test periods, and cost per deliverable.  The buy-in per "benefactor" was set at $350,000, and i

I've got to give this one extra points for creativity!  All anyone has to do is visit the W3C web sites for CDF WICD Full 1.0 to realize that there is in fact a CDf profile for desktops.  CDF WICD Mobile is the profile for devices.

My guess is that Chris Lilley is threading the needle here.  IBM, Groklaw, and the lawyer for OASIS have portrayed the Foundation's support for CDF WICD Full as a replacement for ODF - as in native file format for OpenOffice kind of replacement.  Mr. Lilley insists that CDF WiCD Full was not designed for that purpose.  It's for export only!  As in a conversion of native desktop file formats.

Which is exactly what the da Vinci group was doing with MSOffice.  The Foundation's immediate interest in CDF WICD was based on the assumption that a similar conversion would be possible between OpenOffice ODF and CDF WICD.

The Foundation's thinking was that if the da Vinci group could convert MSOffice documents and processes to CDF WICD Full, and, a similar conversion of OpenOffice ODF documents and processes to CDF WICD could be done, then near ALL desktop documents could be converted into a highly interoperable web platform ready format.

Web platform ready documents from OpenOffice?  What's not to like?  And because the conversion between ODF and CDF WICD Full is so comparatively clean, OpenOffice would in effect, (don't go native file format now) become ahighly integrated rich client end user interface to advancing web platforms.

The Foundation further reasoned that this conversion of OpenOffice ODF to CDF WICD Full would solve many of the extremely problematic interoperability problems that plague ODF.  Once the documents are in CDF WICD Full, they are cloud ready and portable at a level certain to diminish the effects of desktop applications specific feature sets and implementation models.

In Massachusetts, the Foundation took