Patrick Durusau, editor of ODF, asked me to restate my thoughts on what “contradiction” should mean at ISO. I had mentioned my views in an SC34 meeting last year. This topic is, of course, of interest right at the moment, because the Ecma proposal for OOXML is at the stage in its acceptance process where the process says it should be checked to make sure it doesn’t contradict other standards.
I take a fairly strict view of “contradiction”. Anything else works against fairness of process.
A contradiction is where
- One standard attempts to redefine another, or is a rival standard for exactly the same named thing but is different in some aspect. The precedent here is the contradictions alleged between two standards for UNIX-derived APIs that arrived at ISO by different routes ISO Linux API and ISO POSIX. The remedy is withdrawal and harmonization.
- One standard disrupts another. The precedent for this is the IEEE 802 WAPI issue in which the claim was that the changes would make existing conforming implementations non-conforming. The remedy is withdrawal of the contradicting standard and future harmonization. (However, the WAPI issue does not seem to have been resolved; certainly the Chinese approach (compared to the UK body) is that procedural issues should not be used to block standards, in particular that obsoleting old standards for allowing a “contridiction” to block the progress of the standard if the issues have been raised before and not disposed of. But it does suggests that fairness is a more important criterion than contradiction, at the end of the day. Or, at least, that using procedural tactics to block something may not find much favour in the eyes of the ISO Secretariat and many ISO participants. )
- One standard pretends to be another. The precedent for this at ISO are the UK objections to C++/CLI. The remedy for this is a simple name change, and other associated editorial changes.
- One standard incorrectly uses another. For example, if a standard said it used ISO SGML but allowed that to be invalid for no intrinsic reason. (I have not found any precedent for this, but it seems the obvious case.)
A contradiction may have negative effects, such as user confusion, but it is not the negative effects that cause that there is a contradiction; a highly technical standard will confuse anyone. It is the direct contradictions int he text of the standards that is involved.
So what, in those terms, are not contradictions?
- Overlap. There are many overlapping standards. For example, there is ISO 12803, a schema for books: if it is an absolute requirement that existing standards be re-used, ODF would not be allowed unless used the ISO 12803 conventions, presumably. Another example, there are two to five (depending on how you count them) standards for grammar-based schema languages at ISO (SGML/XML DTDs, Architectural Forms, RELAX NG, RELAX NG compact syntax, namespace-aware DTDs) let alone considering W3C XML Schemas as a standard schema language.
- Using a profile. A profile is a subset. Unless a standard forbids profiles, they are obviously allowed. Of course, a standard that does not take the requirements of a particular locale seriously riskd being voted down if that locale has a national body that is concerned. However, national bodies may be more lenient on standard coming in by fast-track, in that they may be works-in-progress where localizations are a stage subsequent to the initial standardization. ISO ODF is probably an example of this: ODF 1.1 may not handle every requirement of every writing system at the moment, but that is no reason not to have as a standard. And, in any case, it is not a contradiction.
- Doing your own thing within a specification. Specifications being fast-tracked that come from a different technological tradition may indeed have different conventions. For example, identifiers coming in from W3C will have identifiers in IETF formats (URI, MIME media types, etc) rather than necessarily adopting ISO formats usch as ISO 9070 Formal Public Identifiers. ISO ODF was not required to follow the prior ISO DSSSL formating model. Making up your own format or functionality is defensible (i.e., It may need to be defended) but it is not a contradiction. For example, ISO Schematron uses simple keywords for the Query Language Binding attribute, not URLs or ISO 9070 FPIs (plus most of them are reserved for future possible use, and recommended but not adequately explained, and one of them is for something that doesn’t even exist…”xslt1.1″ but is there due to historical reason. (We may take it out, but it doesn’t actually cause any harm, it is just reserved.)
- Reserved-but-unused or deprecated keywords with inadequate explaination of the operation that the keywords would have if they were allowed-for-use and not deprecated. Especially if the standard has not been divided in a way where there is an external registry of keywords, it is not unlikely that a fast-tracked standard that encapsulates the current state of a mature technology will have deprecated or reserved keywords. The best way to handle these is unclear to me, but the presence of such keywords are not contradictions.
(I should stress that even if you do accept that “contradiction” has the kind of very specific meaning that I describe here, and even if under this meaning the supposed contradictions detailed by Groklaw fall down on inspection, and even if it means that OOXML can pass beyond the Feb5 adminstration periood into the next phase unmolested, it says nothing about whether OOXL should be defeated (or accepted) at the final ISO vote by member bodies. The issues that national bodies use are their own, and while they certainly include technical ones they may include issues of national interest; whether their own developers would be better with OOXML as a standard, whether their public bodies are capable of distinguishing a standard for document interchange with a standard for exposing the documents of the leading brand, whether they feel bound by international trade treaties (a particularly novel argument, that one), whether it would in fact lead to an interoperable paradise, etc. )
(Note: this is a new entry, and I may update it, Wiki fashion, if improvements come to hand, especially concerning precedents and the results.)
Added 2007-0103 Another aspect of this, a mistake I didn’t realize people would make until I reviewed some of the comments people are sending to their national bodies, is that contradictions are limited to contradictions with ISO/IEC standards. The JTC1 directives, the JTC1 resolution both limit it to that. Even the supposed WTO treaty requirement does not extend itself to industry consortia like, say, OASIS, Ecma or W3C.