Honeymoon Island

That’s what they call it here, and – in season – this resort is throbbing with newlyweds. Right now though, it has a something of the ghost-town about it, as it is half-deserted apart from us standards wonks.


Today was a solid 9-till-5 meeting day, and for me the jet lag is beginning to take its toll. Luckily our Korean hosts have a steady supply of coffee – and that keeps us all in the game; that, and the ineffable fascination of every topic we discuss in WG 1. Take the topic of character registries for example. Now, even for WG 1 diehards this is a somewhat recondite subject area – so I am sure a few eyes glazed over when we addressing the question of whether to include a normative reference to ISO/IEC 15897 in our own CREPDL specification (FCD 19757-7). However, after an eloquent argument from Hideki Hiura there was a clear consensus not to include it. Or, at least, no one (except the original proponent of the inclusion of the reference) contradicted him …

Yet more ODF and OOXML

… were the main topics of today, both separately and in tandem. Of most interest, perhaps, was the discussion surrounding the start of work on a project setting out to describe the mapping between ISO/IEC 26300 (ODF) and ISO/IEC 29500 (OOXML). This had received wide and decisive voting support from countries in its ballot, though some countries had objected to its commencement due to the non-availability of the ISO/IEC 29500 text. That hiatus is now happily behind us and the project is set to proceed with a powerful three-person editing teams (from Germany, Korea and China).

It is always pleasing to see widening participation in SC 34 and in these meetings we have been honoured with the presence of a large Chinese delegation. Word is that UOML may be coming our way shortly, and there are even rumours that there may be an opportunity for SC 34 involvement in UOF. Wow – if so, that would be a really positive opportunity for work on truly International document interoperability work, and would further strengthen SC 34’s role as the centre of the Office document format universe.

ODF – Our work here is done?

Day 0 had been concluded with a tasty Korean meal (washed down with possibly a tad too much Korean vodka) and it was very interesting to hear some of the views from NB members on how they thought the office formats future will play out (and no, there were no Microsoft, IBM or Ecma people at the table). One view was that ODF had served its purpose (to get MS formats out into the open) and should now declare victory before fading away gracefully; another was that OOXML would surely become the default format of the OpenOffice.org suite, and that this would crystallize the real option users had: to use FOSS or commercially-licensed Office packages. I’m not sure I’d go with either of these but still, it was refreshing to get some new perspectives rather than the stale repetitions that have too often characterised the exchanges of the past months. It will be interesting to see what really happens ... personally I think ODF is more likely to emerge as a kind of “default choice” than OOXML (not perhaps, that most users care).

Into the meetings proper

Sunday (Day 1) was a busy day of WG 1 meetings in the excellent facilities provided by our Korean hosts. In the morning we covered a number of DSDL topics, including Part 8 (DSRL) and the part I am editing – now called “Extensible Datatypes” – which has a new draft which will progress to FCD ballot. Rick Jelliffe, who sadly isn’t with us, had sent a voice message talking us through his fascinating proposed enhancements to Schematron – the Part of DSDL for which he is responsible. Very much business as usual for WG 1. However …

OOXML shock?

The afternoon was devoted to OOXML matters. Evidently, the sudden appearance of the final text of ISO/IEC 29500:2008 has come as something of a surprise for many; and the appearance of the first defect report (from Japan) shortly thereafter was a shock. Suddenly it’s all real; the clock is ticking and the Project Editor is obliged to respond to Japan’s report in eight weeks. Murata Makoto (the convenor of WG 1) carefully explained the details of the maintenance regime and took us through an example of one of the Japanese defects, which centred on a BRM-mandated change (from Finland) that had not been properly implemented in the final OOXML text. No doubt other NBs, as a priority, will now scour OOXML to make sure “their” changes have been implemented, and submit defect reports accordingly where they have not. The UK, with its 600 or so accepted changes, has a lot of checking to do …

I look on this though with a certain grim satisfaction, for two reasons. First because by insisting on timely defect handling SC 34 is compensating for a deficiency of the Fast Track process: the lack of National Body review of the final text. Secondly because one of the many problems of the JTC 1 standardisation of ODF in 2006 is the lax maintenance regime, which boils down to OASIS declaring: we’ll fix your reported ODF defects if we want to in our own good time, thank you very much. Partly as a reaction to this SC 34 was determined to hold OOXML’s feet to the fire and make sure the JTC 1 maintenance regime (one of the better processes described by the Directives) was fully applied and that this time, it was got right.

Day 0 is meant to be for acclimatisation – coming to terms with the time-zone, a spot of gentle sightseeing, that sort of thing … The formal meetings start tomorrow (Sunday).


As it is, however, a few pressing issues have demanded attention – one is a rather esoteric problem surrounding XML entity reference renaming in DSRL (follow along on WG1’s public discussion list here); the other is the impact that the sudden appearance of the ISO/IEC 29500 (OOXML) text has had. Suddenly, a lot of work which might have had to go on ice seems likely to proceed apace – for example the ODF/OOXML interoperability work and the defect handling of OOXML.


NBs will also start to scrutinise the final 29500 text to ensure their own BRM-mandated changes have been implemented. In my opinion one of the many problems with the Fast Track process is that the text implied by the BRM result passes straight for publication (this is explicit in the Directives). It would be much more sensible all round, I think, to allow for an FDIS stage so that NBs could proof the text for the implementation of the resolved-on-changes.

Say what you like about Vista, but one ace up is sleeve is definitely the ability to play Crysis using DirectX 10. Eye candy indeed, and an astonishing feat of programming.

I was intrigued to notice in the game's title sequence the other day that the island setting for the game is not too far off the coast of Korea. Coincidentally the venue for the upcoming SC 34 meeting is Jeju Island, and as I write I am in that state of nervous excitement that precedes any long trip. From leaving the front door it is going to be over 20 hours before setting foot in the meeting hotel. If everything goes smoothly.

On a personal level I am expecting (hoping) to hear less at this meeting about OOXML than in the last few, and to be able to return to the important infrastructure XML standards (and in particular DSDL) that first lured me into International standardisation.

So, no nanosuit required ... we shall see ...

In a comment to my last blog entry, Lars Marius Garshol, wondered whether the DxO Optics Pro software I was using was any good at recovering “lost” or “blown” highlights – bright areas of an image which all get maxxed out and appear as pure white. Here’s a simple experiment to see how it performs.

The first thing I discovered is that the “highlight preservation” feature is not enabled unless processing a RAW image, so with some trepidation (am I entering the dark side?), I set my DSLR to take NEF+JPEG, stuck it out of the window and took a couple of shots of Cambridge back gardens with a load of cloudy sky in view.

The result out of the camera was as expected: much of the cloudy sky simply showed as white:




Taking the NEF equivalent image and processing it through DxO Optics Pro with “highlight preservation – strong” selected yielded the following result (tip: if you're viewing this on a less-than-stellar LCD screen which is not good at displaying subtly-differentiated highlights, try tilting it to get an appreciation of what information has been retrieved):



A striking improvement I’d say. From thinking that RAW was an unwarranted nuisance, from now I’m going to set my camera to take JPEG+RAW so that similarly lost highlights can be recovered if need be for interesting pictures. After it, if it looks better – that’s what matters.

Of course the purist might say it would be better to get the exposure right to start with – but in many daylight conditions the light contrasts are just too strong for the sensor on a digital camera to be able to cope – film is better for that right now.