Norway says no to OOXML

12:44 pm Standardization

After a tough race and much debate, the organization responsible for Norway’s vote in ISO has decided to vote “No, with comments”.

Standard Norge has been under much pressure during the last week and came out with its decision today. The comments accompanying the No are these:

Summary: The Scope clause in Part 1 is inappropriate for an ISO standard. Justification: The Scope clause is self-referential, does not convey any useful information, and does not conform to JTC1 and ISO Directives for the scope of a standard or NP (ref. JTC1 Directives, 6.2.1.6; ISO Directives, Part 2, 6.2.1 Scope). In the absence of an appropriate Scope clause it is not possible to resolve a number of issues arising from the current text.

Summary: Rework into a multi-part standard. Justification: As currently drafted, DIS 29500 covers many areas that are not directly related to one another. This makes it difficult to review by National Body experts, difficult to implement, and difficult to assess compatibility.

Summary: Rework into a much more concise standard. Justification: The text of DIS 29500 is too voluminous to be reliably reviewed by National Body experts, or for implementations to be assessed for compatibility. It appears to be unnecessarily long, combining normative text with copious examples and containing a lot of redundancy.

Summary: The information model is unnecessarily complex. Justification: The XML information model described is unnecessarily complex. Given the example in the Overview at page 13 (§5.6)

<w:p>
<w:r>
<w:t>Hello, world.</w:t>
</w:r>
</w:p>

Could - and should - be represented as:
<p>Hello, world.</p>

Summary: All examples should conform to the XML specification. Justification: More than 10% of the examples are not valid XML. This will cause confusion and could lead to differences in implementation that will inhibit interoperability.

Summary: DrawingML should be a separate standard Justification: DrawingML has general applicability as an XML vocabulary for vector graphics. It should therefore be a standard in its own right that can be referenced in isolation by other ISO standards, such as ISO 26300.

Summary: OPC should be a separate standard Justification: The Open Packaging Conventions could support a much broader range of applications than OOXML. It should therefore be a standard in its own right that can be referenced in isolation by other ISO standards, such as ISO 26300.

Summary: The specification should not include binary notations. Justification: Unspecified (or underspecified) binary notations, especially those with operating system dependencies, inhibit interoperability and do not belong in an ISO standard. Even well-specified binary notations, such as bitmasks used to encode multiple boolean values, are inappropriate in an XML-based interchange format. Nonstandard text-based encodings of control characters, such as ‘bstr’ (basic string) are also inappropriate.

Summary: The specification should not contain underspecified features. Justification: Underspecified features and settings, such as “autoSpaceLikeWord95″, “footnoteLayoutLikeWW8″, “lineWrapLikeWord6″, “mwSmallCaps”, “optimizeForBrowser”, “shapeLayoutLikeWW8″, “supressTopSpacingWP”, “truncateFontHeightsLikeWP6″, “useWord2002TableStyleRules”, “useWord97LineBreakRules”, “useWord97LineBreakRules”, “wpJustification”, “wpSpaceWidth”, “sldSyncPr”, “securityDescriptor”, and “revisionsPassword” preclude uniform implementation and thus inhibit interoperability.

Summary: Option sets should be extensible and should avoid cultural bias. Justification: Options to features such as border styles, enumeration styles, list styles, the function NETWORKDAYS(), Clipboard Format Type, etc. should not exhibit cultural bias or be unduly restrictive, since this will inhibit adoption internationally.

Summary: OOXML should reference, use, and conform to existing standards where applicable. Justification: It has been claimed that the current standard conflicts with other ISO standards, such as ISO 8601 (Representation of dates and times), ISO 639 (Codes for the representation of names of languages) and ISO/IEC 10118-3 (Hash functions). If this is the case, the specification should be brought into line with these and other existing standards. The problem is especially apparent in the case of the ‘date1904′ attribute. The ambiguity regarding the status of the year 1900 should be resolved by using ISO standard dates everywhere.

Summary: Lack of consistency in notation of values and dimensions. Justification: There is no coherent dimension notation throughout the specification, for instance the relative dimension “87,5%” is sometimes represented by “pct87″, sometimes by “87500″ or even by “4375″. This will cause confusion and could lead to non-interoperable implementations.

Given these comments, it may be hard for Microsoft and ECMA to turn around and fix this and convince Norway to change its vote to “Yes” in the Ballot Resolution Meeting in February.

The full document that Norway will send to ISO is at Standard.no

I will thank the work of all my allies in this process.

It’s time for a sip of champagne.

One Response

  1. The Open Sourcerer » Is it starting to go “Pete Tong” for Microsoft? Says:

    […] off the blog - Norway says […]

Leave a Comment

Your comment

You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>

Please note: Comment moderation is enabled and may delay your comment. There is no need to resubmit your comment.