Skip to main content

Home/ Document Wars/ Group items tagged harmonization

Rss Feed Group items tagged

Filter: All | Bookmarks | Topics Simple Middle
Gary Edwards

The Case for Harmonization (that IBM will vote against anyway) « A Frantic Op... - 0 views

robweird.wordpress.com/...t-ibm-will-vote-against-anyway

foundation harmonization interop oasis odf ooxml opendocument openxml

shared by Gary Edwards on 09 Feb 08 - Cached
  • The Case for Harmonization (that IBM will vote against anyway) In my recent post, I discussed the case for harmonization, mainly due to trying to portray a more kindly, conciliatory face in the “standards krieg” that I was enjoying so much. I have been forced to take a different tack, in light of being hung out to dry by my more business-focused IBM comrades and the work that the enemy has done in sprucing up the spec. However, as my closest friends know, for me, there are no half-victories, so you can rest assured that I will not settle for this weak “harmonization” compromise. I set out my (and IBM’s) stall some time ago on this, and as those on the Open Document Foundation know, any attempt at harmonization shall be met with swift and final retribution.  They were ejected from the odf-coven just days after their impudence. I have baited my trap, inviting this “harmonization” in my lair (the OASIS ODF TC) where I can bog them down in a morass of incompetence, bickering and politicking, so no new standard is ever ratified.  I have already been practicing for this, as you can see, by the ODF 1.1 and 1.2 specs.
Gary Edwards

ODF and OOXML - The Final Act - 0 views

www.idm.net.au/story.asp

din fraunhofer harmonization iso odf ooxml opendocument openxml

shared by Gary Edwards on 04 Feb 08 - Cached
  • 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.
  • ODF 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.
    • Gary Edwards
      Gary Edwards on 04 Feb 08
       
      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 b
    • Gary Edwards
      Gary Edwards on 04 Feb 08
       
      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 th
  • ...1 more annotation...
    • Gary Edwards
      Gary Edwards on 04 Feb 08
       
      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.
  • Gary Edwards on 04 Feb 08
     
    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.
Gary Edwards

OOXML-ODF: The Harmonization Hope Chest | Orcmid's Lair - 0 views

orcmid.com/...f-harmonization-hope-chest.asp

shared by Gary Edwards on 09 Feb 08 - Cached
  • 4. The Reality in the Punchbowl Meanwhile, Sam Hiser offers a different impression of the DIN effort [4]: "The ODF-to-OOXML harmonization effort being hosted by the German standards group, DIN, is Europe's best effort to resolve our Mexican Standoff between Microsoft, Sun and IBM. Even though harmonization is laughably complex and will not work unless the applications are harmonized too, the best and brightest of Germany are left to hope for success."  [emphasis mine: dh] Although the mission of the German effort is translation (Übersetzung), not harmonization, I find there is a very important point that is not made often enough:  People write, read, and edit office documents with little, if any, understanding of the particular format that makes them persistent in digital form.  The XML-based open formats do not change that.   People adapt to the software/device they are using by trial and error.  We train ourselves to obtain the visible results that we want.  Different people obtain superficially similar results by quite different means.   Even when someone has gone to the trouble to create style sheets, forms, macros, templates and other format-impacting aids, it is very loosey-goosey in practice.  And it still does not require paying attention to the file format.  
Gary Edwards

Harmonizing ODF and OOXML: The DIN - ISO "Harmonization" Project - 0 views

www.fokus.fraunhofer.de/...DIN-E.pdf

din harmonization iso odf ooxml

shared by Gary Edwards on 27 Jan 08 - No Cached
  • Gary Edwards on 27 Jan 08
     
    Contact: Gerd Schürmann Fraunhofer Institute FOKUS Tel +49 (0)30 3463 7213 gerd.schuermann@fokus.fraunhofer.de Berlin
  • Gary Edwards on 27 Jan 08
     
    At a recent meeting in Berlin, The DIN Fraunhoffer Institute pushed forward with the EU project to harmonize ODF and OOXML. Microsoft and Novell attended the harmonization effort. Sun and IBM did not. This in spite of invitations and pleas to cooperate coming into Sun and IBM from government officials across the European continent. We've long insisted that inside the OASIS ODF Technical Committee walls there have been years of discussions concerning ODF compatibility with the billions of MS binary documents, and ODF interoperability with MSOffice. Sun in particular has been very clear that they will not compromise OpenOffice application innovations to improve interoperability with MSOffice and MSOffice documents. The infamous List Enhancement Proposal donnybrook that dominated OASIS ODF discussions from November 20th, 2006, to the final vote in April of 2007, actually begins with a statement from Sun arguing that application innovation is far more important than market demands for interoperability. The discussions starts here: Suggested ODF1.2 items The first of many responses declaring Sun's position that innovation trumps interop, and that if anyone needs to change their application it should be Microsoft: see here DIN will submit a "harmonization" report with recommendations to ISO JTC1. I wonder if IBM and Sun will continue to insist on government mandated "rip out and replace" solutions based on their ODF applications when ISO and the EU have set a course for "harmonization"?
Gary Edwards

The Harmonization Myth: ISO Approval of Open XML Will Hurt Interoperability - 0 views

blog.hvorom.dk/...ill-Hurt-Interoperability.aspx

din fraunhofer harmonization iso odf ooxml opendocument openxml

