The Editor’s Disposition of Comments is quite an important document in the standards development process at ISO. After National Bodies submit their initial positions and comments on a late draft standard, the editor of the standard puts together a document to try to satisfy the various comments. Even though the Disposition of Comments document is not official, in the sense that anything in it is automatically accepted, it is usually the starting point for comment resolution, and, given that most comments are uncontroversial, is often the end-point too.

Monday 14th Jan was the self-imposed deadline for the circulation of the IDS 29500 Editor’s Disposition of comments. (The comments and disposition documents have been leaked to the web, with no tears from anyone.) Here is my rough characterization of them:

image001.gif

The Editor (Rex Jaeschke on behalf of ECMA TC45) has accepted the lion’s share. There is a small chunk of comments that are out of scope (typically concerning IPR or procedural comments.) There is a small chunk which the Editor has decided are issues for the maintenance phase, not the fast-track process: these are typically how comments like “ODF has feature X, why doesn’t OOXML support it?” There is another chunk of issues where the Editor disagrees with the substance of the comment, but wants to address the issue by adding clarifying or helpful text to the specification: for example, the issue of bitmasks is handled by giving examplars of how to handle them in XSD, RELAX NG, Schematron, DTLL and XSLT.. And finally, another chunk where the Editor disagrees, and gives the rationale for the disagreement. These are typically where the comments cross ECMA’s line in the sand: that no currently valid OOXML document should become invalid.

Of course, even in the comments where the Editor agrees with the comment, there may be some cases where the Ballot Resolution Meetinig next month decides to do something different from the Editor’s recommendation.

So how does it compare with the touchstone issues I isuggested in Your Country’s Comments Rated!?

The particular touchstone issues I see are that spreadsheet dates need to be able to go before 1900, that DEVMODE issues need to be worked through more, that the retirement of VML needs to be handled now, and that there needs to be a better story for MathML.

Lets see the suggested resolutions for each of them

  • Spreadsheet dates to go back before 1900 (and can use ISO 8601 date format),
  • DEVMODE concerns printer-dependent data which may be binary: the editor suggests some minimal changes to say “information” rather than “data structure” and to show how the system would work with some future XML-based print structure, but leaves the issue of a standard format to maintenance and justifies the need for these printer-dependent data chunks on the need to package information in legacy documents:
  • VML is being withdrawn from the places it is used in the specification, which now use DrawingML (e.g. for backgrounds in WordpocessingML); (furthermore, this provides a level of modularity that theoretically allows some kind of use of SVG for drawing, though I don’t expect this would be a popular option unless Office supports it.)
  • For Maths, the Editor recommends allowing alternative formats in particular recommending MathML: this is not to replace the OOXML Maths, but in the context of “rehydration” which is where you want to round-trip through systems that don’t support your full language, so they use some lesser one (such as a graphic) as a fallback, but the systems maintain the text of a higher-level format. This is probably good for MathML adoption, but also for professional maths systems developers.

Finally, what about that issue I have been tracking that I think is a crazy edge-case blown out of proportion: the AutospaceLikeWord95? Well, now we have a few pages of documentation about a tiddly bit of extra space between digits and full-width characters (as used by Japanese); in fact we have much more complete documentation of typesetting behaviour that should not be implemented compared to what should be implemented! It doesn’t do any harm to have this documented, except that it is a distraction from more substantive issues and has notoriously been used as evidence that DIS29500 cannot be implemented.

(Full disclosure: I am due to be helping out Rex’s team in some way with editorial gruntwork this month. The above is my own opinion.)

[Update: In case anyone is interested, the chart is based on counts of the US & GB dispositions, two of the largest commenters which I think are pretty representative (I have scanned all the comments and dispositions): most comments from other NBs are mind-numbing copies of these. The numbers appears to match the Australian disposition and other NB comments by inspection. However, not all comments are equal in impact and (as you would expect) the more trivial the change, the more easy it is for the Editor to accommodate. I thought it best not to add the numbers to the chart, because I don’t want people to fall into the “raw page count” trap and read all sorts of things into an inadequate metric. The chart is a sign that the editor thinks most issues are resolvable, not necessarily that all or most critical issues for any NB have or have not been addressed: the devil is in the details. What it is a good indication of, IMHO, is that the ISO process is moving forward, the various parties are being engaged and stretched, and the “formalized conversation” I have written about before has progressed to its next stage. ]