DIS 29500 (OOXML) desde la teoría de juegos

Hasta el 29 de marzo del 2008, los organismos nacionales de estandarización miembros de ISO (en jerga de ISO, “National Bodies”, en adelante “NBs”) tienen la posibilidad de cambiar su voto respecto del destino del proceso fast-track de ISO/IEC DIS 29500, teniendo en cuenta los resultados disponibles del Ballot Resolution Meeting que ISO organizó en Ginebra el pasado mes de febrero. En este texto ensayaremos un argumento basado en herramientas de la teoría de juegos para explicar por qué un voto de “desaprobación” es la opción que mejor defiende los intereses de usuarios y desarrolladores que interactúan con programas de ofimática.

Lo sucedido hasta ahora

En febrero de 2008, ISO llevó a cabo una Reunión de Resolución de Voto (Ballot Resolution Meeting, BRM), con el objetivo de proponer mejoras al texto de DIS 29500 que resolvieran las observaciones señaladas por los NBs durante la votación de pasado agosto.

Dicha votación resultó, luego de un proceso de eliminación de duplicados, en más de 1000 observaciones de distintos NBs. En los seis meses que transcurrieron desde la votación hasta el BRM, tanto ECMA como varios NBs trabajaron en propuestas de modificación del borrador del DIS que permitieran resolver las observaciones, y de esa manera mejorar el texto del borrador.

Los asistentes al BRM, delegados de los NBs de 37 países, encararon la imposible tarea de revisar todas las observaciones presentadas, así como las soluciones propuestas por ellos mismos, en apenas cinco días. Como era previsible, sólo lograron discutir en detalle alrededor del 10% de las resoluciones. Según los reportes de los delegados presentes, ninguna de estas resoluciones fue adoptada sin modificaciones respecto de las propuestas por ECMA.

Cuando fue evidente que no había más tiempo para discutir propuestas en detalle, el BRM decidió simplemente votar si adoptar o no cada una de las resoluciones restantes propuestas por ECMA. Dado que, en general, las resoluciones propuestas eran una mejora respecto del texto original, la mayoría de ellas fue aprobada, lo que fue una decisión sabia por parte del BRM, y estrictamente en concordancia con su misión: lograr un borrador mejorado para el DIS.

Es importante mencionar, sin embargo, que la aceptación de una resolución por parte del BRM no implica que la observación asociada está efectivamente corregida satisfactoriamente. Lo único que la aceptación señala es que, en opinión de la mayoría de las delegaciones presentes en el BRM, la resolución es mejor que el texto original.

La decisión de si el texto resultante es lo suficientemente bueno no es atributo del BRM, cuyo objetivo se limita a lograr un texto de mejor calidad que el original. Esa decisión es de miembros de los NBs, quienes deben informar a ISO antes de la medianoche del 29 de marzo si mantienen su voto de agosto del 2007, o si lo cambian. De acuerdo a las reglas de ISO, los NBs pueden, si así lo desean, cambiar su voto de “abstención”, “aprobación” o “desaprobación” a cualquier otro de ellos.

La pregunta frente a nosotros

La pregunta que ISO está haciendo en este mes siguiente al BRM no es, como muchos interpretan, si ECMA 376 debe ser un estándar ISO o no, sino si los NBs estiman que DIS 29500 cumple, en este momento, las condiciones como para ser aprobado como estándar ISO a través del proceso fast-track. Esto es independiente de la posibilidad, que en todo caso continúa abierta, de que ECMA vuelva a presentar su estándar a través del proceso normal de estandarización ISO.

En otras palabras: independientemente de los méritos de la necesidad de un estándar destinado al objetivo de DIS 29500, el proceso se encuentra ante una disyuntiva:

• si el DIS obtiene la cantidad suficiente de votos de aprobación, se convierte automáticamente en estándar ISO en su forma actual
• si no los obtiene, el proceso fast-track finaliza, y ECMA 376 no obtiene el sello de ISO en esta instancia. Esto no impide que ECMA 376 se convierta en estándar ISO en el futuro, a través del proceso de estandarización habitual.

Por qué la decisión es importante

