Source files of,,,,, and Contribute:
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.

msooxml-questions.en.xhtml 9.0KB

  1. <?xml version="1.0" encoding="UTF-8" ?>
  2. <html>
  3. <head>
  4. <title>FSFE - Six questions to national standardisation bodies about MS-OOXML</title>
  5. </head>
  6. <body>
  7. <h1>Six questions to national standardisation bodies</h1>
  8. <center>
  9. [<a href="msooxml-questions.pdf">Also available as PDF (28k)</a>]
  10. </center>
  11. <p>
  12. The following six questions relate to the application of the
  13. ECMA/MS-OOXML format to be accepted as an IEC/ISO standard. Unless a
  14. national standardisation body has conclusive answers to all of them, it
  15. should vote no in IEC/ISO and request that Microsoft incorporate its work
  16. on MS-OOXML into ISO/IEC 26300:2006 (Open Document Format).
  17. </p>
  18. <p>
  19. This is a summary document. More detailed information is available
  20. online.
  21. </p>
  22. <ul>
  23. <li>
  24. <a href=""></a>
  25. </li>
  26. <li>
  27. <a href=""></a>
  28. </li>
  29. <li>
  30. <a href=""></a>
  31. </li>
  32. </ul>
  33. <ol>
  34. <li>
  35. <h3>Application independence?</h3>
  36. <p>
  37. No standard should ever depend on a certain operating system,
  38. environment or application. Application and implementation
  39. independence is one of the most important properties of all
  40. standards.
  41. </p>
  42. <blockquote>
  43. <strong>
  44. Is the MS-OOXML specification free from any references to
  45. particular products of any vendor and their specific behaviour?
  46. </strong>
  47. </blockquote>
  48. </li>
  49. <li>
  50. <h3>Supporting pre-existing Open Standards?</h3>
  51. <p>
  52. Whenever applicable and possible, standards should build upon
  53. previous standardisation efforts and not depend on proprietary,
  54. vendor-specific technologies.
  55. </p>
  56. <p>
  57. MS-OOXML neglects various standards, such as MathML and SVG, which
  58. are recommendations by the W3C, and uses its own vendor-specific
  59. formats instead. This puts a substantial burden on all vendors to
  60. follow Microsoft in its proprietary infrastructure built over the
  61. past 20 years in order to fully implement MS-OOXML. It seems
  62. questionable how any third party could ever implement them equally
  63. well.
  64. </p>
  65. <blockquote>
  66. <strong>
  67. What is the benefit of accepting usage of such vendor-specific
  68. formats at the expense of standardisation in these areas? Where
  69. will other vendors get competitive, compatible and complete
  70. implementations for all platforms to avoid prohibitively large
  71. investments?
  72. </strong>
  73. </blockquote>
  74. </li>
  75. <li>
  76. <h3>Backward compatibility for all vendors?</h3>
  77. <p>
  78. One of the alledged main advantages of MS-OOXML is its ability to
  79. allow for backward compatibility, as also referenced in the
  80. <a href="">ECMA International press release</a>.
  81. </p>
  82. <p>
  83. For any standard it is essential that it is implementable by any
  84. third party without necessity of cooperation by another company,
  85. additional restricted information or legal agreements or
  86. indemnifications. It is also essential to not require the cooperation
  87. of any competitor to achieve full and comparable interoperability.
  88. </p>
  89. <blockquote>
  90. <strong>
  91. On the grounds of the existing MS-OOXML specification, can any
  92. third party regardless of business model, without access to
  93. additional information and without the cooperation of Microsoft
  94. implement full backward compatibility and conversion of such legacy
  95. documents into MS-OOXML comparable to what Microsoft can offer?
  96. </strong>
  97. </blockquote>
  98. </li>
  99. <li>
  100. <h3>Proprietary extensions?</h3>
  101. <p>
  102. Proprietary, application-specific extensions are a known technique
  103. employed in particular by Microsoft to abuse and leverage its desktop
  104. monopoly into neighboring markets. It is a technique at the heart of
  105. the abusive behaviour that was at the core of the decision against
  106. Microsoft by the European Commission in 2004 and Microsoft is until
  107. today continuing its refusal to release the necessary
  108. interoperability information.
  109. </p>
  110. <p>
  111. For this reason, it is common understanding that Open Standards
  112. should not allow such proprietary extensions, and that such
  113. market-distorting techniques should not be possible on the grounds of
  114. an Open Standard.
  115. </p>
  116. <blockquote>
  117. <strong>
  118. Does MS-OOXML allow proprietary extensions? Is Microsoft's
  119. implementation of MS-OOXML faithful, i.e. without undocumented
  120. extensions? Are there safeguards against such abusive behaviour?
  121. </strong>
  122. </blockquote>
  123. </li>
  124. <li>
  125. <h3>Dual standards?</h3>
  126. <p>
  127. The goal of all standardisation is always to come to one single
  128. standard, as multiple standards always provide an impediment to
  129. competition. Seeming competition on the standard is truly a strategic
  130. measure to gain control over certain segments of a market, as various
  131. examples in the past have demonstrated.
  132. </p>
  133. <p>
  134. There is an existing Open Standard for office documents, namely the
  135. Open Document Format (ODF) (ISO/IEC 26300:2006). Both MS-OOXML and
  136. ODF are built upon XML technology, so employ the same base technology
  137. and thus ultimately have the same theoretical capabilities. Microsoft
  138. itself is a member of OASIS, the organisation in which the ODF
  139. standard was developed and is being maintained. It was aware of the
  140. process and invited to participate.
  141. </p>
  142. <blockquote>
  143. <strong>
  144. Why did and does Microsoft refuse to participate in the existing
  145. standardisation effort? Why does it not submit its technological
  146. proposals to OASIS for inclusion into ODF?
  147. </strong>
  148. </blockquote>
  149. </li>
  150. <li>
  151. <h3>Legally safe?</h3>
  152. <p>
  153. Granting all competitors freedom from legal prosecution for
  154. implementation of a standard is essential. Such a grant needs to be
  155. clear, reliable and wide enough to cover all activities necessary to
  156. achieve full interoperability and allow a level playing field for
  157. true competition on the merits.
  158. </p>
  159. <p>
  160. MS-OOXML is accompanied by an unusually complex and narrow "covenant
  161. not to sue" instead of the typical patent grant. Because of its
  162. complexity, it does not seem clear how much protection from
  163. prosecution for compatibility it will truly provide.
  164. </p>
  165. <p>
  166. Cursory legal study implies that the covenant does not cover all
  167. optional features and proprietary formats mandatory for complete
  168. implementation of MS-OOXML. So freedom of implementation by all
  169. competitors is not guaranteed for the entire width of the proposed
  170. MS-OOXML format, and questionable even for the core components.
  171. </p>
  172. <blockquote>
  173. <strong>
  174. Does your national standardisation body have its own, independent
  175. legal analysis about the exact nature of the grant to certify
  176. whether it truly covers the full spectrum of all possible MS-OOXML
  177. implementations?
  178. </strong>
  179. </blockquote>
  180. </li>
  181. </ol>
  182. <p>
  183. All these questions should have answers that should be provided by the
  184. national standardisation bodies through independent counsel and experts,
  185. and in particular not by Microsoft or its business partners, which have a
  186. direct conflict of interest on this issue.
  187. </p>
  188. <p>
  189. If there is no good answer to any one of them, a national body should
  190. vote no in ISO/IEC.
  191. </p>
  192. <h2>Related reading</h2>
  193. <ul>
  194. <li><a href="/documents/msooxml-interoperability.html">Interoperability woes with MS-OOXML</a></li>
  195. <li><a href="/documents/msooxml-idiosyncrasies.html">DIS-29500: Deprecated before use?</a></li>
  196. <li><a href="/documents/msooxml-converter-hoax.html">The Converter Hoax</a></li>
  197. <li><a href="/documents/msooxml-questions-for-ms.html">Questions for Microsoft on Open Formats</a></li>
  198. </ul>
  199. </body>
  200. <tags>
  201. <tag>Policy</tag>
  202. <tag content="Open Standards">OpenStandards</tag>
  203. </tags>
  204. <timestamp>$Date$ $Author$</timestamp>
  205. </html>
  206. <!--
  207. Local Variables: ***
  208. mode: xml ***
  209. End: ***
  210. -->