OO-XML: Chile debe decir NO al estándar de Microsoft

Hace algunos días tuve la oportunidad de asistir a una reunión organizada por el INN en dependencias de la Cámara de Comercio Electrónico. La reunión era del Comité organizado para determinar el voto de Chile respecto de si la propuesta ISO 29500 (llamado OO-XML, que supuestamente estandariza los formatos MS-Word, MS-Excel y otros) debería o no ser efectivamente aceptado como estándar ISO. Este hecho puede traer consecuencias técnicas, ecónomicas y sociales altamente inconvenientes para todo el mundo dentro de los próximos 50 años.

Dados los hechos recientes relacionados con Microsoft (y sin hacer más juicios al respecto), sería lamentable que un hecho como éste pasara nuevamente inadvertido. Es por eso que queremos contarles algunos detalles específicos acerca de qué se trata la propuesta de estándar, de porqué es una mala propuesta, y cómo y dónde se decidirá la suerte de esta propuesta.

Antes de comenzar, los detalles esenciales:

1. Varios de estos argumentos fueron adaptados de la primera fuente indicada al final de este post. Algunos de ellos fueron verificados directamente sobre la especificación ECMA.
2. Los estándares ISO se votan mundialmente, con un voto por país, por mayoría simple. Existen tres votos posibles: "Apruebo" (que significa que el país ha considerado cuidadosamente la propuesta, y cree que debe ser aprobada como estándar ISO), "Desapruebo" (que significa que el país ha considerado que la propuesta posee errores lógicos, técnicos, jurídicos, administrativos o de cualquier otra índole, y cree que no debe ser aprobado), y "Abstengo" (que significa que no ha tenido tiempo o recursos para revisar la propuesta, pues no es posible decir que no tiene todos los antecedentes necesarios para deliberar).
3. Update: Existen dos tipos de membresía de cada país para un comité determinado: "P" y "O". Los países tipo "P" tienen una serie de obligaciones como revisar cuidadosamente la documentación y votar en consecuencia. Los países tipo "O" en cambio (como Chile) no tienen la obligación de votar. En caso de votar, todos los votos son iguales (tanto de miembros "P" como "O"). En la página del comité de ISO aparecen las membresías de países, entre los cuales aparece Chile como país "O".
4. Chile debe decidir antes del 2 de septiembre cuál será su voto a través del INN, que es la entidad representante de la ISO en Chile.
5. Hasta ahora, se han realizado sólo dos reuniones. La tercera (entiendo que la última) se realizará este próximo martes 21 de agosto.
6. Dentro del proceso de votación para estándares ISO, normalmente se dan dos tipos de proceso:
• Una propuesta puede ser revisada y votada (y aceptada o rechazada) a través del proceso "normal", que es relativamente largo (y es la idea que así sea),
• Es posible aplicar un "fast-track" para propuestas que han sido aceptadas como estándares por otras organizaciones, como la ECMA.
7. Microsoft envió sus especificaciones de Office bajo el nombre OO-XML (Office Open XML) a la ECMA, y fueron aprobados como estándar ECMA-376. Así, esperaba poder aprobar su especificación vía "fast-track" a la ISO, proceso en el cual nos encontramos justo ahora.
8. Ya existe un estándar para documentos electrónicos aprobado por la ISO: es el llamado Open Document Format, especificado a través del estándar ISO 26300. En particular este estándar ha sido construido por más de 40 software, de los cuales el más conocido actualmente es OpenOffice 2.0.

En qué consiste OO-XML

OOXML es una especificación aprobada por ECMA como el estándar ECMA-376, en Diciembre de 2006. Contiene especificaciones para un formato de texto (WordprocessingML), un formato de hojas de cálculo (SpreadsheetML) y un formato para presentaciones (PresentationML), más varias especificaciones "de soporte" (DrawingML, VML y otras). Está dividido en 5 partes, más varios anexos en formatos electrónicos (principalmente las especificaciones de XML, en formato XML Schema y RelaxNG).

Problemas técnicos

La propuesta de estándar posee una serie de errores técnicos inaceptables, que provienen de (y que mantendrían) problemas de software actualmente declarado como obsoleto por parte de Microsoft. Algunos de estos errores son:

