Garyedwards's Favorite Links on opendocument from Diigo

Wizard of ODF: The Foundation on Interop and the List Proposal Vote Deadline

Fri, 30 May 2008 21:08:33 -0000

If ever there was a discussion thread of consequence at the OASIS ODF TC, the "Enhanced List Proposal" donnybrook is it. This is where the ODF interoperability nightmare burst into the daylight of a showdown vote. The interop issues were clear. OpenDocument TC members voted between interoperability and/or application specific innovation. Application specific innovation trumped interoperability. Again.

And what a sad day it was. The thing is, the recent ECIS antit trust action against Microsoft comes at the request of IBM and Sun. They allege that Microsoft is violating standards requirements for interoperability, and has launched a series of corrupt activities to push through a non interoperable standard. They are right. Microsoft is guilty. The problem is that Microsoft can easily point to Sun and IBM activities at OASIS ODF, and make the same allegation! Using this thread as evidence!\n\nFurthermore, this thread is evidence that if Microsoft had tried to implement ODF, their efforts to establish interop would have been met with the same response from IBM and Sun that the OpenDocument Foundation received. Or so they could argue.

Houston, we have a problem.

IBM and Sun could have fixed the ODF interop problems at any time during the past five years. Yet, the world is waiting. Meanwhile, this will full negligence and lack of desire to address pressing market needs for full interop has served to hold the door open for OOXML. And now these negligent acts look to be the basis of a Microsoft counter claim.

Oh well ..

Highlights and Sticky Notes:

Oh, my. Both IBM and Sun voted for the proposal that broke the Foundation's plugin that was going to add full-fidelity native ODF file support to Microsoft Office. So it's sounding to me like at least two of the TC members who voted for the Sun/KOffice proposal didn't check in with the ECIS lawyer before they broke interoperability with Microsoft Office. Do you think Microsoft won't use this evidence in the DG Competition antitrust proceeding, Michael? Let's see, you guys are prosecuting Microsoft for not supporting ODF in Microsoft Office while you block Microsoft Office from supporting ODF. Yeah, I think DG Competition is going to hear about this one from Microsoft. They'll probably hear about what you said about compatibility being a trade off too. Oh, yeah. Microsoft's lawyers are going to love this. Look at the ECIS public statement about interoperability's importance.

Tags: ECIS anti-trust foundation odf ooxml

Posted by: garyedwards

Open Malaysia: Geneva, Day Five

Mon, 03 Mar 2008 23:11:07 -0000

Highlights and Sticky Notes:

We eventually found out that if any changes affected current implementations it would certainly be rejected. This seriously compromised any elegant solutions, and it forced us to be mindful of the "existing corpus of documents" in the wild. I personally don't believe that that should be our problem, but there was a large and vocal voting bloc which would oppose any changes to the spec which would 'break' Ecma 376.

This was why appeasing Ecma had to happen. Even though they rushed their Ecma International Standard, and Microsoft took the risk in shipping Microsoft Office 2007 last year, we now have to bear the burden of having to support its limitations. This also means that future maintenance changes would get harder and harder.

Tags: BRM Geneva ISO odf ooxml

Posted by: garyedwards

Google: OOXML 'insufficient and unnecessary' - marbux - ge comments | ZDNet UK

Fri, 29 Feb 2008 08:52:35 -0000

Highlights and Sticky Notes:

Google's technical analysis of the OOXML specification — which notoriously runs to 6,000 pages of code, compared with ODF's 860 pages — has led the company to believe that "OOXML would be an insufficient and unnecessary standard, designed purely around the needs of Microsoft Office", Bhorat claimed.

ODF and OOXML are standards in... Marbux

Tags: google interop odf ooxml opendocument

Posted by: garyedwards

ODF and OOXML are standards in name only - Google: OOXML 'insufficient and unnecessary' - Talkback at ZDNet UK

Fri, 29 Feb 2008 08:27:41 -0000

Highlights and Sticky Notes:

Both ODF and OOXML flunk that test badly. Their interoperable implementation neither has nor can be demonstrated. Both are designed for the waging of feature wars, not for interoperability. Both attempt to legitimize market-leading companies embracing and extending their own formats. They are standards in name only. What we are watching is a contest to decide which big vendor formats will be allowed to undeservedly claim the title of "international standard."

Tags: BRM ISO google interop marbux

Posted by: garyedwards

ODF useless for Microsoft needs - Google: OOXML 'insufficient and unnecessary' - Talkback at ZDNet UK

