Skip to main content

Gary Edwards's Library tagged officeopenxml →  View Popular

07 Jun 09

ODF and OOXML must converge!! AFNOR, the French Standards Body, announces proposals for revisable office document formats

  • French experts have determined that it is technically possible to converge ODF and MS-OOXML, into a single, revisable document format standard?



    The plan has four parts:



    "Firstly, to restructure the ECMA standard in two parts so as to differentiate between, on the one hand, a core of essential and simple functionalities to be implemented (OOXML-Core) and, on the other hand, all the additional functionalities required for compatibility with the stocks of existing office document files created by numerous users, which will be gathered within a package called OOXML-Extensions."



    "Secondly, AFNOR proposes to take into account a full series of technical comments submitted to the draft in order to make OOXML an ISO document of the highest possible technical and editorial quality."



    "Thirdly, it proposes to attribute to OOXML the status of ISO/TS for three years."



    Fourth, "Finally, AFNOR proposes to set up a process of convergence between ISO/IEC 26300 and the OOXML-Core. In order to achieve this, AFNOR will begin the simultaneous revision of ISO/IEC 26300 and of ISO/TS OOXML (subject to the latter being adopted after the aforementioned restructuring), so as to obtain the most universal possible single standard at the end of the convergence process. Any subsequent evolutions will be decided upon at ISO level and no longer at the level of such a group or category of players."









    So there you go.  A solution that removes ODF and OOXML from the clamy big vendor hands of both OASIS and Ecma, and puts the future of a "single revisable document" in the hands of ISO national bodies.

    IMHO, this is a winner.  If they (the ISO national bodies) can control the big application vendors, this will work.  And it's actually quite reasonable.

    They can't even begin to solve the technical challenge of convergence until they separate ODF from OpenOffice and OOXML from MSOffice.  The French have proposed their plan for separating OOXML from MSOffice, by creating a basic OOXMl-Core, and legacy compatible OOXML-Extensions.  Okay, but what about separating ODF from OpenOffice?

    ODF failed in Massachusetts for the love of five lousy generic elements we called the iX "interoeprability enhancements".  That's all it takes to convert existing MSOffice documents, applications and processes to ODF. 

    The five generics dealt with document structure fundamentals that were implemented differently in MSOffice and OpenOffice.  The generics are for lists, fields, tables, sections and page dynamics (breaks).

    There is also the problem with both ODF and OOXML that "compatibility-conformance" is optional.  Meaning, there is no requirement that compliant applications preserve the document markup of other applications.  Bye bye "round trip" fidelity!

    These implementation differentials break the high fidelity "round trip" conversion required by MSOffice bound workgroup-workflow business processes.  And with near 500 million MSOffice workgroups out there, this is hardly a trivial problem.  For Massachusetts, California, Denmark and Belgium this is an ODF show stopper.

    So what's the problem with adding five lousy generics to the ODF specification? 

    It's simple.  Nothing goes into ODF unless OpenOffice supports and implements that feature.  And OpenOffice is unable to support and implement these five generics unless there are significant changes made to the internal layout engine - implementation model. 

    The iX "interoperability enhancements" wouldn't degrade in any way the current OpenOffice conversion fidelity between MS binaries and xml docs, and ODF.  But they wouldn't improve that fidelity either.  The impact on OpenOffice conversion fidelity would be neutral. 

    Where the iX proposals would have an impact is on emerging ODF applications that would design their layout engines to perfectly implement ODF within the new iX interoperability framework.

    In the past year Florian Reuter submitted for discussion no less than five iX based proposals to the OASIS ODF TC members.  The first three iX proposals were submitted on behalf of the OpenDocument Foundation, and were signed off on by Massachusetts CIO Louis Gutierrez.  A fourth iX proposal was presented in November of 2006 on behalf of Florian's new employer, Novell.  And in February of 2007, the fifth iX proposal, also known as the RDF interoperability framework, was submitted to the OASIS ODF Metadata SC.

    A sixth "iX interoeprability framework" is in the works.  It's designed to bring ODF 1.1 and ODF 1.2 into conformance with



    ISO/IEC
    JTC 1 Directives     5th ed., v. 3.0, pp. 11, 145 (PDF), that mandate interoperability. 

    The ISO/IEC JTC 1 Directives for interop conformance requirements are uncompromising.  ODF 1.0 somehow slid through ISO without being held to account.  Interestingly, in May of 2006, ISO specifically refused to grant ODF an exception to interop conformance requirements.

    Here's a brief taste of what ODF 1.1, 1.2 and MS-OOXML face:

    ISO/IEC JTC 1 Directives unequivocally require that standards "specify clearly and unambiguously the conformity requirements that are essential to achieve the interoperability." Since ODF v. 1.2 is intended to become an ISO draft standard, this TC must shoulder the task the Directives place upon it. The Directives provide in relevant part:

    These Directives shall be complied with in all respects and no deviations can be made without the consent of the Secretaries-General.
    ............

    A purpose of IT standardization is to ensure that products available in the marketplace have characteristics of interoperability, portability and cultural and linguistic adaptability. Therefore, standards which are developed shall reflect the requirements of the following Common Strategic Characteristics:

        * Interoperability;
        * Portability;
        * Cultural and linguistic adaptability.

    Interesting huh?  There is the possiblity that come February, MS-OOXML will be put on the three year AFNOR plan.   Next up for ISO/IEC consideration will be ODF 1.1 and/or ODF 1.2.  Maybe by May of 2008? 

    Given the interoperability challenges facing both ODF and MS-OOXML, the world could easily find itself without an ISO approved desktop document standard.

    Although ODF 1.1 was OASIS approved in January of 2007, it has yet to be presented to ISO for consideration.  Meanwhile, ODF 1.2 is in it's final stages before it too goes before OASIS.  Shipping versions of OpenOffice.org, StarOffice, and Novell Office implement ODF 1.2 aspects.  We're way beyond ISO approved ODF 1.0 here!

    I like the French plan.  It's doable.  But speaking as someone who has been there, the ISO national bodies are going to have to wrestle the big vendors to get both an interoperable document standard, and, conforming applications.

    The expected February fireworks are just the start.  For sure there will be no lack of entertainment in 2008.

    ~ge~
     - garyedwards on 2007-09-25
  • AFNOR has recommended to ISO adopting an approach enabling it to guarantee – using ISO processes – mid-term convergence between Open Document Format (ODF) and OfficeOpen XML (OOXML), as well as the stabilisation of OOXML on a short-term basis.
  • Firstly, to restructure the ECMA standard in two parts so as to differentiate between, on the one hand, a core of essential and simple functionalities to be implemented (OOXML-Core) and, on the other hand, all the additional functionalities required for compatibility with the stocks of existing office document files created by numerous users, which will be gathered within a package called OOXML-Extensions. Secondly, AFNOR proposes to take into account a full series of technical comments submitted to the draft in order to make OOXML an ISO document of the highest possible technical and editorial quality. Thirdly, it proposes to attribute to OOXML the status of ISO/TS for three years. 
     
    Finally, AFNOR proposes to set up a process of convergence between ISO/IEC 26300 and the OOXML-Core. In order to achieve this, AFNOR will begin the simultaneous revision of ISO/IEC 26300 and of ISO/TS OOXML (subject to the latter being adopted after the aforementioned restructuring), so as to obtain the most universal possible single standard at the end of the convergence process. Any subsequent evolutions will be decided upon at ISO level and no longer at the level of such a group or category of players.
