SC 34 Meetings, Okinawa - Days 3 & 4

by Alex Brown 29. January 2009 09:15
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

1/29/2009 5:27:06 PM #

Wu MingShi

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

Wu MingShi United Kingdom |

1/31/2009 1:35:19 AM #

Rick Jelliffe

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.

Rick Jelliffe Japan |

2/1/2009 11:58:27 AM #

Dubai

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

Dubai United States |

2/1/2009 4:37:38 PM #

Alex

@Wu MingShi

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


@Rick

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 ...


@Dubai

It's not the camera, but the technique! see http://www.adjb.net/post/Autumnal-HDR.aspx for details ...

Alex United Kingdom |

2/3/2009 6:25:23 PM #

trackback

Trackback from Doug Mahugh

Okinawa WG4/WG5 Meetings

Doug Mahugh |

2/4/2009 10:41:08 AM #

trackback

Trackback from A mooh Point

Post WG4-meetings in Okinawa

A mooh Point |

Comments are closed

About the author

Alex Brown


Links

Legal

The author's views contained in this weblog are his, and not necessarily of any organisation. Third-party contributions are the responsibility of the contributor.

This weblog’s written content is governed by a Creative Commons Licence.

Creative Commons License     


Bling

Use OpenDNS  

profile for alexbrn at Stack Overflow, Q&A for professional and enthusiast programmers

Quotable

Note that everyone directly involved in the development of ISO standards is a volunteer or funded by outside sponsors. The editors, technical experts, etc., get none of this money. Of course, we must also consider the considerable expense of maintaining offices and executive staff in Geneva. Individual National Bodies are also permitted to sell ISO standards and this money is used to fund their own national standards activities, e.g., pay for offices and executive staff in their capital. But none of this money seems to flow down to the people who makes the standards.

Rob Weir

RecentComments

Comment RSS