Wed, 27 Feb 2008 19:31:18 -0000

Highlights and Sticky Notes:

ODF's limited spec can't support all MS Office features unless Microsoft goes on a major entending trip.

Tags: embrace-extend google harmonization odf ooxml

Posted by: garyedwards

A Savage Journey … ODF at the OOXML BRM « A Frantic Opposition

Tue, 26 Feb 2008 17:32:22 -0000

Highlights and Sticky Notes:

A Savage Journey …

‘Erupting from my vivid nightmares into the retro 80s faded luxury of a five-star hotel in Geneva, the pictures of the first victim reappeared on the wall. The head of the Brazilian delegation-it’s only a matter of time now.

My mind thrashes to disentangle the thrown spaghetti threads of blurred reasoning; who’s next, is it just the heads of delegation they are after, any NB member, P-members only?

The fog lifts and it’s worse. Who is behind this, them or us? We outnumber them, but maybe their plan is more devious. Must find Bonky Bob, he’ll know what to do.’

Enough levity for now. The BRM has held few surprises, other than the rather galling situation where I was forced to publicly toe the INCITS line by the temporary head of delegation, a Microsoft employee, against my better judgement.

Tags: brm ecma geneva iso odf

Posted by: garyedwards

Compound Document Formats Group Charter

Sun, 10 Feb 2008 20:14:41 -0000

The W3C CDF Charter written in 2004

Highlights and Sticky Notes:

be widely implementable in browsers and authoring tools

Tags: cdf da-vinci foundation opendocument w3c

Posted by: garyedwards

Harmonizing ODF and OOXML using NameSpaces | Tim Bray's Thought Experiment

Sat, 09 Feb 2008 22:17:12 -0000

Tim Bray suggests using namespaces to brdige the comatibility gap between ODF and OOXML.

Highlights and Sticky Notes:

First, what if Microsoft really is doing the right thing? Second, how can we avoid having two incompatible file formats? [Update: There’s been a lot of reaction to this piece, and I addressed some of those points here.]

On the technology side, the two formats are really more alike than they are different. But, there are differences: O12X’s design center, Microsoft has said repeatedly, is capturing the exact semantics of the billions of existing Microsoft Office documents. ODF’s design center is general-purpose reusability, and leveraging existing standards like SVG and MathML and so on.

OOXML, or to put it more accurately "O12X" as Tim suggests, is designed to capture the exact semantics of MSOffice 12. In fact, OOXML is an XML encoding of the MSOffice 12 in-memory-binary-representation dump. When it comes to representing older versions of MSOffice documents, OOXML must use legacy compatibility settings" to capture the semantics. And it's not an exacting science to say the least.

The thing is, OpenOffice ODF uses the same technique resulting in application specific ODF documents with over 150 un docuemnted, unspecified "compatibility settings". After years of requests from the OASIS ODF Technical Committee to document these application specific settings, Sun has yet to provide any kind of response. And this kills ODF interoperability. Especially concerning KOffice.

There is also the issue of OASIS ODF high-jacked namespaces. When ODF applications reference a namespace, the actual URL is high-jacked with http://oasis-open.org/???? replacing the proper namespace of http://W3C.org/????

This high-jacking impacts the oDF reuse of important W3C technologies such as XForms, SVG, MathML, and SMiL.

So where's the problem you ask? Well, when a developer imports or tries to process an OpenOffice ODF document, they rely on say the W3C XForms specification for their understanding. OpenOffice however seriously constrains the implementation of XForms, SVG, MathML, RDFa and RDF/XML. This should be reflected in the new namespace. However, if you follow the high-jacked URL, you'll find that there is nothing there. There is no specification describing how OpenOffice implements XForms in ODF! This breaks developer libraries, breaks ODF interoperability between ODF applications, and, offends the W3C to no end.

So i think it might be fair to say that at this point, neither ODF or OOXML have come close to fulfilling their design objectives.
posted by garyedwards

The capabilities of ODF and O12X are essentially identical for all this basic stuff. So why in the flaming hell does the world need two incompatible formats to express it? The answer, obviously, is, “it doesn’t”.

Exactly!! Except for one thing that Tim misses: the presentation layers of both ODF and OOXML are application specific. It is also the application specific nature of OpenOffice ODF presnetation layer that prevents interoperability with KOffice ODF!

There is near zero interop between OpenOffice and KOffice, and KOffice has been a contributing member of the OASIS ODF TC for FIVE YEARS!

