Group items tagged

This article left me a bit confused. The author poses an important question about the next release of MSOffice; MSOffice 2010. Or what others have called MSOffice 11. The question is whether or not end users will buy into the new features, and continue on the upgrade treadmill as they have for the past 15 years or so. Strangely though, there is no discussion of the traditional factors binding end users to the upgrade treadmill. Things like ever changing formats, protocols and interfaces. Nor is there discussion as to the impact of marketplace demands that Microsoft comply with open standards; including open document exchange formats like ODF, OOXML and HTML+ (the advanced WebKit-Ajax document model).

The thing is, it's more than simple "inertia" that compels people to jump on the upgrade treadmill. The ODF pilot studies conducted in Massachusetts, California, Denmark and Belgium brought into sharp focus the difficulties workgroups have in replacing MSOffice. Years of client/server systems designed to run within the MSOffice productivity environment has left many a business process bound to the MSOffice suite of editors and the compound documents they produce.

I left my response in the reader feedback section of this CIO article.

".....In the past, the MSOffice upgrade treadmill was unavoidable due to the file format compatibility problem. As workgroups and business divisions purchased new computers with newer versions of MSOffice, resulting file format incompatibilities made workflow exchange of documents impossibly frustrating. Eventually, entire workgroups were forced into upgrading just to keep day to day business processes working....."

Marbux on metadata and the language of universal interoperability: Few people are aware of the raging debate that has pushed ODF to the edge. The OASIS ODF TC is split between those who support Universal Interoperability, and those who insist on continuing with limited ODF interoperability.

ODF (OpenDocument), formally known as Open Office XML, began it's standards life in the fall of 2002 when Sun submitted the OpenOffice file format to OASIS for consideration as a office suite XML fiel format standard. The work on ODF did not start off as a clean slate in that there were near 600 pages of application specific specification from day one of the standards work. The forces of universal interop have sought for years to separate ODF from the application specific features and implementation model of OpenOffice that began with those early specification volumes, and continues through the undue influence Sun continues to have over the ODF specification work.

Many mistakenly believed that submission of ODF to ISO and subsequent approval as an international standard would provide an effective separation, putting ODF on the track of a truly universal file format.

Marbux is one of those Universal Interop soldiers who has dug in his heels, cried to the heavens that enough is enough, and demanded the necessary changes to ODF interoperability language.

This post he recently submitted to the OASIS ODF Metadata SC is a devastating rebuttal to the arguments of those who support the status quo of limited interoperability.

In prior posts, marbux argues that ISO directives demand without compromise universal interoperability. This demand is also shared by the World Trade Organization directives regarding international trade laws and agreements. Here he brings those arguments together with the technical issues for achieving universal interop.

It's a devastating argument.

Dana Blankenhorn posted this article back in March of 2007.  It was right at the time when the OASIS ODF TC and Metadata XML/RDF SC (Sub Committee) were going at it hammer and tong concerning three very important file format characteristics needed to fulfill a real world interoperability expectation:

.... Compatibility - file format level interop -
:::  backwards compatibility / compatibility with existing file formats, including the legacy of billions of binary Microsoft documents

....... Interoperability - application level interop-
::::::  application interoperability including interop with all Microsoft applications

French experts have determined that it is technically possible to converge ODF and MS-OOXML, into a single, revisable document format standard?

The plan has four parts:

"Firstly, to restructure the ECMA standard in two parts so as to differentiate between, on the one hand, a core of essential and simple functionalities to be implemented (OOXML-Core) and, on the other hand, all the additional functionalities required for compatibility with the stocks of existing office document files created by numerous users, which will be gathered within a package called OOXML-Extensions."

"Secondly, AFNOR proposes to take into account a full series of technical comments submitted to the draft in order to make OOXML an ISO document of the highest possible technical and editorial quality."

"Thirdly, it proposes to attribute to OOXML the status of ISO/TS for three years."