Dada la importancia de ISO como rectora de estándares internacionales, la decisión acerca de si DIS 29500 es aceptado o no como estándar ISO, en un área tan crítica como la codificación de documentos, tendrá consecuencias en especial para los individuos y organizaciones que producen y usan programas que procesan este tipo de información.

En particular, el resultado más indeseable sería que los usuarios y desarrolladores se encontraran con que deben ajustarse a una norma internacional inmadura: esto se traduciría en un sinnúmero de problemas de interoperabilidad, inseguridad acerca de si los datos almacenados hoy van a poder ser leídos con el programa de mañana, y una enorme inversión de recursos en implementar características pobre o ambiguamente definidas.

Sin entrar aún en los detalles de los resultados del BRM, tenemos en este momento bastante información cuantitativa y cualitativa acerca de las observaciones hechas por aquellos NBs que votaron “desaprobación” en agosto, y acerca de los resultados del BRM:

• los NBs compilaron conjuntamente más de 3000 observaciones al borrador original de DIS 29500, que corresponden a más de 1000 observaciones una vez eliminadas las repeticiones;
• ECMA, en un esfuerzo sobrehumano, confeccionó durante el transcurso de seis meses más de 1000 propuestas de resolución a ser consideradas durante los cinco días del BRM en Ginebra;
• los delegados ante el BRM, también invirtiendo un enorme esfuerzo, propusieron mejoras significativas a aquellas propuestas de ECMA que pudieron ser discutidas en detalle en el tiempo disponible (aproximadamente 10%), y la mayoría de las resoluciones resultantes fueron aprobadas por consenso, mientras que algunas pocas requirieron votación;
• cuando resultó evidente que no había tiempo para discutir en detalle y mejorar más propuestas el BRM decidió, en un último esfuerzo por llevar a buen puerto la titánica tarea que le fuera encargada, votar por la aceptación o no de cada una de las restantes, sin discusión ni modificaciones;
• Mediante este mecanismo de voto, cerca del 90% de las resoluciones propuestas por ECMA fueron aceptadas por el BRM, apuntando al hecho de que, aún si dichas resoluciones probablemente no fueran satisfactorias, la mayoría de ellas representaba al menos una mejora del texto original;
• el cuerpo de las resoluciones obtenidas por el BRM de este modo consta de más de 2000 páginas detallando modificaciones a realizar al borrador, tarea que aún no ha podido ser llevada a cabo por ECMA, de modo que los NBs deben votar sobre un texto que, concretamente, aún no existe;
• el tiempo disponible entre la publicación de las resoluciones y la fecha límite para votar es menos de un mes, lo que es claramente insuficiente para revisar 2000 páginas, ponerlas en el contexto del DIS, y verificar que el resultado no sólo resuelva las observaciones presentadas, sino que no contenga nuevas contradicciones e imprecisiones.

Es difícil compatibilizar estos hechos con los requerimientos de una norma internacional: que sea madura, estable y haya sido sometida a análisis concienzudo por parte de la comunidad interesada. En un documento con el tamaño y la complejidad de este DIS, es altamente probable que las modificaciones introducidas a último momento hayan creado una cantidad significativa de problemas que sólo saldrán a la luz a través de un largo proceso de escrutinio.

Ejemplos de problemas que subsisten en el borrador actual de DIS 29500

El resultado del BRM consiste de más de 2000 páginas, y no existe aún un texto que consolide el borrador original con las resoluciones adoptadas. Esto, combinado con el hecho de que las resoluciones sólo fueron publicadas hace pocos días, hace imposible realizar una revisión exhaustiva del borrador actual, y nos fuerza a limitarnos a presentar sólo algunos ejemplos de problemas que hemos identificado a través de la información disponible. Aún así, los problemas que señalamos son lo suficientemente graves como para demostrar, aún cada uno por separado, que la especificación no está lo suficientemente madura como para merecer aprobación en este momento, y que el grado de escrutinio que se puede proveer en el corto lapso de tiempo previsto por el proceso fast-track es insuficiente como para sancionar a DIS 29500 como estándar ISO en este momento.

