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, which constrained the TC as follows: 

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.[emphasis added]

Notice that the target in both charters is that of fostering interoperability across office productivity applications and with line-of-business systems. 

It's beyond important that perople understand the nature of the MSOffice lock-in barriers that ODF and PDF must overcome.  If our only problem was that of converting legacy MSOffice binary docuemnts to ODF or PDF, we would have broken the monopolist grip years ago. 

What people have to realize is that it is the MSOffice bound workgroup-workflow business process barrier that is near impossible to overcome!

Let's go one step further and admit that Micrsoft's plugin approach for installing OOXML and XML-PDF in MSOffice is the only way to "realistically" overcome this business process barrier.

Which means there is an interesting corrollary for ODF.  Only the internal ODF-PDF plugins for MSOffice will be able to similarly overcome the business process barrier.  Rip out and replace approaches are too costly and disruptive.  So much so that even in governments like Massachusetts, where they had mandated ODF, it has proved impossible to implement ODF.

One way of looking at this problem is to take the OASIS ODF big vendor blinders off and see clearly that the way Microsoft deals with the problem of converting existing documents and bound business processes to XML, is to provide their own OOXML :: XML-PDF plugin for existing MSOffice desktops.

Note well one other phenomenon confirming the efficacy of the plugin approach.  The Microsoft - Novell deal resulted in a OOXML plugin for OpenOffice!  Subsequent Micrsoft deals feature this highly controlled and directed version of "interoperability" through agreements with prominent LiNUX vendors tha tthey distribute the Novell OpenOffice version with the OOXML plugin set as the default file format!

The same ODF vendors who opposed an internal ODF Plugin for MSOffice, are now shipping an OpenOffice with the OOXML plugin set as default.