• Respecto de WordprocessingML, en la sección 11.3.1, (pág. 38, "Alternative Format Import Text"), se especifica como uno de los formatos aceptados para la importación de datos el "texto plano" (plain text). Pero no se especifica la codificación de los caracteres. El estándar XML establece específicamente una codificación por default (UTF-8), que es la misma establecida para los documentos electrónicos en Chile (D.S. 81/2004, D.S. 100/2006, DS 181/2002, etc.)
• Existen problemas serios con diversas fórmulas en la especificación de SpreadSheetML:
• Para las funciones trigonométricas sin(), cos(), tan() y sus inversas asin(), acos(), atan() y atan2() no se especifica si sus argumentos son en grados o en radianes (Parte 4, secciones 3.17.7.287, 3.17.7.50, 3.17.7.313, 3.17.7.12, 3.17.7.4, 3.7.17.14 y 3.17.7.15, respectivamente).
• Existe una función avedev() que debería calcular la desviación estándar de una serie de valores, pero en realidad calcula ¡la cantidad de combinaciones de N sobre K objetos! (Parte 4, sección 3.17.7.17).
• También en SpreadSheetML, existen al menos dos problemas serios con las fechas que se describen a continuación:
  • Se trata el año 1900 como año bisiesto, lo que es un error viejo de Excel, heredado de Lotus 1.2.3. El calendario Gregoriano establece que los años "de siglos" (1700, 1800, 1900, 2000, etc.) sólo pueden ser bisiestos si son divisibles por 400 (entonces 1600, 2000 y 2400 lo son, pero 1700, 1800 y 1900 no).
  • Los años anteriores a 1900 son considerados como "ill-formed data" (Parte 4, sección 3.17.4.1). Esto sí es un detalle importante: para los sistemas que tomen información de fechas anteriores a 1900 de una supuesta planilla de cálculo que implemente OO-XML, y que envíe esta información a otro sistema, es necesario implementar algoritmos especiales no especificados para transformar y comprender adecuadamente este dato.
• Lo inaceptable dentro de lo anterior es que un estándar incluya un error heredado de un software comercial actualmente considerado obsoleto incluso por la empresa que lo creó.

Otras consideraciones

Existe una serie de otras consideraciones que, incluso más importantes que las anteriores, prueban que OO-XML es, desde el punto de vista de la ISO, un mal estándar que es necesario rechazar:

• Uno de los argumentos que se dan en ambos "bandos" es el largo de las especificaciones: OO-XML posee más de 6000 hojas de especificaciones, mientras ODF posee alrededor de 600. El argumento de los defensores de OO-XML es que "mientras más detallada es la especificación, más fácil es construir un sistema que lo implemente; por tanto, la especificación de ODF probablemente es muy pobre y ambigua". Lo cierto es que el estándar ODF hace uso intensivo de otras especificaciones y estándares ISO, o aceptadas y publicadas por la W3C: ISO 8601 para las fechas, MathML (W3C) para fórmulas matemáticas, SVG (W3C) para los "archivos gráficos", etc. Esto implica una especificación mucho más compacta, modular y por tanto comprensible, haciendo inválido el argumento contrario.
• Por otro lado, OO-XML incluye varias especificaciones que están directamente en conflicto con estándares ISO aprobados. Al respecto, dos ejemplos:
• El estándar ISO 639 especifica una lista de lenguajes existentes en el mundo, utilizado intensamente para tareas como definir distribuciones de teclado para distintos idiomas. OO-XML especifica su propia lista incrustada de códigos (ECMA 376, sección 2.18.52, pág. 2530).
• El estándar ISO 8632 especifica un estándar para los archivos de "metagráficos". OO-XML utiliza y recomienda "Windows Metafiles" o "Enhanced Metafiles" en vez del estándar ISO.
• Hoy en día, la criptografía es un tema esencial para las aplicaciones que requieren un cierto nivel de seguridad. Al respecto, cada país ha revisado cuidadosamente los estándares disponibles y ha recomendado u obligado la utilización de ciertos estándares específicos:
• ISO escogió y publicó el algoritmo "Whirlpool" bajo el estándar ISO 10118-3.
• La W3C publicó el estándar XML-ENC, que incluye una lista de algoritmos: SHA1, SHA256, SHA512, RIPEMD-160.
• El proyecto europeo NESSIE recomienda ISO 10118-3 ("Whirlpool"), SHA-256, SHA-384 y SHA-512.
• En EE.UU., el NIST recomienda SHA1, SHA224, SHA256, SHA384 y SHA512.
• En Japón, el CRYPTREC recomienda MD5, RIPEMD-160, SHA1, SHA256, SHA384, y SHA512.
• Pues bien: OO-XML no sigue ninguno de estas tendencias, y propone algoritmos propios de Microsoft, que no han sido ni revisados ni aprobados por ningún cuerpo colegiado, lo que claramente es un problema de seguridad mayor. Sobre todo considerando que la forma en que la criptografía de llave pública se masificará dentro de los próximos años será a través de documentos de ofimática firmados a través de certificados personales.
• En el caso de Chile, a pesar de que no existe una recomendación normativa completa respecto de los estándares técnicos a utilizar en todos los ámbitos, existen algunos antecedentes que es necesario tomar en cuenta: el decreto supremo 81/2004, de MINSEGPRES, establece la utilización de varios estándares ISO y de la W3C; asimismo, y tal vez más importante, el reglamento de la Ley de Documento y Firma Electrónica N°19799 (decreto 181/2002, de Economía) mencionan y utilizan varios estándares de la ISO, W3C y otras entidades. Para el propósito de no generar inconsistencias en nuestro naciente contingente de especifcaciones y estándares para Gobierno electrónico e Interoperabilidad, es deseable no tener estándares que entren en conflicto con otros estándares aceptados.