It's the presentation layer Tim. ODF and OOXML are application specific formats because their presentation layers are woefully applicaiton specific and entirely reflective of each applications layout engine and feature set implementation model.

I often imagine what ODF would be like if back in 2001, Sun had chosen to implement CSS as the OpenOffice presentation layer instead of the quirky but innovative, and 100% application specific automatic-styles presentation layer we now see in ODF.

Unlike ODF's "automatic-styles", CSS is a totally application independent presentation model prized exactly for it's universal interoperability!
posted by garyedwards

The ideal outcome would be a common shared office-XML dialect for the basics—and it should be ODF (or a subset), since that’s been designed and debugged—then another extended vocabulary to support Microsoft features , whether they’re cool new whizzy features or mouldy old legacy features (XML Namespaces are designed to support exactly this kind of thing). That way, if you stayed with the basic stuff you’d never need to worry about software lock-in; the difference between portable and proprietary would be crystal-clear. And, for the basic stuff that everybody uses, there’d be only one set of tags.

This outcome is technically feasible. Who could possibly be against it?

Bingo! ODF and OOXML should strip off the application specific complexities and seek a neutral generic XML representation of basic document structures common to ALL documents. Then, use the XML NameSpace mechanism to extend (with proper descriptions) the generic to include the volumes of application specific features that now fill each format.

One thing i disagree with Tim about. And that's that the interop of ODF and OOXML is hopelessly broken. The OpenDocument Foundation tried for over a year to close the compatibility gap between ODF and MSOffice binary - xml documents. The OASIS ODF TC would have none of it. IBM and Sun are set on a harsh course of highly disruptive and costly rip-out-and-replace of MSOffice based on government mandates for ODF. There is no offer of compromise to be had.

On the Microsoft side, even if they did want to compromise (a big IF), there is that problem of over 550 million MSOffice workgroup-workflow desktops to contend with. The thing is, the only way to harmonize, merge, convert or translate between two application specific formats is to actually harmonize the applications themselves. While the generic subset is a worthy goal, the process would be fraught with real world concerns that the existing application workflows are not disrupted.

My proposal? Demand that ODF and OOXML application vendors provide format options for PDF, and the W3C's family of formats: (X)HTML5, (X)HTML - CSS, and CDF (XHTML-CSS-XForms-SVG-SMil-MathML). That will do it.

We might never see the quality of interoperability we had hoped for in a desktop application to application scenario. But we can and should fully expect high quality interop at the higher level of the Web. You can convert an application specific format to a generic like CDF. By setting up conversion channels to the same CDF profile within MSOffice, OpenOffice, KOffice, Symphony, and Google Docs, we can achieve the universal interoperability we had hoped to see but will never get from ODF and OOXML.

Works for me!
posted by garyedwards

Tags: bray florian-reuter namespaces odf ooxml

Posted by: garyedwards

Wizard of ODF: Proposal to amend TC charter, re interoperability with non-conformant ap

Sat, 09 Feb 2008 06:30:38 -0000

The marbux proposal to ammend the ODF charter to include interoperability with MSOffice

Highlights and Sticky Notes:

7. it must provide all feasible functionality required to suppport full fidelity conversions from and to existing office document binary file formats.

Tags: OASIS harmonization interop interoperability odf

Posted by: garyedwards

The Case for Harmonization (that IBM will vote against anyway) « A Frantic Opposition

Sat, 09 Feb 2008 04:30:26 -0000

This very funny satire builds on some harsh realities. The ODF chickens have come home to roost, and it isn't pretty. Very funny, yes. But not pretty for those who continue to believe that somehow ODF is a standard worthy of their support.

The flip side of the coin is that using the same critieria of interoperability, OOXML is worthless. The sad truth is that both ODF and OOXML are applicaiton specific formats that will continue to defy and defeat all efforts at interoperability. Inparticular, it's the presentation layers of ODF and OOXML that remain bound to the layout engines and feature sets of their originating applications.

Just as the presentation layers defy interoperability, they will also defeat harmonization. The only way to harmonize two application specific formats is to harmonize the originating applications. And Microsoft, Sun and IBM are not about to do that.

The links in this satire are stunning!!! They shout loudly as to how Microsoft is going to respond to the ECIS anti trust allegations. So when you stop laughing, make certain you track down the links and read through the various OASIS ODF archive threads. IBM and Sun had their chance to fix ODF interoperability. Now it may be too late.

Highlights and Sticky Notes:

The Case for Harmonization (that IBM will vote against anyway)

In my recent post, I discussed the case for harmonization, mainly due to trying to portray a more kindly, conciliatory face in the “standards krieg” that I was enjoying so much. I have been forced to take a different tack, in light of being hung out to dry by my more business-focused IBM comrades and the work that the enemy has done in sprucing up the spec. However, as my closest friends know, for me, there are no half-victories, so you can rest assured that I will not settle for this weak “harmonization” compromise. I set out my (and IBM’s) stall some time ago on this, and as those on the Open Document Foundation know, any attempt at harmonization shall be met with swift and final retribution. They were ejected from the odf-coven just days after their impudence. I have baited my trap, inviting this “harmonization” in my lair (the OASIS ODF TC) where I can bog them down in a morass of incompetence, bickering and politicking, so no new standard is ever ratified. I have already been practicing for this, as you can see, by the ODF 1.1 and 1.2 specs.

Tags: foundation harmonization interop oasis odf

Posted by: garyedwards

Calling all black helicopters! This is a red alert. The OpenDocument Foundation suspected of interfering with Roy's tin foil hat reception!

Thu, 07 Feb 2008 21:30:25 -0000

Yo Marbux! Fire up the Black Hawk! They want us. They need us. Without the big bad bogey man, lurkign in the shadows, secretly conspiring against them, who will they blame their failures on?

Highlights and Sticky Notes:

Be aware that Gary Edwards and Marbux (of the organisation formerly known as “The OpenDocument Foundation” [1, 2]) have begun submitting links to their new site. They use Digg where they post elaborate comments about a decoy, a distraction. They comment on each other’s submissions, which are barely receiving any attention at all. The OpenDocument Foundation’s Web site has meanwhile become a link farm (inactive) with many inbound links. This is not very ordinary.

“At times, however, new people are introduced to intervene and create tensions, misunderstandings, and civil wars.”

Tags: odf ooxml opendocument opendocument-foundation openxml

Posted by: garyedwards

Word of recognition from an unexpected side: ODF editor Patrick Durusau supports OOXML - ISO effort

Thu, 07 Feb 2008 19:04:16 -0000

Patrick Durusau, the OASIS ODF editor has written an open letter praising the OOXML standardization effort at Ecma and ISO. Patrick is a long time member of ISO JTCS1, currently serving as the ODF editor for both ISO and OASIS ODF efforts. That his endorsement of OOXML comes on the eve of the critically important February BRM is beyond incredible. 

Jesper offers this quote which i think adequately summarizes Patrick's endorsement:

The OpenXML project has made a large amount of progress in terms of the openness of its evelopment. Objections that do not recognize that are focusing on what they want to see and not what is actually happening with OpenXML"

Highlights and Sticky Notes:

The OpenXML project has made a large amount of progress in terms of the openness of its evelopment. Objections that do not recognize that are focusing on what they want to see and not what is actually happening with OpenXML

Tags: BRM Durusau ISO OASIS odf

Posted by: garyedwards

The ODF Alliance puckers up and gets smacked with the CSS question - Where is it? | O'Reilly XML Blog

Wed, 06 Feb 2008 08:52:02 -0000

MS-OOXML supporter Rick Jellife discusses the ODF Alliance response to Ecma's proposed disposition of ISO NB comments on OOXML. The Allaince response has recieved quite a bit of ink, wtih waves of ODF jihadists pointing to it as incontroverible evidence that they are right. Rick provides a lengthy response, most of which presents the ODF jihadis with some difficult issues they must now explain.

More importantly though, RJ uncovers one of the more glaring examples proving that ODF is application specific to the core, and bound to OpenOffice. He points out that OpenOffice ODF could have chosen the W3C's highly portable and infinitely interoeprable CSS as the ODF presentation layer. This would have been a great reuse of existing standards. But that's not what happened!

Instead of the widely used CSS, OpenOffice chose an incredibly application specific presentation model with the unique innovation of "automatic-styles". And with this choice came years of problematic zero interop as application after application try to exchange ODF documents with little success.

Take for example KDE-KOffice. They've been a member of the OASIS ODF TC for near five years now, almost since the beginning. Yet it's impossible to exchange all but the most basic of documents with any of the OpenOffice derivaties (OpenOffice, StarOffice, Novell Office, and Lotus Symphony - OOo 1.1.4).

