I was chuffed to see the ODF Alliance quoting this blog in their new Alliance Response to Ecma’s Proposed Disposition of Comments on OOXML. And they seem particularly interested in getting good results on the Standards Australia issues AU-09, and AU-15, AU-23 which are issues I submitted.
I guess they love me now! Though not enough to mention me by name, I am the only person quoted who is left nameless merely one XML expert. Hmmm, “He who shall not be named”… Since Groklaw thinks that the mere linking to this blog with my name by collegues foreshadows bad things, it is only prudent. I suppose it will have to be a secret love.
Since they quote me, I hope it is not too much to look at their response.*
Procedural Irregularities
In their early material various claims are made which bear looking at in more depth. They say there are many “documented irregularities”, yet when ISO JTC1 looked at them they found no substance. Looking at the list on Wikipedia where is the actual evidence of this villainy?:
- Portugal: a fixed working group size caused late-applicants to have sour grapes. Actually, the Portuguese already had expanded the size of that working group. Not chairs. The problem as such is the regularity not the irregularity, it seems: Sun and IBM didn’t like the rules. (Note the Wikipedia entry is biased.)
- Sweden: MS withdrew within hours an mistaken inappropriate offer of support to 2 partners before the meetings and notified the Swedish body themselves before any votes. (Again the Wikipedia entry is biased: IIRC it was MS who reported it, not “it surfaced.”) Sweden ended up abstaining due a procedural SNAFU: a double count of a vote in a meeting where another meeting could not be convened in time. So what do we have? A cock-up, transparency, the correct channels notified, no votes affected: no smoking gun (unless there is material that hasn’t come out.)
- In the Netherlands, the MS delegate voted one way, other people voted another way: again, a case of regularity not irregularity. (The Wikipedia entry is biased here:why is that substantial problem? Different national bodies have different rules depending on their bureaucratic culture and traditions apart from anything.)
- In Switzerland, it seems discussions were limited to technical and editorial considerations. These are the only comments that can be considered by the BRM, as has been emphasized recently by Alex Brown, the BRM convenor. So the Swiss chairman had in fact completely legitimate view, as far as I can see, as far as what is in-scope for ballot comments; that other NBs might put out-of-scope material in their ballot responses might make them feel good but they don’t go anywhere. (The Wikipedia article does not mention the scope of ballot comments to provide some balance.)
- Malaysia voting abstain is typical when there is no consensus. Australia did the same, it not an irregular procedure. If a NB submits their comments with the abstention, the comments get to the BRM and they become part of the mix, so no harm is done.
- Cyprus joins late. The idea that one side is more remiss than the other in trying to stack SC34 is not evidenced by the numbers: they just came in different waves separated by a few months. Given that perhaps 2500 of the 3500 comments sent in by NBs are parroted comments from a mail-in campaign (i.e. not from a proper independent review) it would take a lot of chutzpah for the ODF Alliance to get too excited by this one.
- Finally, in Norway MS asked its partners to participate. Again, no procedural irregularity at all.
I don’t know if pointing this out will have much effect. I think the point with the various bribery/corruption claims is that they have the necessary truthiness, so it doesn’t matter if none of them have any procedural irregularities.
5 Months?
ODF Alliance say there was only 5 months to review, yet there was a full year before then during the Ecma process for participation (e.g. by ODF Alliance and Ecma member IBM). Yet the draft was submitted in: December 2006 draft submitted and the ballot was in September 2007: that is at least 9 months. (And then there is the five months until the BRM for further looking at how to resolve the issues and the issues of other NBs.)
And after that comes the maintenance process, whatever form it will take: certainly it will have a pretty high premium on interoperability with ODF and other standards.
6,045 Pages
I have previously dealt with why raw page count is not a very fertile metric. There is so much duplication, so much whitespace and so many diagrams that the effective size for review is much smaller. Furthermore, the assumption that any large standard will not be reviewed with an international and national division of labour is, in my experience and certainly in this case, incorrect.
3520 Comments
The trouble with this number is that people then think “3520 flaws” rather than “750 individual issues and a lot of repetition”. Too many? In my blog On error rates in drafts of standards I have a good quote from Jim Melton, the editor of SQL, who has commented on his standards frequently getting thousands of comments. For a large standard, a good number of comments is an indication of real review, and says absolutely nothing good or bad about the general quality of the standard or the technology IMHO.
Seven Dwarfs
The ODF Alliance groups its response under 7 heads:
In short, the proposal does NOT address the critical need for: a.) review time; b.) harmonization, c.) a clear name; d.) a sound standard with no (new or old) technical errors; e.) interoperability; f.) support for legacy documents; and g.) consistency of “fixes.”
Lets have a look at each of them:
Review time
I have mentioned above that there is more review time than is often bandied about.
But the ODF Alliance argument here is that OOXML should be be standardized because of errors that were not found in DIS29500. This is a remarkably hopeful claim (perhaps a cunning plan): see falsifiability for a discussion on why it is shakey ground.
The strongest evidence would be if the (non-duplicate) flaw rates detected for DIS29500 were far in excess of the same for other standards. However, as the blog item above mentions, the numbers don’t go that way.
However, this is not to say that OOXML and ODF and PDF would not have been better submitted as Committee Drafts in the accelerated process to ISO/IEC JTC1 SC34. No-one is particularly enamored of any of the current fast-track processes.
Harmonisation
It is interesting that the ODF Alliance quotes Tim Bray that the world doesn’t need another way to express basic typesetting features. If it is so important, why didn’t ODF just adopt W3C CSS or ISO DSSSL conventions? Why did they adopt the odd automatic styles mechanism which no other standard uses? Now I think the ODF formating conventions are fine, and automatic styles are a good idea. But there is more than one way to make an omlette, and a good solution space is good for users.
My perspective is that harmonisation (which will take multiple forms: modularity, pluralism, base sets, extensions, mappings, round-trippability, feature-matching, convergence of component vocabularies, etc, not just the simplistic common use of a common syntax) will be best achieved by continued user pressure, both on MS and the ODF side, within a forum where neither side can stymie the legitimate needs of other.
Clear name
This is actually something that I have been pushing since early last year, in discussions with other SC34 people. It is part of the general observation that many of the problems with DIS29500 are not with the technology or the technical parts but can be fixed editorially: the scoping and conformance issues are examples. My point is not that “Office Open XML” is particularly confusing or that it should not continue as a brand name (not ISO’s business!), my point is rather that it is too similar to ODF/ODA/OpenOffice to be the name of the standard. I don’t know why the standard cannot have an extra part added to its name to be more descriptive. (And indeed if the plan to split out OPC to a separate part comes off, then the Ofiice Open XML really applies to the other parts so it may not be the best collective name.)
For example, the full name of the ISO Schematron is Information technology — Document Schema Definition Languages (DSDL) — Part 3: Rule-based validation — Schematron.
But is this really a showstopper for the standard? Of course not: the brand OOXML is already out in the wild. And Alex Brown has indicated that this kind of issue might be at the bottom of the list for discussion at the BRM; it is the kind of thing where people are happy to spend days discussing, which Alex is clearly not going to allow. 120 people are not traveling from all parts of the world for a week to get the issues they have raised ignored because other people’s issues are taking a disproportionate amount of time.
Sound standard
This is where I (this blog) get quoted! The blog item was The design goals of XML.
Note the difference in approaches. My angle is “I think this is a problem, I hope it can be fixed.” Their angle is “He thinks this is a problem, therefore the whole process should be abandoned.”
I think there is a kind of bait-and-switch going on: to understand it you have to make the distinction in your mind between what a particular draft (e.g. DIS29500) says and the larger concept of what OOXML could be when fixed up (e.g. substantially the same, with the same design approaches, though different in details.) It is the difference between text and technology. Here is the ploy: first find a technical or editorial problem in the draft, then transfer this to OOXML as if it were intrinsic or necessary, then use it as evidence of the unreformability of OOXML, in which case there is no point fixing the draft since the whole thing stinks.
My POV, if anyone cares, is no different from what I wrote in 2005:
I read recently a criticism of the “Binary XML Infoset” project as polluting the stream. I believe the lesson to be learned from XML is not that “Everyone should use one format, it should be simple, it should be Unicode, it should use angle brackets” but the far more challenging “Respect-driven standards development produces really good and generally applicable results.”
Note in particular this:
when I read general, rather than technical, criticism of standards or standards bodies, I usually detect strategic sour grapes, where the organization or writer is trying to undermine a process that they cannot influence enough. XML wasn’t based on the mentality people who don’t or won’t use this are idiots but we want to add to the solution space.
All that being said, I think buried in this section is the germ of an entirely valid point: even things included for legacy reasons should be in standard notations. You have make a more specific judgment than legacy=good (as some Ecma some people are perhaps prone to) or legacy=bad (as some anti-ODF people are perhaps prone to).
For example, I have written about the integer measurement system EMU used in OOXML: this is unusual but useful and a common kind of thing to do (e.g. groff, PDF, etc). But I don’t see any reason for twips let alone half points, they are just a bunion and a carbuncle, if not vice versa. Are they showstoppers? Well, it would be really good to get gratuitous problems fixed now, rather than leaving it for maintenance. But it is a matter best practice, but not an actual error or gap.
Interoperability
Interoperability is a great motherhood word. No-one is perfect.
They complain that
While the proposers “agree that it is important for the specification to support multiple types of object linking,” they suggest changing oleLink(OLE Link) to oleLink(Generic Object Connection). And, instead of referencing the specific OLE2 connection they say to use any generic ‘embedded object’.
When we look at ODF we see they have an element draw:object-ole which has a definition represents objects which only have a binary representation, almost the same thing. So the ODF Alliance want to keep the reference to OLE (and make it a normative reference, which is probably dubious but I digress). Fair enough: lets make the spec better! But look at the use this issue is put to: the heading says “What is missing? Interoperability! Why ignore the re-use of existing standards?” but the use of existing standards is never mentioned in the text.
I suspect that the heading is a carry over from a previous draft, where the body text was changed as it was discovered that among the Editors Disposition of Comments are details of adding scores of references to the various standards used by OOXML (both in DIS29500 and in other proposed fixes.) But my point is that the conclusion is not supported by the evidence, and their reaction to the issues they raise is too strident and over-reacting.
Support for legacy documents
This begins with actually quite an interesting point, and the first really new things to consider. Should a new standard have deprecated material? Putting aside the general point that a fast-tracked standard is not a new standard but a review and rebadging of an an existing external standard, the comment is that OOXML is a different case than other standards where this mechanism has been used: like C++ these standards capture a living technology in which some parts are living and others are dieing, but the ODF Alliance thinks that compatibility or legacy options are only warranted when they reflect multiple previous implementations. I wonder whether the presence of compatibility options designed to handle old Word Perfect behaviours puts a spanner in the works for that argument?
From the interesting start, the material on this point rapidly descends, ultimately saying
However, from the details provided, it appears that Ecma is merely taking a subset of VML, giving it another name (DrawingML), and using it in places where VML was previously called for. What is deprecated
merely re-enters through the back door.
This is quite bizarre: VML and DrawingML are in different namespaces and I have not seen anything in the Editor’s Disposition of Comments about taking subsets of VML and renaming it. I’d love to know what in particular is meant by this. DrawingML is not something new, but part of the draft (VML had almost been entirely retired, the difference is that the Editor wants to completely retire it.) In particular, there is nothing in the section they quote (Response 92) about subsetting: there is only material on the mechanics of deprecating VML, removing references to it in favour of DrawingL, and enhancing DrawingML so that it can do every that VML did (for example, to support rich text comments); deprecating VML necessarily involves making sure that DrawingML has equivalent features, how else could it be? So the ODF Alliance comment here is completely wrong, perhaps they think they can get away with it because the Editor’s Disposition of Comments document is not generally available.
The background to all this is that France’s AFNOR in its comments asked that the standard be split up with all the core material in one part and all the deprecated functions, documented settings, VML etc in a second part. Many other NBs also asked for the standard to be split up and for OPC to be its own part. My suggestion, through Standards Australia, was to split into 9 parts for example. So ECMA’s proposal is to do both: a part for core, one for deprecated/legacy/VML material, and a part for OPC, but then to add various conformance classes for different application areas which would give the same conformance subset effect that having multiple parts would achieve. So splitting up is a straightforward and direct response to NB suggestions.
Consistency
Once the Editor’s initial Disposition of Comments document is out, then the issue of consistency rightly becomes important for reviewers. If the Editor accepts one comment with a particular fix on certain grounds, why not accept another comment with a similar fix on the same grounds? So now is exactly the time to be bringing up consistency issues. And there certainly might be inconsistent responses to different NB comments, where the NB comments are themselves incompatible.
It is the job of the BRM to work through as many of these these kind of issues as it can. The Editor can only say “Here is how I would solve this” and the BRM has to sort through the issues and contradictions. And ultimately it is the National Bodies who then decide whether the revised text of the standard passes their tests.
The ODF Alliance give two example of horrible inconsistent responses. One is concerned with which version of schemas is normative, with the choices being suggested of either the electronic version or neither. (I hope what will happen is that the schemas will be printed as an annex in the standard, and that many of the schema fragments in the standard will be removed. ) I don’t think they are very serious here, the standard will end up saying something, and that something will in all probability be whatever the BRM decided.
The other inconsistency concerns another one of the Standards Australia Issues I raised. I don’t see the contradiction here: one response concerns content-type labels, the other concerns how to locate executables. Maybe there is some deeper issue that has evaded me…I think there might be a confusion here between OOXML content types (which are expressed using MIME content type notation, and live in the [Content_Types].xml part) and relationship types (which are expressed using a URI syntax and live in the various .rels parts.)
Again, the reason to mention all this is not to say that it is not appropriate to bring up issues like consistency in the lead up to the BRM. My problem is in using these run-of-the-mill things that can happen in any standard as evidence that we should decide to disallow the revised OOXML spec ahead of fixing it.
They write:
Can we in good faith endorse a standard that is not technically sound with conflicting recommendations on technical remedies?
But hold on, who is asking for such an endorsement? The purpose of the BRM is to fix these, so that the identified tecnical unsoundnesses get addressed and that there are no conflicts in the editor’s instructions. Then, after these have been fixed, the National Bodies can respond by changing their ballot responses if they are satisfied.
I am sad if I may jeopardize the love of the ODF Alliance, but this document of theirs is so full of non sequiturs that I don’t see it as adding much light to the discussions. But perhaps the purpose of the document is not to join in any dialog but to try to withdraw participants from it.
[Update: I think if I make fun of poor efforts, I should also praise good efforts. After the disaster of the document above, I see the ODF Alliance has now put out another one OOXML: Top 10 Worst Responses to the NB Comments which is a much more respectable effort, raising reasonable issues this time, restraining itself from the dire and lazy mish-mash, and good-humoured rather than ranting, which is particularly welcome. Its only a document format. In a previous blog I mentioned the spin technique of “innoculation” with the example of list, but I don’t see new ODF Alliance document as that at all, but entirely appropriate, and the kind of things the BRM should be discussing and that non-armchair people should be thinking about. (Of course, I do make the same proviso as with the NB comments: if you parrot a set of points provided by a campaign, you are not doing an independent review of the standard draft but you are doing a review of the pre-fab talking points! If every NB comes with its own Top 10 Worst list, that allows much more coverage and improvement than just one: otherwise when the BRM takes 10 minutes to fix these 10, there will be four days left twiddling thumbs! :-) ) So, well done ODF Alliance, I hope this is a sign of things to come.]
