Where is there an end of it? | SC 34 Meetings, Okinawa - Days 3 & 4

SC 34 Meetings, Okinawa - Days 3 & 4

Hotel Walkway at Sunset
Hotel Walkway at Sunset

Two days of hard grind. A lot of administrivia to sort (meeting dates, etc.); many paragraphs of the Directives to read; many defect reports on OOXML to address; and some vigorous discussion to be had about interoperability.

Some concrete progress was made, notably:

  • The first defect reports on ISO/IEC 29500 (aka OOXML) were addressed, and fixes agreed
  • Some principles were established how updates (as opposed to fixes) for OOXML might be processed
  • Some useful discussions in WG 5 clarified the scope of the ongoing work drafting a technical report giving guidance on how 29500 (OOXML) and 26300 (ODF) can interoperate

From my perspective, the most exciting discussion during these meetings centred on a presentation from the ODF editor, Patrick Durusau, on what he called “true” interoperability. Patrick (betraying his Topic Maps background) set out a suggestion that a PSI might be created to identify the document constructs described by the two document format Standards, and that each PSI might be in turn associated with metadata and documentation related to that construct. Essentially, this approach views the “problem” of interoperability between ODF and OOXML as a problem of documentation — though Patrick also pointed out that the interoperability problem had already been solved by corporations (maybe he meant Microsoft, for example) and that these corporations were, perhaps churlishly, keeping the information to themselves.

I see the establishment of such rich descriptive material as being a first important step on a road which leads to the dissolving of what we currently see as meaningful differences between the document formats. Perhaps in time the rest of the world will come to realise too that when we talk of a preference for ODF and OOXML we are, in the main, expressing a preference for syntax, and that the juvenile “OOXML vs ODF” arguments – however much they are loaded with corporate agendas masquerading as moral superiority – will achieve precisely nothing for those who matter: the end users.

Comments (4) -

  • Wu MingShi

    1/30/2009 1:27:06 AM |

    Nice picture of the walkway. One question though, does it shield you from the rain?

  • Rick Jelliffe

    1/31/2009 9:35:19 AM |

    A death march of a thousand miles starts with the first step! I don't want to insist that the mappings approach is bureaucratic, tail-chasing and can only work when the level of detail is such that it will require double the ODF and OOXML efforts combined, but I don't want to deny it either.

    A different approach (though one that does not preclude a mapping effort) would be that of aligning the packaging/alternatives/chunking/graceful-degradation/hinting-extensions/component mechanisms to allow plurality ASAP, for governments to insist on this kind of plurality support as a real basis for openness (i.e. level playing field) and let developers and users determine which technologies meet the mark and what their connections are.

    In concrete terms, we need OOXML and ODF to support as part of the same package, as well as their home-made drawing packages (ODF's dialect of SVG and OOXML's DrawingML), JPEGs at screen resolution and even real SVG Tiny (at user option, for example.)  

    The standards are pretty close to this, and these kind of packaging issues are much easier to change than ones that relate to the deeply embedded functionality of a program (e.g. the atomic scalar units used by drawing programs, or the calculation order of spreadsheets).

    Look how easy and uncontroversial MathML is in this regard: it is not necessary for it to be used as the internal format as long as there is a complete-as-possible-given-the-capabilities-of-the-application transformation.

    Once we are 5 years or so down the track, and we have our complete mappings and PSIs, what will we discover? ...Apart from that the world has changed and what we have mapped may not be so relevant now... That we need the infrastructure in the file formats to support plurality and multiplicity in order to decouple the exchange format from the native formats, in order to make the whole thing politically and commercially acceptable.

    When we look at the things that work, that have flexibility and agility, they are based on kinds of modularization and plurality: the internet stack being the classic example. Even XML Namespaces (the feature, not the syntax) has been a great success in allowing modularization and componentization.

    I think the standards effort has to make it easy to allow a new generation of mixed-tradition documents. If OOXML's graphics are better than ODF's graphics as far as presentations go, there should not be any artificial barriers to allowing those in ODF; if SVG tiny is better than DrawingML for wordprocessing, it should be usable; if Open Formula's function library is better than the one in SpreadsheetML, it should be usable. The wide range of strategies (translation to native, downloadable components, adoption as native format) should be the developer's business.

  • Dubai

    2/1/2009 7:58:27 PM |

    wow.. did you took this picture?? what camera did you use.. really beautiful.. I've been following all your articles..

  • Alex

    2/2/2009 12:37:38 AM |

    @Wu MingShi

    Perhaps if the rain was very vertical, a thin person might so benefit ...


    For a "mapping" you may be right about the 1000 years, however Patrick's proposal in the immediate term would tend to increase (a) the identifyability of document constructs (whatever that quite means) and possibly (b) the amount of documentation -- he wants to associate a bunch of metadata and commentary with each PSI.

    Watching Jesper cut code to use OOXML, for example, it was striking that the current documentation is so unwieldy for developers who can see an element name, and want to know quickly what that element is for.

    If this work can help to raise levels of understanding about the two formats, I can't see it as anything but good. I don't see it as being at all at odds with the move away from One-Schema-Driven formats, which we are both interested in ...


    It's not the camera, but the technique! see for details ...

Comments are closed