If after five years of active particpation and cooperative efforts, KOffice is unable to exchange ODF docuemnts with OpenOffice, how is it that somehow Microsoft Office would be able to implement ODF without similar zero interop results? Isn't the purpose of standardized formats that end users of different applications could effectively exchange documents?

The truth is that both ODF and OOXML are application specific formats. And you can't harmonize, merge, map, or translate between two application specific formats without also having harmonized the applications.

Fear not though. It is possibl

Highlights and Sticky Notes:

Harmonisation

It is interesting that the ODF Alliance quotes Tim Bray that the world doesn’t need another way to express basic typesetting features. If it is so important, why didn’t ODF just adopt W3C CSS or ISO DSSSL conventions? Why did they adopt the odd automatic styles mechanism which no other standard uses? Now I think the ODF formating conventions are fine, and automatic styles are a good idea. But there is more than one way to make an omlette, and a good solution space is good for users.

My perspective is that harmonisation (which will take multiple forms: modularity, pluralism, base sets, extensions, mappings, round-trippability, feature-matching, convergence of component vocabularies, etc, not just the simplistic common use of a common syntax) will be best achieved by continued user pressure, both on MS and the ODF side, within a forum where neither side can stymie the legitimate needs of other.

Tags: harmonization hypocrisy interop iso odf

Posted by: garyedwards

Putting Andy Updegrove to Bed (without his supper) | Universal Interoperability Council

Wed, 06 Feb 2008 03:53:47 -0000

Great article from the Universal Interoperability Council arguing the case for CDF as a universally interoperable format capable of fully representing desktop productivity environment documents. The UIC arguments are of course opposed by IBM and the lawyer for OASIS, Andy Updegrove.

Highlights and Sticky Notes:

In late 2007, an article by OASIS attorney Andy Updegrove claimed that W3C Compound Document Formats: [i] are non-editable formats; [ii] are not designed for conversions to other formats; and [iii] are therefore unsuitable as office formats. Updegrove could not have been more wrong.

But unfortunately, the erroneous Updegrove article was widely publicized by the usual occupants of the IBM cheering section⁽¹⁾ in the stadium where the latest big vendor game for the Incompatible File Format Cup is being played, IFFC Games Stadium.

Tags: IBM OASIS cdf interop odf

Posted by: garyedwards

Harmonization and Interop: The dizzying dance of ODF, OOXML, and CDF

Wed, 06 Feb 2008 03:49:40 -0000

Will the real universal document format please stand up! Comments on the recent article posted by the Universal Interoperability Council: "Putting Andy Updegrove to bed without his supper".

The UIC article is well worth your time. It is extremely well referenced and researched. The arguments put forth counter claims by IBM and OASIS that the W3C's CDF format can not be used to represent desktop productivity environment documents. Not surprisingly, IBM and OASIS argue that the OpenOffice specific ODF is the only alternative to Microsoft Office specific OOXML.

The UIC argues that the full range of MSOffice legacy binary documents and emerging XML documents can fully be represented in CDF - something that not even the most ardent of ODF jihadists would claim as an ODF capabilitiy. The truth is that ODF was not designed for the conversion of MSOffice binary and xml documents.

Highlights and Sticky Notes:

With the ISO BRM fast approaching, the harmonization of ODF and OOXML is all the rage. The legendary marbux takes on this discussion arguing that ODF and OOXML both lack the interoperability framework needed to meet ISO directives describing interop requirements. He argues that interop between MSOffice and OpenOffice can be achieved using CDF.

Tags: IBM OASIS UIC W3C cdf

Posted by: garyedwards

Harmonization Wars : Is it jetlag? | Brian Jones: Open XML- Open Document Formats

Fri, 01 Feb 2008 19:50:41 -0000

Brian Jones responds to Rob Weir's very strange demand that he be put in charge of any harmonization effort involving ODF and OOXML. 

In his response, Brian points to the Ecma official statement in support of harmonization provided in February of 2007. The harmonization response was directed at ISO National Body members objecting to the proposed fast tracking of OOXML. 

In late February -early March of 2007, the EU held an "interoeprability Workshop" in Berlin, Germany.The session was attended by IBM, Sun and Microsoft, as well as Ecma and OASIS. 

The EU took a very hard line position on "harmonization", embracing a position put forward by the French ISO NB group known as AFNOR. The WorkShop was followed by the EU establishment of DIN Workgroup NIA-01-34, headed by the Fraunhoffer Fokus Institute. 

The DIN WG sent out invites to all the major players, with Microsoft and Novell accepting the invitation to particpate in the harmonizatioon effort. IBM and Sun refused the invitation. 

