Another call for the "convergence" of ODF and MS-OOXML, this time from the government technology magazine, GCN.com.
IMHO, there is a very steep technical barrier to both the harmonization and/or convergence of ODF and OOXML. The problem is that these file formats are application specific and bound respectively to OpenOffice and MSOffice feature sets and implementation models. The only way to perfect a harmonization or convergence file format effort is to dramatically change the reference applications.
With over 500 million MSOffice workgroup bound desktops in the world, changing that suite of applications is likely to break business processes with a global disruption factor that is simply unacceptable. OpenOffice on the other hand could better sustain such the needed layout engine changes, but estimates it will take 3-5 years to accomplish this.
Sun has often stated at the OASIS ODF TC (technical committee) that OpenOffice will not be bound and limited by having to mirror MSOffice features and implementation models. These arguments are often called application innovation rights.
In the past year alone, there have been no less than five ODF iX "interoperability enhancement" proposals submitted to the OASIS ODF TC members for discussion. The iX proposals are designed to solve the problem of high fidelity "round trip" conversion of MSOffice binary and xml documents with OpenOffice ODF documents.
Sadly, Sun and the other ODF application vendors fought and thoroughly defeated every aspect of these proposals even though the first three iX proposals were signed off on by Massachusetts ITD, and considered vital to the successful implementation of ODF there. ODF of course proved impossible to implement in Massachusetts. And without the iX interoperability enhancements, it is impossible for ODF plug-ins for MSOffice to perfect the high fidelity "round trip" conversion of existing documents, applications and processes to ODF.
The iX interoperability enhancement proposals are simplicity itself. There are only five generic elements that need to be added to the ODF spec to solve two of three real world problems holding ODF back. The five generics deal with the basic document structures of lists, fields, tables, sections and page dynamics (page breaks). These five structural elements account for almost all fidelity conversion problems between MS binaries, MS XML, and ODF.
So why would anyone oppose the inclusion of these proposals in ODF? Especially with Massachusetts, California, Denmark, Belgium and the EU-IDABC successful implementation of ODF hanging in the balance?
The answer is that neither Microsoft or Sun is willing to give up application control of their respective file formats. We all know that MS-OOXML is bound and strapped to the emerging Microsoft Stack of desktop, server, device and web applications. The surprise for many is that ODF is similarly bound and strapped to the OpenOffice/StarOffice desktop, with an added proviso that defies all pubic expectations; Sun insists that nothing goes into the ODf specification that isn't fully implemented and supported by OpenOffice.
Here's the kicker; it will take a major overhaul of the OpenOffice layout engine to implement the five generic iX elements. The iX interoperability enhancements are needed to solve real world problems now blocking the implementation of Odf.
What “real world” problems you might ask? Well, the world is not a clean slate. Most of the world's existing binary documents are bound to the MSOffice application platform. They are application specific/platform specific, and defy high fidelity conversion to any other application specific implementation model. Like that of OpenOffice.
Five years ago when the OASIS ODF effort began, we believed it was entirely possible to create a universal file format based on a highly portable XML document model. The needs of this universal file format were simple enough to enumerate. It had to be open, unencumbered, universally interoperable (reuse of open standards, open interfaces and open methods), and application-platform-vendor independent with an acceptable governance model.
We thought ODF could be that universal file format.
Five years later and we are nowhere near our goal of a universal file format capable of universal interoperability. The thing is, when a specification hits the real world, as ODF did in Massachusetts, the proof of it's universality, application independence and governance model is sorely tested. And ODF failed that test miserably.
Massachusetts had conducted a year long Pilot Study to determine how they could implement ODF. The final report led to the now infamous RFi - Request for Information about the feasibility of a ODF plug-in for MSOffice. Meaning, Massachusetts realized they could not implement ODF without having a ODF plug-in clone of the MS-OOXML plug-in for MSOffice. The disruption cost of rip out and replace alternatives to MSOffice was impossibly high. The problem being the incredible volumes of MSOffice bound workgroup-workflow business processes, line of business integrated applications, and assistive technology add-ons.
An XML plug-in for MSOffice enables a non disruptive and cost free transition of documents, applications and processes. Microsoft provides a plug-in for OOXML. So Massachusetts thought, why not one for ODf?
The problem with that question is this; ODf is bound to the OpenOffice specific layout and conversion engines. To implement ODf in MSOffice, some changes must be made to accommodate the MSOffice specific layout and feature set model. These changes were codified in the various ODf iX “interoperability enhancement” proposals submitted to the OASIS ODf membership for discussion. OpenOffice cannot implement or support the iX enhancements without significant changes to their layout engine and implementation model. End of story.
The Universal Document Challenge:
The iX “interoperability enhancement” issues are only one part of the impossible to implement ODf story. The other part is basic to any universal file format contender – the ability to solve three "real world" problems. Problems a universal file format must address because the world is not a clean slate:
.......Compatibility with existing documents - file formats :: including the volumes of MS binary documents.
...... Interoperability with existing applications :: including the over 500 million MSOffice bound workgroups.
.......Convergence of desktop, server, device, and web systems as fluid and highly interoperable routers of documents, data, and media.
First off, let's be clear that ODf is unable to solve any of the these problems. It was clearly not designed to address these issues. Not that they don't come up at the OASIS ODf TC. This is evidenced over the years by efforts to amend the ODf Charter to include compatibility with existing documents and interoperability with existing applications. Also there have been efforts to amend the infamous Section 1.5 “Compatibility – Conformance Clause” so that interoperability isn't an “optional” afterthought. And of course, there the iX proposals mentioned above.
Here's something to think about. Using the Microsoft OOXML plug-in for MSOffice, MS can solve all three problems. But that solution also locks business processes into the proprietary MS Stack of desktop, server, device and web applications and services. Locks them in for who knows how many years to come. So much so that, imho, this represents the most dramatic expansion of a convicted monopolist's power in history. Microsoft is making it's move from the desktop to the Internet, and taking everything in between.
ODf is not the target of Microsoft's OOXML-Smart Documents efforts!
Au contraire! Do not kid yourselves ..... HTML is the target! And the Internet the prize.
As for ODf? If ODf can't solve the three universal document challenges, it's not a threat to Microsoft.
Here's how it works. The core of the MS Stack is an alignment of MSOffice, IE, and the Exchange/SharePoint Developers Hub. From there, the MS Stack connects to a sprawl of applications including Active Directory, MS SQL Server, MS Dynamics, and MS Live. Everything in the MS Stack speaks fluent MS-OOXML-Smart Documents, and is able to access all proprietary dependencies found within the portable document. (Psst! MOOS docs are different than Ecma 376 docs in that MOOS docs are specific to MSOffice and bound through platform specific dependencies to the MS Stack)
Now pay close attention. MS-OOXML-Smart doc containers are designed for two things. First, to port document/data/media packages across the entire stack. There is no HTML or HTML+ here! Second, MOOS docs are a bridge to existing documents, applications and bound business processes that drive workgroups. Microsoft's emerging systems can of course integrate with existing workgroup-workflow processes, facilitating a massive migration of these processes from the current desktop interface to that of the Exchange/SharePoint Developer Hub.
So where are we at here? OpenDocument was designed for the “rip out and replace” of MSOffice, can't meet the universal file format challenge – was never designed for that, and there little interest amongst the OASIS masters for harmonization, convergence, or any kind of compatibility-interoperability with Microsoft products. MOOS docs were designed for the transition of existing workgroup-workflow business processes to the Exchange/SharePoint Hub, and the replacement of HTML as the primary language of the Internet. Ecma 376 does not have a non binding implementation worth spit. So what is the world left with?
The answer is HTML+. The surprise being that HTML+ can meet all three of our universal document challenges. Governance through the W3C and universal interoperability are of course, built into the DNA. Stay tuned. This battle is just beginning.
~ge~
Would you like to comment?
Join Diigo for a free account, or sign in if you are already a member.
Page Comments
IMHO, there is a very steep technical barrier to both the harmonization and/or convergence of ODF and OOXML. The problem is that these file formats are application specific and bound respectively to OpenOffice and MSOffice feature sets and implementation models. The only way to perfect a harmonization or convergence file format effort is to dramatically change the reference applications.
With over 500 million MSOffice workgroup bound desktops in the world, changing that suite of applications is likely to break business processes with a global disruption factor that is simply unacceptable. OpenOffice on the other hand could better sustain such the needed layout engine changes, but estimates it will take 3-5 years to accomplish this.
Sun has often stated at the OASIS ODF TC (technical committee) that OpenOffice will not be bound and limited by having to mirror MSOffice features and implementation models. These arguments are often called application innovation rights.
In the past year alone, there have been no less than five ODF iX "interoperability enhancement" proposals submitted to the OASIS ODF TC members for discussion. The iX proposals are designed to solve the problem of high fidelity "round trip" conversion of MSOffice binary and xml documents with OpenOffice ODF documents.
Sadly, Sun and the other ODF application vendors fought and thoroughly defeated every aspect of these proposals even though the first three iX proposals were signed off on by Massachusetts ITD, and considered vital to the successful implementation of ODF there. ODF of course proved impossible to implement in Massachusetts. And without the iX interoperability enhancements, it is impossible for ODF plug-ins for MSOffice to perfect the high fidelity "round trip" conversion of existing documents, applications and processes to ODF.
The iX interoperability enhancement proposals are simplicity itself. There are only five generic elements that need to be added to the ODF spec to solve two of three real world problems holding ODF back. The five generics deal with the basic document structures of lists, fields, tables, sections and page dynamics (page breaks). These five structural elements account for almost all fidelity conversion problems between MS binaries, MS XML, and ODF.
So why would anyone oppose the inclusion of these proposals in ODF? Especially with Massachusetts, California, Denmark, Belgium and the EU-IDABC successful implementation of ODF hanging in the balance?
The answer is that neither Microsoft or Sun is willing to give up application control of their respective file formats. We all know that MS-OOXML is bound and strapped to the emerging Microsoft Stack of desktop, server, device and web applications. The surprise for many is that ODF is similarly bound and strapped to the OpenOffice/StarOffice desktop, with an added proviso that defies all pubic expectations; Sun insists that nothing goes into the ODf specification that isn't fully implemented and supported by OpenOffice.
Here's the kicker; it will take a major overhaul of the OpenOffice layout engine to implement the five generic iX elements. The iX interoperability enhancements are needed to solve real world problems now blocking the implementation of Odf.
What “real world” problems you might ask? Well, the world is not a clean slate. Most of the world's existing binary documents are bound to the MSOffice application platform. They are application specific/platform specific, and defy high fidelity conversion to any other application specific implementation model. Like that of OpenOffice.
Five years ago when the OASIS ODF effort began, we believed it was entirely possible to create a universal file format based on a highly portable XML document model. The needs of this universal file format were simple enough to enumerate. It had to be open, unencumbered, universally interoperable (reuse of open standards, open interfaces and open methods), and application-platform-vendor independent with an acceptable governance model.
We thought ODF could be that universal file format.
Five years later and we are nowhere near our goal of a universal file format capable of universal interoperability. The thing is, when a specification hits the real world, as ODF did in Massachusetts, the proof of it's universality, application independence and governance model is sorely tested. And ODF failed that test miserably.
Massachusetts had conducted a year long Pilot Study to determine how they could implement ODF. The final report led to the now infamous RFi - Request for Information about the feasibility of a ODF plug-in for MSOffice. Meaning, Massachusetts realized they could not implement ODF without having a ODF plug-in clone of the MS-OOXML plug-in for MSOffice. The disruption cost of rip out and replace alternatives to MSOffice was impossibly high. The problem being the incredible volumes of MSOffice bound workgroup-workflow business processes, line of business integrated applications, and assistive technology add-ons.
An XML plug-in for MSOffice enables a non disruptive and cost free transition of documents, applications and processes. Microsoft provides a plug-in for OOXML. So Massachusetts thought, why not one for ODf?
The problem with that question is this; ODf is bound to the OpenOffice specific layout and conversion engines. To implement ODf in MSOffice, some changes must be made to accommodate the MSOffice specific layout and feature set model. These changes were codified in the various ODf iX “interoperability enhancement” proposals submitted to the OASIS ODf membership for discussion. OpenOffice cannot implement or support the iX enhancements without significant changes to their layout engine and implementation model. End of story.
The Universal Document Challenge:
The iX “interoperability enhancement” issues are only one part of the impossible to implement ODf story. The other part is basic to any universal file format contender – the ability to solve three "real world" problems. Problems a universal file format must address because the world is not a clean slate:
.......Compatibility with existing documents - file formats :: including the volumes of MS binary documents.
...... Interoperability with existing applications :: including the over 500 million MSOffice bound workgroups.
.......Convergence of desktop, server, device, and web systems as fluid and highly interoperable routers of documents, data, and media.
First off, let's be clear that ODf is unable to solve any of the these problems. It was clearly not designed to address these issues. Not that they don't come up at the OASIS ODf TC. This is evidenced over the years by efforts to amend the ODf Charter to include compatibility with existing documents and interoperability with existing applications. Also there have been efforts to amend the infamous Section 1.5 “Compatibility – Conformance Clause” so that interoperability isn't an “optional” afterthought. And of course, there the iX proposals mentioned above.
Here's something to think about. Using the Microsoft OOXML plug-in for MSOffice, MS can solve all three problems. But that solution also locks business processes into the proprietary MS Stack of desktop, server, device and web applications and services. Locks them in for who knows how many years to come. So much so that, imho, this represents the most dramatic expansion of a convicted monopolist's power in history. Microsoft is making it's move from the desktop to the Internet, and taking everything in between.
ODf is not the target of Microsoft's OOXML-Smart Documents efforts!
Au contraire! Do not kid yourselves ..... HTML is the target! And the Internet the prize.
As for ODf? If ODf can't solve the three universal document challenges, it's not a threat to Microsoft.
Here's how it works. The core of the MS Stack is an alignment of MSOffice, IE, and the Exchange/SharePoint Developers Hub. From there, the MS Stack connects to a sprawl of applications including Active Directory, MS SQL Server, MS Dynamics, and MS Live. Everything in the MS Stack speaks fluent MS-OOXML-Smart Documents, and is able to access all proprietary dependencies found within the portable document. (Psst! MOOS docs are different than Ecma 376 docs in that MOOS docs are specific to MSOffice and bound through platform specific dependencies to the MS Stack)
Now pay close attention. MS-OOXML-Smart doc containers are designed for two things. First, to port document/data/media packages across the entire stack. There is no HTML or HTML+ here! Second, MOOS docs are a bridge to existing documents, applications and bound business processes that drive workgroups. Microsoft's emerging systems can of course integrate with existing workgroup-workflow processes, facilitating a massive migration of these processes from the current desktop interface to that of the Exchange/SharePoint Developer Hub.
So where are we at here? OpenDocument was designed for the “rip out and replace” of MSOffice, can't meet the universal file format challenge – was never designed for that, and there little interest amongst the OASIS masters for harmonization, convergence, or any kind of compatibility-interoperability with Microsoft products. MOOS docs were designed for the transition of existing workgroup-workflow business processes to the Exchange/SharePoint Hub, and the replacement of HTML as the primary language of the Internet. Ecma 376 does not have a non binding implementation worth spit. So what is the world left with?
The answer is HTML+. The surprise being that HTML+ can meet all three of our universal document challenges. Governance through the W3C and universal interoperability are of course, built into the DNA. Stay tuned. This battle is just beginning.
~ge~
Would you like to comment?
Join Diigo for a free account, or sign in if you are already a member.