OOXML

• si dispones de info adecuada, por favor, edita las entradas incompletas

• quienes proponen, deciden

• quienes deliberan

• Gustavo Boksar
• OOXML Necesidad de un Standard o demostración de poder?
• UNIT dijo SI a OOXML - ISO/IEC DIS 29500

• Presentación de UNIT sobre FastTrack
• Significado de los votos

Documentos presentados a ISO(ISO/IEC DIS 29500):

• OOXML Abstract
• OOXML Fundamentals Parte 1
• Open Packaging Conventions Parte 2
• Markup Compatibility Extensibility Parte 5
• Electronic inserts

Documento con respuestas de ECMA a inquietudes planteadas por ISO/IEC JCT1 durante los 3 primeros meses de evaluación:

• 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:

• Comentarios de Entidades Nacionales asociados a ISO

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.

Consideraciones Sobre Manipulacion de Fechas

Comentarios emitidos por España

El Caso contra OOXML en España

• 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)

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).

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.

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.

• 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:

1. 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?.

1. 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.

1. 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.

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.

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:

1. Su posible capacidad de falla.

1. No seguir un estándar.

1. 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.

• Grokdoc
• Rob Wier(IBM)
• Página ODF/MS OOXML en Groklaw