Director del DCC Explica Postura sobre OOXML

Seguimos con nuestro tema favorito de los ultimos meses..
a continuación tambien recién salida del horno una entrevista
al director del DCC que le hizo emol (la versión de emol, es esta pero editada).

----------------

DIRECTOR DEL DCC
EN ENTREVISTA EXPONE POSTURA DEL DEPARTAMENTO SOBRE OOXML 
En una entrevista con El Mercurio, publicada el lunes 24 de marzo, el director de nuestro Departamento Gonzalo Navarro respondió varias consultas realizadas por este diario. Aquí reproducimos sus respuestas completas y sin edición.
1. ¿Está realmente Microsoft abriendo sus formatos de Office? 
Cada vez gana más consenso la idea de adoptar formatos estándares de almacenamiento de datos y documentos para que distintas aplicaciones y plataformas puedan interoperar. A quien insista en mantener un formato propietario, o sea, que sólo él pueda leer, la tecnología lo sobrepasará y dejará atrás. Varios gobiernos ya están exigiendo usar formatos estándares para sus documentos, incluso Chile aprobó una norma por lo que toda la documentación pública debiera tender a estar en XML, un estándar universalmente aceptado para definir formatos de almacenamiento e intercambio de información.
Efectivamente las últimas versiones de MS Office graban sus documentos en OOXML, pero lo que suceda de aquí en adelante habría que preguntárselo a Microsoft.
2. ¿No es muy raro adjuntar 6.000 páginas de documentación y esperar que se obtenga una respuesta rápida? 
No se había visto algo así en el mundo de los estándares de datos. Un estándar debe ser lo más claro y simple posible para facilitar que los desarrolladores de software puedan implementarlo. Por ejemplo, el estándar XML tiene sólo unas 40 páginas. Aun si OOXML fuera un formato técnico impecable, que hoy no lo es, su complejidad lo torna muy difícil de ser implementado completamente por cualquiera que no sea Microsoft, pues implica replicar casi toda la funcionalidad de su suite Office.
Además se ha utilizado el mecanismo "Fast Track" para su aprobación, lo que a todas luces es insuficiente, primero, para corregir como la materia lo amerita los miles de problemas que se le encontraron a la propuesta de OOXML y, segundo, para verificar cómo quedará la propuesta luego de las correcciones. Ahora la propuesta suma más de 8000 páginas.
Algo que tal vez no es evidente es la importancia de la calidad de los estándares y los ISO en particular. Una pequeña imprecisión en la redacción del estándar que dos implementadores lo interpreten de forma distinta, puede generar dos aplicaciones imposibilitadas de intercambiar documentos entre sí. Es como una ley: lo que se redacta de forma imprecisa da lugar a resquicios legales.
3. ¿Qué gana el usuario en cada uno de los casos? 
Microsoft diseñó OOXML con el objetivo de ser "compatible hacia atrás", es decir, que los documentos hechos con cualquier versión de la suite Office puedan seguir viéndose igual que antes. Entonces OOXML está condenado a no ser mucho más simple de lo que es pues debe contener todas las opciones, incluso los errores históricos de programación de la suite Office.
El que OOXML se convierta en un estándar hoy no es bueno porque aun contiene demasiados errores. Hay gran incertidumbre sobre cómo quedará redactado exactamente el estándar final. En la reunión mundial (Ballot Resolution Meeting) de febrero pasado en Ginebra, el editor Microsoft del estándar OOXML se comprometió a hacer los grandes cambios solicitados por diversos países, sobre los que habrá que votar este mes sin llegar a verlos escritos. Esto es firmar una carta en blanco.
Si algún día OOXML corrige todos sus problemas actuales y se convierte en un estándar, probablemente será bueno porque permitirá traducir toda la documentación legada de MS Office del pasado a un formato abierto y documentado públicamente. Pero esto no significa que, corregidos sus problemas, OOXML será un estándar recomendable para continuar usando hacia adelante. OOXML es demasiado complejo. Un estándar diseñado para el futuro debería ser mucho más simple que OOXML. La mochila de la compatibilidad hacia atrás es demasiado pesada.
4. ¿Va a hacer públicos Microsoft los formatos de Office? 
Habría que preguntárselo a Microsoft. Hacer públicos los formatos de almacenamiento siempre es una buena noticia técnica. Pero abrir el formato no lo hace automáticamente mejor. Un argumento que Microsoft emplea a favor de OOXML es que sólo un estándar que prometa fidelidad en la conversión convencerá a los organismos que manejan miles de documentos en Office de atreverse a dar el salto hacia XML y los formatos abiertos y estándares. Y que de no hacerse así, estos continuarán usando los formatos cerrados de MS Office. Es posible que haya una parte de verdad en eso, y que un OOXML corregido sea una buena opción para convertir toda esa información legada. Pero ¿es una buena opción para seguirlo usando a futuro? ¿Evolucionará alguna vez OOXML hacia un estándar más conveniente? Incluso de ser así puede ser un camino demasiado largo, que prolongue la dependencia con Microsoft y retrase el desarrollo de la industria del software. Por lo pronto hay que asegurarse de que tenga la calidad técnica para que funcione bien al menos para la documentación legada.
5. Cómo se las arregla Google Docs para leer y crear archivos ".doc" y ".xls"? Cómo hace lo mismo OpenOffice.org? 
Con un proceso que se llama ingeniería reversa. Sin ninguna ayuda del creador, toman los archivos y literalmente los descifran. Algunas partes son más fáciles de descifrar que otras. Es un proceso artesanal y nadie garantiza que el resultado sea del todo correcto. De hecho muchos de estos lectores no logran reproducir los documentos tal como se ven en MS Office. Con un formato abierto no sería necesario descifrar o adivinar, pues el formato estaría documentado y disponible.
6. ¿Por qué el DCC recomendó al INN rechazar la propuesta OOXML, y en qué se basaron? 
Nuestro Departamento basándose exclusivamente en consideraciones técnicas, de nuestra competencia, recomendó al INN rechazar la propuesta de OOXML como un estándar ISO. Las razones son las expuestas: la imposibilidad de estudiar seriamente un formato gigantesco en modo "Fast Track", y las deficiencias técnicas que tiene este formato. Segundo, la versión actual pone serios obstáculos a la interoperabilidad, debido a problemas de diseño, de extensa documentación y falta de modularidad.
También comentamos que, corregidos sus errores, podría ser un estándar recomendable para la información legada pero difícilmente para continuar usándose en el futuro.
Otros miembros del Comité argumentan que lo que corresponde, al no haber podido estudiar el estándar seriamente, es la abstención. Creo que ambos argumentos son válidos. Lo que, al menos con consideraciones técnicas, no puede validarse es un voto afirmativo para dar status de estándar ISO a una propuesta que actualmente tiene muchos problemas técnicos, y sobre la que prácticamente se votaría a ciegas por no estar disponible la redacción final.