No cumple con su objetivo declamado

El objetivo ostensible de DIS 29500 es el de establecer un estándar internacional para la representación fidedigna del cuerpo preexistente de documentos codificados en formatos legados de Microsoft Office. Lamentablemente, el borrador actual no alcanza este objetivo, dado que olvida especificar la codificación, decodificación y comportamiento asociados a elementos importantes de los formatos legados.

Un ejemplo de esta falencia se encuentra en las llamadas “macros”, mecanismos que permiten incluir funciones avanzadas, programadas por el usuario, dentro de los documentos. DIS 29500 propone mecanismos para empotrar representaciones de estas macros dentro de archivos conformes al estándar, pero no especifica la manera de representarlas, de modo que potenciales implementadores no cuentan con información necesaria para interpretarlas o codificarlas. Peor aún, incluso suponiendo que un implementador consiguiera interpretar la representación sin ayuda (por ejemplo, a través de “reverse engineering”), tampoco existe información dentro de DIS 29500 acerca de cuál es el comportamiento esperado de las macros.

Esta omisión tiene dos consecuencias graves:

1. una parte crucial del contenido de documentos heredados carece de representación sancionada dentro de DIS 29500, y por lo tanto simplemente es copiada a un contenedor binario codificado en el mismo formato heredado, lo que claramente es insuficiente para el objetivo que DIS 29500 se fijó a sí mismo;
2. si se hubieran incluido las especificaciones faltantes, éstas hubieran caído dentro del alcance de la “Open Specification Promise” ofrecida por Microsoft. Su no inclusión pone a potenciales implementadores en riesgo ser blanco de acciones legales por parte de Microsoft si intentan distribuir software que implemente estas funciones en mercados en los que estén permitidas las patentes de software.

Además de las macros, existen otros elementos en la especificación que comparten este problema, tales como las estructuras DEVMOD o las secuencias cifradas.

Las resoluciones del BRM en Ginebra, en vez de reducir la lista de estructuras de datos no definida, la amplió al quitar del borrador todas las referencias a objetos OLE. Esto es a raíz de la resolución ofrecida por ECMA como respuesta al comentario de varios NBs que reclamaban que la estructura de los objetos OLE no estaba adecuadamente definida. En vez de incorporar la estructura de OLE a la especificación, ECMA prefirió eliminar las referencias a OLE, alejándose así aún más de su objetivo declamado de ofrecer una representación fiel de documentos heredados.

Exige esfuerzo significativo e innecesario por parte de potenciales implementadores

Si bien el borrador de DIS 29500 que surgió del BRM resolvió algunos ítems tales como la imposibilidad de especificar fechas en formato ISO8601, o la exigencia de representar ciertas opciones utilizando máscaras de bits (lo que hace imposible su interpretación mediante herramientas genéricas de procesamiento de XML), la resolución en muchos casos pasó por permitir la representación correcta, y no por exigirla.

El ejemplo de las fechas es una muestra clara de las consecuencias de tal decisión: en el viejo borrador no estaba permitido representar fechas en formato ISO8601, mientras que en el nuevo sí es posible hacerlo. Pero también está permitido representarlas en cuatro otros formatos completamente distintos, incompatibles entre sí, y que contradicen el calendario gregoriano. Así, cualquier potencial implementador debe incluir en sus programas no uno, sino cinco mecanismos diferentes de decodificar una fecha, cada uno con sus peculiaridades específicas, aumentando la complejidad del programa y por consiguiente la probabilidad de introducción de errores.

La exigencia de representar fielmente los documentos heredados no justifica esta multiplicidad de soluciones: un delegado del cuerpo de estandarización griego al BRM propuso un mecanismo mediante el cual DIS 29500 podría exigir la representación de fechas en ISO8601, preservando al mismo tiempo toda la semántica de los demás formatos. Lamentablemente, dicha propuesta no pudo ser discutida a fondo en el BRM, por lo que terminó prevaleciendo la insuficiente resolución propuesta por ECMA.