shared by Gary Edwards on 31 Jan 08 - Cached
  • This myth is rather silly if you think about it. Here is why… When people talk about interoperability and Open XML they do so primarily in the context of ODF. The story goes something like this: 1. Open XML is not interoperable with ODF 2. Open XML should be interoperable with ODF because ODF is already an ISO standard! 3. Hence: Open XML is no good, because it is not interoperable with ODF and therefore Open XML should not be an ISO standard!!!
    • Gary Edwards
      Gary Edwards on 31 Jan 08
       
      Forget ISO approval of OOXML. I would rather see ISO enforce the current directive that ODF be brought into compliance with existing ISO Interoperability requirements. Then and only then should ISO then consider OOXML.
      The reason for this approach? If ODF wiere compliant with existing ISO Interop Requirements, there would probably be some hope of harmonizing ODF and OOXML. Until ODF is stripped of it's application specific settings, and fully documented, we can hardly beging the process of figuring out harmonization.
      ODF 1.0 has four gapping holes that must be tended to before ISO proceeds any furhter with either ODF or OOXML. The holes are that ODF numbered lists, formulas and the presentation layer (styles) are woefully underspecified. The fourth problem is that ODF is seriously lacking an interoperability framework.
      These ODF problems can of course be traced back to the fact that ODF is application specific and bound to the "semantics and capabilities" of OpenOffice. That creates all kinds of problems. OOXML on the other hand is even worse. OOXML is application, platform and vendor specific!!!! If ODF were brought up to snuff, we could reasonably start work on harmonization. Thereby eliminating the need to standardize two file formats for the same purposes. Until ODF is fixed, what's the world to do?
      ~ge~
Gary Edwards

Independent study advises IT planners to go OOXML | All about Microsoft | ZDNet.com - 0 views

blogs.zdnet.com/microsoft

burtongorup cdf css garyedwards maryjo odf okelly ooxml w3c xhtml

shared by Gary Edwards on 20 Jan 08 - Cached
  • “ODF represents laudable design and standards work. It’s a clean and useful design, but it’s appropriate mostly for relatively unusual scenarios in which full Microsoft Office file format fidelity isn’t a requirement. Overall, ODF addresses only a subset of what most organizations do with productivity applications today.” The report continues: “ODF is insufficient for complex real-world enterprise requirements, and it is indirectly controlled by Sun Microsystems, despite also being an ISO standard. It’s possible that IBM, Novell, and other vendors may be able to put ODF on a more customer-oriented trajectory in the future and more completely integrate it with the W3C content model, but for now ODF should be seen as more of an anti-Microsoft political statement than an objective technology selection.”
    • Gary Edwards
      Gary Edwards on 20 Jan 08
       
      Mary Jo takes on the recently released Burton Group Report comparing OOXML and ODF. Peter O'Kelly, one of the Burton Group authors, once famously said, "ODF is a great format if you live in an alternative universe where MSOffice doesn't exist!" This observation speaks to the core problem facing ODF and those who seek to implement the ODF standard: ODF was not designed for the conversion of MSOffice documents. Nor was ODF designed to work with MSOffice applications. Another way of saying this is to state that ODF was not designed to be interoperable with MSOffice documents, applications and bound processes. The truth is that ODF was designed for OpenOffice/StarOffice. It is an application specific format. Both OOXML and ODF do a good job of separating content from presentation (style). The problem is that the presentation - layout layers of both ODF and OOXML remains bound to specific applications producing it. While the content layers are entirely portable and can be exchanged without information loss, the presentation layers can not. Microsoft makes no bones about the application specific design and purpose of OOXML. It's stated right in the Ecma 376 charter that OOXML was designed to be compatible with MSOffice and the billions of binary documents in MSOffice specific binary formats. The situation however is much more confusing with ODF. ODF is often promoted as being application, platform and vendor independent. After five years of development though, the OASIS ODF TC has been unable to strip ODF of it's OpenOffice/StarOffice specific aspects. ODF 1.0 - ISO 26300 had three areas that were under specified; meaning these areas were described in syntax only, and lacked the full semantics demanded by interoperable implementations. Only OpenOffice and StarOffice code base applications are able to exchange documents with an acceptable fidelity. The three under specified areas of ODF are: Lists (numbered), F
Gary Edwards

Can't We All Just Get Along? - 0 views

www.gcn.com/...45014-1.html

ecma iso microsoft ms-ooxml oasis odf officeopenxml opendocument openxml

shared by Gary Edwards on 12 Dec 07 - Cached
  • Gary Edwards on 12 Dec 07
     
    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 doc
Gary Edwards

Harmonizing ODF and OOXML using NameSpaces | Tim Bray's Thought Experiment - 0 views

www.tbray.org/...Office-XML

bray florian-reuter namespaces odf ooxml opendocument openxml

