According to an anonymous source cited by Andy Updegrove Germany is voting “Yes” on DIS 29500 aka OOXML at ISO – provided the procedure used in the DIN committee could be called a “vote”:
Germany is voting “YES” on DIS 29500 at ISO. The relevant committee was given by DIN only the choice between “YES” and “ABSTAIN” on DIS 29500, since changing from “YES with comments” in September 2007 to “NO” in March 2008 was deemed impossible. Everyone could vote “yes”, “abstain” or “no” on the question whether Germany should vote “YES” or “ABSTAIN” on DIS 29500.
8 votes were in favour of “YES”, 6 were in favour of “ABSTAIN”, some pointing out that they would have preferred to vote an outright “NO”. 4 voted “abstain to the DIN vote”, i.e. on the vote between “YES” and “ABSTAIN” to ISO. 2 of the 4 had initially voted for a German “ABSTAIN”, but under pressure changed within 48 hours their vote from a German “ABSTAIN” to “abstain to the DIN vote”; one of the 4 was compelled by instruction to vote “abstain to the DIN vote”, even though he wanted to vote at least “ABSTAIN”. That means: without very strong pressure from Microsoft Germany would have voted “ABSTAIN”, with 9 to 8.
It’s hard to explain why the coordinator of the DIN committee, Dr. Stefan Weisgerber, decided that a German “No” should not be considered. According to Heise Newsticker the technical committee that prepared the decision considered a “No” to DIS 29500 as “unnecessary”.
If Updegrove’s report proves true, the German DIN has made a fool of itself. It will be interesting what the EU investigation of Microsoft’s influence on ISO Standardization of OOXML will make of these strange irregularities in one of the most renowned national standardization bodies.
However, not only the procedure, but also the content of this decision is embarrassing. Admitted that I don’t have the time to read the 6000 pages of the OOXML specification, but I took the time to read the 37 pages of comments the DIN committee submitted last September. As Germany voted “Yes with comments” on this occasion I could assume that these comments were not based on prejudices against Microsoft but rather benevolent.
Actually, however, these comments confirm the most substantial critiques against OOXML. They can be grouped under the following points:
- OOXML is plattform dependent containing elements specific to 32 bit Microsoft Windows.
The allowed values of this enumeration, EMF, WMF, etc., are Windows-specific formats. No allowance seems to have been made for use by other operating systems.
The described algorithms make use of byte-level manipulations which depend on the machine architecture (big endian versus little endian).
- OOXML is application and vendor dependent drawing on ideosyncratic features of Microsoft products.
The restriction to only two date bases is arbitrary and based only on one vendor’s applications.
This feature has been defined in a way which ignores the existence of current browsers other than Internet Explorer.
- OOXML violates existing standards or replaces established standards with Microsoft specific specifications.
The proposed date and time system makes no reference to ISO 8601, and is markedly different from it.
This is the specification of Office Open Math Markup Language, a specialized XML vocabulary for the describing the layout of mathematical equations. This solves the same problem as MathML, a long-established W3C standard and an ongoing activity in the W3C.
More than 10% of the examples shown in the spezification are not proper XML.
- OOXML lacks in internationalization.
The formatting system described here is not comprehensive, lacking, for example, support for Armenian, Tamil, Greek alphabetic, Ethiopic and Khmer numerations, all in use today, as well as the various historical systems still used by scholars.
- OOXML is incomplete and inconsistent.
The proposed date system does not cope with dates anterior to 1900-01-01.
The standard contains insufficient detail on how to replicate this behavior. For e.g. “autoSpaceLikeWord95”,
The results as displayed in this table contradict the definition of LISTNUM as specified page 1542 line 12 (neither ‘a’ nor ‘iii’ are numbers).
- Some parts of OOXML are marked as “deprecated” which is rather odd for a new standard.
OOXML states that VML should be considered as deprecated. A new standard should not contain deprecated parts.
I confess that for me as a simple user who is not an expert in document standards it is hard to understand why a specification that contains plattform and application dependent elements, violates existing standards, and is incomplete and inconsistent could be deemed as an international standard.
Update
Meanwhile DIN published a press release justifying the procedure. According to this press release the executive committee didn’t decide whether to approve or disapprove DIS 29500 (this decision was made by the technical committee on 11 March 2008) but only whether the standardization process for DIS 29500 has to be regarded as regular or irregular. The committee decided with 7 to 6 votes and 7 abstentions that the process was regular. In the case that the majority considered the process as irregular Germany would have changed its ISO vote from “approval” to “abstention”.
Update 29 March 2008
Meanwhile Andy Updegrove has updated his article on the vote in the DIN committee. After DIN published an official statement on the decision to approve DIS 29500, Andy asked his source for a more detailed report that is now available on Andy Updegrove’s website.