solshare.net
Sign in or Join. Username:   Password:   (forgot password?)     Submit

MS Public Sector Team Blog

Browse by Tags

All Tags » Document Format... » Standards   (RSS)
Sorry, but there are no more tags available to filter with.

  • OpenXML and ODF - it's not a zero sum game.

    Jean Goffinet of Clever Age has a post intriguingly titled "Are we traitors or mercenaries?" on the ODF Converter team blog describing a lunch appointment with two "emissaries" from OpenOffice.org and OASIS. He explains how after the project was announced he reached out to both organisations, as he says :-

    After the project launching, I had contacted both organizations: the first one to ask for contributors (our plug-in is designed to allow its use by other applications, so we thought that OpenOffice.org could be interested in joining the team to make its product open and save docx files) and the second to have its agreement to use OASIS logo in our plug-in (agreement that we never had, so we decided to use another picture).

    Sadly he then goes on to say

    The two emissaries wanted to tell us how we were seen by OpenOffice.org and OASIS, and also to ask us some questions regarding our position. So we learnt that the OpenOffice.org team considered us as "traitors" (who are those traitors that work for the Big Satan Microsoft?) and that people from OASIS "did not like us" (even if they don't really care about our little company). In fact that was not a definitive judgement: they wanted to know exactly in which camp we were - because in this war, you cannot remain independant, you have to choose your side. So by default, as we work for Microsoft, we are seen as enemies; but if we show good willing and for instance join the OpenDocument consortium, that could be a sign that we may on the contrary be friends.

    If you are interested in document formats, in OpenXML, ODF, or interoperability you should read the rest of his post. For my part I don't think that this is a zero sum game. Happily more and more of the policy makers I am interacting with are reaching this same realisation too.

  • Cutting corners - the realpolitik of ODF standardisation?

    I made a comment at an event in Brussels and quite a few people have asked for more information so I thought I'd post here.

    I mentioned that in my opinion, Sun were completely aware that ODF wasn't sufficiently defined to support spreadsheet interoperability as long ago as February 2005 and that the realpolitik inside OASIS was to take advantage of the EU IDA's request to standardise by rushing to be first despite knowing the ODF specification was deficient in at least this area.

    So, here's how I reached this opinion. As I said, I'm delighted to be corrected if this proves to be factually inaccurate. This isn't intended to be FUD, I am only quoting OASIS' own mailing list.

    Back in early February 2005 James Clark made a comment to the OASIS OpenDocument technical Committee about the lack of interoperability for spreadsheet documents (my emphasis)

    I really hope I'm missing something, because, frankly, I'm speechless.  You cannot be serious. You have virtually zero interoperability for spreadsheet documents. OpenDocument has the potential to be extraodinarily valuable and important standard. I urge you not to throw away a huge part of that potential by leaving such a gaping hole in your specification.

    Claus Agerskov further commented that this provided a means of creating lock-in (my emphasis)

    "OpenDocument doesn't specify the formulars used in spreadsheets so every spreadsheet vendor can implement formulars in their own way without being an open standard. This way a vendor can create lock-in to their spreadsheets"

    SUN's Chair of the Technical Committee, Michael Bauer, responded that

    "There are from our point of view also no interoperability issues, because the namespace prefix mechanism we have specified unambiguously specifies what syntax and semantics are used for a formula".

    which David Wheeler interpreted as saying 

    "Every implementation must reverse engineer all other implementations' namespaces (they're not in the spec, so everyone's free to invent their own private incompatible namespaces). Then, every implementation must implement all the syntax and semantics of all other implementations' namespaces for formulas, if they wish to achive interoperability. And oh, by the way, your implementation might not implement the namespace for the document you're trying to load, so you may lose all the formulas."

    David made some proposals which I believe have now led to the OASIS Open Document -Formula subcommittee, but at the time the OASIS Technical Committee answered David saying amongst other things that: (my emphasis)

    "... please keep in mind that we have to fit proposed solutions into the politic of work that has already been done.  A politic that represents years of work that is just now on it's way to ratification at OASIS, and beyond to ISO.  Keep in mind also that the ISO certification comes at the request of the European Union. Time is of the essence. Ratification perhaps trumps perfection. At least for the moment. We are very much aware that whatever we leave outside the specification remains open (or not) and exposed to ambiguities and custom implementations, all of which have proved to be so problematic in the past."

    Remember this was back in February 2005. In September 2005 Newsforge carried an artlicle euphamistically titled "OpenDocument office suites lack formula compatibility" but which did a good job of demonstrating that OpenDocument represented a step backwards from the status-quo and included some screen-shots to illustrate the problem, concluding

    Sooner or later, a solution to the formula incompatibility problem will be found. Ideally, someone will solve it sooner, and without any intellectual property problems. The capability to exchange spreadsheets freely is essential for free desktops in the business and education markets, and it should not be limited by artificial restrictions.

    Now when Tim Bray (also with Sun) heard of this in October 2005 he wrote

    Bad Formula Trouble · I learned, to my dismay, that the ODF specification is silent on spreadsheet formulas, they’re just strings. This is obviously a problem; much discussion on what to do ensued. I lean to the idea, much bally-hooed by Novell, of simply figuring out what Excel does, writing that down, and building it into ODF v.Next. Mind you, anyone who’s really been to the mat with Excel, in terms of Math & Macros, knows that it isn’t a pretty picture, there are real coherency problems. But it’s good enough and the world has learned how to make it work.

    I don't know if its correct, but the roadmap on OASIS' web site seems to suggest that this might be fixed in ODF 1.2, but it seems that's not due before October 2007 at the earliest.

    Remember all of this was known back in very early 2005, pre-ISO certification. Since ODF became ISO26300 OASIS has been working hard to promote its adoption. A prime tactic has been to create the impression with public policy makers that the longevity of public records is in danger unless they mandate ODF.

    Somehow they neglect to mention that the spreadsheets can't interoperate though.

  • Ecma Office Open XML File Formats Standard – Status Report - 21 June 2006

    Here's June's update (see also May's and April's) from the Ecma International Technical Committee (TC45) which is working to establish an international open standard for Office Open XML File Formats (as described in the TC45 program of work) :-

    This week (June 19-21), the committee held its fourth face-to-face meeting in Sapporo, Japan. The meeting was hosted by Toshiba and attended by eighteen participants. The technical agenda included new material on SpreadsheetML, PresentationML, DrawingML, compound documents, and the Open Packaging Convention. The committee reviewed issues and modifications to WordProcessingML as proposed by the committee, and finished resolving substantive issues regarding conformance and interoperability. Highlights of the meeting included presentations by Statoil, BP, and Essilor of methods for visualizing and analyzing the schema interdependencies defining the file format, and demonstrations of Java prototype tools by Toshiba to transform Office Open XML to HTML for viewing in any browser. Ecma has requested liaison with ISO/IEC JTC1 SC34 in order to help prepare a possible Open XML submission to ISO/IEC, and SC34 has appointed a liaison officer. The TC45 committee's next face-to-face meeting will be hosted in August by Microsoft in Redmond, Washington.

    The technical committee includes representatives from Apple, Barclays Capital, BP, The British Library, Essilor, Intel, Microsoft, NextPage, Novell, Statoil, and Toshiba. The United States Library of Congress has also recently joined the Ecma TC45 committee. By monitoring and contributing to the formation of this standard, the Library hopes to ensure that office productivity documents created by individuals and organizations using widely available tools can be saved in a form that will remain accessible as technology changes.

    The work is in progress, and the participants in Ecma TC45 are providing the reference schema and specification as working documents, for informational purposes only. The contents are subject to change, and may change monthly; a channel is offered to provide technical feedback on the drafts. There is also a technical forum at http://www.openxmldeveloper.org/ for developers who are interested in using the Ecma Office Open XML file formats. For general information about Ecma International, please contact Christa Rosatzin-Strobel (media@ecma-international.org).

    Tom Ngo (NextPage)
    TC45

    The following organizations have participated in the work of Ecma TC45 and their contributions are gratefully acknowledged:

    Apple, Barclays Capital, BP, The British Library, Essilor, Intel, Microsoft, NextPage, Novell, Statoil, and Toshiba

    Available Documents:

    [Update] Brian Jones has written about the ECMA meeting  in Sappora too. Brian reports that the U.S. Library of Congress has joined Ecma TC-45.

This Blog

Syndication

SSN Program Home | Terms of Use | Privacy Statement
© Copyright 2008 Microsoft Corporation. All rights reserved.