Read it and weep! Sun agrees that ODF was not designed for and is unable to meet these important market requirements

What is he talking about? Does a developer write to Vista? Or do they write to MS Stack ready .NET - OOXML-Smart Documents, XAML, Silverlight stuff?

Bear in mind that these "service components" are proprietary, and represent the only way to connect MS clients to the rest of the MS STack of applications.

Oh right! The anti trust restrictions will not be lifted until November. Have to be careful here. But how is it Craig that non Microsoft devlopers and service providers will be albe to access and interoperate with important "service components"?

Then why is Microsoft dragging us through this standardization nonsense? Is this nothing more than thinly veiled assault on open standards in general?

The battle between OOXML and ODF is very much about two groups of big vendor alliances. Interestingly, both groups seek to limit ODF interoperability, but for different reasons.



See: The Plot To Limit ODF Interop

Presentation fidelity and round tripping? Looks like someone has been attention to what happened in Massachusetts.

Keep in mind orchmid that it is the OpenOffice code base that ODF is bound to. There are many instances of the OOo code base pushed by various vendors. Sun provides OpenOffice.org and StarOffice versions of the code base. Novell Open Office is the same code base. Same with Red Hat Office and IBM WorkPlace. Outside this common code base, ODF has near ZERO interoperability.

A "Yes with comments" is a yes for the ISO approval of MS-OOMXL. If ISO approves MS-OOXML, it won't matter what Bosak's "comments" strategy is. Microsoft and the Vista Stack will be off to the races. The full disclosure of the MS binary document secret blueprint won't matter much at that point.

There you go Geir!

Sun and Bosak have held the door open for MS-OOXML since 2002, when Sun blocked an effort to write the ODF Charter to include as a priority, "compatibility with existing file formats". This of course would include the billions of legacy MS binary documents.



The thing is that those who work in the conversion-translation field will tell you that it is currently impossible to pipe converted legacy binary documents and OOXMl docs for that matter into ODF. Just as Microsoft claims, ODF in it's current state is insufficient and unable to handle the rich feature set of the MSOffice developers platform.



The problem could of course be easily fixed by the inclusion in ODF of five structural generics. In the past year, there have been no less than five iX "interoperability enhancement" proposals submitted to the OASIS ODF TC for discussion and consideration. As uber universal interop expert Florian Reuter points out in his blog, these iX proposals did not fare so well.



What Florian doesn't point out is that it was Sun who opposed any and all efforts to improve compatibility with existing Microsoft binary and OOXML documents. Just as they have done for nearly five years now.



Sort of puts the Sun-Bosak support for ISO approval of MS-OOXML in a different light.

~ge~

This backwards compatibility with the existing binary file formats isn't the big deal Micrsoft makes it out to be.  ODF 1.0 includes a "Conformance Clause", (Section 1.5) that was designed and included in the specification exactly so that the billions of binary legacy documents could be converted into ODF XML.

The problem with the ODF Conformance Clause is that the leading ODF application, OpenOffice,  does not fully support and implement the Conformance Clause. 

The only foreign elements supported by OpenOffice are paragraphs and text spans.  Critically important structural document characteristics such as lists, fields, tables, sections and page breaks are not supported!

This leads to a serious drop in conversion fidelity wherever MS binaries are converted to OpenOffice ODF.

Note that OpenOffice ODF is very different from MSOffice ODF, as implemented by internal conversion plugins like da Vinci.  KOffice ODF and Googel Docs ODF are all different ODF implementations.  Because there are so many different ways to implement ODF, and still have "conforming" ODF documents, there is much truth to the statement that ODF has zero interoperabiltiy.

It's also true that OOXML has optional implementation areas.  With ODF we call these "optional" implementation areas "interoperabiltiy break points" because this is exactly where the document exchange  presentation fidelity breaks down, leaving the dominant market ODF applicaiton as the only means of sustaining interoperabiltiy.

With OOXML, the entire Vista Stack - Win32 dependency layer is "optional".  No doubt, all MSOffice - Exchange/SharePoint Hub applications will implement the full sweep of proprietary dependencies.    This includes the legacy Win32 API dependencies (like VML, EMF, EMF ), and the emerging Vista Stack dependencies that include Smart Documents, XAML, .NET 3.0 Libraries, and DrawingML.

MSOffice 2007 is extremely unique as an application in that it's able to import legacy documents and preserve their Win32 dependencies.  Yet, if you were to re create those same documents "natively" in MSOffice 2007, the dependencies would all be Vista Stack types.

Here's a kicker.  If you attach an MSOffice legacy binary to an eMail, and send that eMail to any Exchange/SharePoint Hub application (like OWL), the attachment will automatically be converted to MS OOXML - complete with Vista Stack dependencies!  Unl,ike MSOffic e2007, the E/S Hub does not offer that dual backwards compatibiltiy model. 

Because of this dual model, MSOffice is one of the most unique applications Microsoft has ever put on the market.  The traditionnal MS application only proivedes for one way backwards compatibility. You can read in a legacy document, but are unable to effectively wirte out to the legacy binary format.  MSOffice 2007 steps soff the forced upgrade treadmill, and offers a dual mode two way form of backwards compatibiltiy.  It' will be tricky for end users to avoid the upgrade trap of writing new documents and thinking they can be inserted into a MSOffic ebound workgroup tha tincludes legacy MSOffice versions.  But it can be done.

The traditional forced march upgrade treadmill strategy has been moved to the Exchange/SharePoint Hub.  This is also where next generation line of business integration apps will be written - replacing the desktop platform as everything is migrated to Microsoft's XML.