Todo lo anterior demuestra de alguna forma que OO-XML es una propuesta incompleta e inmadura, que contiene muchos errores que individualmente es posible solucionar, pero que en su conjunto configuran una propuesta de estándar que provocará muchos problemas de implementación, caros de solucionar, en el supuesto de que algún otro proveedor distinto de Microsoft quisiera arriesgarse a implementar el eventual estándar.

Lo anterior es muy probablemente producto del acelerado proceso de revisión por el que pasó a través de la ECMA: aproximadamente 6000 páginas fueron revisadas en 30 días, lo que significa un promedio de 200 páginas por día. Incluso paralelizando la revisión (cosa que no es enteramente posible) esto es simplemente infactible, hasta para los expertos y más avezados programadores.

Al respecto (y aquí me tomaré un poco la opinión del resto de los SK's, que discutimos este tema hace un par de días atrás), los SK pensamos que aceptar un estándar como OO-XML es muy inconveniente, no porque provenga de Microsoft, sino porque es un pésimo estándar.

Post-addendo y Updates

Para quienes no tengan experiencia en estándares, podrán pensar de lo anterior que si finalmente se acepta la propuesta de OOXML como estándar ISO, entonces será obligatorio de implementar. Eso sería un error. Los estándares, ISO entre ellos, suelen ser opcionales, salvo que por otro medio (leyes, decretos, etc.) se transformen en obligatorios, o bien que por condiciones de mercado, se generen en estándares de facto y procesos de "lock-in" tecnológico. Cuando eso sucede, el supuesto general de quién está relevando los estándares útiles a un cierto contexto suele creer que organismos como ISO han hecho un gran trabajo, y sus estándares son confiables... en este caso, como el estándar presenta tantos errores e inconsistencias sería un problema. Aceptar en ISO un estándar con errores sería "un error" en sí mismo.

A veces se aceptan estándares incompletos porque el nivel de consenso amerita la generación de un estándar así. Luego, con el tiempo estos estándares se van completando... pero definitivamente es mejor un estándar incompleto que uno que parece completo pero que está malo. Es como construir un sistema.... mejor incremental pero bueno, que completo con errores técnicos y que generan una mochila difícil de corregir en el futuro.

Como este proceso está en curso y requiere urgencia, necesitamos que este tema se converse y se canalice en forma ordenada hacia los espacios de decisión, labor que estamos desarrollando los SushiKnights desde nuestros entornos propios. Para el caso de los ciudadanos (muchos de ellos lectores de SushiKnights), Felipe propone en su comentario (abajo) enviar un correo identificado, respetuoso y responsable al INN, quien lidera esta conversación. Por favor, seamos responsables en este proceso. Gracias.

Fuentes:

• "Microsoft OOXML / ECMA376, Get The Facts v1.2", por Anand Vaidya, vaidya.anand@gmail.com, bajo licencia Creative Commons.
• http://www.noooxml.org
• http://www.odfalliance.org
• http://www.openxml.info