shared by Gary Edwards on 07 Mar 08 - Cached
  • First, what if Microsoft really is doing the right thing? Second, how can we avoid having two incompatible file formats? [Update: There’s been a lot of reaction to this piece, and I addressed some of those points here.]
  • On the technology side, the two formats are really more alike than they are different. But, there are differences: O12X’s design center, Microsoft has said repeatedly, is capturing the exact semantics of the billions of existing Microsoft Office documents. ODF’s design center is general-purpose reusability, and leveraging existing standards like SVG and MathML and so on.
    • Gary Edwards
      Gary Edwards on 07 Mar 08
       
      OOXML, or to put it more accurately "O12X" as Tim suggests, is designed to capture the exact semantics of MSOffice 12. In fact, OOXML is an XML encoding of the MSOffice 12 in-memory-binary-representation dump. When it comes to representing older versions of MSOffice documents, OOXML must use legacy compatibility settings" to capture the semantics. And it's not an exacting science to say the least. The thing is, OpenOffice ODF uses the same technique resulting in application specific ODF documents with over 150 un docuemnted, unspecified "compatibility settings". After years of requests from the OASIS ODF Technical Committee to document these application specific settings, Sun has yet to provide any kind of response. And this kills ODF interoperability. Especially concerning KOffice. There is also the issue of OASIS ODF high-jacked namespaces. When ODF applications reference a namespace, the actual URL is high-jacked with http://oasis-open.org/???? replacing the proper namespace of http://W3C.org/???? This high-jacking impacts the oDF reuse of important W3C technologies such as XForms, SVG, MathML, and SMiL. So where's the problem you ask? Well, when a developer imports or tries to process an OpenOffice ODF document, they rely on say the W3C XForms specification for their understanding. OpenOffice however seriously constrains the implementation of XForms, SVG, MathML, RDFa and RDF/XML. This should be reflected in the new namespace. However, if you follow the high-jacked URL, you'll find that there is nothing there. There is no specification describing how OpenOffice implements XForms in ODF! This breaks developer libraries, breaks ODF interoperability between ODF applications, and, offends the W3C to no end. So i think it might be fair to say that at this point, neither ODF or OOXML have come close to fulfilling their design objectives.
  • The capabilities of ODF and O12X are essentially identical for all this basic stuff. So why in the flaming hell does the world need two incompatible formats to express it? The answer, obviously, is, “it doesn’t”.
    • Gary Edwards
      Gary Edwards on 07 Mar 08
       
      Exactly!! Except for one thing that Tim misses: the presentation layers of both ODF and OOXML are application specific. It is also the application specific nature of OpenOffice ODF presnetation layer that prevents interoperability with KOffice ODF! There is near zero interop between OpenOffice and KOffice, and KOffice has been a contributing member of the OASIS ODF TC for FIVE YEARS! It's the presentation layer Tim. ODF and OOXML are application specific formats because their presentation layers are woefully applicaiton specific and entirely reflective of each applications layout engine and feature set implementation model. I often imagine what ODF would be like if back in 2001, Sun had chosen to implement CSS as the OpenOffice presentation layer instead of the quirky but innovative, and 100% application specific automatic-styles presentation layer we now see in ODF. Unlike ODF's "automatic-styles", CSS is a totally application independent presentation model prized exactly for it's universal interoperability!
  • ...1 more annotation...
  • The ideal outcome would be a common shared office-XML dialect for the basics—and it should be ODF (or a subset), since that’s been designed and debugged—then another extended vocabulary to support Microsoft features , whether they’re cool new whizzy features or mouldy old legacy features (XML Namespaces are designed to support exactly this kind of thing). That way, if you stayed with the basic stuff you’d never need to worry about software lock-in; the difference between portable and proprietary would be crystal-clear. And, for the basic stuff that everybody uses, there’d be only one set of tags. This outcome is technically feasible. Who could possibly be against it?
    • Gary Edwards
      Gary Edwards on 07 Mar 08
       
      Bingo! ODF and OOXML should strip off the application specific complexities and seek a neutral generic XML representation of basic document structures common to ALL documents. Then, use the XML NameSpace mechanism to extend (with proper descriptions) the generic to include the volumes of application specific features that now fill each format. One thing i disagree with Tim about. And that's that the interop of ODF and OOXML is hopelessly broken. The OpenDocument Foundation tried for over a year to close the compatibility gap between ODF and MSOffice binary - xml documents. The OASIS ODF TC would have none of it. IBM and Sun are set on a harsh course of highly disruptive and costly rip-out-and-replace of MSOffice based on government mandates for ODF. There is no offer of compromise to be had. On the Microsoft side, even if they did want to compromise (a big IF), there is that problem of over 550 million MSOffice workgroup-workflow desktops to contend with. The thing is, the only way to harmonize, merge, convert or translate between two application specific formats is to actually harmonize the applications themselves. While the generic subset is a worthy goal, the process would be fraught with real world concerns that the existing application workflows are not disrupted. My proposal? Demand that ODF and OOXML application vendors provide format options for PDF, and the W3C's family of formats: (X)HTML5, (X)HTML - CSS, and CDF (XHTML-CSS-XForms-SVG-SMil-MathML). That will do it. We might never see the quality of interoperability we had hoped for in a desktop application to application scenario. But we can and should fully expect high quality interop at the higher level of the Web. You can convert an application specific format to a generic like CDF. By setting up conversion channels to the same CDF profile within MSOffice, OpenOffice, KOffice, Symphony, and Google Docs, we can achieve the universal interoperabil
Gary Edwards

Wizard of ODF: OASIS invited to join Microsoft in the DIN technical report - harmoniz... - 0 views

www.oasis-open.org/...msg00040.html

din eu harmonization iso oasis odf ooxml xml