07 Feb 08

Word of recognition from an unexpected side: ODF editor Patrick Durusau supports OOXML - ISO effort

<p>Patrick Durusau, the OASIS ODF editor has written an open letter praising the OOXML standardization effort at Ecma and ISO. Patrick is a long time member of ISO JTCS1, currently serving as the ODF editor for both ISO and OASIS ODF efforts. That his endorsement of OOXML comes on the eve of the critically important February BRM is beyond incredible. </p>

<p>Jesper offers this quote which i think adequately summarizes Patrick's endorsement:</p>

<p>The OpenXML project has made a large amount of progress in terms of the openness of its evelopment. Objections that do not recognize that are focusing on what they want to see and not what is actually happening with OpenXML"</p>

idippedut.dk/...n-from-an-unexpected-side.aspx - Preview

BRM Durusau ISO OASIS odf officeopenxml ooxml opendocument openxml

  • The OpenXML project has made a large amount of progress in terms of the openness of its evelopment. Objections that do not recognize that are focusing on what they want to see and not what is actually happening with OpenXML
04 Dec 07

The Future is CDF | Metaphorical Web - Kurt Cagle

  • As editing increasingly moves onto the web, its safe to say that the document of choice will be neither ODF nor OOXML, both of which gain their power on the basis of supporting legacy word processing systems. Instead, what seems to be emerging from the W3C is something that is not an office suite because it didn’t evolve from one, but that nonetheless is capable of most if not all of the same functions that office suite documents pose.
03 Nov 07

Sun-Bosak "Yes" Vote on ISO approval of MS OOXML

  • Sun announces support for ISO approval of MS OOXML as an international standard:



    "We wish to make it completely clear that we support DIS 29500 becoming an ISO Standard and are in complete agreement with its stated purposes of enabling interoperability among different implementations and providing interoperable access to the legacy of Microsoft Office documents."



    Bosak tries to obscure this "YES" vote by pointing to their comments that Microsoft should finally reveal the MS binary secret blueprints with a mapping of the binary blueprints to OOXML. Ha Ha Ha! Now we know what Microsoft paid Sun $2 Billion for in 2004.

    - garyedwards on 2007-08-28
  • Yagotta B. Kidding:
    The vote was "yes, with comments." That is not, per ISO rules, a "conditional" yes, it's a just-plain-yes. The comments are advisory and regardless of whether they're resolved there's no way to change the "yes" to a "no."

    Specifically, ISO voting procedure [1] states, "Conditional approval should be submitted as a disapproval vote."

    Yes, it's confusing. The way these things work, there's no way to vote "unconditional no." The options are "yes, as it currently stands" and "yes, if the following problems are addressed."

    That makes the enormous effort to get unconditional approval quite curious.

    [1] JTC1 Directives, 5th Edition, Version 3.0, Section 9.8     - garyedwards on 2007-08-28
  • We wish to make it completely clear that
    we support DIS 29500 becoming an ISO Standard and are in complete
    agreement with its stated purposes of enabling interoperability
    among different implementations and providing interoperable access
    to the legacy of Microsoft Office documents.
15 Sep 07

INTERVIEW: Craig Mundie -- Microsoft's technology chief, taking over from Bill Gates

  • Great inteview, i'll comment as i make my way down the page.  Hopefully others will do the same.
     - garyedwards on 2007-09-15
  • In this exclusive interview with APC, Mundie says the notion of all software delivered entirely through the web browser is now widely recognised as being 'popular mythology'. He also stakes the claim that Google's existence and success was contingent on Microsoft creating Windows. He talks about what's coming down the pipeline for future versions of Windows, and his belief that Windows can get still more market share than it has today. He also discusses the issues around the recent controversy over the Office Open XML file format.
  • So Vista is in its diffusion cycle and until there is enough of it out there, you won't really see the developer community come across.
  • 3 more annotations...
13 Sep 07

