<P>A <i>"touch limited in scope"?</i> 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.</p><br>
<p>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 <i>touch limited in scope!</i><p><br>
<p>Many would claim that this <i>limitation</i> 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.</p><br>
<p>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.</p><br>
<p>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.</p><br>
<p>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.</p><br>
<p>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.</p><br>
<p>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.</p><br>
<p>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.</p><br>
<p>One last point. The German DIN group was authorized by the EU to write a report for ISO concerning the prospects of <b><i>harmonizing</i></b> 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.</p><br>
<p>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.</p><br>
This link has been bookmarked by 1 people . It was first bookmarked on 30 Jan 2008, by Gary Edwards.
-
30 Jan 08
-
The format war between Microsoft’s Open Office XML (OOXML) and the open source OpenDocument Format (ODF) has flared up again, right before the looming second OOXML ISO vote in March.
-
“ISO has a policy that, wherever possible, there should only be one standard to maximise interoperability and functionality. We have an international standard for digital documentation, ODF,” IBM’s local government programs executive Kaaren Koomen told AustralianIT.
-
Add Sticky NoteODF has garnered some criticism for being a touch limited in scope, however, one of its strengths is that it has already been accepted as a worldwide ISO standard. Microsoft’s format on the other hand, has been criticised for being partially proprietary, and even a sly attempt by the software giant to hedge its bets and get in on open standards while keeping as many customers locked into its solutions as possible.
-
-
<p>Will harmonization work?</p>
<p>I don't think so. The problem is that the DIN group is trying to <i>harmonize</i> 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 <i>harmonize</i> ODF and OOXML will require that the applications, OpenOffice and MSOffice, be <b><i>harmonized</i></b>! </p>
<p>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.</p>
<p>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.</p>
<p>That brings us to a difficult compromise. Should OpenOffice compromise it's <i>"innovative"</i> features and methods in favor of greater <i>interoperability</i> 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?</p>
<p>Sun and IBM have provided the anser to this question. They are not about to compromise on OpenOffice <i>innovation</i>! They believe that since their applications are free, the cost of ODF mandated "rip out and replace" is adequately offset.</p>
<p>Events in Massachusetts prove otherwise!</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>It's that simple.</p>
<p>~ge~</p>
-
-
Add Sticky Note
-
<p>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. </p>
<p>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. </p>
<p>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.</p>
-
-
Public Stiky Notes
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~
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.
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.
Page Comments
Correcto mundo! There should be only one standard to maximise interoeprability and functionality. But ODF is application specific to the way OpenOffice works. It was not designed from a clean slate. Nor was the original 2002 OpenOffice XML spec designed as an open source effort! Check the OOo source code if you doubt this claim. The ONLY contributors to Open Office XML were Sun employees!
What the world needs is in fact a format standard designed to maximise interoperability and functionality. This requires a total application-platofrm-vendor independence that neither ODF or OOXML can claim.
The only format that meets these requirements is the W3C's family of HTML-XML formats. These include advancing Compound Docuemnt Framework format components such as (X)HTML-5, CSS-3, XForms, SVG and SMiL.. The W3C's CDF does in fact meet the markeplace needs of a universal format that is open, unencumbered and totally application, platform and vendor independent. The only trick left for CDF is proving that legacy desktop applications can actually implement conversions from existing in-memory-binary-representations to CDF without loss of information.
Would you like to comment?
Join Diigo for a free account, or sign in if you are already a member.