shared by Gary Edwards on 29 Jan 08 - Cached
  • the WG is busy working on a first draft. This'll include mainly work in Wordprocessing. Spreadsheet and Presentation is still in the very early work. So help from the ODF TC would be great --- and a liaison would make sense IMHO. To give you an idea why help from the ÓDF TC would be needed I'll briefly outline some questions which arose: * Need for more use-cases, i.e. feasable interop scenarios * Discussions of unspecified behaviour (e.g numbering in 1.0, spreadsheet formulas, compatibilty options, etc.) and their impact on interop scenarios * Questions regaring generic settings like e.eg. form:control-implementation="ooo:com.sun.star.form.component.Form", or tweaking a la http://www.openoffice.org/issues/show_bug.cgi?id=51726. * Possible interop problems not handled by the specs (e.g. graphics, WMF, EMF, SVM, etc.) or e.g. font metrics and font embedding. As you see there are a lot of overlapping areas with eg. the "ODF interop" we dealt with in the workshop in Barcelona. [This issue is hosted in the Adoption TC, right? Maybe this TC is also suited as a liaison partner?]
    • Gary Edwards
      Gary Edwards on 29 Jan 08
       
      Uh Oh. Microsoft and Novell joined the EU's call to harmonize ODF and OOXML, but Sun and IBM refused the invite. Now we have the invite in front of the OASIS ODF TC!. Is there any rock big enough for them to hide under if they also refuse?
      And if the OASIS ODF does join the EU-DIN-ISO effort, where doe stha tleave IBM, Sun and their inistance on a politically mandated "rip out and replace" as the only acceptable solution?
Gary Edwards

ODF Civil War: Bulll Run - Suggested Changes on the Metadata proposal - OASIS ODF - 0 views

www.oasis-open.org/...msg00072.html

metadata odf odf-civil-war ooxml

shared by Gary Edwards on 12 Dec 07 - Cached
  • From our perspective it would be better to aim for doing the job in ODF 1.2, even if that requires delay. We will oppose ODF 1.2 at ISO unless the interoperability warts are cleaned up. What the market requires is no longer in doubt. See the slides linked above and further presentations linked from this page, < http://ec.europa.eu/idabc/en/document/6474/5935>. Substantial progress toward those goals would seem to be mandatory to maintain Europe's preference for a harmonized set of file formats that uses ODF to provide the common functionality. Delaying commencement of such work enhances the likelihood that governments will tire of waiting for ODF to become interoperable with MS Office and simply go with MOOXML. We may not be able to force Microsoft to participate in the harmonization work, but we will be in a far better position if we have done everything we can in aid of that interoperability without Microsoft's assistance. As the situation stands, we have what is known in the U.S. as a "Mexican stand-off," where neither side has taken a solitary step toward what Europe has requested. We have decided to do that work via a fork of ODF; it is up to this TC whether it wishes to cooperate in that effort.
  • Gary Edwards on 12 Dec 07
     
    This is the famous marbux response to Sun regarding Sun's attempt to partially implement ODF 1.2 XML-RDF metadata.  It's a treasure.

    There is one problem with marbux's statement though.  We had decided long ago not to fork ODF even if the five iX "interoperability enhancement" proposals were refused by the OASIS ODF TC.   This assurance was provided to Massachusetts CIO Louis Gutierrez witht he the first ODF iX proposal submitted on July 12th, 2006.  Louis ended up signing off on three iX proposals before his resignation October 4th, 2006.

    The ODF iX enhancements were essential to saving ODF in Massachusetts.  Without them, there was no way our da Vinci plug-in could convert existing MSOffice documents and processes to ODF with the needed round trip fidelity.

    For nearly a year we tried to push through some semblance of the needed iX enhancements.  We also tried to push through a much needed Interoperability Framework, which will be critical to any ISO approval of ODF 1.2.

    Our critics are correct in that every iX effort was defeated, with Sun providing the primary opposition. 

    Still rather than fork ODF, we are simply going to move on. 

    On October 4th, 2006, all work on ODF da Vinci ended - not to be resumed unless and until we had the ODF iX enhancements we needed to crack the MSOffice bound workgroup-workflow business process barrier.

    In April of 2007, with our OASIS membership officially shredded by OASIS management, bleeding from the List Enhancement Proposal doonybrook, and totally defeated with our hope - the metadata XML-RDF work, we threw in the towel.

    Since then we've moved on to CDF, the W3C Compound Document format.  Incredibly, CDF is able to do what ODF can not.  With CDF we can solve the three primary problems confronting governments and MSOffice bound workgroups everywhere. 

    The challenge for these g
Gary Edwards

War rages on over Microsoft's OOXML plans: Insight - Software - ZDNet Australia - 0 views

www.zdnet.com.au/...0,139023769,339284737,00.htm

australia cdf interop iso microsoft odf ooxml opendocument