Frankly Speaking: Microsoft's Cynicism - Flock

  • Good commentary from Frank Hayes of Computerworld concerning a very serious problem. Even if ISO somehow manages to approve MS-OOXML, Microsoft has reserved the right to implement whatever extension of Ecma-OOXML they feel like implementing. The whole purpose of this standardization exercise was to bring interoperability, document exchange and long term archive capability to digital information by separating the file formats from the traditions of application, platform and vendor dependence.



    If Microsoft is determined to produce a variation of OOXML that meets the needs of their proprietary application-platform stack, including proprietary bindings and dependencies, any illusions we might have about open standards and interoeprability will be shattered.  By 2008, Microsoft is expected to have over a billion MS-OOXML ready systems intertwined with their proprietary MS Stack of desktop, server, device and web applications. 

    How are we to interoperate/integrate non Microsoft applications and services into that MS Stack if the portable document/data/media transport is off limits?  If you thought the MS Desktop monopoly posed an impossible barrier, wait until the world gets a load of the MS Stack!

    Good article Frank.

    ~ge~



     - garyedwards on 2007-09-13
  • In July, Jones was asked on his blog whether Microsoft would actually commit to conform to an officially standardized OOXML. His response:




    “It’s hard for Microsoft to commit to what comes out of Ecma [the European standards group that has already OK’d OOXML] in the coming years, because we don’t know what direction they will take the formats. We’ll of course stay active and propose changes based on where we want to go with Office 14. At the end of the day, though, the other Ecma members could decide to take the spec in a completely different direction. ... Since it’s not guaranteed, it would be hard for us to make any sort of official statement.”


  • To at least some people at Microsoft, this isn’t about meeting the needs of customers who want a stable, solid, vendor-neutral format for storing and managing documents. It’s just another skirmish with the open-source crowd and rivals like IBM, and all that matters is winning.
12 Sep 07

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

  • 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 failed in Massachusetts.

    Without these iX "interoperability enhancements", it's impossible to implement ODF anywhere there are MSOffice bound workgroups and business processes.  Which is just about everywhere.

    So what now?

    For the past four months we have been converting da Vinci to pipe into a recent W3C release of HTML+.  It's difficult, but we now are certain it can be done with the same high fidelity "round trip" conversion Microsoft achieves with the OOXML plug-in.

    The significance of this discovery and proof is that there is a web ready alternative to MS-OOXML and the MS Stack.  An alternative that should provide Office 2.0 - Web 2.0 and SaaS apps the same measure of interop - integration with existing documents, applications and processes that Microsoft now enjoys.

    The consumer is caught between a rock and a hard place.  Waiting for either the ODF or the OOXML gangs of big vendors to blink is a non starter.  And even if they did want to harmonize or converge, that in itself may well be a technical impossiblity.  The differences between how MSOffice works and how OpenOffice works are directly and "perfectly" reflected in the file formats.  And never the twain shall meet.

    So here it is.  The world is not a clean slate.  There are MSoffice workgroups everywhere.  Meaning, in real world terms ODF is impossible to implement.  Besides that, ODF is a desktop office suite only file format.  It was not designed for the Internet, and can only be useful in that capacity through a lossy conversion.  OOXML was designed to cover the full expanse of desktop, server, device and web.  Only, it's to be a 100% Microsoft dominated and controlled expanse.  Which leaves us with one alternative: HTML+

    Time to get back to work :)

    ~ge~

    Ref:  "Why Can't We All Just Get Along?"


     - garyedwards on 2007-09-12
  • 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.

Why Can't We All Just Get Along?

  • My response to Tiffany's eWEEK article, Office file formats fail to communicate, and the GCN article, Can't we just get along?. good articles both.


    My comments are the first time i've responded directly to Sun's proprietary eXtensions allegation. The truth is that we refused to release the da Vinci plug-in with the must have iX "interoperability enhancements". Sun of course totally opposed our iX proposals, insuring that ODF would fail in Massachusetts, California, Denmark, Belgium and with the EU-IDABC.


    Nice work Sun! Yeah, that's the ticket. Limit ODF's interoperability so much so that it is impossible to implement ODF, and the world willl beat a path to your door.


    Right!

    ~ge~

    ~ge~     - garyedwards on 2007-09-12
11 Sep 07

