Posición del DCC de la Universidad de Chile respecto al OOXML

Esto es fresquito, resulta que tal como bloguearamos ayer, se produjo una reunión en el DCC de la Universidad de Chile en el cual se debatieron los problemas del estándar y de esta nueva votación fast track que se quiere hacer para aprobarlo.

Como resultado el DCC entrega un breve resumen de su posición y de sus puntos principales que procedo a reproducirlo aquí.

Estándares de datos y OOXML

Original en PDF

A fines de marzo la Organización Internacional de Estándares (ISO) deteminará si aprueba o rechaza la propuesta presentada por Microsoft (OOXML, ISO/IEC DIS 29500) de un formato de datos que permitiría pasar del obsoleto formato binario de MS Office (versiones de 97 a 2008) al moderno XML. Esta decisión se basará en el voto que emita cada país, en nuestro caso el Instituto Nacional de Normalización, votación que concluye esta semana.
La elaboración de estándares debe ser un proceso que promueva la calidad técnica de los productos y procesos. Para el Comité chileno, a esto se agrega el verificar que las propuestas sean técnicamente correctas y aceptables para su uso en Chile.
Este breve artículo explica la postura que el Departamento de Ciencias de la Computación de la Universidad de Chile tiene al respecto, después de haber participado en el Comité chileno que estudió la propuesta (Comité Espejo ISO/IEC JTC1/SC34 ISO/IEC DIS 29500).

1. Sobre el proceso ISO/IEC DIS 29500.
a) El proceso que se ha seguido dista mucho de haber sido realizado con la profundidad técnica que una decisión de este tipo requiere. Es patente que ningún miembro del Comité estudió las más de 6.000 páginas que contiene la propuesta de estándar. Esta aparente desprolijidad es una consecuencia previsible de la decisión de los proponentes de apurar la discusión (Fast Track), que fuerza a tomar una decisión en pocos meses.
b) La inconveniencia de apurar la estandarización de un producto aún inmaduro quedó en evidencia en la reunión BRM (Ballot Resolution Meeting) de Ginebra el pasado febrero. En ella sólo fue posible discutir técnicamente menos del 20% de las observaciones hechas por los distintos países.
c) Los temas relativos al contexto nacional chileno fueron escasamente tratados en las reuniones del Comité chileno, sobre todo debido a la premura del tiempo por responder comentarios técnicos propios de la propuesta.

2. Las características técnicas de la propuesta OOXML
1. Interoperabilidad. Es la capacidad que permite a los sistemas heterogéneos comunicarse y operar entre sí.
a) Este es un tema crucial para ISO en la estandarización de datos. La propuesta presentada está lejos de satisfacer este requerimiento, debido a uso de múltiples funcionalidades que no son estándar (ej. fechas, fórmulas matemáticas, referencias).
b) No hay consenso, aún después del BRM de febrero, que la traducción del formato binario de Office a OOXML esté documentado. Esto es esencial para que otros desarrolladores puedan recrear el formato original.
c) La extensiva y compleja documentación (más de 6.000 páginas; comparar por ejemplo con las 40 páginas del estándar XML) hace muy difícil extender y desarrollar aplicaciones que interoperen con este formato.
d) Los temas legales de licenciamiento han sido objeto de muchas críticas debido a su falta de precisión. La incerteza sobre si se ha cruzado una línea legal o no también desalienta las implementaciones alternativas.
e) Para nuestra comunidad local, el determinar cómo armoniza cualquier propuesta de formato de datos con el decreto de firma electrónica y el Decreto 81 sobre interoperabilidad documental en Chile, es un aspecto crucial, que no se alcanzó a discutir en el proceso.

2. Modularidad. Es la capacidad de un software de ser tratado como un sistema coherente de varias partes independientes entre sí.
a) La propuesta carece absolutamente de modularidad. Esto es particularmente notorio en la dificultad para reemplazar formatos obsoletos por funcionalidades ISO estandarizadas (por ejemplo fechas, fórmulas matem áticas, algoritmos de seguridad, algoritmos de cálculo, etc.). Los editores optaron por agregarlas junto a (no en vez de) las antiguas no recomendables.
b) La experiencia demuestra que la alta complejidad de las especificaciones no modulares tiende a producir una sola implementación (la del autor de la propuesta).
En consecuencia, la adopción de formatos con este tipo de deficiencia puede limitar seriamente el desarrollo de la industria de software en Chile.
En resumen, nos parece que técnicamente, la propuesta de estándar de datos es deficiente.

3. Aspectos rescatables. De estandarizarse correctamente una propuesta de este tipo, Microsoft debería hacer pública la documentación de los formatos usados en las suites Office. Esto debiera acompañarse de la apertura de licencias correspondientes. Estas acciones al menos en principio permitirían a otros productores de software que no sean MS desarrollar aplicaciones para intercambiar datos con esos formatos.
Adicionalmente, se conseguiría la existencia de un estándar para la documentación legada que está en esos formatos (MS Office).

4. Recomendación al INN. Una estandarización de la importancia de ésta, donde se intenta modernizar una tecnología usada en más del 90% del mercado mundial, no puede realizarse en pocos meses bajo un apuro a todas luces artificial.
La prueba está en los problemas técnicos que mencionamos más arriba.
En base a los antecedentes señalados, el Departamento de Ciencias de la Computación, Universidad de Chile, recomienda al INN modificar la posición de abstención expresada en septiembre 2007, y rechazar ISO/IEC DIS 29500.