ODF infighting could help Microsoft's OOXML

ODF infighting could help Microsoft's OOXML

Summary: Microsoft's battle with backers of the Open Document Format (ODF) standard could end up going the way that so many contests do: Won by Microsoft as much -- if not more -- because of the ineptitude of its competition than by Redmond's prowess.

SHARE:
42

Microsoft's battle with backers of the Open Document Format (ODF) standard could end up going the way that so many contests do: Won by Microsoft as much -- if not more -- because of the ineptitude of its competition than by Redmond's prowess.ODF iinfighting could help Microsoft's OOXML

Just as Netscape and Sony ended up their own worst enemies, the ODF camp might unravel before Microsoft's rival Office Open XML (OOXML) comes up for final international standardization vote early next year. Microsoft lost a vote earlier this year to get OOXML on the ISO fast track.

A number of ODF backers are abandoning ODF and throwing their weight behind the Worldwide Web Consortium (W3C Compound Document Format (CDF).

Microsoft Director of Corporate Standards Jason Matusow blogged recently about the splintering of the ODF coalition. Matusow pointed to a post by former ODF champion (and now CDF advocate) Sam Hiser. Hiser, a systems consultant who has served as Vice President & Director Business Affairs at the OpenDocument Foundation, blogged earlier this month:

"It may be news to some -- not to the ODF Community, certainly -- that we at the OpenDocument Foundation have been displeased with the direction of ODF development this year. We find that ODF is not the open format with the open process we thought it was or originally intended it to be....

"Among ODF's weaknesses is its provenance from a specific application and the unwillingness of its originators to release it into the Bazaar. Merchants of irony will note this is the identical problem that paralyzes the incumbent gorilla's (Microsoft's) format."

Microsoft has been arguing that ODF never was a single, unified standard and that developers and customers had no way of knowing which version of it (1.0? 1.2? other?) to use.

As a result of the latest infighting, is Microsoft now all-but-guaranteed that OOXML will sail through the ISO standardization vote in Feburary 2008 because ODF -- and its backers -- will be in disarray?

(vote no. Image by Paul Keheler. CC 2.0)

Topics: Emerging Tech, Microsoft

About

Mary Jo has covered the tech industry for 30 years for a variety of publications and Web sites, and is a frequent guest on radio, TV and podcasts, speaking about all things Microsoft-related. She is the author of Microsoft 2.0: How Microsoft plans to stay relevant in the post-Gates era (John Wiley & Sons, 2008).

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

42 comments
Log in or register to join the discussion
  • Is the vote the most important issue?

    A splintering of ODF advocates won't affect IBM's attempt to discomfit a rival nor slow those who believe Microsoft villainous. But it does reduce or make less enthusiastic the number of those campaigning against Office and for ODF adoption.

    The tactical and strategic mistakes of opponents have helped Microsoft, perhaps more than the company's own efforts. But in this case I think the impact of a split would be more on the market than on a technical/political organization.
    Anton Philidor
  • One supporter, actually

    [i]A number of ODF backers are abandoning ODF and throwing their weight behind the Worldwide Web Consortium (W3C Compound Document Format (CDF).[/i]

    The OpenDocument Foundation is precisely one supporter, if you actually look into it, and is pretty much a one-man shop. Its sole claim to fame was its promise to produce an ODF plugin for MSOffice -- which at last word worked well on MSO2k3 but broke on MSO2k7. Hard to say, since (despite the sound bite regarding "releasing ODF to the bazaar") the plugin is/was not open source.

    So now he/they decide to switch direction to CDF -- which is in very early stages and not (at least at first glance) intended for remotely similar uses.

    [i]As a result of the latest infighting, is Microsoft now all-but-guaranteed that OOXML will sail through the ISO standardization vote in Feburary 2008 because ODF ??? and its backers ??? will be in disarray?[/i]

    This has nothing to do with the outcome of the Ballot Resolution Meeting.
    Yagotta B. Kidding
    • Splintering of the ODF community has nothing to do with the OOXML battle

      YBK said: "The OpenDocument Foundation is precisely one supporter, if you actually look into it, and is pretty much a one-man shop."

      That's incorrect. The Foundation presently has three spokesmen, a board of directors, and a development team. I am the Foundation's director of legal affairs and its representative on the OpenDocument Technical Committee.

      In answer to Mary Jo's question whether disarray in the ODF community will result in OOXML being approved by ISO, splintering over which standard to support does not mean the opposition to OOXML is splintering. We continue to work closely with ODF advocates and others to defeat OOXML. But we also oppose adoption of ODF 1.2 as an ISO standard in the form we expect it to emerge from OASIS.

      For us, the big issue with both ODF and OOXML is the lack of interoperability conformance requirements. Neither set of formats is designed to serve as a universal set of formats. The ODF TC's refusal to fix the interop warts is precisely why we put ODF support on the shelf for our products and switched to support for CDF+. That standard has an interoperability framework and interop conformance requirements, amongst other advantages.

      The real issue at ISO is whether OOXML and ODF will be: (i) harmonized; and/or (ii) converged. That battle will be won or lost on application of the ISO/IEC JTC 1 Directive requiring that "Standards designed to facilitate interoperability need to specify clearly and unambiguously the conformity requirements that are essential to achieve the interoperability."

      If that Directive is ignored, everyone loses but the big vendors. But if it is faithfully applied to both ODF and OOXML, then the big vendors lose and the rest of the world wins.

      There has been a lot of disinformation about ODF perpetuated around the improper conflation of the terms "open" and "interoperable." They are not synonyms. As only one example, consider the words of Thomas Zander, lead developer of the KOffice word processor, also a member of the ODF TC:

      [i]"One thing I have always dreamed to be possible is that when I write a doc in KOffice I can then open it in OOo to use that one feature that's useful to me and then save it and continue in KOffice without loosing lots of data.

      "Its still a dream, of course. Most features are lost on opening and saving it in OOo, but its a nice goal."[/i]
      http://www.oasis-open.org/archives/odf-adoption/200709/msg00032.html

      Conformance requirements that allow implementing apps to destroy metadata created by other implementing apps is only one of the major interoperability warts in ODF.
      Marbux
      • Maybe, Maybe not?

        What helps Microsoft here is that they at least have a standard that people can start to build on while the ODF is at a point in which how do you build your softawre if you do not know what the final standard is going to be?
        GuidingLight
        • No such thing

          [i]What helps Microsoft here is that they at least have a standard that people can start to build on while the ODF is at a point in which how do you build your softawre if you do not know what the final standard is going to be?[/i]

          There's no such thing as a "final standard." ODF is going through evolution, DIS-29500 isn't even that far along, and Microsoft has stated that they aren't committing to support it in the future.

          You pays your money and you takes your chances.
          Yagotta B. Kidding
      • Thanks for the correction

        Haven't seen much of you on Groklaw lately. At one point I was starting to worry for you. Good to see you around and kicking.
        Yagotta B. Kidding
        • Stilll alive and kicking.

          Thanks, YBK. I'm doing fine. Still working on keeping the big vendors honest.

          --Marbux
          Marbux
      • How do you eliminate that possibility?

        "Conformance requirements that allow implementing apps to destroy metadata created by other implementing apps is only one of the major interoperability warts in ODF."

        How do you eliminate the possibility of metadata being destroyed, if the metadata isn't part of the standard? You can apply a "snark" property to a bunch of paragraphs, but if an application splits one does the new paragraph inherit the "snark" property, and what value should it have? Either answer may result in broken data.
        Resuna
    • An empty handed ISO

      <pre>Hi YBK,

      I don't think MS-OOXML (ISO 29500) will survive the 2008 February Ballot Resolution effort. There are 3,000 NO with Comments that must be responded to and resolved. Even if Microsoft was inclined to do the unthinkable, and resolve these comments, there is no way they could do it within the few days alloted.

      MS-OOXML failed at ISO on September 2nd, 2007.

      I think the best Microsoft can do is first, keep MS-OOXML alive at the JTC-1 level as a stalled effort still on the books.

      Second, Microsoft will, (with the help of Sun), make certain that ODF 1.1 and 1.2 do not receive ISO approval either.

      ODF 1.2 work was closed in July of 2007 without having complied with ISO Directives insisting that ODF must meet existing ISO Interoperability Requirements. The directives were issued in May of 2006, yet ODF 1.2 work proceeded blissfully unaware of the order.

      We could argue that the failure of ODF 1.2 at ISO is the backup strategy contingency if MS-OOXML failed the September 2nd vote, except that Microsoft has nothing to do with ODF 1.2. The failure of ODF 1.2 at ISO is entirely the handiwork of the OASIS ODF TC. A handiwork we tried to derail, but failed.

      So here we are. Expect an MS-OOXML ISO failure in February of 2008. The OASIS ODF TC will perhaps then move to hold ODF 1.2 out of ISO consideration, hoping the marketplace will be lulled into thinking that since ODF 1.0 was approved, ODF 1.2 is also acceptable. They know that ODF 1.2 will be similarly rejected, and at this late date, what else could OASIS do but to withhold ODF 1.2?

      Any attempt by OASIS to withhold ODF 1.2 from ISO consideration is doomed to failure. In fact, one could argue that such an action would cause the JTC-1 to fix ODF 1.0 themselves, hammering it into ISO Interoperability Requirements compliance any way they can. Which would of course wreck havoc with all the application interests represented on the OASIS ODF TC.

      Of course, we can expect Microsoft to make ODF 1.2 ISO approval an issue also. They will of course insist that ODF be held to the same high bar of ISO requirements MS-OOXML was held to. And they would be right.

      All of which means there is high probability come April or May of 2008 that ISO might find itself without an approved XML file format standard for desktop office suites. The marketplace might be expected to respond to this dilemma by holding off on any requirements decision, and going with their existing application processes.

      This won't work for too long because of surging market uptake of the Exchange/SharePoint developers hub, now exceeding 65%. The E/S juggernaut automagically converts MSOffice binary attachments to, hold your breath, MS-OOXML.

      An empty handed ISO has only one consequence; the near certain transition of all existing MSOffice documents, applications and processes to MS-OOXML.

      We are rushing like crazy to get our CDF implementation ready and tested with the rigorous and demanding CDR test suite, for one reason; we need an alternative to MS-OOXML, and ODF does not fill the bill.

      What we know for certain is that ODF isn't an implementable alternative to MS-OOXML, given the critical market requirements we found in Massachusetts. MS-OOXML was designed to meet these requirements. ODF was not. We followed the proper procedures of submitting our needed extensions to OASIS, and failed. Even though there are only five generic extensions needed to meet those market <i>"compatibility with existing MS documents and interoperability with existing MS applications"</i> requirements.

      We failed to get approval at OASIS. It's that simple. But that doesn't mean we are about to roll over and let MS-OOXML run off with the great herd of 550 million desktops.

      If we can't do this ODF we'll do it with CDF. And you're right YGK, CDF is different. It's Web centric to the core. The grand convergence of desktop, server, device and web systems is the sweet spot for CDF, and i think that's all the more reason for moving to CDF. Although, if we could have pulled this off with ODF, we would have.

      One last thought. Many people doubt we can hit a conversion fidelity similar to that of the MS-OOXML Compatibility Pack plug-in. They insist we would need to have access to the secret binary blueprints to do that.</pre>

      <pre>Since our da Vinci plug-in uses an internal MSOffice conversion process to break the binaries, we really don't have a need for the blueprints. This puzzles everyone since most are stuck in the rut of trying to reverse engineer those binaries. We let Microsoft do that for us, and the result is high fidelity conversion, which anyone can test for themselves by downloading <a href="http://opendocument.foundation.googlepages.com/acme376.msi">ACME 376</a> and testing your documents.</pre>

      <pre>The conversion process has two components; the actual conversion of the binaries, and, the piping into a target format. The da Vinci converter is ACME 376. The piping stage is handled by a second component called "InfoSet", where targeted file format profiles can be stored.

      The issue is this, although ACME 376 can do the conversion, we can't pipe into ODF without loss of that fidelity. Least ways not without having our five generic "iX" elements (lists, tables, fields, sections and page dynamics) approved by OASIS. Without iX, piping into ODF is like trying to pour a hundred gallons into a tin cup (OK, i exaggerate greatly here to make the point - it's not that bad, but bad enough :)

      Here's the thing. We are fully convinced we can pipe into CDF, and do so without loss of fidelity.</pre>

      <pre>Hope This helps,
      ~ge~</pre>
      gary.edwards
      • Known solutions

        1) ZD Talkbacks use BBcode -- your markup failed. Simple paragraphs are all you need.
        2) Please format with newlines!
        3) To content:

        [i]I don't think MS-OOXML (ISO 29500) will survive the 2008 February Ballot Resolution effort. There are 3,000 NO with Comments that must be responded to and resolved. Even if Microsoft was inclined to do the unthinkable, and resolve these comments, there is no way they could do it within the few days alloted.[/i]

        You're assuming an honest BRM. The alternative is classical Chicago electoral engineering.
        Yagotta B. Kidding
      • Most comment easy to fix

        [quote]There are 3,000 NO with Comments[/quote]
        There are only 26% of voting ISO members that voted NO on OOXML and allthough the member submitted 3500 comments about 3000 of those are actually copies from each other.
        For instance by changing about 50 minimal edittorial edits that do not affect the standards in any way (just minor text errors, reprasing and better referencing) about 1000 comments can be solved.
        Multivac
    • An Empty Handed ISO : fix

      Hi YBK,
      <br><br>
      I don't think MS-OOXML (ISO 29500) will survive the 2008 February Ballot Resolution effort. There are 3,000 NO with Comments that must be responded to and resolved. Even if Microsoft was inclined to do the unthinkable, and resolve these comments, there is no way they could do it within the few days alloted.
      <br><br>
      MS-OOXML failed at ISO on September 2nd, 2007. I think the best Microsoft can do is first, keep MS-OOXML alive at the JTC-1 level as a stalled effort still on the books. Second, Microsoft will, (with the help of Sun), make certain that ODF 1.1 and 1.2 do not receive ISO approval either.
      <br><br>
      ODF 1.2 work was closed in July of 2007 without having complied with ISO Directives insisting that ODF must meet existing ISO Interoperability Requirements. The directives were issued in May of 2006, yet ODF 1.2 work proceeded blissfully unaware of the order.
      <br><br>
      We could argue that the failure of ODF 1.2 at ISO is the backup strategy contingency if MS-OOXML failed the September 2nd vote, except that Microsoft has nothing to do with ODF 1.2. The failure of ODF 1.2 at ISO is entirely the handiwork of the OASIS ODF TC. A handiwork we tried to derail, but failed.
      <br><br>
      So here we are. Expect an MS-OOXML ISO failure in February of 2008. The OASIS ODF TC will perhaps then move to hold ODF 1.2 out of ISO consideration, hoping the marketplace will be lulled into thinking that since ODF 1.0 was approved, ODF 1.2 is also acceptable.
      <br><br>
      The lords of ODF at OASIS know that ODF 1.2 will be similarly rejected, and at this late date, what else could OASIS do but to withhold ODF 1.2?
      <br><br>
      Not that this will work.
      <br><br>
      Any attempt by OASIS to withhold ODF 1.2 from ISO consideration is doomed to failure. In fact, one could argue that such an action would cause the JTC-1 to fix ODF 1.0 themselves, hammering it into ISO Interoperability Requirements compliance any way they can. Which would of course wreck havoc with all the application interests represented on the OASIS ODF TC.
      <br><br>
      Of course, we can expect Microsoft to make ODF 1.2 ISO approval an issue also. They will of course insist that ODF be held to the same high bar of ISO requirements MS-OOXML was held to. And they would be right.
      <br><br>
      All of which means there is high probability come April or May of 2008 that ISO might find itself without an approved XML file format standard for desktop office suites.
      <br><br>
      The marketplace might be expected to respond to this dilemma by holding off on any requirements decision, and going with their existing application processes. This won't work for too long because of surging market uptake of the Exchange/SharePoint developers hub, now exceeding 65%. The E/S juggernaut automagically converts MSOffice binary attachments to, hold your breath, MS-OOXML.
      <br><br>
      An empty handed ISO has only one consequence; the near certain transition of all existing MSOffice documents, applications and processes to MS-OOXML.
      <br><br>
      We are rushing like crazy to get our CDF implementation ready and tested with the rigorous and demanding CDR test suite, for one reason; we need an alternative to MS-OOXML, and ODF does not fill the bill.
      <br><br>
      Anyone who disagrees with our position is encouraged to prove us wrong by providing real world ODF solutions that are effective alternatives to MS-OOXML. All we ask is that you hurry it up. The MS-Stack is looming large, and ISO approval is not going to stop the juggernaut.
      <br><br>
      What we know for certain is that ODF isn't an implementable alternative to MS-OOXML, given the critical market requirements we found in Massachusetts. MS-OOXML was designed to meet these requirements. ODF was not.
      <br><br>
      We followed the proper procedures of submitting our needed extensions to OASIS, and failed. Even though there are only five generic extensions needed to meet those market "compatibility with existing MS documents and interoperability with existing MS applications" requirements.
      <br><br>
      We failed to get approval at OASIS. It's that simple. Our extensions are indeed outside the ODF charter and way beyond the scope of current ODF work.
      <br><br>
      But that doesn't mean we are about to roll over and let MS-OOXML run off with the great herd of 550 million desktops. If we can't do this with ODF we'll do it with CDF.
      <br><br>
      And you're right YGK, CDF is different. It's Web centric to the core. The grand convergence of desktop, server, device and web systems is the sweet spot for CDF, but i think that's all the more reason for moving to CDF.
      <br><br>
      Although, if we could have pulled this off with ODF, we would have.
      <br><br>
      One last thought. Many people doubt we can hit a conversion fidelity similar to that of the MS-OOXML Compatibility Pack plug-in. They insist we would need to have access to the secret binary blueprints to do that.
      <br><br>
      Since our da Vinci plug-in uses an internal MSOffice conversion process to break the binaries, we really don't have a need for the blueprints. This puzzles everyone since most are stuck in the rut of trying to reverse engineer those binaries; a moving target if ever there was one. We let Microsoft do that for us, and the result is high fidelity conversion, which anyone can test for themselves by downloading ACME 376 and testing your documents.
      <br><br>
      The da Vinci conversion process has two components; the actual conversion of the binaries, and, the piping into a target format. The da Vinci converter is ACME 376. The piping stage is handled by a second component called "InfoSet", where targeted file format profiles can be stored.
      <br><br>
      The issue is this, although ACME 376 can do the conversion, we can't pipe into ODF without loss of that fidelity. Least ways not without having our five generic "iX" elements (lists, tables, fields, sections and page dynamics) approved by OASIS.
      <br><br>
      Without iX, piping into ODF is like trying to pour a hundred gallons into a tin cup (OK, i exaggerate greatly here to make the point - it's not that bad, but bad enough :)
      <br><br>
      Here's the thing. We are fully convinced we can pipe into CDF, and do so without loss of fidelity. So if ACME 376 can handle your documents, we'll be able to pipe them into CDF without loss (but with lots of work :).
      <br><br>
      Hope This helps,
      <br>
      ~ge~
      gary.edwards
    • Garage Requirements at ZDNet?

      Sorry i didn't think of this before posting, but as a matter of etiquette, are there any garage requirements we should be aware of?
      <br><br>
      I ask because we've run into this problem elsewhere. We are garage challenged, and our participation in discussions where there is a garage entry requirement offends many.
      <br><br>
      The <a href="http://www.robweir.com/blog/2007/10/cracks-in-foundation.html">lord of the garage gestapo</a> has warned us, and i apologize for jumping in here without first disclosing our garage challenged circumstances.
      <br><br>
      ~ge~
      gary.edwards
  • Matusow???s Point

    The point Jason Matusow was making was that it is silly to believe that you can have one open document format (e.g. ODF) to support all applications. Therefore those who argue that OOXML should not be made an open standard because there should only be one, don???t really know what they are talking about. As vendors start competing and try to differentiate themselves from one another, you are inevitably going to have wrangling over what application features document formats should support.

    Matusow???s argument sounds reasonable to me. I believe it is completely unrealistic to expect ODF to support all of Adobe???s, Microsoft???s, Corel???s, and every ISV out there applications. A far better model would be for application vendors to make their proprietary document formats open, so that if need be, they can be read by other applications in the future, and support various application interoperable scenarios.
    P. Douglas
    • Matusow is spreading disinformation

      P. Douglas, Matusow sounds reasonable only if you are not a file format [i]congnoscenti.[/i] He uses an appeal to ignorance. A single universal set of formats is entirely feasible from a technical standpoint; e.g., the example of HTML. But the chances of getting there by opening application-specific formats are dim at best, as the ODF experience teaches.

      You might acquire an entirely different perspective if you spent some time viewing the short sets of slides from the IDABC Open Document Exchange Formats Workshop 2007, which laid down the market requirements for 21 European government IT national bodies. http://ec.europa.eu/idabc/en/document/6474 (.) I particularly recommend Dr. Barbara Held's report to the plenary session linked from this page, http://ec.europa.eu/idabc/en/document/6704/5935 and the four workshop reports linked from the bottom of this page, http://ec.europa.eu/idabc/en/document/6702/5935 (.)

      Those slides reflect a lot of careful research into the issue you and Matusow discuss. And it might also be helpful to realize that having multiple standards for the same functionality defeats the very purpose of standardization, which is to commodify products and stimulate competition.

      Matusow's "protect the ability to innovate" argument is bogus. E.g., all versions of WordPerfect from 6.x through 13.x can exchange documents without loss of data, despite feature mismatches. WordPerfect uses an interoperability framework built around "unknown" tags. When an older version of WordPerfect opens a document containing unrecognized tags, the unrecognized tags are enclosed in "unknown" tags and the tag contents rendered as text or a graphic image. But after editing, when the same document is opened in a newer version of WordPerfect, the tags enclosed by the "unknown" tags are scanned, and if the tags are recognized by that version, the "unknown" tags are removed and the tag contents rendered as intended for the newer feature.

      The bottom line here: innovation need not be hampered by a file format standard and a single standard for the same functionality is unquestionably an unfulfilled market requirement. Matusow's position is pure smoke and mirrors. Where he is correct is that ODF offers no such solution for Microsoft. But ODF is hardly an optimal standard.
      Marbux
      • You are being unrealistic

        [i]Matusow's "protect the ability to innovate" argument is bogus. E.g., all versions of WordPerfect from 6.x through 13.x can exchange documents without loss of data, despite feature mismatches. WordPerfect uses an interoperability framework built around "unknown" tags. When an older version of WordPerfect opens a document containing unrecognized tags, the unrecognized tags are enclosed in "unknown" tags and the tag contents rendered as text or a graphic image. But after editing, when the same document is opened in a newer version of WordPerfect, the tags enclosed by the "unknown" tags are scanned, and if the tags are recognized by that version, the "unknown" tags are removed and the tag contents rendered as intended for the newer feature.[/i]

        What you wrote above has to do with handling different versions of documents within different versions of an application. I believe the point Matusow is making, is that it is unrealistic to expect a software developer to go to one or more bureaucracies, apply to have new and revised features in his application be supported by a universal document format, be given a gigantic manual to see which tags could be used by him, then be told that he has to wait a few years for the bureaucracies to okay the new tags necessary for the universal document to fully support his application. If you announced this on stage in front of room of ISVs, you would be booed off stage.
        P. Douglas
        • Yeah, but ...

          P. Douglas said: "What you wrote above has to do with handling different versions of documents within different versions of an application."

          True, but there is no reason why a similar scheme cannot be used to enable non-lossy interop among different applications that share the same file format. And it could work even for extensions to ODF. ODF 1.0 in fact has the necessary tags, the foreign elements and attributes described in section 1.5 of the specification (albeit they could stand some refinement). But the barrier is that the specification allows implementations to destroy foreign elements and attributes created by other apps. OOo is programmed to destroy them, except for its own and paragraphs and text spans. So we're left in this situation where the most widely used ODF app chews up metadata created by other apps, guaranteeing that only 1-way non-lossy interop with OOo is possible.

          I stand by what I said. Matusow's position is an appeal to ignorance. Standards and innovation can co-exist. And if we are to have full benefit of eXtensible Markup Languages, specifications must be eXtensible without data loss. Both ODF and OOXML fail in that respect. Both specs allow implementations unfettered discretion to trash metadata created by other implementations and still claim conformance.
          Marbux
  • How ironic is it that ...

    <a href="http://enterpriselinuxlog.blogs.techtarget.com/2007/10/26/odf-alliance-hails-record-growth-application-support-for-odf/"> ODF Alliance hails record growth in application support for ODF</a>
    n0neXn0ne
  • RE: ODF infighting could help Microsoft's OOXML

    Mary-

    As we've pointed out to our colleagues & friends in the ODF community, both OOXML <em>and</em> ODF v1.2 are having (going to have) difficulty at ISO.

    ODF v1.2's problem is that it doesn't respect ISO's "JTC 1" directive mandating interoperability. Same OOXML.

    So, the dream of a single universal document format (around which all applications have equal access) has, for the time-being, gone sideways.

    We tried really hard working within the standards process (for years) and our interoperability proposals were rejected by Sun (who leads the ODF OASIS TC by governing the schedule of what proposals will be discussed and what and when voting will or won't occur). They read our whitepaper published in Spanish in Dec 2006 ...

    <a href="http://fussnotes.typepad.com/fr0mat/2007/03/novaticaupgrade.html">"Interoperability: Will the Real Universal File Format Please Stand Up?"</a>

    ... where we first clearly articulated our vision for ODF v1.2 and the necessary changes to the ODF specification to align it with ISO interop directives as well as the high-level of document fidelity required by the enterprise market (simply installing OpenOffice is not enough). Experts were able to grok that the OpenDocument Foundation's interop proposals were necessary also to make the Foundation's ODF Plug-in viable at the ODF format level. We knew it would take Sun's Hamburg engineers 2 to 3 years to catch the OpenOffice application up to our proposed changes in the ODF spec, but hey, that's life.

    Sun blocked the changes we believe to avoid embarrassment if the ODF spec should be able to do things that the application could not handle; and they did it also to honor their $2 Billion hardware & server commitment to Microsoft (in the 2004 pact, meaning to prevent or delay perfect interop with MS documents) and, therefore, to keep the Foundation's plug-in from the playing field.

    All this is merely historical arcana to many observers, and the open source chorus seems to think it's a good idea to avoid extending the life of Microsoft's legacy applications with an EXCELLENT-QUALITY (**INTERNAL**) plug-in ... only weak plug-ins (Microsoft's, Novell's, Sun's) are wanted.

    What seems missing from the discussion is that the market is going to give the <em>de facto</em> standard back to Microsoft, regardless of events at ISO. That is, unless we provide a clean way for enterprises to access their Microsoft formatted documents and play with an open document format standard within BUSINESS PROCESSES.

    While part of the world is swallowing the ODF story, those enterprises who are testing ODF implementations and hitting the brick wall of business processes (Mass ITD [with whom I am under NDA], Denmark, Belgium) are finding it impossible to implement across autonomous networks of decentralized government agencies (each with its own CIO) for practical reasons. People wonder why the ODF policies are drifting back to ODF + OOXML. Wonder no more.

    It's true -- I was a <a href="http://www.onlamp.com/pub/a/onlamp/2007/06/14/achieving-openness-a-closer-look-at-odf-and-ooxml.html">vociferous supporter</a> of ODF, and among the most passionate and committed people to identify <a href="http://marketing.openoffice.org/servlets/ReadMsg?list=dev&msgNo=121">the importance of OpenOffice's file format back in 2002</a>.

    But this year the vendors' tendency to use open standards and open source applications as a bargaining chip to extract (some would say 'extort') money from the deep-pockets Gorilla [that's your client, Microsoft] seems to have won out over good software that works for people.

    CDF is better. It's governance is with the W3C: does anyone dare question the integrity of Sir Tim? And it is a format -- or I should say a framework for open formats -- which does something ODF can't do at all and OOXML can only do with Microsoft products -- it can go Mobile.
    swhiser
  • RE: ODF infighting could help Microsoft's OOXML

    <p>Please forgive my long post there.</p>

    <p>Our view is that not addressing the problems of ODF is helping Microsoft.</p>
    swhiser