Can't We All Just Get Along?

  • Another call for the "convergence" of ODF and MS-OOXML, this time from the government technology magazine, GCN.com.



    IMHO, there is a very steep technical barrier to both the harmonization and/or convergence of ODF and OOXML. The problem is that these file formats are application specific and bound respectively to OpenOffice and MSOffice feature sets and implementation models. The only way to perfect a harmonization or convergence file format effort is to dramatically change the reference applications.



    With over 500 million MSOffice workgroup bound desktops in the world, changing that suite of applications is likely to break business processes with a global disruption factor that is simply unacceptable. OpenOffice on the other hand could better sustain such the needed layout engine changes, but estimates it will take 3-5 years to accomplish this.



    Sun has often stated at the OASIS ODF TC (technical committee) that OpenOffice will not be bound and limited by having to mirror MSOffice features and implementation models. These arguments are often called application innovation rights.



    In the past year alone, there have been no less than five ODF iX "interoperability enhancement" proposals submitted to the OASIS ODF TC members for discussion. The iX proposals are designed to solve the problem of high fidelity "round trip" conversion of MSOffice binary and xml documents with OpenOffice ODF documents.



    Sadly, Sun and the other ODF application vendors fought and thoroughly defeated every aspect of these proposals even though the first three iX proposals were signed off on by Massachusetts ITD, and considered vital to the successful implementation of ODF there. ODF of course proved impossible to implement in Massachusetts. And without the iX interoperability enhancements, it is impossible for ODF plug-ins for MSOffice to perfect the high fidelity "round trip" conversion of existing documents, applications and processes to ODF.



    The iX interoperability enhancement proposals are simplicity itself. There are only five generic elements that need to be added to the ODF spec to solve two of three real world problems holding ODF back. The five generics deal with the basic document structures of lists, fields, tables, sections and page dynamics (page breaks). These five structural elements account for almost all fidelity conversion problems between MS binaries, MS XML, and ODF.



    So why would anyone oppose the inclusion of these proposals in ODF? Especially with Massachusetts, California, Denmark, Belgium and the EU-IDABC successful implementation of ODF hanging in the balance?



    The answer is that neither Microsoft or Sun is willing to give up application control of their respective file formats. We all know that MS-OOXML is bound and strapped to the emerging Microsoft Stack of desktop, server, device and web applications. The surprise for many is that ODF is similarly bound and strapped to the OpenOffice/StarOffice desktop, with an added proviso that defies all pubic expectations; Sun insists that nothing goes into the ODf specification that isn't fully implemented and supported by OpenOffice.



    Here's the kicker; it will take a major overhaul of the OpenOffice layout engine to implement the five generic iX elements. The iX interoperability enhancements are needed to solve real world problems now blocking the implementation of Odf.



    What “real world” problems you might ask? Well, the world is not a clean slate. Most of the world's existing binary documents are bound to the MSOffice application platform. They are application specific/platform specific, and defy high fidelity conversion to any other application specific implementation model. Like that of OpenOffice.

    Five years ago when the OASIS ODF effort began, we believed it was entirely possible to create a universal file format based on a highly portable XML document model. The needs of this universal file format were simple enough to enumerate. It had to be open, unencumbered, universally interoperable (reuse of open standards, open interfaces and open methods), and application-platform-vendor independent with an acceptable governance model.



    We thought ODF could be that universal file format.



    Five years later and we are nowhere near our goal of a universal file format capable of universal interoperability. The thing is, when a specification hits the real world, as ODF did in Massachusetts, the proof of it's universality, application independence and governance model is sorely tested. And ODF failed that test miserably.



    Massachusetts had conducted a year long Pilot Study to determine how they could implement ODF. The final report led to the now infamous RFi - Request for Information about the feasibility of a ODF plug-in for MSOffice. Meaning, Massachusetts realized they could not implement ODF without having a ODF plug-in clone of the MS-OOXML plug-in for MSOffice. The disruption cost of rip out and replace alternatives to MSOffice was impossibly high. The problem being the incredible volumes of MSOffice bound workgroup-workflow business processes, line of business integrated applications, and assistive technology add-ons.



    An XML plug-in for MSOffice enables a non disruptive and cost free transition of documents, applications and processes. Microsoft provides a plug-in for OOXML. So Massachusetts thought, why not one for ODf?



    The problem with that question is this; ODf is bound to the OpenOffice specific layout and conversion engines. To implement ODf in MSOffice, some changes must be made to accommodate the MSOffice specific layout and feature set model. These changes were codified in the various ODf iX “interoperability enhancement” proposals submitted to the OASIS ODf membership for discussion. OpenOffice cannot implement or support the iX enhancements without significant changes to their layout engine and implementation model. End of story.



    The Universal Document Challenge:

    The iX “interoperability enhancement” issues are only one part of the impossible to implement ODf story. The other part is basic to any universal file format contender – the ability to solve three "real world" problems. Problems a universal file format must address because the world is not a clean slate:



    .......Compatibility with existing documents - file formats :: including the volumes of MS binary documents.



    ...... Interoperability with existing applications :: including the over 500 million MSOffice bound workgroups.



    .......Convergence of desktop, server, device, and web systems as fluid and highly interoperable routers of documents, data, and media.



    First off, let's be clear that ODf is unable to solve any of the these problems. It was clearly not designed to address these issues. Not that they don't come up at the OASIS ODf TC. This is evidenced over the years by efforts to amend the ODf Charter to include compatibility with existing documents and interoperability with existing applications. Also there have been efforts to amend the infamous Section 1.5 “Compatibility – Conformance Clause” so that interoperability isn't an “optional” afterthought. And of course, there the iX proposals mentioned above.

    Here's something to think about. Using the Microsoft OOXML plug-in for MSOffice, MS can solve all three problems. But that solution also locks business processes into the proprietary MS Stack of desktop, server, device and web applications and services. Locks them in for who knows how many years to come. So much so that, imho, this represents the most dramatic expansion of a convicted monopolist's power in history. Microsoft is making it's move from the desktop to the Internet, and taking everything in between.



    ODf is not the target of Microsoft's OOXML-Smart Documents efforts!



    Au contraire! Do not kid yourselves ..... HTML is the target! And the Internet the prize.



    As for ODf? If ODf can't solve the three universal document challenges, it's not a threat to Microsoft.



    Here's how it works. The core of the MS Stack is an alignment of MSOffice, IE, and the Exchange/SharePoint Developers Hub. From there, the MS Stack connects to a sprawl of applications including Active Directory, MS SQL Server, MS Dynamics, and MS Live. Everything in the MS Stack speaks fluent MS-OOXML-Smart Documents, and is able to access all proprietary dependencies found within the portable document. (Psst! MOOS docs are different than Ecma 376 docs in that MOOS docs are specific to MSOffice and bound through platform specific dependencies to the MS Stack)



    Now pay close attention. MS-OOXML-Smart doc containers are designed for two things. First, to port document/data/media packages across the entire stack. There is no HTML or HTML+ here! Second, MOOS docs are a bridge to existing documents, applications and bound business processes that drive workgroups. Microsoft's emerging systems can of course integrate with existing workgroup-workflow processes, facilitating a massive migration of these processes from the current desktop interface to that of the Exchange/SharePoint Developer Hub.



    So where are we at here? OpenDocument was designed for the “rip out and replace” of MSOffice, can't meet the universal file format challenge – was never designed for that, and there little interest amongst the OASIS masters for harmonization, convergence, or any kind of compatibility-interoperability with Microsoft products. MOOS docs were designed for the transition of existing workgroup-workflow business processes to the Exchange/SharePoint Hub, and the replacement of HTML as the primary language of the Internet. Ecma 376 does not have a non binding implementation worth spit. So what is the world left with?



    The answer is HTML+. The surprise being that HTML+ can meet all three of our universal document challenges. Governance through the W3C and universal interoperability are of course, built into the DNA. Stay tuned. This battle is just beginning.



    ~ge~     - garyedwards on 2007-09-11
09 Sep 07