Recently DIN invited the OASIS ODF Technical Committee to join the harmonization effort. The OASIS TC responded by asking Novell developer (and DIN participant) Florian Reuter to act as liaison to DIN. ODF grand puba Rob Weir himself put forward this request. 

Here's the thread:
http://www.oasis-open.org/archives/office/200801/msg00040.html
 
Now it looks like the grand puba is backtracking! Rob Weir wants to put himself in charge of harmonization. And we all know where that would lead. 

Harmonization will be difficult. It might even be impossible. As indicated by the Ecma statement Brian copiies in his post. 

The dynamics of harmonization are fairly simple to understand; you can't harmonize two application specific formats without also harmonizing the applications. This problem is further complicated by the fact that the presentation layers (styles) of both ODF and OOXML are woefully underspecified. While ea

Highlights and Sticky Notes:

if you actually read the Ecma response, you'll see that TC45's position is actually quite the opposite. Harmonization is not as simple as just adding a few tags here and there. It's going to be a lot of hard work, and the German Standard Body (DIN) is already working on the first step, which is to identify the differences. This isn't something to take lightly.

Here is Ecma's full response to this issue (emphasis added):

There are currently several XML-based document formats in use, each designed to address a different set of goals or requirements. These include ISO/IEC IS 26300 (ODF), China's UOF, and ECMA-376 (DIS 29500 – Open XML). All these formats have numerous implementations in multiple tools and multiple platforms (Linux, Windows, Mac OS, hand-held devices).

The Ecma Response Document from the Fast Track 30-Day contradiction phase for DIS29500 addressed the question of harmonization by explaining the differences between the ODF and Open XML formats as follows:

Tags: harmonization jones odf ooxml opendocument

Posted by: garyedwards

What IBM VP Bob Sutor does not want you to read | Universal Interoperability Council

Fri, 01 Feb 2008 08:49:24 -0000

Highlights and Sticky Notes:

What IBM VP Bob Sutor does not want you to read

Submitted by marbux on Thu, 01/31/2008 - 23:36.

This site is now live, although there's a ton of customization and configuration work to be done. But we might as well kick off by reprinting a comment I unsuccessfully attempted to post on IBM vice president Bob Sutor's blog today.

I'm flattered that my post was the apparent triggering event for Sutor's announcement later in the day that he will now only allow comments from people who use their "real names."

Tags: ecma harmonization ibm interoperability iso

Posted by: garyedwards

ODF and OOXML - The Final Act

Thu, 31 Jan 2008 02:08:16 -0000

Comments:

Correcto mundo! There should be only one standard to maximise interoeprability and functionality. But ODF is application specific to the way OpenOffice works. It was not designed from a clean slate. Nor was the original 2002 OpenOffice XML spec designed as an open source effort! Check the OOo source code if you doubt this claim. The ONLY contributors to Open Office XML were Sun employees!

What the world needs is in fact a format standard designed to maximise interoperability and functionality. This requires a total application-platofrm-vendor independence that neither ODF or OOXML can claim.

The only format that meets these requirements is the W3C's family of HTML-XML formats. These include advancing Compound Docuemnt Framework format components such as (X)HTML-5, CSS-3, XForms, SVG and SMiL.. The W3C's CDF does in fact meet the markeplace needs of a universal format that is open, unencumbered and totally application, platform and vendor independent. The only trick left for CDF is proving that legacy desktop applications can actually implement conversions from existing in-memory-binary-representations to CDF without loss of information.
posted by garyedwards

Highlights and Sticky Notes:

The format war between Microsoft’s Open Office XML (OOXML) and the open source OpenDocument Format (ODF) has flared up again, right before the looming second OOXML ISO vote in March.

“ISO has a policy that, wherever possible, there should only be one standard to maximise interoperability and functionality. We have an international standard for digital documentation, ODF,” IBM’s local government programs executive Kaaren Koomen told AustralianIT.

ODF has garnered some criticism for being a touch limited in scope, however, one of its strengths is that it has already been accepted as a worldwide ISO standard. Microsoft’s format on the other hand, has been criticised for being partially proprietary, and even a sly attempt by the software giant to hedge its bets and get in on open standards while keeping as many customers locked into its solutions as possible.

A "touch limited in scope"? Youv'e got to be kidding. ODF was not defined to be compatible with the billions of MSOffice binary (BIN) documents. Nor was it designed to further interoperability with MSOffice.

