Source files of fsfe.org, pdfreaders.org, freeyourandroid.org, ilovefs.org, drm.info, and test.fsfe.org. Contribute: https://fsfe.org/contribute/web/ https://fsfe.org
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 
 
 
 
 

244 lines
11 KiB

<?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: ***
-->