Once again I feel that bubbling up of almost schoolboy fervour that presages a set of SC 34 meetings. In Paris no less (AFNOR shall be our hosts): the city of love, fine art and rognons à la moutarde.
What is tasty on SC 34’s menu? Well four working groups are meeting next week:
- WG 1 (which I convene) will be carrying forward its work on foundation standards – particularly the schema languages of DSDL. We have two new (/proposed) projects to discuss: one a schema language focussed on cross-reference validation; one on associating schemas with documents using processing instructions. Probably our most successful schema language, RELAX NG, is due for an update and several new features are up for discussion: keep it coming!
- WG 4 (OOXML) will continue its intensive maintenance on ISO/IEC 29500 – not least in handling a new set of approved corrigenda (just voted on) and dealing with the day-to-day grind of correction and improvement. There are larger questions to answer too, in particular those which concern the relationship between the Strict and Transitional forms of OOXML. I have led the preparation of a background paper on this which (thanks to the newly open WG 4 mail archive) can be accessed as a public document (PDF). I predict some lively discussion!
- WG 5 (OOXML/ODF interop) will continue its work examing how (or not) the two formats may be used by systems which hope to interoperate. TR 29166 - dedicated to this topic - continues to take shape ahead of its projected finishing date in 2011.
- WG 6 is the newly-created WG dedicated to the JTC 1 side of maintenance of ISO/IEC 26300:2006 (aka ODF v1.0). As a newly-created group there will no doubt be a certain amount of adminstrivia to be got through but there are more substantial issues looming too: defect reports to be advanced and the longer-term project of amending ISO/IEC 26300 to bring it into alignment with ODF 1.1 – there is general agreement that it makes sense to reduce marketplace confusion by reducing the confusing number of standard (and non-standard) “ODF” variants out there, and aligning versions between standards organisations.
Stay tuned (and follow hashtag #sc34 for real-time updates) …
Last year I made an autumn photo trip to Wicken Fen; and this morning decided, seeing the light, to have a repeat visit. It was more sombre today, but quite interesting in a muted way I think.
These are three-photo images tone-mapped from HDR with Photomatix.
At the invitation of ANSI, SC 34 is in sunny Bellevue for five jam-packed days of Standards meetings (Sunday-Thursday). This is a full and busy event, with around 60 delegates registered from 14 countries (Belgium, Brazil, Canada, China, Denmark, Finland, France, Germany, India, Korea, Norway, South Africa, UK, and the USA) and 4 liaison organisations (Ecma, OASIS, W3C and the XML Guild).
Maybe by the end of it a number of momentous questions will have been answered, including:
- Whether the world needs a standardised way to associate XML documents with schemas
- Whether OOXML Transitional should be evolved
- How ISO/IEC 26300 shall be maintained within SC 34
- How standard schemas should be licensed to users
- How MIME types should best be used for identifying document formats
Stay tuned ...
I have been using a Nikon D300 now for six months, and one of the characteristics I have had to get to grips with is its default colour handling: out of the camera the colours can be a touch “zingy” to my eyes – in an effort to replicate the classic Fuji Velvia look, the colours processing gives very rich yellows, but this has the side effect of making reds somewhat orangey.
Here is a picture of some rose hips:
In real life to my eye it seemed that the central rose hip had no orangeyness to its red; the upper rose hip had just a touch of orange. But, out-of-the camera, the colour rendition here differs from what I saw: the tints are much more orange.
One solution to this lies in the dark art of RAW conversion. Many photographers roll their eyes at this business – it can require a lot of time farting around with post processing software rather than taking more photos. However, I quite like farting around with software, so am quite happy to experiment.
For RAW conversion I use the fabulous DxO Optics Pro package. This offers a host of options for converting the RAW image into a JPEG, and it has to be said that some of these (such as chromatic aberration fixing) are now finding their ways into camera bodies. However, this software still offers quite a bit more flexibility and, in particular, will fix lens distortion for certain camera/lens bodies which have been analysed.
Another useful feature is the ability to control colour rendering. Want to give your Nikon D300 pictures the look of a Canon 40D? No problem – just specify it.
For Nikon users, a DxO user by the name of Andy_F has developed some RAW conversion presets specifically targeted at correcting the colour conversion of recent Nikon bodies. The result of using one of these to process the original RAW file give this result:
Which is much closer to what I think I saw.
Even better though is Andy_F’s “landscape” preset, which attempts some detail recovery from the image:
This week I attended 4 days of meetings of SC 34 working groups. WG 4 (OOXML maintenance) and WG 5 (OOXML/ODF interoperability). Last year I predicted that OOXML would get boring and, on the whole, the content of these meetings fulfilled that prophecy (while noting, of course, that for us markup geeks and standards wonks “boring” is actually rather exciting). There was however, one hot issue, which I’ll come to later …
Defects
Since the publication of OOXML in November last year, the work of WG 4 has been almost exclusively focussed on defect correction. To date over 200 defects have been submitted (the UK leading the way having submitted 38% of them). Anybody interested in what kinds of thing are being fixed can consult the material on the WG 4 web site for a quick overview. During the Copenhagen meeting WG 4 closed 53 issues meaning that 71% of all submitted defects submitted have now been resolved. By JTC 1 standards that is impressively rapid. The defects will now go forward to be approved by JTC 1 National Bodies before they can become official Amendments and Corrigenda to the base Standard. Among the many more minor fixes, a couple of agreed changes are noteworthy:
- In response to a defect report from Switzerland, for the Strict version (only) of IS 29500, the XML Namespace has been changed, so that consumers can know unambiguously whether they are consuming a Strict or Transitional document without any risk of silent data loss. This is (editorially) a lot of work, but the results will be I think worthwhile.
- As I wrote following the Prague meeting, there was a move afoot to re-instate the values “on” and “off” as permissible Boolean values (alongside “true”, “1”, “false” and “0”) so that Transitional documents would accurately reflect the existing corpus of Office documents, in accord with the stated scope of the standard. This change has now been agreed by the WG.
The ISO Date Issue
The “hot issue” I referred to earlier is ISO dates. What better way to illustrate the problem we face than by using one of Denmark’s most famous inventions, the LEGO® brick …
OOXML Transitional imagined as a LEGO® brick
More precisely, the problem is about date representation in spreadsheet cells. One of the innovations of the BRM was to introduce ISO 8601 date representation into OOXML. However the details of how this have been done are problematic:
- Despite the text of the original resolution declaring that ISO 8601 dates should live alongside serial dates (for compatibility with older documents), one possible reading of the text today is that all spreadsheet cell dates have to be in ISO 8601 format
- Having any such dates in ISO 8601 format is particularly problematic for Transitional OOXML, which is meant to represent the existing corpus of office documents. Since none of these existing documents contain ISO 8601 dates having them here makes no sense
- Even more seriously, if people start creating “Transitional” OOXML documents which contain 8601 dates, then a huge installed base of software expecting Ecma-376 documents will silently corrupt that data and/or produce surprising results. (My concern here is more for things like big ERP and Financial systems, rather than desktop apps like MS Office). Hence the odd LEGO brick above: like those bricks, such files would embody an interoperability disaster
- Even the idea of using ISO 8601 is pretty daft unless it is profiled (currently it is not). ISO 8601 is a big complex standards with many options irrelevant to office documents: it would be far more sensible for OOXML to target a tiny subset of ISO 8601, such as that specified by W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes
-
Many date/time functions declared in spreadsheetML appear to be predicated on date/time values being represented as serial values and not ISO 8601 dates. It is not clear if the Standard as written makes any sense when ISO 8601 dates are used.
The solution?
Opinions vary about how the ISO date problem might best be solved. My own strong preference would be to see the Standard clarified so that users were sure that Transitional documents were guaranteed to correspond to the existing document reality – in other words that Transitional documents only contain serial date representations, and not “ISO 8601” date representations. In my view the ISO dates should be for use in the Strict variant of OOXML only.
If a major implementation (Excel 2010, say) appears which starts pumping incompatible, ISO 8601-flavoured Transitional documents into circulation, then that would be an interop disaster. The standards process would be rightly criticised for producing a dangerous format; users would be at risk of corrupted data; and guilty vendors too would be blamed accordingly.
It is imperative that this problem is fixed, and fixed soon.
Impressions of Copenhagen
Our meetings took place at the height of midsummer, and every day was glorious (all meetings started with a sad closing of the curtains). Something of a pall was cast over proceeding by thefts, in two separate incidents, of delegates’ laptop computers; but there is no doubt Copenhagen is a wondeful city blessed with excellent food, tasty beer, and an abundance of good-looking women. Dansk Standard provided most civilised meeting facilities, and entertainment chief Jesper Lund Stocholm worked hard to ensure everyone enjoyed Copenhagen to the full, especially the midsummer night witch-burning festivities! Next up is the SC 34 Plenary in Seattle in September; I’m sure there will be many more defect reports on OOXML to consider by then, and that WG 4's tireless convenor Murata-san will be keeping the pressure on to mantain the pace of fixes …
Jesper Lund Stocholm