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~

Of course this "incompatibility"outcome was planned years ago.  What else could we expect since Microsoft has steadfastedly refused to participate in the OASIS Open Office XML (ODF) effort, which began in 2002 with Microsoft joining the group, but noticeably choosing to observe without contribution or participation.

So it is Microsoft who is a fault for any finding of ODF - MSOffice incompatibility, not the OASIS ODF Technical Committee or ODF community of vendors, developers and users.

Our friends in Redmond planned and plotted for this dilemma.  Their intentions are to control completely the migration of information and information processes from legacy binary file formats to their own version of XML.

One thing many people miss about this is that Microsoft mus tmove to XML fiel formats no matter what.  The Internet has usshered in a new age of collaborative computing based on universal access, connectivity and exchange.  It's a world driven by HTML, XML and RDF/XML.  Microsoft either embraces this juggernaut, or gets left in the dust.

Interestingly, i for one believe that Microsoft has the best next generation Internet - XML stategey out there.  There's a lot of low level wiki - writely collaobration out there.  And of course Lotus Notes has reigned for years, alone and unchallenged in the client/server area of intelligent documents, forms, managed workflows, scripted routing, and collaborative computing.  Microsoft's extraordinary opportunity is to leverage their desktop MSOffic emonopoly of over 500 million users into the emerging arena of highly interoperable "Information Processing Chains".

Because of Redmond's iron fisted monopolist control over MSOffice desktop productivity environment's, they own entirely the Information Processing Chain opportunity.  And the Vista Chain (Stack) is a wonder to behold.

The core of the Vista Chain is the OOXML document/data transport connection between MSOffice and the Exchange/SharePoint/Groove Hub.  IE and Vista augment this chain in that they are OOXML fluent and OOXML enabling. 

The idea here is for Microsoft to migrate to the E/S XML HUB both the MSOffice bound binary documents and the volumes of critical day to day  MSOffice bound business processes, line of business integrated apps, and scores of assistive technology type add-ons.  Microsoft has to ge this job done before others swoop in and do it for them.  Others would be SaaS, SOA, and a host of Enterprise 2.0 collaborative computing initiatives.

The Vista Chain is based on the portable XML document/data transport, OOXML; and,the Vista .NET 3.0 framework.  Legacy Win 32 APi application and platform dependencies that bind those billions of binary documents to MSOffice, are replaced in OOXML by bindings to the Vista .NET 3.0 dependencies.  From the E/S Hub, it's easy for end users to create data and workflow bindings involving MS SQL Server transaction and data processing backends.  Same with MS Live, Office Communicator, Active Directory, MS ERP, MS CRM, and MS Money.

The Vista Chain is good stuff.  Moving those MSOffic ebound business processes to the E/S XML Hub is not all that difficult, and the reward is a guaranteed leap in porductivity.  A giant leap.

Which brings us back to the challenge ODF faces.  Will there be an ODF Chain?  Not if users and providers are unable to perfectly convert those MSOffice bound billions of billions fo binary documents and MSOffice bound business processes to ODF.

The challenge for ODF is in doing exactly what OOXML does.  The end users migration to XML and the XML Hubs is entirely dependent on three successive stages.  All of which OOXML can currently master:

1. Perfect Conversion Fidelity :: of billions of binary documents to XML (ODF - OOXXML)
2. Perfect Round Trip Fidelity :: MSOffic ebound business processes Workgroup - WorkFlow
   
3. Application Interoperability :: between all processing chain application participants, even as they
   span desktop, server, device and Enterprise 2.0 serivces and systems.

http://opendocument.foundation.googlepages.com/home

The ACME 376 Compatibility Kit is
the Da Vinci plugin producing ACME 376; an XML encoding of RTF.  Da
Vinci can also produce MS Binary <> ODF 1.0 and ODF 1.2.
conversion processes.  If wee wanted to, Da Vinci could be configured to
produce MS Binary <> Chinese UOF conversion processes.  It's a
very flexible conversion and mapping engine.