245 lines
11 KiB
HTML
245 lines
11 KiB
HTML
<?xml version="1.0" encoding="UTF-8"?>
|
|
|
|
<html>
|
|
<version>1</version>
|
|
|
|
<head>
|
|
<title>Context Briefing - DIS-29500: Deprecated before use?</title>
|
|
</head>
|
|
|
|
<body>
|
|
<h3>FSFE Context Briefing</h3>
|
|
|
|
<h1>DIS-29500: Deprecated before use?</h1>
|
|
|
|
<center>
|
|
[<a href="msooxml-idiosyncrasies.pdf">Also available as PDF (1.4M)</a>]
|
|
</center>
|
|
|
|
<p>
|
|
When ECMA submitted MS-OOXML as ECMA-376 to ISO for fast-track approval,
|
|
several countries<sup><a href="#1">1</a></sup> criticised overlap with
|
|
the existing ISO standard ISO/IEC 26300:2006, the Open Document Format
|
|
(ODF).
|
|
</p>
|
|
|
|
<p>
|
|
In its
|
|
<a href="http://www.ecma-international.org/news/TC45_current_work/Ecma%20responses.pdf">February 2007 response</a>,
|
|
ECMA admits that MS-OOXML addresses the same high-level goals of
|
|
representing documents, spreadsheets and presentations as ISO/IEC
|
|
26300:2006, but maintains that the standards meet different user
|
|
requirements. This is clarified by ECMA's statement that the explicit
|
|
design goal for ECMA-376 is to preserve idiosyncrasies from Microsoft's
|
|
proprietary legacy file formats. This statement was included in the ECMA
|
|
response on January 2008 to 113 comments<sup><a href="#2">2</a></sup>
|
|
made by national bodies during the 2 September 2007 ballot, as well as
|
|
its 14 January 2008 proposed Disposition of Comments.
|
|
</p>
|
|
|
|
<p>
|
|
Considering that alleged preservation of idiosyncrasies is the stated
|
|
reason for the entire DIS-29500 ISO process, FSFE considers it worthwhile
|
|
to investigate this claim in greater depth.
|
|
</p>
|
|
|
|
<p>
|
|
The preservation of idiosyncrasies is a questionable reason for an
|
|
international standard. The goal of standardisation is to provide
|
|
consistency and to remove idiosyncrasies, not to perpetuate them. By
|
|
aiming to preserve idiosyncrasies, the best achievable outcome is good
|
|
documentation of incompatibilities. When it became clear that the main
|
|
purpose of DIS-29500 was the documentation of idiosyncrasies, the process
|
|
should have stopped. That it did not indicates a lack of internal
|
|
structures in the fast-track procedures to prevent abuse of the
|
|
international standardisation system.
|
|
</p>
|
|
|
|
<p>
|
|
Analysis of DIS-29500 by the national standardisation bodies quickly
|
|
revealed that information to preserve proprietary legacy formats was
|
|
referenced in the specification, but the specification of these formats
|
|
was missing. So although the preservation of idiosyncrasies was the
|
|
declared design goal and the reason for the creation of DIS-29500, this
|
|
information is missing from the 6000+ page specification.
|
|
</p>
|
|
|
|
<p>
|
|
Microsoft recently deprecated its legacy file formats and as part of its
|
|
response to criticism in the DIS-29500 process announced to finally make
|
|
documentation of these formats available under the Open Specification
|
|
Promise just before the BRM. Although there will not be enough time for
|
|
analysis of comprehensiveness, quality and fidelity of that documentation
|
|
for purpose of the BRM, it seems likely that Microsoft will declare this
|
|
a satisfactory response to the question of missing specification in
|
|
DIS-29500. It would however be premature for national bodies to accept
|
|
this assertion in blind faith - in particular as publication will take
|
|
place outside the ISO scope and is subject to all legal concerns
|
|
regarding the Open Specification Promise.
|
|
</p>
|
|
|
|
<p>
|
|
Simultaneously, ECMA addresses this in Response 34 of its proposed
|
|
Disposition of Comments by removing all references to idiosyncrasies from
|
|
the specification and placing them in a newly formed Annex for deprecated
|
|
information. With the removal of this information from the DIS-29500, the
|
|
design goal of MS-OOXML can no longer be met. The entire specification
|
|
has therefore effectively become obsolete.
|
|
</p>
|
|
|
|
<p>
|
|
Analysis has shown before that MS-OOXML is covering the same functional
|
|
space as ISO/IEC 26300:2006 and is unnecessary. It was ECMA which
|
|
insisted on backward-oriented documentation of idiosyncrasies being a
|
|
sufficient motive for ISO to ignore the good practice of forward-oriented
|
|
standardisation. But even by ECMAs own criteria the rationale for
|
|
DIS-29500 has been deprecated.
|
|
</p>
|
|
|
|
<p>
|
|
In essence: Response 34 of the proposed Disposition of Comments
|
|
effectively contradicts and invalidates Response 31, which cites
|
|
preservation of idiosyncrasies as the primary design goal and reason for
|
|
DIS-29500. It also invalidates ECMAs February 2007 response to similar
|
|
criticism.
|
|
</p>
|
|
|
|
<h4>No implementation of DIS-29500</h4>
|
|
|
|
<p>
|
|
Because there is no justification for the standardisation of DIS-29500,
|
|
its approval places an unnecessary cost on competition in the IT sector,
|
|
resulting in artificially higher prices for end users.
|
|
</p>
|
|
|
|
<p>
|
|
Furthermore, the ongoing standardisation process increasingly modifies
|
|
what started out as a documentation effort for Microsoft's current
|
|
default file format. The implementation is already being shipped for some
|
|
time, and updating the product with the various improvements made to
|
|
DIS-29500 would result in incompatibility of next year's version of
|
|
Microsoft Office with the files written by today's version. Microsoft
|
|
itself maintained this as an argument against these suggested changes
|
|
during the international review phase.
|
|
</p>
|
|
|
|
<p>
|
|
With more than 2,000 pages of proposed Disposition of Comments and
|
|
Microsoft as the only party with commercial interest in DIS-29500, it
|
|
seems likely that we will see significant differences between the
|
|
DIS-29500 specification and the MS-OOXML implementation, which will
|
|
nonetheless claim implementation of DIS-29500.
|
|
</p>
|
|
|
|
<p>
|
|
Verification of this claim and ensuring fidelity of written data against
|
|
the DIS-29500 will be an extremely costly exercise for all users of
|
|
MS-OOXML. Because there will only be one alleged full implementation
|
|
available, users will need to carefully compare their binary files
|
|
against the DIS-29500 specification to protect fidelity of their data.
|
|
</p>
|
|
|
|
<p>
|
|
Microsoft and ECMA are in fact already using this strategy in their
|
|
current responses to criticism by listing applications that seek
|
|
compatibility with Microsoft Office 2007 as implementations of DIS-29500.
|
|
Even where not sub-contracted by Microsoft, these applications certainly
|
|
use DIS-29500 for guidance on how to implement the current Microsoft file
|
|
format, but their benchmark for success is not faithful implementation of
|
|
DIS-29500, it is binary compatibility with Microsoft Office 2007.
|
|
</p>
|
|
|
|
<p>
|
|
It should be noted that a similar situation could never arise with
|
|
ISO/IEC 26300:2006 (ODF) because it already has several independent
|
|
implementations. Files written by one application need to be readable by
|
|
all others, otherwise there is a problem with fidelity in at least one of
|
|
the applications. Because there is a wide range of applications and users
|
|
for ODF, such incompatibilities will be detected easily. A diverse user
|
|
and application base is the best insurance against creeping legacy
|
|
lock-in.
|
|
</p>
|
|
|
|
<h4>Remember ECMA-234?</h4>
|
|
|
|
<p>
|
|
There is no need in the marketplace for ECMA-376, the specification does
|
|
not deliver the promised preservation of idiosyncrasies, and there is no
|
|
commitment by Microsoft to implement the outcome of the DIS-29500 process
|
|
faithfully for a meaningful period of time. Does anyone remember
|
|
<a href="http://www.ecma-international.org/publications/standards/Ecma-234.htm">ECMA-234</a>,
|
|
the "Application Programming Interface for Windows (APIW)"?
|
|
</p>
|
|
|
|
<p>
|
|
This ECMA standard was also put forward as standardisation of the Windows
|
|
operating system with much the same promises that are being made for
|
|
ECMA-376 today. It was deprecated just after ECMA-234 was finally
|
|
standardised when Microsoft published Windows 95, which completely
|
|
ignored the existence of ECMA-234. Microsoft's product decision made
|
|
ECMA-234 obsolete and turned the entire specification into a huge waste
|
|
of collective effort. Without a binding commitment by Microsoft to
|
|
faithfully implement the outcome of DIS-29500, the current process is
|
|
promising to go down the same route.
|
|
</p>
|
|
|
|
<p>
|
|
It seems that ISO, its national standardisation bodies and hundreds of
|
|
standardisation experts around the world are essentially being used for a
|
|
rather costly product marketing exercise. The question is whether ISO
|
|
should allow itself to be used in this way.
|
|
</p>
|
|
|
|
<p>
|
|
If it becomes common practice to standardise for promotional effect and
|
|
then ignore, ISO might find itself deprecated in the area of Information
|
|
and Communication Technologies.
|
|
</p>
|
|
|
|
<p>
|
|
FSFE would consider this too high a price to pay for approval of
|
|
DIS-29500.
|
|
</p>
|
|
|
|
<h2>Related reading</h2>
|
|
|
|
<ul>
|
|
<li><a href="/activities/msooxml/msooxml-interoperability.html">Interoperability woes with MS-OOXML</a></li>
|
|
<li><a href="/activities/msooxml/msooxml-questions.html">Six questions to national standardisation bodies</a></li>
|
|
<li><a href="/activities/msooxml/msooxml-converter-hoax.html">The Converter Hoax</a></li>
|
|
<li><a href="/activities/msooxml/msooxml-questions-for-ms.html">Questions for Microsoft on Open Formats</a></li>
|
|
</ul>
|
|
|
|
<hr />
|
|
|
|
<p class="footnote">
|
|
[<a name="1">1</a>] Australia, Canada, Denmark, France, Germany, Japan,
|
|
Kenya, New Zealand, Norway, Sweden, Singapore, and the United Kingdom.
|
|
</p>
|
|
|
|
<p class="footnote">
|
|
[<a name="2">2</a>] BR-0002, CL-0057, CL-0058, CL-0059, CL-0060, CL-0061,
|
|
CL-0062, CL-0063, CL-0064, CL-0065, CL-0066, CL-0067, CL-0068, CL-0069,
|
|
CL-0070, CL-0071, CL-0073, CL-0074, CL-0075, CL-0076, CL-0077, CL-0078,
|
|
CL-0079, CL-0080, CL-0081, CL-0082, CL-0083, CL-0084, CL-0085, CL-0086,
|
|
CL-0087, CL-0089, CL-0090, CO-0081, CO-0082, DE-0114, DK-0004, DK-0005,
|
|
GB-0136, GB-0137, GB-0138, GB-0140, GB-0141, GB-0142, GB-0143, GB-0144,
|
|
GB-0145, GB-0146, GB-0147, GB-0148, GB-0149, GB-0150, GB-0151, GB-0152,
|
|
GB-0153, GB-0154, GB-0155, GB-0156, GB-0157, GB-0158, GB-0159, GB-0160,
|
|
GB-0161, GB-0162, GB-0163, GB-0164, GB-0165, GB-0166, GB-0167, GB-0168,
|
|
GB-0169, GB-0170, GR-0094, GR-0095, IR-0008, IR-0010, IR-0011, NZ-0015,
|
|
NZ-0016, NZ-0017, NZ-0018, NZ-0019, NZ-0020, NZ-0021, NZ-0022, NZ-0023,
|
|
NZ-0024, NZ-0025, NZ-0026, NZ-0027, NZ-0028, NZ-0029, NZ-0031, NZ-0032,
|
|
NZ-0033, NZ-0034, NZ-0035, NZ-0036, NZ-0037, NZ-0038, NZ-0039, NZ-0040,
|
|
NZ-0041, NZ-0042, NZ-0043, NZ-0044, NZ-0045, NZ-0046, NZ-0047, NZ-0048,
|
|
US-0096, US-0097, US-0098
|
|
</p>
|
|
</body>
|
|
|
|
</html>
|
|
<!--
|
|
Local Variables: ***
|
|
mode: xml ***
|
|
End: ***
|
|
-->
|