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.

Finally, someone who understands the grand strategy of levergaing the desktop monopoly into the converged space of server, device and web information systems.

What Joe isn't watching is the way the Exchange/SharePoint Server connects to MS SQL Server, Active Directory Server, MS LIve and MS Dynamics.

Also, Joe does not see the connection between OOXML as the portable XML document/data transport, and the insidiously proprietary Smart Documents metadata - data binding system that totally separates MSOOXML from Ecma 376 OOXML!

Include support for this feature in ISO ODF is another way of saying to hell with Ecma, OASIS and the big vendors driving the ODF-OOXML bus, Micrsoft and Sun.

This is delicious beyond belief. It's also the only way the world is going to get the interoperability they are demanding. The big vendors must be neutralized. The file formats must be completely independent of applications, platforms and the control of big vendors who routinely make exclussionary interoperabilty deals with each other whenever and wherever profitable.