Group items matching

in title, tags, annotations or url

An honest misunderstanding? Hardly! Play the tape! ... A response to David Berlind relating to false claims made by IBM and the W3C regarding direct correspondence concerning CDF being used as an interchange format. Instead of arguing about who said what when, let's just go to the record and see exactly what the W3C's Doug Schepers said to us in an eMail introducing himself. Keep in mind that we did not contact the W3C or Mr. Schepers. The following eMail was most welcome, but entirely unsolicited.

ODF was created on the principles that interoperability and innovation were paramount, and that these are based on open standards. Not coincidentally, ODF's creation coincided with the growing support of open ICT architectures, which grew from the Web model where the standardization of HTML, an open, royalty-free standard, enabled the Web to be an open platform that enabled much innovation on top of it. The key was interoperability, or the ability of multiple parties to communicate electronically, without the need to all run the same application software or operating system. Also critical to the development of ODF was the introduction of OpenOffice.org, the open source office suite that first implemented the format, and the rise of XML as a widely supported foundational standard for describing structured data.

This is the report John Cody worked on.  I spent four months answering his questions but was unable to adequately explain to him the difference between an "Office Suite" and a workgroup-workflow centric "Productivity Environment".   John insists that it's entirely possible to rip-out-and-replace the MSOffice editors with the free OpenOffice Suite without disrupting important workflows and business processes.  I explained to him what happened in Massachussetts, including the 300 page pilot study report Sam wrote.  What he needs to do i think is pay close attention to the Burton Group coverage of what is now known as the SharePoint Foundation platform;  SharePoint 2010 having totally swallowed the MSOffice 2010, leaving the venerable desktop productivity office suite as an important end user interface into information rich business systems centered on the SharePoint "Unified Productivity" platform.

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

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.

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

This is part of a series of talkback responses i had made to a ZDNet article, "Microsoft: We were railroaded in Massachusetts on ODF".  Andy Updegrove participated in this exchange.

My comment was picked up by the Heise in a FSF Free Software Foundation Europe article, "The Converter Hoax".

~ge~

Published May 22, 2007, this comment was written in the aftermath of List Enhancement Proposal donnybrook at the ODF OASIS TC.

It was at the height of our List Enhancement battle with Sun that OASIS stepped in their threat to boot the OpenDocument Foundation.  OASIS carried out that threat in May.  The lesson we learned is clear and unequivocal.  Opposition to Sun, in either the marketplace (da Vinci) or in the OASIS ODF TC, can be quite hazzardous to your health.

Not that this comes as any surprise.  Nearly five years ago in 2002, when i first joined OASIS to work on OpenDocument, it was clear that OASIS was a big vendor consortia.  While OASIS does have an affordable "Lawn Jockey" program, Sun is clearly calling all the shots on the OASIS ODF TC.  This is why ODF is bound so tightly to the OpenOffice feature set.

Still, we thought the "Lawn Jockey" loophole could be used to balance out the interests and control of the OASIS big vendors.  We were wrong.  And it took near five years for the obvious to finally sink.  Well, "sink in" thanks to the OASIS hammer and boot.

~ge~

Incredible comment by Marbux!  With one swipe he takes out both Ecma 376 and ODF. 

Microsoft has written a letter claiming that they will support ODF in MSOffice, but only if ISO approves Ecma 376 as a second office suite XML file format standard.  ODF was approved by ISO nearly a year ago.

Criticizing Ecma 376 is easy.  It was designed to meet the needs of  a proprietary application, MSOffice, and, to meet the needs of the emerging MS Vista Stack of applications that spans desktop to server to device to web platforms.  It's filled with MS platform dependencies that make it impossibly non interoperable with anything not fully compliant with Microsoft owned API's.

Criticizing ODF however is another matter entirely.  Marbux points to the extremely poor ODF interoperability record.  If MOOXML (not Ecma 376 - since that is a read only file format) is tied to vendor-application specific MSOffice, then ODF is similarly tied to the many vendor versions of OpenOffice/StarOffice.

The "many vendor" aspect of OpenOffice is somewhat of a scam.  The interoperability that ODF shares across Novell Office, StarOffice, IBM WorkPlace, Red Office, and NeoOffice is entirely based on the fact that these iterations of OpenOffice are based on a single code base controlled 100% by Sun.  Which is exactly the case with MSOffice.  With this important exception - MOOXML (not Ecma 376) is interoperable across the entire Vista Stack!

The Vista Stack is comprised of Exchange/SharePoint, MS Live, MS Dynamics, MS SQL Server, MS Internet Server, MS Grove, MS Collaboration Server, and MS Active Directory.   Behind these applications sits a an important foundation of shared assets: MOOXML, Smart Documents, XAML and .NET 3.0.  All of which can be worked into third party, Stack dependent applications through the Visual Studio .NET IDE.

Here are some thoughts i wou

Another good one from that all around funny guy and document processing expert extraordinaire, Florian Reuter.  This one is way too funny.  I hope the lord of the garage gestapo doesn't take him up on this.

Interesting observation about South Africa and their "free as in beer" software requirements.  This governement attitude towards open source is far more wide spread than commonly thought.  One would have hoped that interoperability and open standards were also part of the FOSS equation, but it looks like zero cost is the primary driver.

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,

The sad thing is that in early January of 2003, it was proposed that we start with a clean slate effort based on structural document generics instead of accepting the OpenOffice XML spec, and trying to strip out the application specific settings.  History will record that we accepted the OpenOffice XML spec, and were unable, after five years of effort (2002-2007) to clean things up.

Perhaps ODF was doomed almost from the start.  The UNiX suggestion is interesting if not an arrow through the core.

More great stuff from Michael Desmond

Now you're talking!

Interesting comment from Simon Phipps: maybe we'll see ODF interoperability in versions 1.3 or 1.5? Note to Simon: It's been five years now since owrk on ODF began! Why not do something about the piss poor ODF interop now? Do we really need to wait another five years? ODF interop problems can be fixed with a simple vote to change the wording in Section 1.5, the Compatibility Clause, from should to must. Today compliance is optional, and it's killing ODF!!!! And this clown says we were out of our depth? He's out there peddling zero interoperability amongst ODF ready applications, with over 550 million users unable to convert their billions MSOffice documents to ODF, and we're the ones out of our depth? Although ODF began a noble and honorable effort to gift mankind with an open universally interoperable XML strucutred format also application, platform and vendor independent, things have changed. The big vendors have taken over, and turned this once noble effort into a shameless marketing war that's invaded international politics as it has corrupted international standards orgs. Game Over! ~ge~

Interesting comment from Simon Phipps: maybe we'll see ODF interoperability in versions 1.3 or 1.5? Note to Simon: It's been five years now since owrk on ODF began! Why not do something about the piss poor ODF interop now? Do we really need to wait another five years? ODF interop problems can be fixed with a simple vote to change the wording in Section 1.5, the Compatibility Clause, from should to must. Today compliance is optional, and it's killing ODF!!!! And this clown says we were out of our depth? He's out there peddling zero interoperability amongst ODF ready applications, with over 550 million users unable to convert their billions MSOffice documents to ODF, and we're the ones out of our depth? Although ODF began a noble and honorable effort to gift mankind with an open universally interoperable XML strucutred format also application, platform and vendor independent, things have changed. The big vendors have taken over, and turned this once noble effort into a shameless marketing war that's invaded international politics as it has corrupted international standards orgs. Game Over! ~ge~