Cuando a una administración pública se le dice que sus documentos están almacenados en «un formato estándar ISO», la suposición es razonable: una norma ISO debería ser una especificación clara y aplicable que cualquier proveedor de software calificado pueda admitir. Las normas existen precisamente para que nadie quede atado a un único proveedor.
OOXML -ISO/IEC 29500, el formato en el que se basan los archivos docx, xlsx y pptx de Microsoft- no funciona así.
El estándar se divide en dos clases de conformidad. Strict es la versión limpia: un formato de documento moderno, libre de lastre heredado, que un desarrollador independiente podría implementar de manera razonable. Transitional es todo lo demás: un vasto catálogo de características de compatibilidad, elementos obsoletos, comportamientos específicos de cada plataforma y referencias a peculiaridades no documentadas de las versiones de Microsoft Office de la década de 1990. La clase Transitional existe para garantizar que los documentos convertidos desde los antiguos formatos binarios doc, xls y ppt puedan representarse en XML sin pérdida de información.
Hay un detalle que importa por encima de todos los demás: Microsoft Office nunca ha producido Strict OOXML de forma predeterminada. La opción para guardar en formato Strict está disponible en las aplicaciones de escritorio instaladas, pero está ausente en las versiones basadas en navegador de Microsoft 365 – y las distintas ediciones de Microsoft han diferido durante mucho tiempo en las funciones que ofrecen, siendo la versión para macOS históricamente distinta de la de Windows. El «formato estándar ISO» en el que las administraciones públicas realmente almacenan sus documentos, cuando usan Office, es Transitional – el desordenado. Strict es una característica que puedes encontrar si sabes dónde buscar, en las plataformas donde Microsoft ha decidido ofrecerla. Ese no es el trato que recibe una norma abierta seria.
Esto tiene consecuencias que van mucho más allá de un simple tecnicismo.
El estándar codifica comportamientos heredados no documentados. OOXML Transitional contiene indicadores de compatibilidad cuya especificación equivale a «comportarse como Word 95» o «diseñar las notas al pie como en Word 97». No se trata de definiciones formales, sino de referencias al comportamiento de productos de software comerciales específicos lanzados hace más de treinta años -productos cuyos algoritmos de diseño nunca se publicaron-. Un implementador independiente que desee renderizar correctamente un documento de este tipo debe realizar ingeniería inversa en el software de la era de Windows 95. Esto no es estandarización en ningún sentido significativo; es la codificación del historial de implementación de un proveedor como norma global.
El estándar perpetúa errores conocidos. Es bien sabido que Excel trata el año 1900 como un año bisiesto -cuando no lo fue- porque Lotus 1-2-3 lo hacía así en la década de 1980, y Microsoft eligió la compatibilidad binaria con Lotus por encima de la corrección aritmética [1]. OOXML Transitional conserva este error. La configuración predeterminada del libro de trabajo en cada archivo xlsx que hayas abierto codifica un error aritmético de fechas de la era de MS-DOS. Una hoja de cálculo que calcule duraciones a lo largo de febrero de 1900 producirá respuestas erróneas, y el estándar lo exige.
El estándar incluye formatos gráficos obsoletos. Microsoft presentó el Lenguaje de Marcado Vectorial (VML) al W3C en 1998 como candidato a estándar de gráficos vectoriales. El W3C lo rechazó en favor de SVG. El VML debería haber desaparecido ahí. En cambio, sigue vivo dentro de OOXML Transitional, ya que los documentos convertidos desde archivos .doc lo contienen, y Microsoft Office sigue generándolo. Los implementadores deben admitir tanto VML como su sustituto moderno, DrawingML, para manejar archivos del mundo real.
El problema de la clase de conformidad es estructural. Se pretendía que Strict fuera el futuro y Transitional el puente temporal. Dos décadas después de la estandarización, Transitional sigue siendo lo que produce Office, lo que reciben los usuarios y lo que cualquier implementación competidora debe admitir para ser útil. El estándar limpio existe sobre el papel. El estándar que existe en la práctica -y que Microsoft Office produce de manera predeterminada- es el desordenado.
Para las administraciones públicas, esto importa de tres maneras específicas.
Para el archivo. Un formato de documento que depende del comportamiento no documentado de aplicaciones de la década de 1990 no es un formato de archivo seguro a largo plazo. La etiqueta ISO ofrece una falsa sensación de seguridad: las partes de la norma que tus documentos utilizan realmente son precisamente aquellas que están menos especificadas y que dependen en mayor medida de las herramientas de un único proveedor.
Para la contratación pública. Especificar «ISO/IEC 29500» en una licitación no garantiza la interoperabilidad ni la neutralidad respecto a los proveedores. Garantiza que los documentos se ajustarán a una especificación cuya variante implementada en la práctica es, en efecto, lo que haga Microsoft Office. Esto es lo contrario de lo que se supone que debe ofrecer un estándar abierto.
En cuanto a la soberanía. Las instituciones europeas, los gobiernos nacionales y las administraciones regionales reconocen cada vez más que la elección del formato de documento es una cuestión de soberanía. Un formato cuya implementación de referencia definitiva es el producto comercial de una sola empresa estadounidense no puede servir como base técnica de la autonomía digital europea, sea cual sea su número ISO.
La alternativa no es hipotética. El formato OpenDocument (ODF), ratificado como norma ISO/IEC 26300 hace veinte años este mes, se diseñó desde el principio como un estándar independiente de los implementadores. Su especificación es completa, autónoma y no requiere conocer la historia de ningún producto comercial específico. Existen múltiples implementaciones independientes. Es, en el sentido estricto del término, un estándar abierto.
Para las administraciones que evalúan la política de formatos, la pregunta no es si OOXML es «un estándar». Lo es. La pregunta es qué implica realmente el cumplimiento de ese estándar, qué exige a los implementadores y si eso sirve a los intereses a largo plazo de las instituciones que almacenan su trabajo en él.
Para aquellos interesados en los detalles técnicos detrás de estas afirmaciones, adjuntamos un análisis en profundidad complementario [2] que cataloga las características de Transitional, sus categorías y los problemas estructurales específicos que introducen.
[1] La historia del error del año bisiesto de 1900 está bien documentada. Joel Spolsky, quien trabajó en el equipo de Excel en Microsoft a principios de la década de 1990, relató en My First BillG Review cómo Excel heredó el error de Lotus 1-2-3 para preservar la compatibilidad binaria. La propia documentación de soporte de Microsoft reconoce abiertamente el error y explica por qué no se corregirá: hacerlo invalidaría todas las fechas en todas las hojas de cálculo de Excel existentes.
[2] El documento complementario de análisis en profundidad en formato PDF, que recoge las características de transición, sus categorías y los problemas estructurales específicos que plantean: Una norma solo de nombre: análisis en profundidad.
Artículo original (en inglés)
