OpenDocument

An eWEEK must read.  I think the recent aquisition is having a positive impact on the eWEEK journalist and reporters.   What a great series they've put together on SOA. SaaS and the Web 2.0

The reason da Vinci was broke in Office 2007

Must read!  Must also keep private!

The title here has nothing to do with the content.  The original title is, "Politics is only a small part of this story". 

It's been a while since i last posted to the ZDNet TalkBack, and was totally thrown by the TalkBack formating needs.  My first post dropped all line breaks, and came out as one long run on sentence.

Now maybe that's the way i write, (and think), but at least with some formatting i can hide that fact!

Still, "Butcher This!" is not a bad title. 

~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~

I promise that within a few minutes of reading this OOXML Wiki you will be wondering if this is in fact an ODF Wiki!  This is incredible.

Fast forward to the section called, "Interoperability between ODF and OOXML", and enjoy.  They cite the problem and make an interop recommendation for each entry.  And what a recommendation it is.  Speaks volumes.

There is definately something going on in Europe.  The EU IDABC has rejected ODF, OOXML, OASIS, Ecma and ISO!  And are now trying to write their own highly interoperable XML file format, ODEF.  an effort we will fully support with our da Vinci plugin for MSOffice. 

Well, not only will we support ODEF, we'll write it for them if they really want to cut to the chase and get the kind of vendor independent interoperability the world hungers for.

The British Standards Institute (BSi) is responsible for the massive research that went into this OOXML Wiki.  They have hunted down and defined the interoperability problem areas between ODF and OOXML.  Surprise surprise.  They be many. 

The interesting part is that the BSi researchers have found massive, indeed overwhelming fault with OOXML!  Yet, instead of recommending that Ecma make the needed changes to OOXML, they instead recommend that ISO ODF make the changes!

Not OASIS ODF!  Not Ecma OOXML.

ISO ODf!

The difference is all the difference in the world.  Sun does not control ISO ODF the way they control OASIS ODF.   And at ISO, all the binding of ODF to OpenOffice/StarOffice that accounts for the zero interoperability of ODF applications can be broken as needed.

This is

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

Eben explains that the process behind the GPL3 is actually a newly christened collaborative legislation process that uniquely supercedes nations, treaties and the traditions of legialative law making.  He traces the evolution of the disemination of ideas. the protection of ideas, and the rise of digitized representation - computerized ideas.

It's a wonderfully sweeping speach that takes collaborative community possibilities far beyond the realm of software.  I'm left wondering if this same approach can be used to re invent the open standards process?   Just as big vendors have come to control and stifle innovation in software through the assertion of property ownership of mathmatical ideas, open standards are similarly under the command and control of these same big vendors. 

The GPL3 process may in fact be a model for a new open standards process.  And it comes non too soon!

~ge~

More on Andy UpDegrove's "Game Over for open standards" comment.

Andy UpDegrove takes on the issue of Microsoft submitting their proprietary "XML alternative to PDF" proposal to Ecma for consideration as an international standard.  MS XML-PDF will compliment ECMA 376 (OOXML - OfficeOpenXML) which is scheduled for ISO vote in September of 2007.  Just a bit over 60 days from today.

Andy points out some interesting things; such as the "Charter" similarities between MS XML-PDF and MS OOXML submisssions to Ecma:

MS XML-PDF Scope: The goal of the Technical Committee is to produce a formal standard for office productivity applications within the Ecma International standards process which is fully compatible with the Office Open XML Formats. The aim is to enable the implementation of the Office Open XML Formats by a wide set of tools and platforms in order to foster interoperability across office productivity applications and with line-of-business systems. The Technical Committee will also be responsible for the ongoing maintenance and evolution of the standard.   Programme of Work: Produce a formal standard for an XML-based electronic paper format and XML-based page description language which is consistent with existing implementations of the format called the XML Paper Specification,…[in each case, emphasis added]

If that sounds familiar, it should, because it echoes the absolute directive of the original OOXML technical committee charter, wh

This is the full response to Swapnil's seven questions.  It's long.  But we hold back nothing!  Thanks again to Marbux.  He is a peach!

This discussion is part of a much larger response to a series of questions from a LiNUX magazine in India.  The mighty Marbux helped answer the questions, so please don't mistake his eloquence for my customary thundering.

You have to read this!  Xandros is taking this interoperability garbage seriously!

Interesting topic which i've covered more fully with the OpenStack Blog : Connecting the Dots

Check out the comments below this article.  There are links to Ian Foster of Globus and to the Marbux license disseration posted with the OpenDocument Foundation's NO VOTE at OASIS.

This the infamous Microsoft letter that many have misconstrued as an announcement of support for OpenDocument.  Only in a Microsoft universe can the statement, "We're not going to attack ODF" be taken as Micrsoft support for ODF.

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

Whoa, Stepen Rodriguez knocks this one out of the park.  What an impressive dissembling of MS OfficeOpenXML and it's poor sister subset, Ecma 376.  Incredible.