Given that there are over 550 million MSOffice desktops, representing upwards of 95% of all desktop productivity environments, this discrepancy of design would seem to be a bit more than a touch limited in scope!

Many would claim that this limitation was due to to factors: first that Microsoft refused to join the OASIS ODF TC, which would have resulted in an expanded ODF designed to meet the interoperability needs of the great herd of 550 million users; and second, that Microsoft refused to release the secret binary blueprints.

Since it turns out that both IBM and Sun have had access to the secret binary blueprints since early 2006, and in the two years since have done nothing to imptove ODF interop and conversion fidelity, this second claim doesn't seem to hold much water.

The first claim that Microsoft didn't participate in the OASIS ODF process is a bit more interesting. If you go back to the first OASIS ODF Technical Committee meeting, December 16th, 2002, you'll find that there was a proposal to ammend the proposed charter to include the statemnt that ODF (then known as Open Office XML) be compatible with existing file formats, including those of MSOffice. The "MSOffice" reference was of course not included because ODF sought to be application, platform and vendor independent. But make no mistake, the discussion that day in 2002 was about compatibility and the conversion of the legacy BIN's into ODF.

The proposal to ammend the charter was tabled. Sun objected, claiming that people would interpret the statement as a direct reference to the BIN's, clouding the charter's purpose of application, platform and vendor independence. They proposed that the charter ammendment be taken up a later time after the OASIS TC members had had a chance to read through the Open Office XML specification proposal.

Later attempts to change the charter (and the specification) to recognize the marketplace needs of compatibility with the BIN's were defeated. These issues came to a head when Massachusetts passed an ODF mandate, and was unable to implement ODF exactly because they couldn't convert existing documents, applications and business processes to an ODF based footing. This in turn lead to a major push within the OASIS ODF TC to ammend the specification and charter. If the compatibility - interoeprability problems with legacy desktop systems could not be resolved, there was no way ODF could succeed in Massachusetts.

That would of course leave the door open for OOXML and the OOXML plug-in for MSOffice as the only means of Massachusetts moving to a highly structured XML document footing. Massachusetts needed to get their desktop documents, applications and business processes into some form of useful XML before they could push forward with their SOA-SaaS-Web 2.0 enterprise infrastucture initiatives.

Between July 12th of 2006, and February 20th of 2007, there were six proposals submitted to the OASIS ODF groups designed to improve ODF compatibility - interoperability with the legacy desktops. Six different proposals! And not one survived the OASIS ODF discussion process.

One last point. The German DIN group was authorized by the EU to write a report for ISO concerning the prospects of harmonizing ODF and OOXML. DIN invited all the players with Microsoft and Novell accepting the challenge, and the ODF contingent led by IBM and Sun refusing to participate. The OASIS ODF TC was also inviited, but so far has waffled and stuttered even thoguh a number of meetings have already been held.

Given this past history, is it reasonable to assume that the OASIS ODF TC would have cooperated with Microsoft at any time in the past five years? There simply isn't any evidence to support claims that the ODF TC supports marketplace needs of compatibility - interoeprability. The evidence is quite to the contrary. And it's substantial.

posted by garyedwards
Will harmonization work?

I don't think so. The problem is that the DIN group is trying to harmonize two application specific formats. OpenOffice has one way of implementing basic document structures, and MSOffice another. These differences are directly reflected in the related formats, ODF and OOXML. Any attempts to harmonize ODF and OOXML will require that the applications, OpenOffice and MSOffice, be harmonized!

There is no other way of doing this unless the harmonized spec has two different methods for implementing basic structures like lists, tables, fields, sections and page dynamics. Not to mention the problems of feature disparities.

If the harmonized spec has two different implementation models for basic structures, interoeprability will suffer enormously. And interoperability is after all the prupose of the standardization effort.

That brings us to a difficult compromise. Should OpenOffice compromise it's "innovative" features and methods in favor of greater interoperability with MSOffice and billions of binary documents? Let me see, 100 million OpenOffice installs vs. 550 MSOffice installs bound to workgroup-workflow business processes - many of which are critical to day to day business operations?

Sun and IBM have provided the anser to this question. They are not about to compromise on OpenOffice innovation! They believe that since their applications are free, the cost of ODF mandated "rip out and replace" is adequately offset.

Events in Massachusetts prove otherwise!

On July 2nd, 2007, Sun delivered to Massachusetts the final version of their ODF plug-in for MSOffice. That night, after reviewing and testing the 135 critical documents, Massachusetts made a major change to their ETRM web site. They ammended the ETRM to fully recognize OOXML as an acceptable format standard going forward.

