====== OOXML ====== [[http://www.noooxml.org/|{{bannerooxmlnoapto.gif|OOXML NO APTO ISO}}]] ===== Informe del proceso OOXML en Uruguay ===== * DELETEME %% si dispones de info adecuada, por favor, edita las entradas incompletas %% ==== Organzaciones Involucradas ==== * FIXME %% quienes proponen, deciden %% ==== Integración de Comisiones, Representantes ==== * FIXME %% quienes deliberan %% ==== Evolución de las distintas propuestas ==== * FIXME %% %% ==== Cronología ==== * FIXME %% %% ==== Notas y conclusiones ==== * [[http://www.boksar.info/index.php/acerca-de-mi/|Gustavo Boksar]] * [[http://www.boksar.info/index.php/2007/07/23/ooxml-necesidad-de-un-standard-o-demostracion-de-poder/| OOXML Necesidad de un Standard o demostración de poder?]] * [[http://www.boksar.info/index.php/2007/08/28/unit-dijo-si-a-ooxml-isoiec-dis-29500| UNIT dijo SI a OOXML - ISO/IEC DIS 29500]] ===== Documentación Util ===== * {{Open_XML.odp.tar.gz|Presentación de UNIT sobre FastTrack}} * [[http://www.openxml.info/index.php?option=com_content&task=view&id=17&Itemid=7|Significado de los votos]] Documentos presentados a ISO(**ISO/IEC DIS 29500**): * {{office_open_xml_overview.pdf|OOXML Abstract}} * {{Office_Open_XML_Part1_Fundamentals.pdf|OOXML Fundamentals Parte 1}} * {{Office_Open_XML_Part2_OpenPackagingConventions.pdf|Open Packaging Conventions Parte 2}} * {{Office_Open_XML_Part5_MarkupCompatibilityExtensibility.pdf|Markup Compatibility Extensibility Parte 5}} * {{C045515e_Electronic_inserts.tar.gz|Electronic inserts}} Documento con respuestas de ECMA a inquietudes planteadas por ISO/IEC JCT1 durante los 3 primeros meses de evaluación: * {{ecma_responses.pdf|Respuestas de ECMA}} a las inquietudes del JCT1 durante los 3 primeros meses de evaluación del ISO/IEC DIS 29500 Respuestas de países que ya han emitido comentarios sobre OOXML: * [[http://jtc1sc32.org/doc/recent/JTC001-N-8530.zip|Comentarios de Entidades Nacionales asociados a ISO]] ===== Observaciones y Consideraciones Técnicas ===== Tendríamos que tener consistencia a la hora de nombrar los formatos. Para mí es mejor nombrar **ODF** como ISO 26300 y **OOXML** como ECMA 376. Eso da una indicación del peso real (actual) de ambos formatos. Un punto interesante es que no parece haber una sola función de **OOXML** que no pueda ser implementada en **ODF** (ISO26300). Si la hubiera, entonces tendrían que extender **ODF**. **ODF** hace esto, referencia a todos los otros estándares existentes que resuelven la funcionalidad requerida (como tiene que ser, para no reinventar la rueda) *y* define sus propias funciones. **OOXML** debería entonces hacer referencia a **ISO 26300** para todas las funciones ya resueltas y agregar sus definiciones para las que no lo están. {{consideraciones_sobre_manipulacion_de_fechas_ooxml-ffii-20070713.pdf|Consideraciones Sobre Manipulacion de Fechas}} {{spain_comments-ffii-2007071.pdf|Comentarios emitidos por España}} {{elcasocontraooxml-20070630opentia.pdf|El Caso contra OOXML en España}} ===== Conflictos con otros estándares ===== ==== W3C SVG ==== * Ecma 376 sección 14 página 132, "DrawingML" define un formato XML de dibujo de vectores que entra en conflicto con el estándar W3C SVG. * Ecma 376 sección 8.6.2 página 24, usa "VML", otro formato XML de dibujos que entra en conflicto con W3C SVG. Hay que notar que VML fue propuesto por Microsoft como estándar ante W3C en 1998, pero fue rechazado y en su lugar se eligió SVG. (http://www.w3.org/TR/NOTE-VML.html) Ecma 376 debería hacer referencia a **SVG** para las funciones que éste provee y agregar definiciones para las que no provea, en caso de ser necesario. si bien SVG es un estándar de W3C, es referenciado en ISO 26300, por lo que entrar en conflicto con él es entrar en conflicto con ISO. ==== Representación de fechas y horas ==== OOXML 3.17.4.1 "Date Representation", página 3305 exige que el año 1900 sea un año bisiesto (no lo es). Esto es para replicar un error en productos de Microsoft. De hecho esta exigencia va contra el estándar ISO 8601:2004 "Representation of Dates and Times". (en aras de quedarse en los hechos no menciono que esto puede provocar errores en la función WEEKDAY que el estándar exige implementar). ==== Representación de códigos de idiomas ==== En la sección 2.18.52, "ST_LangCode (Two Digit Hexadecimal Language Code)", página 2531, el estándar propuesto indica que se debe usar una lista fija de códigos hexadecimales de idioma en lugar del estándar ISO 639 "Codes for the Representation of Names and Languages." ISO 639 está diseñado para acompañar la evolución etno-lingüística con una lista que es mantenida por una entidad, en lugar la lista fija propuesta. Esto, que podría parecer un detalle, es algo muy importante en la interoperabilidad de documentos de texto. ==== Inclusión de imágenes ==== En las secciones 6.2.3.17 "Embedded Object Alternate Image Requests Types (página 5679) y 6.4.3.1 "Clipboard Format Types" (página 5738) hay referencias a Windows Metafiles o Enhanced Metafiles, siendo los dos formatos propietarios con dependencia técnica de los sistemas Windows. La alternativa natural para estas secciones sería la norma ISO/IEC 8632 "Computer Graphics Metafile", un formato ISO independiente de la plataforma. ===== Funciones no documentadas ===== * Section 2.15.3.6 page 2161, autoSpaceLikeWord95. * Section 2.15.3.26 page 2199, footnoteLayoutLikeWW8. * Section 2.15.3.31 page 2209, lineWrapLikeWord6. * Section 2.15.3.32 page 2210, mwSmallCaps. * Section 2.15.3.41 page 2225, shapeLayoutLikeWW8. * Section 2.15.3.51 page 2245, suppressTopSpacingWP. * Section 2.15.3.53 page 2250, truncateFontHeightsLikeWP6. * Section 2.15.3.54 page 2252, uiCompat97To2003. * Section 2.15.3.63 page 2264, useWord2002TableStyleRules. * Section 2.15.3.64 page 2265, useWord97LineBreakRules. * Section 2.15.3.65 page 2266, wpJustification. * Section 2.15.3.66 page 2268, wpSpaceWidth. Los bitmask son una técnica para codificar múltiples valores en una sola variable, asignando un significado a los bits individuales de cada variable. Por ejemplo, el número binario 10110001 (decimal 177) tendría el significado SI/NO/SI/SI/NO/NO/NO/SI y contendría la respuesta para 8 diferentes preguntas SI/NO. En el caso del OpenXML muchos atributos son definidos como bitmasks. Por ejemplo: * Section 2.3.1.18, Paragraph conditional formatting (page 842). * Section 2.4.7, Table cell conditional formatting (page 1085). * Section 2.4.8, Table row conditional formatting (page 1087). * Section 2.4.51, Table style conditional formatting settings (page 1211). * Section 2.4.52, Table style conditional formatting settings exceptions (page 1213) * Section 2.15.1.86, Suggested filtering for list of document styles (page 2034) * Section 2.15.1.87, Suggested sorting for list of document styles (page 2036) * Section 6.1.2.7, tableproperties attribute of shape group (page 5227) Los bitmasks definidos por OpenXML son en su mayoría de longitud fija (un número fijo de bits). Por ejemplo, los bitmasks usados en las secciones 2.4.51, 2.4.52, 2.15.1.86, and 2.15.1.87 son todos de tipo ST_ShortHexNumber (2.18.86, p. 2591). Debido a que no se puede agregar nuevos bits a un bitmask con una longitud fija, la extensibilidad es muy limitada. **Pero lo más importante es que:** - XML no necesita de bitmasks, XML provee una estructura mucho más rica, por otra parte los beneficios originales de usar bitmasks no son aplicables, ¿qué sentido tiene ahorrar memoria si estamos utilizando etiquetas de texto y el formato además va comprimido?. - El usar bitmasks crea un nuevo modelo de datos, separado del modelo de datos del XML. Por otra parte los bitmasks no son validados por ningún esquema estándar de validación de XML. - XSLT es el estándar de la W3C para manipular y convertir documentos XML, XSLT no tiene herramientas para trabajar con bitmasks dado que ellos no son parte del modelo de datos del XML. ===== Inconsistencias ===== ==== Unidades Porcentuales ==== Ecma 376 usa **cuatro** notaciones inconsistentes para las unidades porcentuales, una de las cuales es particularmente inflexible: En la sección 2.18.85 (p. 2583) se usan símbolos predefinidos (como "pct15" para 15%) en incrementos de 5 o 2,5 por ciento (lo que es inflexible y difícil de procesar con herramientas estándar de XML, comparado con un valor genérico). * En la sección 2.15.1.95 (p. 2053) se usa un número decimal para indicar el porcentaje. * En la sección 2.18.97 (p. 2608) se usa un número que indica 50-avos (1/50) de punto porcentual. * En la sección 5.1.12.41 (p. 4505) usa un número que indica milésimas (1/1000) de punto porcentual. a modo de contraste, tanto SVG como CSS (normas de W3C) usan consistentemente una notaciación decimal seguida del símbolo "%" (section 7.10 de W3C SVG 1.1 y sección 4.3.3 de CSS 2.1. ==== Criptografía ==== OpenXML propone sus propios algoritmos criptográficos, ignorando algoritmos de encriptación seguros, aprobados luego de un extensivo escrutinio público, como por ejemplo: * ISO "Whirlpool" algoritmo, estándar ISO 10118-3. * La W3C, incluye en su XML-ENC estándar, una lista de algoritmos SHA1, SHA256, SHA512, RIPEMD-160. * El proyecto Europeo NESSIE recomienda: ISO 10118-3 ("Whirlpool"), SHA-256, SHA-384 and SHA-512. * En Estados Unidos, NIST recomienda SHA1, SHA224, SHA256, SHA384, and SHA512. * En Japón CRYPTREC recommends: MD5, RIPEMD-160, SHA1, SHA256, SHA384, and SHA512. OpenXML sección 2.15.1.28 (página 1941) no sigue el consejo de ninguna de las organizaciones arriba mencionadas. Define nuevos algoritmos que no han sido revisados por la comunidad de criptografos. Sección 2.15.1.28 (página 1941) define uno. Sección 3.3.1.69 (página 2786) y 3.2.29 (página 2698) define otro algoritmo muy similar. Lo anterior genera tres riesgos importantes: - Su posible capacidad de falla. - No seguir un estándar. - Si se llegara a considerarse el formato, un formato estándar, se estaría aceptando una función que no ha sido debidamente escrutada por la comunidad criptográfica, lo cual implica validar algo que puede ser poco seguro, y esta poco probado, como un estándar. ===== Referencias ===== * [[http://www.grokdoc.net/index.php/EOOXML_objections|Grokdoc]] * [[http://www.robweir.com/blog/2007/07/ooxml-fails-to-gain-approval-in-us.html|Rob Wier(IBM)]] * [[http://www.groklaw.net/staticpages/index.php?page=20051216153153504|Página ODF/MS OOXML en Groklaw]]