First a quick recap about one of the many games at play in the recent and current standards battles.
Plan A was that if ODF was made an international standard, it would allow government mandates and a seizing of market share away from Microsoft Office. Everyone knew that Microsoft's file formats were its crown jewels that never would be revealed, and that it was only monopoly/bundling effects that made people use its applications. That didn't work out, in part because product trials failed to convince the customers that rip out and replace would be satisfactory at that time. But also because Microsoft put its own formats forward for standardization.
So Plan B was to participate in the standardization process for Office Open XML (OOXML), to point out as many flaws as possible, though whether the flaws were real or illusionary was not necessarily the highest priority in every case. Everyone knew that Microsoft would never agree to any changes. That didn't work out, because in fact Ecma agreed to almost all suggested changes** (though not the more, ummm, hopeful ones that involved OOXML morphing into ODF and not always to the extent preferred by the proposer.)
So as it became clearer that in fact the the changes that Ecma was willing to make would indeed satisfy a majority of reviewing National Body, Plan C was initiated: if the process itself could be discredited, it would be just as good as if the standard had not been accepted. Everyone knew that whatever changes were made, it would not be enough to satisfy the National Bodies.
Towards the end of the ballot, when there was such a large participation, along came Plan D, which involved what was certainly perceived by the targets as intimidation, including threatening legal action against National Bodies or their decisions. After the disaster of the UK Unix Users' Group's failed court case (to the High Court) Plan D seems to have been abandoned, and so we are back to Plan C.
And that is where we are at the moment. Now, the thing is of course that few people who participated in Plans A to D will imagine themselves as being played like a violin, but Plans A to D rely on mobilizing open source proponents and fitting in with their mindset, aspirations, prejudices and ideals. So please don't read me as positing some world with helpless puppets and some evil puppetmaster pulling their strings! That would be as dismissive and reductive as speaking of "Microserfs"! These plans are viral and obviously resonate with many people, which is not to say there was not a Patient Zero!...
The CONSEGI 2008 Declaration
I write this as a preamble to quickly looking at a particular issue: the news last week that several Southern hemisphere government IT departments had announced that they would not be taking appeals to IS29500 further, that with respect to government interoperability frameworks
Whereas in the past it has been assumed that an ISO/IEC standard should automatically be considered for use within government, clearly this position no longer stands.
I would briefly point out that in fact very few, perhaps none, of the interoperability standards that might be used actually come through ISO/IEC (by which they mean JTC1). This is because many of the JTC1 standards came from the outside (e.g. OASIS RELAX NG, OASIS ODF, Ecma OOXML) where they continue to be co-developed. And some of the leading ISO standard get adopted not in their ISO form but in their industry consortium profiles/value-adds—you adopt XML not SGML and W3C and ISO take care of the XML<->SGML relationship; similarly, you adopt Unicode and the Unicode Consortium and ISO take care of the Unicode<->IS10646 relationship.
So there is an aspect of huffing and puffing there, where they are refusing to do something they weren't going to do anyway. The thing is that ultimately considerations about interoperability comes down to implementation and deployment not standardization.
However, I actually think this is a good move by the state IT managers, but in a different area. Regular readers will be aware that I think there needs to be a much more pro-active stance (by governments and activists) against royalty-bearing standards, particularly at the ISO level. OASIS seems largely free of it now, but at ISO it noticeably lingers on with the MPEG work. Free technologies such as Ogg Vorbis need to be standardized (whether at ISO or OASIS or W3C it really doesn't matter, though I suspect there would be too many turf battles at ISO initially) and promoted by governments. Public but not open specifications such as ZIP too. Royalty-bearingness is more important than pedigree, for promoting open standards, IMHO.
Actually, almost the only open standard from SC34 with only open source implementations (as far as I know) but which does not come from external organization that might be affected here is ISO Schematron (and some of the other parts of ISO DSDL). It is interesting to read a press release where your own standard is perhaps the only actual victim. But I don't really worry if Schematron is on any list for automatic consideration, because not only do I doubt that any automatic list for path-based schema languages exist, but more because I think all standards need to rely on their excellence as technologies which is utterly different from their status as IT standards (which is a QC/QA process, an agreement, and never a warrant that the technology is indiscriminately applicable.) And I think Schematron fits in there as technically excellent: and I see nothing in the IT statements about any technology being rejected because of its status as an ISO standard!
But, of course, this is really about IS29500 Office Open XML. And there, again, I think the comment is interesting. No-one expects that governments will mandate OOXML over ODF for their public use. I think that underneath the IT bigwigs' comments is the ghost of Plan A: an avoidance of responsibility by procurement or policy makers by invoking the authority of ISO as the reason why a standard should be adopted as a strategy to disentangle from Microsoft and go open source. However, since that was a dodgy proposition to start with (i.e. the invocation, not the disentangling), withdrawing it actually withdraws nothing.
The responsibility should be on the public official to justify the particular technology for a particular application, not merely resorting to its status. I think there may an expectation gap here, too; perhaps influenced by the so-called authoritarian left views of the guiding role of government some see at play in the region, but certainly not reducible to that.
On the particular issues that the state IT managers mention, I have blogged before on the appeal result. The particular claim is that the rules were bent, and I have a blog item about that issue: see the heading Who votes at the BRM?.
The Brazilian proposal
One particular issue I have not dealt with in this blog is Brazil's objection that they were prevented from presenting their proposal for a reference to mappings to the binary formats. This was a pet issue of Patrick Durusau's among others, and one I have never understood as being necessary to IS29500: you use IS29500 to avoid the binary formats after all, and you want the documentation to be self-standing. (A standard for the binary formats, perhaps a JTC1 Technical Report rather than an International Standard, certainly would be independently useful, since all market dominating interface technologies should be QAed. RAND-z standards)
Now you can see the Brazillian proposal here: the idea is that the Brazil delegation to the BRM had a good proposal, the US delegation tried to get the Brazilian proposal looked at ahead of time, and the convener insisted on continuing in the predetermined order for time reasons, consequently time ran out for presentation of that proposal. I don't know whether anti-Americanism played any role in the convener's decision, I doubt it, but US delegations simply cannot assume that because they ask for some procedural arrangement, they will get it. Delegations demanded an orderly proceeding with no favoritism.
Be that as it may, I want to point out something about this vital Brazilian proposal that I think people might not be aware of: it was not something that had the slightest chance of success, because it would violate basic standards drafting rules. You can see the Brazilian proposal here, which is the proposal made the day before the final day. There are five problems with the proposal, any of which were showstoppers for it IMHO:
- First, the BRM has to give editor's instructions for the draft of IS29500: it cannot make editing instructions for other documents (or the creation of other documents such as this Binary Legacy Format Specification.)
- Second, you cannot make a reference to a non-existing document. The idea that any National Body would vote to accept a standard if it contained references to imaginary or large unvetted documents is very, very peculiar, especially in the climate where many National Bodies did not have the resources or skills to adequately review the IDS29500 text (which is why so many parroted the same points, perhaps) and were complaining about this.
- Third, would this be a normative reference or a non-normative reference? Every technology that is required for a standard needs to have a normative reference, but otherwise the technologies are non-normative. Since the mappings are clearly not needed to implement OOXML, the reference would have to be non-normative.
- Fourth, the editor's instructions that are allowed by the BRM need to be very specific: change this word to that word, change this sentence to that sentence, check that all end-tags are there, and so on. If done correctly, the editor has no discretion on semantics; indeed, in the case of the fast-track BRM, the instructions need to be such that the ISO technical committee called the ITTF can check that the editor has faithfully carried out the instructions. This proposal provides no wording at all.
- Fifth, what this proposal really involves is a very large change in scope. Rather than being a standard for conveying the same information as in the binary formats, it would become a standard for mapping from the binary formats. You can see this in the comment in the proposal It will technically support the DIS 29500 major scope argument (support of legacy documents). But the scope statement of IS29500 is explicitly not about supporting legacy document formats but replacing them with an XML vocabulary (my boldings):
This International Standard defines a set of XML vocabularies for representing word-processing documents, spreadsheets and presentations. On the one hand, the goal of this standard is to be capable of faithfully representing the pre-existing corpus of word-processing documents, spreadsheets and presentations that had been produced by the Microsoft Office applications (from Microsoft Office 97 to Microsoft Office 2008, inclusive) at the date of the creation of this standard. It also specifies requirements for Office Open XML consumers and producers.
Has there ever been a flimsier reason for an appeal than that time was not spent discussing an informative reference to imaginary, unvetted text when there were specific proposals in the queue that could be dealt with quickly? Is running out of time to present this, and then being unable to convince the various National Bodies on the appeal route that this was a credible reason to appeal, really their rationale for abandoning their assumption about automatic lists and ISO standards?
And if Brazil has been allowed and, say, the Malaysian/Australian proposal for spreadsheets which did not require discussion did not get time instead, would MY and AU have just as legitimate reason to complain? The BRM had a deadline, and the story is simple as that, as far as I can see. The deadline and the need to keep proceedings going fast in order to maximize the chance that everyone's pet projects would get through was the reason for being strict with time, not some rule-bending to prevent change as seems to be the allegation.
Furthermore, the issue of including references to binary mappings is not closed. The Brazilian National Body can bring it up at any time as part of the normal maintenance procedure at SC34. If this is indeed such an important issue, has the Brazilian National Body submitted a defect report and more detailed proposal to SC34? Have they started to negotiate with Ecma to get MS to submit the binary formats to some standardization procedure (e.g. an Ecma report or ISO technical report) that would make them reference-able? If they have not, what has happened over the last six months that makes something that is so critical so unimportant? Or is the whole thing just a stunt, just Plan C? I hope not, it is entirely unnecessary.
The second head of the CONSEGI declaration is on the issue of appealing because of overlapping standards, again, this is the ghost of Plan A and the avoidance of responsibility. There simply are numerous overlapping standards and the adopters need to justify which ones they choose.
The third head lacks an explicit connection to the subject: I suppose it means that adoption is costly and difficult, and if they are forced to allow every ISO standard that will blow everything out. So this is the same answer as before: the premise that ISO standardization forces adoption being wrong, the conclusion is invalid. (Now some may say there are WTO treaty issues, perhaps, especially the Technical Barriers to Trade, but they are mostly concerned with no putting up regional standards and arbitrarily restricting trade, and not about choosing between overlapping standards where a choice needs to be made. And which government is going to protest to these nations about them adopting ODF for their public documents? And if any government did, why don't the special TBT provisions for developing countries apply?)
** Some minor incompatible changes slipped through the process, (i.e. not just removals of technology or alternative preferred forms or clarifications of the text)* notoriously an example where the Ecma spec allowed "yes" but the IS29500 spec requires "true". This tiny incompatibility was enough to for Microsoft to defer support for IS29500 into the next major release cycle of their products, but no-one was particularly fussed (though I think it is unnecessary) because it allows more chance for improving IS29500 at the SC34 committee: it is difficult to find anyone who thinks that the fast-track process is remotely optimal for a large standard, and indeed many feel it is inappropriate, however the Ballot Resolution process is not the end of progress if the stakeholders are on-side. (Under the ISO/IEC JTC1 rules, the size or maturity of the draft are not grounds for appeal: the criteria for a draft to submitted are the submitters, and the National Bodies get their say during review and the final ballot.)
In the final text for IS29500, Part 1 has a seven page Annex which gives these differences between the Ecma technology and the ISO version. For example, adding a <compatSetting> element and removing 58 compatibility settings.