void life(void)

He recibido en los últimos días varios documentos del JTC1/SC34 acerca de los progresos en el grupo de trabajo que está tratando de arreglar el OpenXML, y es impresionante lo hay de información surrealista en estos documentos.

El documento N1101/N1168 contiene por ejemplo, varios artículos en los que reconocen que hay decisiones tomadas en el BRM que no fueron incorporadas en el texto final de la norma publicada. En otras palabras, aun teniendo casi un año después de la aprobación de la norma a publicar el texto (sí, aprobado sin leer), no hubo tiempo/atención o cualquier otra cosa necesaria para hacer los cambios (algunos condicionantes de la aprobación) en el texto. Lo que más me deja enojado por esto, es que durante el BRM he preguntado acerca de quién sería responsable de verificar que todos estos cambios serían parte del texto final y la respuesta fue ITTF (como una secretaría conjunta de la ISO y la IEC). Cuando he preguntado si la ITTF realmente haría este trabajo, he recibido una respuesta intimidatoria: “Estas a dudar del ITTF, muchacho?” …

Peor que eso, es que las informaciones contenidas en este documento, para mí son suficientes para dudar de que todas las correcciones que han sido aprobados fueran aplicadas en el texto. Si antes sospechaba de que esta última versión de la especificación no era lo que todo el mundo pensaba, ahora estoy seguro que no es y creo que no hay problemas aún más graves encontrados por que la mayoría de la gente, como yo, se niega a mirar nuevamente las malditas 6.000 páginas.

En el documento N1171, uno de los grupos de trabajo de SC34 anuncia que fueran encontrados problemas en las fuentes del OpenXML y enviarán un informe de error sobre la cuestión al grupo responsable de la reparación de la norma (se ve gracioso, pero hasta hoy se están encontrando defectos…).

El documento N1183 justifica la subdivisión de las partes actualmente existentes de la norma, al decir que esto es necesario para que se pueda corregir algunos errores señalados, añadiendo a la especificación nuevas “pequeñas” funcionalidades (y que está bien, ahora que la ISO ha aprobado la norma, pueden escribir lo que quieras, ¿no?).

Me salvó la mejor para el final, el documento N1187, que nos relata que el OpenXML contiene “errores involuntarios que pueden impedir que los documentos existentes sean representados en este nuevo formato.” El soporte a el “legado de documentos” fue la razón principal utilizada para que se desarrollase y aprobase el OpenXML, y fue también la razón por la cual varios países apoyaron el desarrollo y la aprobación de la norma. Como eso se explica ahora ? En este documento, se explica también los criterios que se utilizarán para especificar los cambios que se desarrollarán a fin de que puedan hacerlo con rapidez (en otras palabras, abusan de la interpretación de las directivas del JTC1  para obtener los cambios necesarios o deseados si que se haga mucho ruido en el proceso).

Lamentablemente no puedo poner todos estos documentos para aquí en mi blog por que debe ser documentos rescritos del SC34 (0% de transparencia), pero creo que, tarde o temprano, ellos deberán ser publicados en alguna parte (y por supuesto, quién es miembro de su NB ya los debería haber recibido).

Desde niños he aprendido a no firmar el papel en blanco, pero creo que esto no es una lección valiosa en otros países.

Me gustaría de ver la contestación a algunas preguntas:

Brasil, Sudáfrica, India y Venezuela, tenían o no la razón cuando apelaran a la ISO (y fueran ignorados completamente)?

Sera que los mismos señores del board de la ISO, que ignoraran los protestos, están ahora siguiendo el desarrollo y documentos como los que he comentado aquí?

¿Quiénes son responsables de todo eso? Cómo se paga?

Share/Save/Bookmark

One Response to “Para el escéptico, la prueba final: El OpenXML no estaba (y no esta) listo”

  1. João Sérgio

    Ta aí meu e-mail

Deixe seu comentário

Proudly powered by WordPress. Theme developed with WordPress Theme Generator.
Creative Commons License