A través del Blog de Héctor Sánchez (por uno de sus comentaristas al post Informando y actualizando OpenXML) he conocido la iniciativa Dile NO al formato de Microsoft Office como estándar ISO.

Y creo que se deben dar respuesta a sus argumentos.

• Ya hay un estándar, ISO 26300, llamado Open Document Format (ODF): un doble estándar supondrá incertidumbre, confusión y un coste añadido para la industria, gobiernos y ciudadanos.;

Existen múltiples estándares para montones de cosas tales como redes inalámbricas, o alámbricas, de diferentes cuerpos de estandarización e incluso para un mismo tema, del mismo organismo normalizador. Sólo en el ámbito del XML, y ciñéndome a un tema que conozco bien, hay montones de estándares para la factura electrónica. ODF es un estándar de OASIS, organismo del que soy miembro y que defiendo. En particular defiendo el ODF, como defiendo el UBL. Lo cual no es óbice para poder defender el formato facturae o el OOXML cuando ayudan a impulsar las ventajas de las tecnologías en las empresas. En particular, el OOXML aporta una compatibilidad hacia atrás con millones de documentos existentes, que no forma parte de los objetivos de diseño de ODF.

• No hay ninguna implementación de referencia de la especificación de OOXML: Microsoft Office 2007 produce una versión especial de OOXML que no cumple con la especificación de OOXML propuesta en ISO;

Al contrario, hasta la publicación del estándar OOXML muchas empresas se han basado en conjeturas, en ingeniería inversa o en publicaciones no oficiales para lograr la compatibilidad con los formatos de Microsoft. Existen millones de documentos de versiones anteriores de los productos de Microsoft, que es posible interpretar de manera abierta gracias a la publicación del estándar OOXML (ECMA 376). Por otro lado, Microsoft simplifica las versiones futuras de los formatos dentro de las posibilidades de OOXML para adoptar las últimas tendencias de buenas prácticas en XML. Existen ya programas que no son de Microsoft que manejan OOXML y programas vinculados a los de Microsoft que manejan ODF.

• En el documento de especificación falta información como, por ejemplo, cómo implementar un “autoSpaceLikeWord95” o un “useWord97LineBreakRules”;

No existe ninguna especificación que no pueda perfeccionarse. Es por ello que los grupos de trabajo de normalización están siempre revisando las propuestas a iniciativa de sus miembros. Incluso se descartan estándares por no ser de aplicación en la época actual. En particular esto sucede en grupos de trabajo de AENOR en los que yo participo. En ocasiones las normas se rehacen completamente (como las ISO 9000) y en algunas ocasiones se definen generaciones de normas en base a otras (como la serie BS-7799, UNE 71502, ISO 17799, o ISO 27001).

• Más del 10% de los ejemplos de su especificación no validan la conformidad con XML;

No olvidemos que hay dos contextos en la norma: los marcados por requisitos legacy, y los que se orientan a mejores prácticas. En el primer caso es de prever que esta limitación no pueda obviarse, pero es al mismo tiempo una de las mayores ventajas del estándar. En el segundo caso se tratará de un error que puede mejorarse en siguientes revisiones.

• No existe garantía alguna para que cualquiera pueda implementar parcial o totalmente la especificación de OOXML sin arriesgarse a que Microsoft le exija daños y perjuicios por infracción de patentes o el pago de licencias de patentes;

Al contrario, esta es una de las garantías de los procesos de normalización: la gestión de IPR (intelectual property rights) de forma que se satisfagan las necesidades de todos los participantes. En todo caso, la existencia del estándar OOXML no prohibe el uso de ODF, de forma que al final las implementaciones dependerán de las diferentes ventajas que encuentren sus implementadores en sencillez de uso o en mercado potencial.

• Esta propuesta de estándar entra en conflicto con otros estándares ISO, como ISO 8601 (representación de fechas y tiempos), ISO 639 (códigos de representación de nombre e idiomas) o ISO/IEC 10118-3 (funciones hash de criptografía);

En realidad no existen conflictos mientras exista un método de representación que permita la traducción a otros formatos cuando sea necesario. Por ejemplo, el estandar para definir paises es el ISO 3166, en el que a España le corresponde el código numérico 724, el Alfa-2 ES y el Alfa-3 ESP. Sin embargo para la ITU (antigua CCITT) España es el 34 en el estándar para definir el pais (y establecer el prefijo de llamada internacional) que evolucionó hasta la «Recommendation  E.164 (tras recogerse en la E.163, antes E.161/Q.11, antes E.29). En la simbología EAN-13, utilizada en los códigos de barras (que a nivel internacional normaliza GS1) España tiene el Código 84.

• Hay un error en la especificación del fichero de formatos de hoja de cálculo que impide introducir cualquier fecha previa al año 1900. Esto es un error que se arrastra desde las obsoletas versiones de 16bits de la aplicación MS-Office;

Este es un problema que afectaría solo a algunas partes legacy de la especificación. Te prometo que yo he puesto fechas anteriores a 1900 en muchas hojas de cálculo.

• Esta propuesta de estándar no ha sido creada aunando la experiencia y mejores prácticas de todas las partes interesadas (tales como productores, distribuidores, consumidores, usuarios y reguladores), sino por Microsoft en solitario.

No es la primera ocasión en la que interesa adoptar un estándar creado por expertos en debates internos, y que después se somete a los criterios generales de los procesos de estandarización. Un caso importante y reciente es el PDF/A aprobado como ISO 19005-1:2005 y basado en el formato propietario de uso libre de Adobe PDF 1.4.

Por tanto, como puede apreciarse, mi idea es que no se puede perder la oportunidad de aprobar el estándard ECMA 376 – OOXML  dentro de ISO y disponer de el a través de los procedimientos de normalización en curso.