Partly right. The MS plan is actually much bigger than Brian Profitt suggests. The MSOffice 2007 SDK is fille dwith new API's, the most interesting of which are the ones connecting MSOffice to XAML and the Windows Presentation Foundation layer. The killer component though is the OOXML <> fixed/flow translator component with related API's.

fixed/flow is a new web format that is 100% proprietary. It's at the heart of the Microsoft cloud, enabling developers to easily transition between OOXML and IE browsers able to serve fixed/flow pages to devices, desktops and just about any kind re purposing publication - content management system imaginable.

If ISO approves OOXML, then they've standardized MSOffice as a legitamate Web editor - enterprise publication, content management, archive management front end. Instead of producing W3C compliant (X)HTML - CSS web pages though, the MSOffice Web editor will produce the proprietary fixed/flow format via the OOXML translation component we can now see in the SDK.

What we don't see in the MSOffice SDK is the use of W3C technologies such as (X)HTML, CSS, SVG, XForms, SMiL, XSL, XSL-FO. Instead of Mozilla XUL or Adobe Flex, we find XAML and Silverlight.

IMHO, Microsoft is making their run for the Web. Key to this run is ISO approval of OOXML. Once that happens, there will be no need for MS product compliance with W3C standards. The break will be complete. The We forever split into the Windows Web, and the Firefox - Apache Tomcat Web. And never the twain shall meet.

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.

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!

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!

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.

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~

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.

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~