shared by Gary Edwards on 27 Dec 07 - Cached
  • "We feel that the best standards are open standards," technology industry commentator Colin Jackson, a member of the Technical Advisory committee convened by StandardsNZ to consider OOXML, said at the event. "In that respect Microsoft is to be applauded, as previously this was a secret binary format." Microsoft's opponents suggest, among a host of other concerns, that making Open XML an ISO standard would lock the world's document future to Microsoft. They argue that a standard should only be necessary when there is a "market requirement" for it. IBM spokesperson Paul Robinson thus describes OOXML as a "redundant replacement for other standards". Quoting from the ISO guide, Robinson said that a standard "is a document by a recognised body established by consensus which is aimed at achieving an optimum degree of order and aimed at the promotion of optimum community benefits". It can be argued that rather than provide community benefit, supporting multiple standards actually comes at an economic cost to the user community. "We do not believe OOXML meets these objectives of an international standard," Robinson said.
  • Gary Edwards on 27 Dec 07
     
    "aimed at achieving an optimum degree of order .... and .... aimed at the promotion of optimum community benefits:. Uh, excuse me Mr. Robinson, tha tsecond part of your statement, the one concerning optimum community benefits - that would also disqualify ODF!! ODF was not designed to be compatible with the 550 million MSOffice desktops and their billions of binary docuemnts. Menaing, these 550 million users will suffer considerable loss of information if they try to convert their existing documents to ODF. It is also next to impossible for MSOffice applications to implement ODF as a fiel format due to this incompatbility. ODF was designed for OpenOffice, and directly reflects the way OpenOffice implements specific document structures. The problem areas involve large differences between how OpenOffice implments these structures and how MSOffice implements these same structures. The structures in question are lists, fields, tables, sections and page dynamics. It seems to me that "optimum community benefits" would include the conversion and exchange of docuemnts with some 550 million users!!!! And ODF was clearly not designed for that purpose!
  • Gary Edwards on 27 Dec 07
     
    I don't agree with this statement from Microsoft's Oliver Bell. As someone who served on the OASIS ODF Technical Committee from it's inception in November of 2002 through the next five years, i have to disagree. It's not that Microsoft wasn't welcome. They were. It's that the "welcome" came with some serious strings. Fo rMicrosoft to join OASIS would have meant strolling into the camp of their most erstwhile and determined competitors, and having to ammend an existing standard to accomodate the implementation needs of MSOffice. There is simply no way for the layout differences between OpenOffice and MSOffice to be negotiated short of putting both methodologies into the spec. Meaning, the spec would provide two ways of implementing lists, tables, fields, sections and page dynamics. A true welcome would have been for ODF to have been written to accomodate these diferences. Rather than writing ODF to meet the implementation model used by OepnOffice, it would have been infinitely better to wrtite ODF as a totally application independent file format using generic docuemnt structures tha tcould be adapted by any application. It turns out that this is exactly the way the W3C goes about the business of writing their fiel format specifications (HTML, XHTML, CSS, XFORMS, and CDF). The results are highly interoperable formats that any applciation can implement.
  • Gary Edwards on 27 Dec 07
     
    You can harmonize an application specific format with a generic, applicaiton independent format. But you can't harmonize two application specific formats!!!!
    The easy way to solve the document exchange problem is to leave the legacy applications alone, and work on the conversion of OOXML and ODF docuemnts to a single, application independent generic format. The best candidate for this role is that of the W3C's CDF.
    CDF is a desription of how to combine existing W3C format standards into a single container. It is meant to succeed HTML on the Web, but has been designed as a universal file format.
    The most exciting combination is that of XHTML 2.0 and CSS in that it is capable of handling the complete range of desktop productivity office suite documents. Even though it's slightly outside the W3C reach, the most popular CDF compound is that of XHTML, CSS and JavaScript. A combination otherwise known as "AJAX".
Gary Edwards

Harmonization and Interop: The dizzying dance of ODF, OOXML, and CDF - 0 views

digg.com/...izzying_dance_of_ODF_OOXML_CDF

cdf ibm interop oasis odf ooxml opendocument openxml uic w3c

shared by Gary Edwards on 06 Feb 08 - Cached
  • With the ISO BRM fast approaching, the harmonization of ODF and OOXML is all the rage. The legendary marbux takes on this discussion arguing that ODF and OOXML both lack the interoperability framework needed to meet ISO directives describing interop requirements. He argues that interop between MSOffice and OpenOffice can be achieved using CDF.
Alex Brown

Doug Mahugh : Tracked Changes - 0 views

blogs.msdn.com/...tracked-changes.aspx