Once More unto the Breach: Office Open XML Conformance (A Lesson in Claiming Standards Conformance)

  • unfortunately the MS argument that support for OOXML equals "conformance" is also the same argument used by OpenDocument supporters to prove multi vendor, multi platform, multi application support.


    - garyedwards on 2007-09-03
  • As far as I can tell in the Massachusetts poster-child case, ODF has simply come to mean whatever OpenOffice.org does
    • Keep in mind orchmid that it is the OpenOffice code base that ODF is bound to. There are many instances of the OOo code base pushed by various vendors. Sun provides OpenOffice.org and StarOffice versions of the code base. Novell Open Office is the same code base. Same with Red Hat Office and IBM WorkPlace. Outside this common code base, ODF has near ZERO interoperability. - on 2007-09-09
    Add Sticky Note
28 Aug 07

OOXML in Norway: The haywire process | Geir Isene : Straight talk on IT

  • see the sticky notes on this one - garyedwards on 2007-08-28

  • I had read the essay by Jon Bosak (SUN Microsystems) on why SUN voted as it did in the US. He lays out a very different strategy. His view is that the battle is lost to completely reject OOXML as an ISO standard. ISO can only reject it with comments, and that is equivalent to giving Microsoft a todo-list on how to fix the draft so as to get it approved. Microsoft has sufficient manpower to easily tackle that.


    Most of us had missed what Mr. Bosak saw: OOXML promises interoperability with earlier closed binary formats (the Word Doc, older Excel file formats etc.). But it doesn’t deliver. How on earth could someone be able to convert old binary files to the new format without having the specification of the old formats and a mapping to OOXML. If you are to translate some text from Chinese to English, it doesn’t much help to only know English.

    • A "Yes with comments" is a yes for the ISO approval of MS-OOMXL. If ISO approves MS-OOXML, it won't matter what Bosak's "comments" strategy is. Microsoft and the Vista Stack will be off to the races. The full disclosure of the MS binary document secret blueprint won't matter much at that point. - on 2007-08-28
    Add Sticky Note
  • “Ah c’mon Bosak, you are chickening out, we must stop this dead in the track”

Microsoft bashed in OOXML shens (and comparing loos) - Computerworld Blogs

  • Collection of clips from the blogosphere concerning the pending Sep 2nd ISO vote on MS OOXML - garyedwards on 2007-08-28

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

  • 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 quietly migrating the MSOffice monopoly to the Vista Stack; where an entirely new generation of lock-in awaits. The Exchange/SharePoint Hub is now over 60% market penetration. Apache installations are in decline. Lotus Notes is getting killed by the E/S Hub. And ISO approval of MS OOXML looms as the tripwire for fifteen or more years of impenetrable monopolist dominated future.



    Let me put this as bluntly as possible. MS OOXML is the stalking horse for the Vista Stack. The key to the entire juggernaut is simple. It is the ability to convert and transition with high fidelity and minimal disruption existing documents, applications and processes to XML. That this XML is OOXML means that the Vista Stack is the only option for those who are currently bound to MSOffice.



    What we are actually witnessing here is the transition from the Microsoft desktop monopoly to a new, next generation, collaborative computing monopoly that will stretch across the convergence of all information platforms. Microsoft applications and those of independent developers brought to heel with Visual Studio .NET will be able converse and exchange information across desktops, servers, devices and web domains with ease. And the barrier to anyone not paying the piper from Redmond will be impossibly high. Interoperability with the Vista Stack comes at a cost designed to leave FOSS on the fringe.



    What other option to this transition from the MSOffice monopoly to the Vista Stack is there?


    Essentially this is a transition of existing documents, applications and processes to XML.



    To pull this off, Microsoft is providing a OOXML plug-in for MSOffice that makes this transition relatively cost free, non disruptive and well, easy.



    Sadly there is no ODF clone of the OOXML plug-in. A plugin for MSOffice that offers the same transition of documents, applications and processes to ODF. A transition that would have opened up a world of opportunity for Open Stack alternatives to the E/S Hub and the Vista Stack.



    There are a few reasons why there isn't an ODF clone of the OOXML plug-in. One reason is that the ODF Community is insistent on a total "rip out and replace" approach to MSOffice. This they seek to achieve this through mandate legislation that would force governments to implement ODf, no matter what the business process re engineering cost or disruption.



    For a time, it did look as though the mandate strategy would work. It does after all have strong anti trust arguments behind it. And ultimately this issue is all about anti trust and reprehensible monopolist business practices that have crushed innovation, eliminated competition, totally compromised sovereign choice, and jacked the cost of our emerging digital civilization at every turn.



    The problem is that governments are unwilling to absorb the cost or tolerate the disruption of "rip out and replace" MSOffice ODf alternatives. The mandate movement came crashing down with the Massachusetts Request for Information regarding the feasibility of an ODF clone of the OOXML plug-in for MSOffice. This was a clear signal that mandate legislation was doomed to failure. And it came from the only government on record as having issued a mandate for ODF!



    The ODF Community did not however read the tea leaves, as the mandate party in Massachusetts went into crash and burn mode. The community vehemently opposed the ODF plug-in clone approach, ignored the cry for help in Massachusetts, and blithely went on to champion any suggestion that other governments might consider "rip out and replace" mandate legislations. Even though it was clear by October 4th, 2006, with the resignation of Massachusetts CIO Louis Gutierrez, that ODF mandate legislation was dead and done.



    Meanwhile, CIO's the world over took the failure in Massachusetts as a clear sign that it was impossible to implement ODF.



    Let me translate that: What this means is that it's impossible to convert existing documents, applications, and processes to ODF without suffering an intolerable loss of information ("round trip" fidelity), incurring a costly productivity neutral re engineering overhead, and having to accept unacceptable disruption to day to day business processes.



    The ODF Community response to this allegation is worth noting. They claim, and rightfully so, that only Microsoft can perfect the transition because they own the secret blueprints to the binary document file format, and, the business process logic layer defined by VBa scripts, macros, OLE, etc. And until Microsoft is forced by anti trust actions or ODF mandate legislation to fully disclose the proprietary bindings, blueprints, and dependencies, there is no way anyone could ever be expected to match the conversion fidelity and non disruptive transition provided by the OOXML plug-in.



    So here it is. We're caught between a rock and a hard place. On one side we have Microsoft unwilling to compromise and share their monopolist secrets. And on the other side we have the ODf community insisting it's up to governments to crack the monopolist iron grip and open up the conversion to XML process.



    This is where Massachusetts found themselves. After a year long Pilot Study examining the issues of implementing ODf, they came to the conclusion that they had no other choice but to throw a Hail Mary. They issued the unprecedented Request for Information of an ODf plugin for MSOffice.



    This all ancient history. But it's a history and a world situation the ODf community refuses to reckon with. It's not going to go away. Nor will it change with whatever ISO decides to do with OOXML. The thing we have to ask ourselves though is if we've done all that we could? Assuming that Microsoft is not going to stop being Microsoft, and that they will stay the course of trying to transition the entire monopoly base over to the Vista Stack come hell or high water, the questions remains. “Did we, the FOSS and ODf community do all we could have done given Microsoft's hard position, and the lack of government anti trust grit?”



    If you put this question in front of those who actually work in the area of document conversion and translation they would tell you no way has enough been done! It is entirely possible to hit the high fidelity “round trip” conversion of existing documents, applications and processes that the OOXML plugin for MSOffice delivers. The OpenDocument Foundation's ACME 376 plug-in fully demonstrates this capability. The Foundation has also figured out how to grab the MSOffice magic key, enabling the full capture of VBa scripts, macros, OLE, and other processing bits like SSPI ("Security Service Provider Interface").



    The problem is that we are unable to pipe the ACME 376 conversion into ODf without the use of interoperability eXtensions and enhancements that Sun and the OASIS ODf TC opposes. Sun in particular is opposed to any ODf “iX” interoperability enhancements that would close the compatibility gap between existing documents and ODf. A gap that must be closed if the conversion of billions of binary documents to ODf is ever to be successful.



    In the past year, there have been no less than five iX proposals submitted to the OASIS ODf TC members for discussion and consideration. Universal interoperability expert Florian Reuter has posted an iX status update, and you can see for yourself the interoperability enhancements proposals went nowhere. Three of the proposals were actually singed off on by Massachusetts ITD. Two of the proposals qualified as interoperability frameworks designed to take the innovation lid off of ODf application developers, introducing an incredible flexibility that would effectively eliminate the need for proprietary ODf eXtensions.



    So here we sit. We could at any time slam the door shut on MS OOXML. We could easily take ISO off the hook. And there is no need for the EU-IDABC to sweat out some sort of hokey harmonization contingent on the cooperation of an unrepentant recidivist reprobate. We know how to break the monopolists grip. We can convert with the required fidelity existing documents, applications and processes to ODf iX. We can even convert to CDF, the W3C's Compound document format. But we can't convert to ODF!



    If there is a way to stop the Vista Stack juggernaut, it's that of neutralizing the head point of MSOffice, and intercepting the conversion of existing documents, applications, and processes. Sure it's difficult. But if we don't do this, and do it now, once those business processes get wound into the Vista Stack they are going to be a bear to interoperate with.



    ~ge~

     - garyedwards on 2007-08-28