Hay otros elementos de la especificación que también inflan innecesariamente el trabajo de potenciales implementadores que pretendan usarla para su fin declamado, por ejemplo VML: si bien la especificación no exige que los implementadores lo soporten, continúa permitiendo la inclusión de secciones VML dentro del formato, en vez de exigir que se las traduzca a SVG (que es un estándar de W3C). Esto último sería recomendable y conveniente, porque permitiría usar los muchos programas que soportan SVG para procesarlas, en vez de tener que construir implementaciones separadas e independientes de un formato redundante.

Por consiguiente, los implementadores se ven obligados a incluir en sus programas código que les permita leer VML, un formato que la misma especificación señala como “deprecado”, porque de lo contrario sus programas no podrán leer archivos que incluyan secciones codificadas en este formato.

Contiene múltiples inconsistencias

Muchas de las resoluciones propuestas por ECMA meramente reconocen la existencia de problemas, pero no los solucionan, de modo que siguen estando presentes en el borrador actual. Uno de los ejemplos más evidentes de esta situación es el elemento ‘w:sz’, cuyo valor es especificado en distintas unidades de medida dependiendo del contexto:

• cuando se refiere a fonts, el elemento ‘w:sz’ especifica el tamaño en “medios puntos”;
• para juegos de marcos (“framesets”), el elemento w:sz tiene un valor de tipo string que puede ser un valor relativo, un porcentaje o una cantidad de pixeles;
• cuando desciende de ‘rPr’, sin embargo, su valor es en puntos.

El atributo del mismo nombre es igualmente inconsistente:

• para bordes de tablas, el valor del atributo ‘w:sz’ se especifica en octavos de punto, a menos que el estilo de borde sea decorado, en cuyo caso el ancho se expresa en puntos;
• cuando se lo usa como un atributo de ‘restoredLeft’, especifica el tamaño en vista normal como un porcentaje de la pantalla;
• en presentaciones, como atributo del elemento ‘ph’, tiene uno de los valores enumerados “full”, “half” o “quarter”;
• en el elemento ‘defRPr’, es el tamaño del font en centésimos de punto.

Esta situación es reconocida como una “seria inconsistencia” por ECMA, pero sin ofrecer ninguna alternativa de solución, de modo que el problema persiste en el borrador actual. Lo mismo ocurre con varios otros elementos del borrador.

La superposición de ECMA 376 con ISO/IEC 26300 se vuelve cada vez más evidente

No es necesario un análisis exhaustivo para concluir que gran parte de ECMA 376 duplica funcionalidad que ya está cubierta por ISO/IEC 26300.

Esta duplicación se vuelve más evidente y grave cuando tenemos en cuenta tres elementos adicionales:

1. como vimos, ECMA 376 no cumple con su objetivo declamado de posibilitar la representación fiel de los documentos heredados;
2. ECMA ha afirmado que no es posible extender ISO/IEC 26300 de tal modo que pueda representar fielmente los documentos heredados, pero no ha ofrecido evidencia alguna para sostener su afirmación;
3. Microsoft acaba de publicar, en virtud de sus condenas por abuso de posición dominante y bajo condiciones idénticas a las de ECMA, las especificaciones de los mismos formatos heredados que ECMA 376 pretende representar. Dado que nada puede representar al documento heredado más fielmente que el formato original, sería mucho más razonable que Microsoft presente a éstos como estándar a tal fin, en vez de impulsar una representación nueva, incompleta e inmadura.

De convertirse ECMA 376 en su forma actual en estándar ISO, terminaríamos con dos estándares de codificación de documentos, ya que la función de “representar fielmente los documentos heredados” no es cubierta por ECMA 376.
Tener dos estándares que cubran el área de codificación de documentos constituye un obstáculos contra la competencia, tal como se ve en el caso de los múltiples estándares de provisión de energía eléctrica, o formatos de vídeo, que actúan efectivamente como barreras de entrada en los mercados. En las palabras de Tim Bray, uno de los diseñadores de XML:

El mundo no necesita dos maneras de decir “este párrafo usa Arial de 12 puntos, sangría de 1 em, y está alineado a la derecha”

Alternativas disponibles