The Massachusetts decision to overturn the ODF mandate was made after two years of testing and study of ODF implementation proposals. The first year was dedicated to "rip out and replace" initiatives put forward by IBM, Sun and Novell. The second year was dedicated to ODF plug-in for MSOffice efforts, culminating in the July 2nd, 2007 decision.

Simply put, Massachusetts was unable to implement ODF. The failures laregly being due to the fact that ODF was not designed to for a world dominated by MSOffice desktops! If users are unable to convert their documents to ODF, they are left with no other choice but to go forward with OOXML. If ODF plug-in desingers are unable to perfect this conversion, there is no way to repurpose MSOffice as an ODF ready application.

It's that simple.

~ge~
posted by garyedwards

The Burton Group did not recommend that ISO recognize OOXML as a standard! They pointed out that the marketplace is going to implement OOXML by default simply because it's impossible to implement ODF in situations where MSOffice dominates.

ISO should not go down the slippery slope of recognizing application-platform-vendor specific standards. They already made that mistake with ODF, and recognizing OOXML is hardly the fix.

What ISO should be doign is demanding that ODF fully conform with ISO Interoeprability Requirements, as identified in the May 2006 directive! Forget OOXML. Clean up ODF first.
posted by garyedwards

Tags: din fraunhofer harmonization iso odf

Posted by: garyedwards

The Harmonization Myth: ISO Approval of Open XML Will Hurt Interoperability

Thu, 31 Jan 2008 01:59:38 -0000

Highlights and Sticky Notes:

This myth is rather silly if you think about it. Here is why…

When people talk about interoperability and Open XML they do so primarily in the context of ODF. The story goes something like this:

1. Open XML is not interoperable with ODF
2. Open XML should be interoperable with ODF because ODF is already an ISO standard!
3. Hence: Open XML is no good, because it is not interoperable with ODF and therefore Open XML should not be an ISO standard!!!

Forget ISO approval of OOXML. I would rather see ISO enforce the current directive that ODF be brought into compliance with existing ISO Interoperability requirements. Then and only then should ISO then consider OOXML.

The reason for this approach? If ODF wiere compliant with existing ISO Interop Requirements, there would probably be some hope of harmonizing ODF and OOXML. Until ODF is stripped of it's application specific settings, and fully documented, we can hardly beging the process of figuring out harmonization.

ODF 1.0 has four gapping holes that must be tended to before ISO proceeds any furhter with either ODF or OOXML. The holes are that ODF numbered lists, formulas and the presentation layer (styles) are woefully underspecified. The fourth problem is that ODF is seriously lacking an interoperability framework.

These ODF problems can of course be traced back to the fact that ODF is application specific and bound to the "semantics and capabilities" of OpenOffice. That creates all kinds of problems. OOXML on the other hand is even worse. OOXML is application, platform and vendor specific!!!!

If ODF were brought up to snuff, we could reasonably start work on harmonization. Thereby eliminating the need to standardize two file formats for the same purposes. Until ODF is fixed, what's the world to do?

~ge~
posted by garyedwards

Tags: din fraunhofer harmonization iso odf

Posted by: garyedwards

ODF Alliance on the Microsoft Disposition of ISO Comments on OOXML

Wed, 30 Jan 2008 18:25:45 -0000

The ever audacious and prevaricating lobbyist group known as the ODF Alliance has posted their critique of Ecma's (Microsoft's) proposed disposition of ISO comments rejecting OOXML. The critique's appeal to ignorance is breath-taking in scope. E.g., whilst slamming DIS-29500 on the subject of interoperability, the same document pushes for harmonization using the following argument:

"Harmonization starts from looking at where the two formats overlap – and there is a significant, perhaps 90 percent or more, area where OOXML and ODF do overlap – and expressing this functional overlap identically. This common functionality between ODF and OOXML would also include a common extensibility mechanism. The remaining 10 percent of the functionality, where these standards do not overlap, would represent the focus of the harmonization effort. That portion of it which represents a widespread need could be brought into the core of ODF. That remaining portion which only serves one vendor's needs, such as flags for deprecated legacy formatting options, could be represented using the common extensibility mechanism."

And precisely how do vendor-specific extensions aid interoperability, particularly when the proposed "harmonization" does not require profiles and an interoperability framework?

Tags: brm odf odf-alliance ooxml opendocument

Posted by: garyedwards