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

msooxml-questions.es.xhtml 10KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266
  1. <?xml version="1.0" encoding="UTF-8" ?>
  2. <html>
  3. <head>
  4. <title>FSFE - Seis preguntas para las entidades nacionales de estandarización sobre el MS-OOXML</title>
  5. </head>
  6. <body>
  7. <h1>Seis preguntas para las entidades nacionales de estandarización</h1>
  8. <center>
  9. [<a href="msooxml-questions.es.pdf">También disponible en PDF (24k)</a>]
  10. </center>
  11. <p>
  12. Las siguientes 6 preguntas son en relación a la solicitud
  13. para que el formato ECMA/MS-OOXML sea aceptado como estándar
  14. IEC/ISO. A menos que una entidad nacional de estandarización
  15. tenga respuestas concluyentes a todas ellas, debería votar
  16. no en la IEC/ISO y solicitar que Microsoft incorpore su trabajo
  17. sobre MS-OOXML al estándar 26300:2006 (<em>Open Document Format</em>).
  18. </p>
  19. <p>
  20. Este documento es un resumen. En la red hay disponible
  21. información más detallada:
  22. </p>
  23. <ul>
  24. <li>
  25. <a href="http://www.grokdoc.net/index.php/EOOXML_objections"
  26. >http://www.grokdoc.net/index.php/EOOXML_objections</a>
  27. </li>
  28. <li>
  29. <a href="http://fsfe.org/activities/os/msooxml-questions"
  30. >http://fsfe.org/activities/os/msooxml-questions</a>
  31. </li>
  32. <li>
  33. <a href="http://www.noooxml.org/arguments">http://www.noooxml.org/arguments</a>
  34. </li>
  35. </ul>
  36. <ol>
  37. <li>
  38. <h3>¿Independencia de la aplicación?</h3>
  39. <p>
  40. Ningún estándar debería depender nunca de un determinado
  41. sistema operativo, entorno o aplicación. La independencia de la aplicación y de la
  42. implementación es una de las propiedades más importantes de todos los
  43. estándares.
  44. </p>
  45. <blockquote>
  46. <strong>
  47. ¿Está la especificación MS-OOXML libre de referencias a productos
  48. concretos de cualquier proveedor y de su comportamiento específico?
  49. </strong>
  50. </blockquote>
  51. </li>
  52. <li>
  53. <h3>¿Soporta los estándares abiertos existentes?</h3>
  54. <p>
  55. Siempre que sea posible y aplicable, los estándares
  56. deberían contribuir a iniciativas anteriores de estandarización
  57. y no depender de tecnologías privativas, específicas de un proveedor.
  58. </p>
  59. <p>
  60. MS-OOXML ignora varios estándares existentes, como MathML
  61. y SVG, que son las recomendaciones del W3C, y usa en su lugar
  62. sus propios formatos, específicos de un fabricante. Esto supone
  63. una importante carga sobre todos demás los fabricantes que quieran
  64. implementar de forma completa MS-OOXML ya que les obliga a seguir
  65. a Microsoft y toda su infraestructura acumulada durante los últimos 20 años.
  66. Es cuestionable cómo una tercera parte lo podría implementar con la misma
  67. corrección.
  68. </p>
  69. <blockquote>
  70. <strong>
  71. ¿Cual es la ventaja de aceptar el uso de dichos formatos
  72. específicos de un fabricante en perjuicio de los demás
  73. estándares en estas áreas? ¿De dónde obtendrán los demás
  74. fabricantes implementaciones completas, compatibles y competitivas
  75. para todas las plataformas que les eviten inversiones prohibitivamente
  76. elevadas?
  77. </strong>
  78. </blockquote>
  79. </li>
  80. <li>
  81. <h3>¿Compatibilidad retroactiva para todos los fabricantes?</h3>
  82. <p>
  83. Una de las supuestas grandes ventajas de MS-OOXML es su
  84. capacidad de proporcionar compatibilidad retroactiva, como
  85. también se anunció en la
  86. <a href="http://www.ecma-international.org/news/PressReleases/PR_TC45_Dec2006.htm"
  87. >nota de prensa de ECMA International</a>.
  88. </p>
  89. <p>
  90. Para cualquier estándar, es fundamental que pueda ser
  91. implantado por terceros sin necesidad del
  92. visto bueno de otra empresa, ni de información adicional
  93. clasificada o de acuerdos legales o indemnizaciones.
  94. También es esencial que no se requiera la cooperación de
  95. ninguna otra empresa de la competencia para conseguir
  96. una interoperabilidad completa y equivalente.
  97. </p>
  98. <blockquote>
  99. <strong>
  100. Partiendo de la especificación existente MS-OOXML
  101. ¿Es posible para cualquier otra empresa, independientemente
  102. de su modelo de negocio, sin tener acceso a información adicional
  103. y sin la cooperación de Microsoft, implementar la plena
  104. compatibilidad con formatos anteriores y la conversión de
  105. dichos documentos heredados a MS-OOXML de forma equivalente
  106. a lo que Microsoft puede ofrecer?
  107. </strong>
  108. </blockquote>
  109. </li>
  110. <li>
  111. <h3>¿Extensiones privativas?</h3>
  112. <p>
  113. Las extensiones privativas y específicas de un programa,
  114. son una técnica conocida usada en particular por Microsoft
  115. para abusar y sacar ventaja de su monopolio sobre la informática
  116. de usuario para entrar en mercados relacionados con éste.
  117. Es una técnica que está en la raíz del comportamiento abusivo,
  118. el principal motivo de la decisión en contra de Microsoft
  119. por parte de la Comisión Europea en 2004, y aun así Microsoft continúa
  120. a día de hoy en su negativa a proporcionar información necesaria
  121. para la interoperabilidad.
  122. </p>
  123. <p>
  124. Por este motivo, es de sentido común que los Estándares
  125. Abiertos no deberían permitir dichas extensiones privativas
  126. y que tales técnicas de distorsión del libre mercado no
  127. deberían ser posibles dentro de las normas de un Estándar Abierto.
  128. </p>
  129. <blockquote>
  130. <strong>
  131. ¿Permite MS-OOXML las extensiones privativas?
  132. ¿Es fidedigna la implementación de Microsoft de MS-OOXML,
  133. es decir, sin extensiones no documentadas?¿Existen salvaguardas
  134. contra dicho comportamiento abusivo?
  135. </strong>
  136. </blockquote>
  137. </li>
  138. <li>
  139. <h3>¿Estándares duplicados? </h3>
  140. <p>
  141. El objetivo de toda estandarización siempre es alcanzar un
  142. estándar único, dado que múltiples estándares siempre
  143. proporcionan un impedimento a la libre competencia.
  144. Una aparente competencia entre estándares es en realidad
  145. una medida estratégica para obtener el control de ciertos
  146. segmentos de un mercado, como han demostrado varios ejemplos
  147. en el pasado.
  148. </p>
  149. <p>
  150. Ya existe un Estándar Abierto en vigor para los documentos
  151. ofimáticos, concretamente el <em>Open Document Format</em> (ODF)
  152. (ISO/IEC 26300:2006). Tanto MS-OOXML como ODF están basados en
  153. la tecnología XML, de modo que emplean la misma base tecnológica
  154. y por lo tanto tienen en última instancia las mismas capacidades
  155. potenciales. La propia Microsoft es miembro de OASIS, la organización en la
  156. cual se desarrolló y que mantiene el estándar ODF. Está al tanto
  157. del proceso y está invitada a participar en él.
  158. </p>
  159. <blockquote>
  160. <strong>
  161. ¿Por qué Microsoft se negó y se niega a participara en la iniciativa
  162. de estandarización ya existente? ¿Y por qué no planteó sus propuestas
  163. a OASIS para que fuesen incluidas en el estándar ODF?
  164. </strong>
  165. </blockquote>
  166. </li>
  167. <li>
  168. <h3>¿Seguridad legal?</h3>
  169. <p>
  170. Es esencial en un estándar, que se garantice que todos
  171. los competidores podrán implementarlo sin arriesgarse
  172. a demandas judiciales. Dicha garantía debe ser clara,
  173. fiable y lo suficientemente amplia para cubrir todas
  174. las actividades necesarias para conseguir una interoperabilidad
  175. total y permitir un punto de partida equitativo que fomente
  176. una verdadera competencia basada en el mérito.
  177. </p>
  178. <p>
  179. MS-OOXML va acompañado de un inusitadamente complejo
  180. «convenio para no demandar» en lugar del clásico otorgamiento
  181. de patentes. Debido a esta complejidad, no parece claro
  182. cuánta protección contra demandas por compatibilidad puede
  183. verdaderamente proporcionar.
  184. </p>
  185. <p>
  186. Un estudio legal somero, demuestra que el «convenio»
  187. no cubre todas las características opcionales y formatos
  188. privativos necesarios para una implementación completa
  189. de MS-OOXML. De manera que la libertad de cualquier
  190. competidor para implementarlo no está garantizada para
  191. todo el ámbito del formato MS-OOXML propuesto, y es
  192. cuestionable incluso para los componentes principales.
  193. </p>
  194. <blockquote>
  195. <strong>
  196. ¿Tiene su entidad nacional de estandarización su propio
  197. análisis legal independiente acerca de la naturaleza
  198. precisa del otorgamiento que certifique si éste verdaderamente
  199. cubre todo el espectro de todas las posibles implementaciones
  200. de MS-OOXML?
  201. </strong>
  202. </blockquote>
  203. </li>
  204. </ol>
  205. <p>
  206. Todas estas preguntas deberían tener respuestas que
  207. las entidades nacionales de estandarización deberían
  208. obtener mediante consultores y expertos independientes,
  209. y en particular no mediante Microsoft o sus socios
  210. comerciales, los cuales tienen un conflicto de intereses
  211. directo en este asunto.
  212. </p>
  213. <p>
  214. Si no existe una buena respuesta a alguna de ellas,
  215. la entidad nacional de estandarización debería
  216. votar «no» en la ISO/IEC.
  217. </p>
  218. <h2>Documentos relacionados</h2>
  219. <ul>
  220. <li><a href="/documents/msooxml-interoperability.html">Interoperability woes with MS-OOXML</a></li>
  221. <li><a href="/documents/msooxml-idiosyncrasies.html">DIS-29500: Deprecated before use?</a></li>
  222. <li><a href="/documents/msooxml-converter-hoax.html">El falso convertidor</a></li>
  223. <li><a href="/documents/msooxml-questions-for-ms.html">Questions for Microsoft on Open Formats</a></li>
  224. </ul>
  225. </body>
  226. <timestamp>$Date$ $Author$</timestamp>
  227. </html>
  228. <!--
  229. Local Variables: ***
  230. mode: xml ***
  231. End: ***
  232. -->