Fourth, "Finally, AFNOR proposes to set up a process of convergence between ISO/IEC 26300 and the OOXML-Core. In order to achieve this, AFNOR will begin the simultaneous revision of ISO/IEC 26300 and of ISO/TS OOXML (subject to the latter being adopted after the aforementioned restructuring), so as to obtain the most universal possible single standard at the end of the convergence process. Any subsequent evolutions will be decided upon at ISO level and no longer at the level of such a group or category of players."




So there you go.  A solution that removes ODF and OOXML from the clam

Game Over?  Probably.  I've been expecting Massachusetts to publicly revise the ODF mandate to include OOXML ever since Louis Gutierrez resigned in early October of 2006.  That was as clear a signal that ODF had failed in Massachusetts as anyone needed.

The only surprise is that it took the new CIO, Beth Pepoli so long to make the announcement that OOXML would be recognized as an officially recognized open XML file format going forward.

Andy UpDegrove of course does his best to downplay the significance of this announcement.  But how can this not be the deathnell for ODF? 

The failure of ODF in Massachusetts has resulted in a world wide recognition that it is impossible to implement ODF. 

This is exactly what happened to ODF mandate legislature in California.  The CIO's in California uniformly rejected both ODF legislation and Sun's hapless effort to set up an ODF Pilot Study based on what had happened in Massachusetts.  If Mass couldn't implement ODF, than they saw no reason for them to try.

And it does come down to "implementation". 

Most people think the implementation of ODF is as easy as downloading OepnOffice and converting your legacy docuemnts to ODF as they are used.  Simply fix the artifacts of conversion in process, and never look back.  OOo is free.  So what's not to like?

Well, the problem is that the world has fifteen plus years of building business processes, line of business integrated applications and other client/server integration on top of the MSOffice application suite.  These business processes are bound hard to MSOffice.

So the barrier for OpenOffice and ODF is twofold.  Any implementation of ODF must overcome both the binary documents conversion barrier, and, the MSOffice bound business process barrier.

The cost and disruption of a <font

My response to Tiffany's eWEEK article, Office file formats fail to communicate, and the GCN article, Can't we just get along?. good articles both.
My comments are the first time i've responded directly to Sun's proprietary eXtensions allegation. The truth is that we refused to release the da Vinci plug-in with the must have iX "interoperability enhancements". Sun of course totally opposed our iX proposals, insuring that ODF would fail in Massachusetts, California, Denmark, Belgium and with the EU-IDABC.
Nice work Sun! Yeah, that's the ticket. Limit ODF's interoperability so much so that it is impossible to implement ODF, and the world willl beat a path to your door.
Right!
~ge~ ~ge~

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

Who knew?  :)

Hey buddy can you spare me a garage?

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 fl

More bad information, accusations and smearing innuendo.  Wrong on the facts,  Emotionally spent on the conclussions.  But wow it's fun to see them with their panties in such a twist.

The truth is that ODF is a far more "OPEN" standard than MS-OOXML could ever hope to be.  Sam's Open Standards arguments for the past five years remain as relevant today as when he first started makign them so many years ago.

The thing is, the Open Standards requirements are quite different than the real world Implementation Requirements we tried to meet with ODF.

The implementation requirements must deal with the reality of a world dominated by MSOffice.  The Open Standards arguments relate to a world as we wish it to be, but is not.

It's been said by analyst advising real world CIO's that, "ODF is a fine open standards format for an alternative universe where MSOffice doesn't exist".

If you live in that alternative universe, then ODF is the way to go.  Just download OpenOffice 2.3, and away you go.  Implementation is that easy.

If however you live in this universe, and must deal with the impossibly difficult problem of converting existing MSOffice documents, applications and processes to ODF, then you're screwed. 

All the grand Open Standards arguments Sam has made over the years will not change the facts of real world implmentation difficulities.

The truth is that ODF was not designed to meet the real world implmentation requirements of compatibility with existing Microsoft documents (formats) and, interoperability with existing Microsoft Office applications.

And then there are the problmes of ODF Interoperability with ODF applications.  At the base of this problem is the fact that compliance in ODF is optional.  ODF applications are allowed to routinely destroy metadata information needed (and placed into the markup) by other applications.<b