Cada NB puede decidir si mantiene o cambia su voto de agosto. En un ejercicio habitual en la teoría de juegos, la siguiente matriz describe las consecuencias, positivas y negativas, de la adopción o rechazo de DIS 29500, tanto bajo la presunción del que el estándar sea maduro como de que no lo sea:

		Maduro	Inmaduro
Aprobación	Positivo	Existe, además del están­dar ECMA dedicado a tal fin, un estándar in­ter­na­cio­nal ISO, dedica­do a la representa­ción fi­de­dig­na de docu­men­tos legados de Microsoft Office.
	Negativo	El alto grado de super­po­si­ción con un ISO/IEC 26300 abre la puerta a pro­blemas de interope­ra­bi­li­dad simi­lares a los que hoy existen en virtud de la multi­pli­ci­dad de for­ma­tos de vídeo, o de voltajes y fre­cuencias de alimen­tación eléctrica.	Usuarios y desarrolladores deben lidiar con un están­dar internacional duplicativo e in­ma­duro, con las consi­guien­tes dificultades de com­pati­bi­li­dad, interoperabi­li­dad e implemen­tación ECMA pierde incentivo para mejorar la especificación a tra­vés del pro­ce­dimiento nor­mal de estandarización
Desaprobación	Positivo	Se mantiene un único están­dar en el área de re­pre­sen­tación de docu­men­tos, evi­tan­do confu­sión en el mer­cado.	Alienta a ECMA a presentar su estándar a través del proceso normal de estan­da­ri­za­ción, du­ran­te el que puede dedicársele el tiempo y el esfuerzo necesario para un escrutinio adecuado y para corregir sus problemas an­tes de la aprobación, y no des­pués. Si decide presentar su están­dar por el proceso habitual de normalización, ECMA tiene un fuerte incen­tivo para armonizar su especifi­cación con ISO/IEC 26300, apor­tando a éste las virtudes de ECMA 376 en vez de propo­ner un estándar paralelo.
	Negativo	La representación fide­dig­na de docu­men­tos le­gados de Microsoft Office sigue ca­re­cien­do de un estándar ISO que la rija, hasta que ECMA de­cida pre­sen­tar y consiga la apro­bación de ECMA 376 o al­guno de sus sucesores a tra­vés del mecanismo nor­mal de es­tan­da­ri­za­ción.

Recomendación

De esta tabla surge que tanto el único aspecto negativo de la desaprobación como el único positivo de la aprobación se ven fuertemente mitigados por la reciente publicación por parte de Microsoft de la mayor parte de las especificaciones de sus formatos heredados. Con dicha publicación, la necesidad de un nuevo formato que represente fielmente los archivos heredados pierde gran parte de su atractivo, ya que ECMA 376 no lo hace, y nada puede representarlos más fielmente que los archivos en su formato original.

Al mismo tiempo, las ventajas de la desaprobación, tanto si se trata de un estándar maduro como si no, combinadas con las fuertes desventajas de aprobarlo si no está maduro (y sobre todo teniendo en cuenta que es al menos imprudente asumir la madurez de una especificación a la que aún no terminan de incorporársele 2000 páginas de cambios), nos llevan a recomendar que:

La mejor alternativa para los NBs, en su rol de guardianes de los estándares que afectan a su Nación, es la de DESAPROBAR DIS 29500, contribuir a que ISO se tome el tiempo necesario para estudiar detenidamente un proyecto de estándar de gran complejidad técnica en un área tan crítica como la codificación de documentos.

De esta manera, contribuirá a evitar el riesgo de que los usuarios y desarrolladores de su país deban lidiar con un estándar incompleto e inmaduro, y alentaremos a ECMA a presentar ECMA 376, si así lo desea, al mecanismo normal de estandarización de ISO, idealmente apuntando a su convergencia con ISO/IEC 26300.

Gracias a Matías Bellone, Bea Busaniche, Rayentray Tappa, Román Gelbort,
Alfredo Rezinovsky, Daniel Moisset Tomás Carbell y Walter Alini
por la paciencia de revisar distintas versiones de este texto,
y por la sabiduría de sus sugerencias.