24 Aug 07

Not Even Close? OOXML Vote Tally for INCITSLB2341

  • Wow. The USA votes ISO approval of MS OOXML (DIS 29500) with only three no votes being cast out of 16 members! It's not even close. - garyedwards on 2007-08-24

Slamming the door shut on MS OOXML

  • Marbux on metadata and the language of universal interoperability:

    Few people are aware of the raging debate that has pushed ODF to the edge. The OASIS ODF TC is split between those who support Universal Interoperability, and those who insist on continuing with limited ODF interoperability.



    ODF (OpenDocument), formally known as Open Office XML, began it's standards life in the fall of 2002 when Sun submitted the OpenOffice file format to OASIS for consideration as a office suite XML fiel format standard. The work on ODF did not start off as a clean slate in that there were near 600 pages of application specific specification from day one of the standards work. The forces of universal interop have sought for years to separate ODF from the application specific features and implementation model of OpenOffice that began with those early specification volumes, and continues through the undue influence Sun continues to have over the ODF specification work.

    Many mistakenly believed that submission of ODF to ISO and subsequent approval as an international standard would provide an effective separation, putting ODF on the track of a truly universal file format.



    Marbux is one of those Universal Interop soldiers who has dug in his heels, cried to the heavens that enough is enough, and demanded the necessary changes to ODF interoperability language.



    This post he recently submitted to the OASIS ODF Metadata SC is a devastating rebuttal to the arguments of those who support the status quo of limited interoperability.



    In prior posts, marbux argues that ISO directives demand without compromise universal interoperability. This demand is also shared by the World Trade Organization directives regarding international trade laws and agreements. Here he brings those arguments together with the technical issues for achieving universal interop.



    It's a devastating argument.



    The OpenDocument Foundation has worked with the OASIS ODF TC since it's inception with one goal in mind. We believed that ODF could be that elusive Universal File Format. Today we know full well the difficulty of transitioning ODF away from it's application specific roots and the control of Sun. It's not that universal interop is difficult. It's actually simple. It's that OpenOffice would have to change and be re written to properly implement an ODF that is truly universal.



    In the past year there were no less than five ODF iX "interoperability enhancement" proposals submitted to ODF TC members for discussion and consideration. Three of these iX proposals were vital to the success of ODF in Massachusetts and California, and were actually signed off on by Massachusetts ITD. The iX discussions did not go well though, as you can see in this status update recently posed by uber universal interop expert, Florian Reuter. (Page down to see the full report).



    The iX interoperability enhancements are only part of the story though. There is still the need to fix the language of limited ODF interop that marbux so ably references. And then there is the need to fix and/or fully document the many application specific configuration-compatibility setting used by OpenOffice.



    Institute the language of universal interop, embrace and implement the iX interoperability enhancement proposals, and fully document the application specific configuration - compatibility settings used by OpenOffice is a tall order for Sun. This is clearly a challenge for OpenOffice developers. But it has to be done if ODF is to achieve the universal interoperability the world expects and ISO directives demand.



    As we approach the September 2nd, 2007 date of the ISO vote on MS OOXML, the world's attention is on the nonsense of OOXML. There is no possible way OOXML should be considered for any kind of standardization, yet here we are. IMHO, there is one and only one reason the world has been brought to the brink of this tragic consideration; and that reason is the limited interoperability of ODF!!



    Even Sun has expressed their approval of ISO OOXML (DIS 29500), with this official comment:



    “We wish to make it completely clear that we support DIS 29500 becoming an ISO Standard and are in complete agreement with its stated purposes of enabling interoperability among different implementations and providing interoperable access to the legacy of Microsoft Office documents.”



    This statement happens to coincide with Microsoft's oft stated reason as to why they could not support ODF and HAD TO create OOXML! Microsoft argues that ODF is insufficient and unable to handle the richness of MSOffice features and the high fidelity conversion of billions of legacy binary documents. They argue that ODF was not designed to meet the needs of existing MS documents, applications and processes. Which is true. ODF was not designed for the conversion of most of the worlds existing documents, applications and processes to ODF.



    And this is where the arguments for universal interoperability come into play. The ISO Directives and WTO Trade Requirements insist that ODF be designed exactly to e compatible with existing file formats, including MS binaries, and, interoperable with existing applications, including MS applications.



    Sun and many of the current OASIS ODF TC membership argue that this compliance-interoperability with existing Microsoft bound proprietary documents and applications is out of scope, outside the charter, and perhaps even impossible without Microsoft's direct participation and support..



    The "impossible to do without Microsoft support" argument is no doubt persuasive. The "out of scope - outside the charter" arguments are ridiculous and can easily be used by Microsoft to justify their non participation.



    It's up to the governments of the world to force Microsoft into compliance, participation and support of ODF. The only thing we can do is to make certain that there is no technical barrier standing between ODF and the perfect implementation of ODF by Microsoft applications. So the question is, "Have we done all we could to remove the technical barriers?"



    Once again, it's all about universal interoperabilityversus limited ODF interoperability. The language of universal interop and the iX interoperability enhancement proposals are designed to remove any technical barriers to the perfect conversion of existing documents, applications and processes to ODF, and back - (the infamous "round tripping" requirement demanded by MSOffice bound workgroups).



    The truth is that if ISO shoots down OOXML - as they MUST if they hope to save whatever's left of public confidence in the international standards process, there is still the problem of converting existing documents, applications and processes to ODF. Without the transition of ODF from limited interop to universal interop, this conversion is impossibly costly and disruptive to try. And because of this, the world will end up implementing OOXML simply because there is no other way to get to XML - as has already been demonstrated by Massachusetts, California, Denmark. and Belgium. More will follow no matter what the vote at ISO simply because ODF is impossible to implement under the circumstances of years of documents, workgroups and workflows being bound to MSOffice.



    The ODF iX "interoperability enhancement" proposals were designed to meet needs which we consider vital to universal interoperability.



    The universal interop characteristics so noticeably missing from ODf fall into these three categories:



    *Compatibility - file format level interop -

    ::: backwards compatibility / compatibility with existing file formats, including the legacy of billions of binary Microsoft documents



    *Interoperability - application level interop-

    :::::: application interoperability including interop with all Microsoft applications



    *Convergence - cross platform interop:

    ::::::::: the portable XML document promise of being able to move content/data/media rich document packages across desktop - server - device and Web information systems. Another way of expressing this would be the exchange of portable XML documents with data bindings across desktop productivity environments, enterprise publication-content-archive management systems, SaaS, SOA and Web 2.0




    Organizations the world over are at an important inflection point. They need to move existing documents, applications and processes to XML. Once there, the explosively rich digital civilization emerging around Web based collaborative computing is within reach. The big enchilada being SaaS, SOA and the Web 2.0 AJAX-REST mashup interop that promises to shatter all the traditional restrictions of application vendor controlled "interop".



    There are only two file formats that could possibly meet the needs of universal interoperability; ODF iX and CDF (the W3C's Compound Document Format).



    CDF is unique in that it can meet all three of the above requirements. (Yes, CDF can handle the perfect conversion of existing MS documents, applications and processes to CDF, and back).



    ODF on the other hand needs work. For sure it needs the iX "Interoperability enhancement" proposals. Otherwise we can't perfect the conversion of existing documents, apps and processes. For sure ODF needs to implement the language of universal interop, and amend the charter accordingly. A process marbux is not likely to let go of. And for sure, the charter of ODF must also be amended support ISO-WTO directives. Which would be for the charter to include "compatibility with existing file formats and interoperability with existing applications".



    Then and only then can we kiss MS OOXML good-bye and good riddance.



    Thanks marbux. Well done!

    ~ge~     - garyedwards on 2007-08-24
  • So your goal is a networked world where metadata is routinely trashed by apps developed by those who are too dumb or otherwise disabled to preserve metadata and only the big boys get to do interoperability, right? So if I send you a document for your editing, I can't count on getting it back with xml:id attributes intact.


    No thanks, Patrick. That sounds way too much like how things have worked ever since office productivity software first came on the market. In your world, interoperability belongs only to those who can map features 1:1 with the most featureful apps. And that is precisely why OpenDocument never should have been approved as a standard. Your kind of interoperability makes ODF a
    de facto Sun Microsystems standard wearing the clothing of a de jure standard. Why not just standardize the whole world on Microsoft apps and be done with it? Are two monopolies maintained by an interoperability barrier between them better than one?


    Fortunately, we don't have to debate the issue because the Directives resolve the issue. You lose under the rules of the game.
23 Aug 07

The Age of OOXML Computing - thanks a pant load Sun!

  • Why does Microsoft want another standard, what's the rationale?



    There are at least 4 good reasons why:

    *ODF started out and was completed as an XML format, specifically supporting OpenOffice with a tight scope around that product.

    *It wasn't until 2005 that the spec was offered up as a general XML office document format and consequently renamed to ODF.

    *No opportunity existed for Microsoft to actually participate in this full process - given the original scope, the 6 months between the re-naming of the spec to ODF, and its subsequent approval by OASIS as a standard.

    *The scope of the ODF spec never included even the basic requirements that Microsoft required to support a fully open format, and nor did the OASIS technical committee want to include these requirements.
20 Aug 07

LOL :: Microsoft’s Jean Paoli on the XML document debate

  • Tim Anderson interviews Microsoft's Jean Paoli about MOOXML and ODF.    Jean Paoli of course has the predictable set of answers.  But Tim anderson provides us with some interesting insights and comments of his own.  There is also a gem of a comment from Stephane Rodriquez, the reknown spreadsheet expert.

    The bottom line for Microsoft has not changed.  MOOXML exists because of the need for an XML file format compatible with the legacy of existing MSOffic ebinary documents.  He claims that ODF is not compatible, and offers the "page borders" issue as an example.

    Page borders?  What's that got to do with the ODF file format?   These are application specific, application bound proprietary graphics that can not be ported to any other application - like OpenOffice.  The reason has nothign whatsoever to do with ODF and everything to do with the fact that the page border library is bound to MSOffice and not available to other applications like OpenOffice. 

    So here is an application specific feature tha tJean Paoli claims can not be expressed in ODF, but can in MOOXML.  But when are running the da Vinci ODF plugin in MSWord, there is no problem whatsoever in capturing the page borders in ODF!!!!!!!!!!!!!!!!!!!!!!!!!!!  No problem!!!!!!!!!!

    The problem is opening up that same da Vinci MSWord document in OpenOffice.  That's where the page borders are dropped.  The issue is based entirely on the fact that OpenOffice is unable to render these MSWord specific graphics bound to an MSOffice only library.

    If however we take that same page border loaded da Vinci MSWord document, and send it half way across the world to another MSWord desktop running da Vinci, the da Vinci plugin easily loads the ODF document into MSWord where it is perfectly rendered, page borders and all!!!!!!!!

    Now i will admit that this is one very difficult issue to understand.  If not for da Vinci, we would have to take Microsoft's word that they can't capture those sacred page borders in ODF so therefore they must invent their own XML:  MOOXML.

    But hey, this is Microsoft.  Who in their right mind would take them at their word? 

    The problem is that one first has to invent an "internal" ODF plugin for MSOffice to prove that Microsoft has it wrong (okay, i'm being kind here :)  And inventing such an internal plugin is one daunting and difficult task.  See, the only way an ODF plugin can work "internally" would be to be able to convert perfectly between MSOffice in-memory-binary-representations  and ODF.

    This involves the perfect fidelity conversion of those infamous billions fo binary documents to ODF.

    Since Microsoft fully understands and owns the complete blueprint for those billions of binary documents, they can perfect the conversion to MOOXML.  But without this secret knowledge, it's near impossible for anyone to match this feat;  as in converting those same documents to ODF XML.

    This isn't the time or place to explain how da Vinci does it, but it does.  The larger point here is that Microsoft intentionally confuses ODF the XML file format with OpenOffice the office suit application.  They take a binary MSWOrd document with page borders, and import it into OpenOffice using the OOo reverse engineering conversion filters.  Then they save the document as "ODF".  And of course it's a mess.  The page borders are no where to be found.

    Is this an OpenOffice problem?  Or a problem for ODF?

    Without da Vinci one would have to say it's probably a little of both.  The truth however is that this is entirely a OpenOffice problem.  The truth is that ODF can handle ANYTHING MSOffice has to throw at it.

    We know this because we see what da Vinci can do. 

    To most people it makes sense that applications with different features would of course need different file formats able to capture those features. Especially advanced features.

    But that's only true if the fiel format in question lacks the needed flexibiltiy.  Maybe MOOXML does lack that kind of extendable flexibility.  But it's not true of ODF!!!!! 

    An incredibly extensible and flexible model was built into ODF exactly for the purposes of being able to handle anything MSOffice documents could throw at ODF.  And while it's true that by nature, XML is rigid, hard coded, with a strictly structured and inflexible hierachy, ODF was designed for near infinite flexiblity.  It's all there, but it's not something Mcirsoft wants anyone to know about or understand.

    ~ge~

     - garyedwards on 2007-04-24
  • Great interview. Tim can obviously run circles around poor Jean Paoli. - garyedwards on 2007-08-20

  • What’s distinctive about the goals of OOXML? Primarily, to have full fidelity with pre-existing binary documents created in Microsoft Office. “What people want is to make sure that their billions of important documents can be saved in a format where they don’t lose any information. As a design goal, we said that those formats have to represent all the information that enables high-fidelity migration from the binary formats”, says Paoli. He mentions work with institutions including the British Library and the US Library of Congress, concerned to preserve the information in their electronic archive.


    I asked Paoli if such users could get equally good fidelity by converting their documents to ODF. “Absolutely not,” he says. “I am very clear on that. Those two formats are done for different reasons.”


    What can go wrong? Paoli gives as an example the myriad ways borders can be drawn round tables in Microsoft Office and all its legacy versions. “There are 100 ways to draw the lines around a table,” he says. “The Open XML format has them all, but ODF which has not been designed for backward compatibility, does not have them. It’s really the tip of the iceberg. So if someone translates a binary document with a table to ODF, you will lose the framing details. That is just a very small example.”

  • “Open Document Format and Office Open XML have very different goals”, says Paoli, responding to the claim that the world needs only one standard XML format for office documents. “Both of them are formats for documents … both are good.”
    • The door should have been slammed shut on OOXML near five years ago when, on December 14th, 2006, at the very first OASIS ODF TC meeting, Stellent's Phil Boutros proposed that the charter include, "compatibility with existing file formats and interoperability with existing applications" as a priority objective. - on 2007-08-19
    Add Sticky Note
  • 6 more annotations...
1 - 20 of 53 Next › Last »
Showing 20▼ items per page

Selected Tags

Related Tags

Sponsored Links

Ads by Google

Highlighter, Sticky notes, Tagging, Groups and Network: integrated suite dramatically boosting research productivity. Learn more »

Join Diigo