(With Sun is not far behind - from the document, "Interoperability Wars", we have this collection of gems:

.... Yes, Sun will, but not as a return favor.  Sun is cooperating with
Novell on the OfficeOpenXML Translator plugin for OpenOffice, even
though they virulently opposed Novell's much needed "Interoperability
Enhancement" proposals on the OpenDocument Technical Committee.  Sun
will focus on a high fidelity import of OfficeOpenXML into OpenOffice,
but most likely will put little if any effort into export.  The old
one-way street trap that helped Microsoft to fame and fortune. Novell
is working on OOo export to OOXML.

• 
  Importing the beast...
  
• 
  Office Open XML Import Filter for Spreadsheets
  
• 
  OpenOffice Development at a Glance - Weekly Update & Schedule CW25  ....(notice all the scheduled work going into MS OfficeOpenXML import)
  
• 
  Roundtrip to Shanghai via Tokyo :: The Sun - Novell Joint Effort Import of OfficeOpenXML
  
• 
  New MS Word Filter for Writer (Milestone 1)  :: Sun Beta of the OfficeOpenXML filter for OpenOffice

The OpenDocument Foundation's da Vinci pllugin for MSOffice is simply a clone of the Microsoft OOXML plugin (which is also called the XML Compatibility Kit :).

Interstingly, when Massachusetts was evaluating da Vinci, one of the priorities they asked for was that we focus on the PDF-ODF digital signature package.  This is a design concept we presented to Massachusetts to include in da Vinci a PDF conversion.  But not just any PDF conversion.  What we proposed was to embed the ODF markup with the PDF file, implementing a digital signature to protect the ODF markup.

The PDF-ODF file could be opened in any Acrobat reader.  This is a "static" view of the content. Or, if one had access to the digitally signed ODF markup, one could "interactively" access the contents using an ODF application.  Including any da Vinci converted MSOffice workgroup-workflow bound desktop.

Now it appears that Microsoft is about to do the same thing with their OOXML :: XML-PDF plugin.  Very cool, and much needed.  But not something that can't also be done in ODF.

One area in his commentary where Andy makes a grave mistake is where he states:
^#1This
seems to me to be a turning point for the creation of global
standards. Microsoft was invited to be part of the original ODF
Technical Committee in OASIS, and chose to stand aside. That committee
tried to do its best to make the standard work well with Office, but
was naturally limited in that endeavor by Microsoft's unwillingness to
cooperate. This, of course, made it easier for Microsoft to later claim
a need for OOXML to be adopted as a standard, in order to "better serve
its customers." The refusal by an incumbent to participate in an open
standards process is certainly its right, but it is hardly conduct that
should be rewarded by a global standards body charged with watching out
for the best interests of all.

This statement is absolutely true of the original OASIS ODF TC (Technical Committee) that first met in December of 2002.  In fact, it was true throughout the first fifteen months of ODF TC activity.  Everyone on that first TC group supported full interoperability with Microsoft applications and documents, except for one company - Sun.

There are three areas of "interoperability" that Sun opposed then, and continues to oppose today.  The only difference being that after their 2004 deal with Microsoft, Sun has been uncompromisingly determined to block the interoperability the marketplace demands. 

Prior to the 2004 deal, there is much evidence of interop flexibility that made it's way past Sun and into the ODF specification.  It's not without good reason that the ODF 1.0  Conformance Section is also called the "universal generic".

The problem is that these interop holes in the ODF spec are "optional", and subsequently not supported or implemented by Sun's OpenOffice/StarOffice code base.  In fact, almost anywhere you find "optional" implementation choices in ODF, most likely your starring at an interoperability break point.

Since the 2004 deal, the binding of ODF to Sun's OpenOffice/StarOffice feature set has hardened.  So much so that after the failure of ODF in Massachusetts, CIO's across the nation started refering to ODF as having zero interop; a nice XML format that is impossible to implement in real world situations.  A real world filled with situations dominated by MSOffice bound workgroup-workflow business processes.

Today the OASIS ODF TC is completly 180 degrees opposite the one that met in December of 2002. 

There are three categories that define the "interoperability" problem:

• Compatibility with existing file formats and documents
• Interoperability at the Application layer
• Convergence - the portability of an XML document across desktop, server, device and web information systems
  

The CIO's who must deal with 15 years of MSOffice line of business development, need XML document solutions that can meet all three of the above interope criteria.  The over riding problem for CIO's is that of migrating their documents and business processes to XML.  The only question is, "Which XML, ODF or OOXML?

So far ODF has been a no show.  The only thing big ODF vendors have to offer is rip out and replace desktop alternatives to MSOffice.  These are too costly and disruptive in terms of the bound business proceses to ever be considered, as evidenced by a year long ODF Pilot Study conducted by the Commonwealth of Massachusetts.  A study that resulted in the Massachusetts Request for Information about the possibility of an ODF plugin for MSOffice.  The Pilot Study was such a disaster for ODF that it was burried forever, never to see the light of day.

That leaves the entire future of ODF with the internal ODF plugins for MSOffice.  An approach the big ODF do not support in either the marketplace, or, perhaps most importantly, at the level of the OASIS ODF TC - where "compatibility, interoperability and convergence" capabilites either go into the spec, or not. 

Since 2004, it's been 100% NOT!

The proof of this can be seen in any number of OASIS ODF TC proposals and discussions.  The most recent examples being threads having to deal with List Enhancement Proposals and Metadata XML/RDF. 

The current membership of the OASIS ODF TC is clearly and unequivocably on record as opposed to the interoperability the marketplace is screaming for.  The issues of "compatibility, interoperability, and convergence", as described above have been called by current TC members: "out of bounds", "out of scope", "not our problem", "let the converters and transformers deal with it", and "talk to Microsoft".

If Micrsoft were to join the OASIS ODF TC today, seeking to adapt ODF to meet the legacy document-MSOffice features-line of business integration needs of their monopoly base, the TC would have to deal with the exact same issues as they have summarily rejected with current compatibility-interoeprability-convergence disussions!

There is no possible way anyone can claim that today's OASIS ODF TC would welcome Microsoft and make accomodating changes to the specification!  No way!  And the proof of this hostility can be seen in the actual disussions and rejections of Micrsoft specific interoperability proposals.

Andy is out of touch and clearly drinking the kool-aid.

~ge~

A different view

I'm not on the ODF TC, but I have followed its evolution through the information publicly available at Oasis.

My
outside view of some of the various interoperability discussions you
mention is different than yours. I saw a resistance to adoption of
features if the sole reason was because OOXML did it that way. The
dissenting members wanted a more substantial reason, not simply to add
OOXML "features" to ODF.

If the goal is to simply make ODF like
OOXML, then what is the point? You would have conceded all control to
Microsoft since they have effective control of OOXML.

• standardize on MS Office2003
•  install the Compatibility Pack, but set group policies to read-only.
• delete key files needed by Sharepoint Server
• push the big vendors to support ODEF (The EU IDABC forked version of ODF that has been optimized for "interoperability")
  

• Commercializing Interoperability
• Billions of Legacy Binary Documents
  
• Singing Kumbaya

• MOOXML (Microsoft OfficeOpenXML)
• .NET 3.0 Components, Libraries and Data Schemas
• XAML - the XML presentation layer (GUI)