shared by Alex Brown on 14 May 09 - Cached
  • Much was made during the IS29500 standards process of the difference in the size of the ODF and Open XML specifications.  This is a good example of where that difference comes from: in this case, a concept glossed over in three vague sentences of the ODF spec gets 17 pages of documentation in the Open XML spec.
    • Alex Brown
      Alex Brown on 14 May 09
       
      This is the nub; OOXML may be overweight, but ODF is severely undernourished as a spec.
  • Paul Merrell on 14 May 09
     
    Alex, I know from your previous writings that you do not regard OOXML as completely specified. But your post might be so misinterpreted. In my view, neither ODF nor OOXML has yet reached the threshold of eligibility as an international standard, completely specifying "clearly and unambiguously the conformity requirements that are essential to achieve the interoperability." ISO/IEC JTC 1 Directives, Annex I. . OOXML is ahead of ODF in some aspects of specificity, but the eligibility finish line remains beyond the horizon for both.
  • ...2 more comments...
  • Alex Brown on 14 May 09
     
    Paul, that's right - though so far the faulty things in OOXML turn out to be more round the edges as opposed to ODF's central lapses. Still, it's early days in the examination of OOXML so I'm reserving making any firm call on the comparative merits of the specs until I have read a lot (a lot) more. Is there an area of OOXML you'd say was particularly underbaked? I'm quite interested in the fact that neither of these beasts specify scripting languages ...
  • Paul Merrell on 14 May 09
     
    Hi, Alex, Most seriously, there are no profiles and accompanying requirements to enable less featureful apps to round trip documents with more featureful apps, a la W3C Compound Document by Reference Framework. That's an enormous barrier to market entry and interoperability. That defect reacts synergistically with the dearth of semantic conformity requirements, with the incredible number of options including those 500+ identified extension points, and with a compatibility framework for extensions that while a good start leaves implementers far too much discretion in assigning and processing compatibility attributes. There are also major harmonization issues with other standards that get in the way of transformations, where Microsoft originally rolled its own rather than embracing existing open standards. I think it not insignificant that OOXML as a whole is available only under a RAND-Z pledge rather than being available for the entire world. The patent claims need to be identified and worked around or a different rights scheme needs Microsoft management's promulgation. This is a legal interoperability issue as opposed to technical, but an interoperability barrier nonetheless, an "unnecessary obstacle to international trade" in the sense of the Agreement on Technical Barriers to Trade. And absent a change by Microsoft in its rights regime, the work-arounds are technical. This is not to suggest that ODF lacks problems in regard to the way it implements standards incorporated by reference. The creation of unique OASIS namespaces rather than doing the needed harmonizing work with the relevant W3C WGs is a large ODF tumor in need of removal and reconstructive surgery. I'm not sure what is happening with the W3C consultation in that regard. I worked a good part of the time over several months comparing ODF and Ecma 376, evaluating their comparative suitability as document exchange formats. I gave up when it climbed well past 100 pages in length because the de
  • Paul Merrell on 14 May 09
     
    1. Full-featured editors available that are capable of not generating application-specific extensions to the formats? 2. Interoperability of conforming implementations mandatory? 3. Interoperability between different IT systems either demonstrable or demonstrated? 4. Profiles developed and required for interoperability? 5. Methodology specified for interoperability between less and more featureful applications? 6. Specifies conformity requirements essential to achieve interoperability? 7. Interoperability conformity assessment procedures formally established and validated? 8. Document validation procedures validated? 9. Specifies an interoperability framework? 10. Application-specific extensions classified as non-conformant? 11. Preservation of metadata necessary to achieve interoperability mandatory? 12. XML namespaces for incorporated standards properly implemented? (ODF-only failure because Microsoft didn't incorporate any relevant standards.) 13. Optional feature interop breakpoints eliminated? 14. Scripting language fully specified for embedded scripts? 15. Hooks fully specified for use by embedded scripts? 16. Standard is vendor- and application-neutral? 17. Market requirement -- Capable of converging desktop, server, Web, and mobile device editors and viewers? (OOXML better equipped here, but its patent barrier blocks.)
  • Paul Merrell on 14 May 09
     
    Didn't notice that my post before last was chopped at the end until after I had posted the list. Then Diigo stopped responding for a few minutes. Anyway, the list is short summation of my research on the comparative suitabilities of ODF 1.1 and Ecma 376 as document exchange formats, winnowed to the defects they have in common except as noted. The research was never completed because in the political climate of the time, the world wasn't ready to act on the defects. The criteria applied were as objective as I could make them; they were derived from competition law, JTC 1 Directives, and market requirements. I think the list is as good today in regard to IS 29500 as it was then to Ecma 376, although I have not taken an equally deep dive into 29500. You might find the list useful, albeit there is more than a bit of redundancy in it.
Gary Edwards

But can money buy love? :: Another Microsoft Sponsored OOXML Study - 0 views

www.microsoft-watch.com/...fts_sponsored_ooxml_study.html

cdf interoperability ms-xml odf officeopenxml ooxml opendocument vista-stack

shared by Gary Edwards on 12 Dec 07 - Cached
  • Gary Edwards on 12 Dec 07
     
    Joe Wilson of Microsoft Watch knocks another one out of the park. Why is it that so few in the media get it? Or anyone else for that matter? Matt Assay gets it. But few understand the Vista Stack and the importance of OOXML in the transition of the monopoly base from MSOffice to the Vista Stack. No doubt the arrogance of those who dare challenge Microsoft is both a necessary blessing and guaranteed curse. Take for instance the widely held assumption that Microsoft invented MS-XML (OfficeOpenXML) in response to OpenDocument (ODf). This is false, misleading and will inevitably result in a FOSS death spiral in the face of a Vista Stack juggernaut. But it sure does feel good.

    Joe Wilson at Microsoft Watch points out the real reason for MS-XML, and why ISO approval of OOXML is so important. Microsoft needs OOXML approved as an international standard because OOXML is the binding model for the emerging Vista Stack of loosely coupled but information integrated applications.

    The Vista Stack model converges desktop, server, device and web information systems using OOXML-Smart Documents, .NET 3.0 and the XAML presentation layer as the binding components.

    The challenge for Microsoft is to migrate existing MSOffice bound business processes, line of business integrated apps, and advanced add-ons to the Exchange/SharePoint Hub. Once the existing documents, applications (MSOffice) and processes are migrated to the E/S Hub, they can be bound tightly to the rest of the Vista Stack.

    Others see OOXML as some sort of surrender or late recognition that the salad days of MSOffice are over. They jubilantly point to Web 2.0, Office 2.0 and rise of the LiNUX Desktop as having ushered in this end of monopoly for MSOffice. Like the ODf champions, these people are similarly sadly mistaken!

    While they celebrate, Microsoft is quie
Gary Edwards

[office] List Proposal Vote Deadline on Wednesday - 0 views

www.oasis-open.org/...msg00006.html

interoperability odf ooxml

shared by Gary Edwards on 12 Dec 07 - Cached
  • Gary Edwards on 12 Dec 07
     
    The List Proposal donnybrook refuses to go away. In a recent argument concerning Rick Jellife's controversial post, "Harmonization by augmenting ODF with OOXML elements", ODF defender Bruce D'Arcus pointed to his own OASIS ODF TC message thread in an effort to defend Sun.

    The issue is that Rick Jellife and others are wondering why it is that Sun opposes interoperability enhancements to ODF that would solve the problem of converting MS binary and XML documents to ODF, and back.

    Bruce's reference introduces the incredibly acrimonious "List Proposal Vote Deadline" thread. He also brings up a really important problem. The ODF Charter does not reference compatibility with existing file formats as a key objective.

    The consequences of this neglect in the ODF Charter is that every time the issue of compatibility with existing MS binary or xml documents comes up, Sun claims it's, "Outside the Charter and Out of Scope".

    I've been hearing that excuse for the last five years!! Meanwhile, the world has discovered it's impossible to implement ODF without also having to totally rip out and replace MSOffice. And that means a costly re engineering all existing business processes, line of business integrated apps, and assistive technology add-ons.

    ODF failed in Massachusetts because Sun and OASIS TC refused to recognize the importance of an ODF plugin for MSOffice offering the same high fidelity "round trip" conversion as the OOXML plugin for MSOffice.

    For one reason or another, big ODF vendors are locked into a "rip out and replace - legislative mandate" strategy. A strategy to limit the interoperability of ODF with MS documents, applications, and processes has only one consequence. As Massachusetts proved to the world, ODF is impossible to implement if you have workgroups and business processes based
Gary Edwards

Indecision in Redmond as Web apps charge : Office 2.0 and Google Apps - 0 views

weblog.infoworld.com/...013777.html

cdf html odf officeopenxml ooxml opendocument

shared by Gary Edwards on 12 Dec 07 - Cached
  • the fact is that Redmond could own this new space if it wanted to. All it would need to do is push interoperability and integration between lightweight Web versions of Office applications and its desktop fatware. Advanced features would be absent from the lightweight versions, but the company could ensure any Office doc would load on the Web -- whatever new desktop service packs and upgrades might appear -- and online document management could be integrated with Windows for offline access.
  • Gary Edwards on 12 Dec 07
     
    Great quote from Eric Knorr.  He hits the nail on the head here, pointing out the problem Office 2.0  Web Apps and SaaS apps face:  If these Web wonders have interoperability and high fidelity document exchange with MSOffice, their collaborative features are value added wonders for existing business processes and workgroup-workflow scenarios.  If, on the other hand they lack this level of interop - integration with MSOffice documents and processes, the value add becomes a problematic split in a business process.  The only way to overcome that kind of a split is to take the entire process.  Which is difficult for lightweight mashup happy web wonders to do.

    Which leaves each and every one of these Office 2.0 - Web 2.0 - Saas Apps vulnerable to Microsoft.  As long as Micrsoft owns the interop-integration keys to MSOffice, the web wonders live a precarious life.  At any time Microsoft can swoop in and take it all.

    Today, the MSOffice OOXML file format displays perfectly in a browser.  It's 100% web ready, but only the MS Stack of applications gets to play.  Web wonders are not likely to recieve a Redmond invite now or ever.

    Which brings us to the issue of the da Vinci plug-in for MSOffice.  da Vinci is a clone of the OOXML plug-in for MSOffice, and fully leverages the same internal conversion process that OOXML enjoys.  It can achieve the same high fidelity "round trip" conversion that OOXML is capable of.  Maybe even better. 

    The problem for da Vinci isn't conversion fidlelity.  Nor is it capturing  business process important VBa scripts, macros, OLE, and security settings.  da Vinci can do that just fine.  The problem is that da Vinci cannot pipe MSOffice developer platform documents into ODF!!  For the love of five generic eXtensions, called the iX "interoperability enhancements", which the OASIS ODF TC blew off, ODF
Gary Edwards

Singing Kumbaya -- Linux leaders plot hapless counterattack on Microsoft - 0 views

talkback.zdnet.com/5208-3513-0.html

interoperability iso linux odf officeopenxml ooxml opendocument patents xml

shared by Gary Edwards on 12 Dec 07 - Cached
  • have you noticed that IBM is softening their position on "harmonization"? There are a number of events to consider that might have influenced this change in tone:
  • Gary Edwards on 12 Dec 07
     
    More in that same "LiNUX Leaders plot counter attack on Microsoft" thread at ZDNet.  This time the issue is what has caused IBM to sing a differnet tune?  The tune known as "harmoniation".
Gary Edwards

5 Things Microsoft Must Do To Reclaim Its Mojo In 2008 -- InformationWeek - 0 views

www.informationweek.com/...showArticle.jhtml

cdf ibm iso oasis odf ooxml opendocument openoffice sun symphony

shared by Gary Edwards on 11 Jan 08 - Cached
  • Instead of fighting standards, Microsoft (NSDQ: MSFT) needs to get on board now more than ever. With open, Web-based office software backed by the likes of IBM (NYSE: IBM) (think Lotus Symphony) and Google (NSDQ: GOOG) now a viable option, users—especially businesses frustrated by Microsoft's format follies (many are discovering that OOXML is not even fully backwards-compatible with previous versions of Microsoft Word)--can now easily switch to an online product without having to rip and replace their entire desktop infrastructure.
    • Gary Edwards
      Gary Edwards on 11 Jan 08
       
      This article discusses how Microsoft might change their ways and save the company. This particular quote concerns Microsoft support for standards, and their fight to push MS OOXML through ISO as an alternative to ISO approved ODF 1.0.
      The thing is, ODF was not designed for the conversion of MSOffice documents, of which there are billions. Nor was ODF designed to be implemented by MSOffice. ODF was designed exactly for OpenOffice, which has a differnet model for impementing basic docuemnt structures than MSOffice.
      So a couple of points regardign this highlight:
      The first is that IBM's Lotus Symphony is NOT Open Source. IBM ripped off the OpenOffice 1.1.4 code base back when it was dual licensed under both SSSL and LGPL. IBM then closed the source code adding a wealth of proprietary eXtensions (think XForms and Lotus Notes connections). Then IBM released the proprietary Symphony as a free alternative to the original Open Source Community "OpenOffice.org".
      If Microsoft had similarly ripped off an open source community, there would be hell to pay.
      Another point here is the mistaken assumption that users can easily switch from MSOffice to an on-line product like Google Docs or ZOHO "without having to rip our and replace their entire desktop infrastructure."
      This is a ridiculous assumption defied by the facts on the ground. Massqchusetts spent two years trying to migrate to ODF and couldn't do it. Every other pilot study known has experienced the same difficulties!
      The thing about Web 2.0 alternatives is that these services can not be integrated into existing business processes and MSOffice workgroup bound activities. The collaborative advantages of Web 2.0 alternatives are disruptive and outside existing workflows, greatly marginalizing their usefulness. IF, and that's a big IF, MSOffice plug-ins were successful in the high fidelity round trip conversion of wor
  • Microsoft in 2008 could make a bold statement in support of standards by admitting that its attempt to force OOXML on the industry was a mistake and that it will work to develop cross-platform compatibility between that format and the Open Document Format
    • Gary Edwards
      Gary Edwards on 11 Jan 08
       
      It's impossible to harmonize two application specific file formats. The only way to establish an effective compatibility between ODF and OOXML would be to establish a compatibility between OpenOffice and MSOffice.
      The problem is that neither ODF or OOXML were developed as generirc file formats. They are both application specific, directly reflecting the particular implementation models of OOo and MSOffice.
      Sun and the OASIS ODF TC are not about to compromise OpenOffice feature sets and implmentation methods to improve interop with MSOffice. Sun in particular will protect the innovative features of OpenOffice that are reflected in ODF and stubbornly incompatible with MSOffice and the billions of binary documents. This fact can easily be proven be any review of the infamous "List Enhancement Proposal" that dominated discussions at the OASIS ODF TC from November of 2006 through May of 2007.
      So if Sun and the OASIS ODF TC refuse to make any efforts towards compatibility and imporved interop with MSOffice and the billions of binary docuemnts seekign conversion to ODF, then it falls to Microsoft to alter MSOffice. With 550 million MSOffice desktops involved in workgroup bound business processes, any changes would be costly and disruptive. (Much to the glee of Sun and IBM).
      IBM in particular has committed a good amount of resources and money lobbying for government mandates establishing ODF as the accepted format. this would of course result in a massively disruptive and costly rip out and replace of MSOffice.
      Such are the politics of ODF.
Gary Edwards

Wizard of ODF: Interoperability barriers and the List Proposal Vote Deadline on Wednesday - 0 views

www.oasis-open.org/...msg00039.html

harmonization interop interoperability odf ooxml opendocment openxml

shared by Gary Edwards on 07 Mar 08 - Cached
  • this TC does not have the final word on what goes into the ODF 1.2 spec. There is still the OASIS vote, the JTC-1 vote, and the ISO final ballot, with a few other stops along the way. There is also the market's response to what this TC does. Given that no one on this TC has objected to my considerable efforts to raise public concerns with Microsoft's ISO submission and some on this TC have lambasted Microsoft for creating interoperability barriers, why should this TC's members consider themselves exempt from warnings that they have just fallen into precisely the kind of behavior we routinely criticize when it's Microsoft that creates the interoperability barriers. Especially when it's the end users who will pay the price of the non-interoperability?
Gary Edwards

Wizard of ODF: Proposal to amend TC charter, re interoperability with non-conformant ap - 0 views

www.oasis-open.org/...msg00022.html

harmonization interop interoperability oasis odf ooxml opendocument

shared by Gary Edwards on 07 Mar 08 - Cached
  • 7. it must provide all feasible functionality required to suppport full fidelity conversions from and to existing office document binary file formats.
1 - 20 of 25 Next ›
Showing 20▼ items per page