Acá esta la declaración oficial del Presidente del Comité Espejo, Carlos Recabarren/This is the official letter from the head of the Chilean JTC1/SC34 committee :
De nuestra consideración:
La Secretaría Técnica del Comité Espejo Nacional en materias de TI comunica a los miembros del comité espejo ISO/ IEC JTC1/SC34 que, el Consejo del INN ha resuelto NO modificar el voto chileno de abstención adoptado en el mes de Septiembre 2007 en relación a la homologación de la norma Ecma 376 a norma ISO , por considerar que no hay un consenso entre los miembros del Comité Espejo y por tanto no existir una posición nacional al respecto.
The Technical Secretary of the National Mirror Committee in IT matters communicates to the members of the ISO/IEC JTC1/SC34 committee that the INN Council has resolved not to modify the abstention vote adopted during the month of September 2007 with respect to the homologization of the ECMA 376 norm to a ISO norm, as it has been resolved that there is no consensus among the Mirror Committee members and therefore there is no national positon with respect to this issue.
Adjunto hacemos llegar a Uds. la votación efectuada por los miembros del Comité espejo en relación a este tema, la cual fue uno de los elementos considerados por el INN en su resolución”.
Attached is the voting conducted by the members of the mirror committee in relation to this issue, which was one of the criteria considered by the INN in its resolution.
Atte.
Carlos Recabarren M.
Presidente.
(See English version below)
Parece que el voto de Chile ya esta decidido:
El Mostrador acaba de publicar un artículo (basado en conversaciones con Sergio Toro del INN) que Chile mantendrá su voto de “abstención”, a pesar de que el comité espejo había votado 60-40 para aprobar OOXML. Toro citó su molestia por la actuación de la delegación Chilena en Ginebra. El párrafo clave es este:
“Según trascendió, en la decisión de Toro de mantener el voto de
abstención del año pasado influyó su molestia por la supuesta decisión
unilateral del presidente de la Cámara de Comercio Electrónico y
secretario ejecutivo del comité consultivo del INN, Carlos Recabarren,
quien apoyó el estándar de Microsoft en una segunda reunión realizada en
Ginebra en febrero de 2007, sin consultar a sus representados, según se
desprende de las actas de reuniones del organismo.”
Esto se refiere a una resolución por parte del comité que indicaba que el Sr. Recabarren, que sería el único enviado al BRM en Ginebra, debía votar “abstención” en todos los votos que no hubieran sido aprobadas expresamente por el comité, que solo había considerado en sus discusiones (y en gran mayoría, aprobado) los 217 comentarios enviados por Chile en Septiembre pasado.
Cuando el Sr. Recabarren, cuya organización (la CCE) tiene a Microsoft como uno de sus miembros y hasta Enero tenía al Jefe de Tecnologías de Microsoft-Chile como uno de sus directores, llegó (tarde, debo agregar) al BRM, el fue uno de los pocos Jefes de Delegación que votó por “aprobar en masa” los cientos de comentarios que las delegaciones no habían podido discutir por falta de tiempo.
Aunque esto le ayudó mucho a Microsoft durante en el BRM, estas acciones han resultado en que en Chile… le salió el tiro por la culata.
El Mostrador, a Chilean newspaper, is reporting (based on conversations with the
Chilean official in charge of deciding the vote) that Chile will
maintain the ‘abstain’ vote, despite the fact that a ‘consulting
committee’ had voted 60-40 for approval. The official cited concerns
about the Chilean HOD in Geneva. The key paragraph is this:
“Según trascendió, en la decisión de Toro de mantener el voto de
abstención del año pasado influyó su molestia por la supuesta decisión
unilateral del presidente de la Cámara de Comercio Electrónico y
secretario ejecutivo del comité consultivo del INN, Carlos Recabarren,
quien apoyó el estándar de Microsoft en una segunda reunión realizada en
Ginebra en febrero de 2007, sin consultar a sus representados, según se
desprende de las actas de reuniones del organismo.”
“According to reports, the decisión by [the head of the Chilean NB, the
INN] Sergio Toro to maintain the ‘abstain’ vote was influenced by him
being upset by the unilateral decision by the president of the Cámara de
Comercio Electrónico [CCE - Electronic Trade Chamber] and executive
secretary of the consulting committee [on OOXML], Carlos Recabarren, to
support Microsoft’ standard in a second meeting conducted in Geneva in
February of 2007 without consulting those who he was representing, as it
is revealed by the committee’s meeting transcripts”.
This refers to a resolution by the committee by which Mr. Recabarren,
the whole Chilean delegation to the BRM, was instructed to vote
‘abstain’ at the BRM in all matters that were not explicitly approved by
the committee, which had only discussed (and mostly approved) only the
217 comments sent by Chile last September.
When Mr. Recabarren, whose organization (CCE) has Microsoft as a member
and until last January had Microsoft-Chile’s CTO as a member of its
board of directors, arrived (late, I might add) to the BRM, he was one
of only a handful of HODs to ‘batch-approve’ the hundreds of comments
that the delegations had not discussed because they ran out of time.
Although this did help Microsoft cause at the BRM, it seems to have
backfired quite badly in Chile.
El 6 de Agosto del año pasado, la CCE le envió una carta al INN ofreciendo “recursos” para que Chile participara en el subcomité JCT1/SC34 de la ISO. Este renovado interés significaba que Chile pasaba de ser país Observante (”O”) a país Participante (”P”). Chile no sería el único país que cambiaría su membresía poco antes del voto de Septiembre, y lasconsecuencia de una estampida de nuevos participantes al “subcomité 34″ estaba clara: para que pudiera ser aprobado entonces, y para ser aprobado ahora, los criterios de la ISO son:
Al menos 2/3 de los países “P” deben aprobar la especificación
Menos de 1/4 del total de los países que votan (”P” + “O”) deben rechazar la especificación
Por lo tanto, esta claro que un voto de un país amigable y que pudiera ser convencido de cambiarse a “P” era mucho más valioso para la causa de OOXML. Aunque en Septiembre OOXML falló ambos criterios, el primero de ellos es mas difícil de alcanzar.
Como muchos de los comentaron sobre el cambio de membresía de Chile, el supuesto era, evidentemente, que el voto de nuestro país sería contado como “P”, y era por lo tanto doblemente importante asegurarse que el proceso fuera adecuado. En conversaciones con gente que particparon en las reuniones del comité espejo, confirmé que esta es la impresión de varios.
Pues bien, aquí va el fé de erratas: Chile no era país “P” para efectos de “fast-track” de OOXML en Septiembre pasado, y no lo es para el voto que cierra esta semana. Como terminé de confirmar esta mañana, nuestro país votará en calidad de “Observante”.
¿Como puede ser? La razón es un poco sutil, y nos lleva a nuestro misterio: resulta que el “subcomité 34″ forma parte del “Joint Technical Committee 1″, o JCT1 para los amigos. Chile, justo antes del voto de Septiembre, se convirtió en miembro “P” de este subcomité, pero sigue siendo miembro “O” del JCT1. Y como indica el sitio de este último, en su sección de preguntas y respuestas:
¿Quiénes son miembros “P” para efectos de la votación?
En todas las votaciones sobre la “vía rápida” de DIS29500 [=OOXML], “miebros P” siginifica miembros P de JTC1 (que votaron como tales en Septiembre), no miembros “P” de SC34 u otro de los subcomités ISO/IEC.
Más claro, echarle agua. Excepto, por supuesto, por el misterio prometido: ¿Por qué solicitó la CCE el cambio de membresía de Chile, cuando ese cambio no tendría ninguna consecuencia para el voto chileno?
Puede parecer un detalle, pero este cambio no es menor. El cambio de membresía en el subcomité trae responsabilidades nuevas, que por ahora, Chile ha cumplido pobremente (por eso es que puse “recursos” así, entre comillas). Y no creo que sea pecar de desconfiado el predecir que una vez que termine la saga de OOXML, veremos que el interés y liderazgo de la CCE sobre los otros temas que han sido tratados en el subcomité se diluirán bastante.
¿Puede haber esto sido un error?¿Penso la CCE y el INN que el cambio en el subcomité eran suficientes para que el voto de Chile valiera como Participante?¿O fue a propósito? Pero, en ese caso, y valga la redudancia… ¿Con qué propósito?
Ese, estimados, es el misterio. Y si, tengo que corregir varios artículos en que equivocadamente afirmé que Chile era país P para efectos de la “Vía Rápida”. De una cosa estoy seguro, eso sí: no estoy solo.
Personalmente, creo que dentro de toda las tácticas desplegadas por Microsoft para abogar por la estandarización de OOXML, el que sus empleados escriban artículos en sus blogs es una de las que aporta más positivamente a esta discusión. Y en ese sentido, los artículos de José Antonio Barriga, CTO de Microsoft Chile, son más que bienvenidos. Lo que no lo es, sin embargo, son las imprecisiones y, francamente, errores garrafales en su respuesta a la posición de rechazo que emitió la DCC de la Universidad de Chile. Como dicen por ahí, todos tenemos derecho a nuestra opinión, pero no a los hechos objetivos.
La bien argumentada posición de la DCC y la respuesta de Barriga son, combinadas, extremadamente largas, así que me disculpo de antemano por violar todas las reglas de los blogs de buena crianza por lo extenso de este artículo, pero acá van, comentados (la posición de la DCC en itálicas, la respuesta de Barriga, y mis comentarios en negrita):
DCC: 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 (Fasta Track), que fuerza a tomar una decisión en pocos meses.
Barriga: La argumentación arriba mencionada muestra una absoluta desinformación de cómo son llevados a cabo los procesos de revisión de normas en el seno de la ISO. ISO toma resoluciones de una manera colegiada en la cual, la suma de las partes revisadas por todos sus miembros dan la garantía que la totalidad de la norma fue revisada. En el caso chileno, se levantaron 217 observaciones que fueron parte de las 3.500 que se levantaron nivel mundial. Nadie puede reclamar que estas 3.500 observaciones no corresponden a la más acuciosa revisión que jamás se le haya hecho a norma alguna. Tal como lo señaló el propio representante de la Free Software Foundation, Oscar Valenzuela, en el Comité Espejo, ellos contaban con un equipo de 50 profesionales dedicados full time a revisar a profundidad la norma y encontrarle los errores más pequeños que se pudiera decir. Baste con ver el comentario CL 126 donde se menciona un error a nivel de un pixel corrido en un Word Art!
Barriga reconoce - implícitamente - que ni el ni nadie más en el comité espejo se leyó las 6000 páginas del documento que debía aprobarse. Y el que el proceso sea “colegiado” no tiene nada que ver con esto: evidentemente, es de esperar que lo mínimo que haga un comité que esta estudiando aprobar una norma es leérsela. El que se hayan encontrado 3.500 observaciones en la primera fase no significa que no hayan muchos más errores. Y como sabe (o debería saber) Barriga, varios de los comités nacionales que fueron a Ginebra tenían muchas otras observaciones que no pudieron presentar porque, francamente, más de 1000 comentarios demostraron ser bastante trabajo para una semana.
El tiempo que ha existido es más que suficiente para hacer un análisis acucioso si uno se dedica a esto. Si la gente no tiene tiempo, ¿es culpa del proceso o de las personas? Un caso para tomar en cuenta. Chile, después de la votación del 2 de septiembre, se juntó 13 veces. Brasil solo 2. Principal argumento de Brasil, no hay tiempo. A ese ritmo, concuerdo 100% que no alcanza el tiempo.
¿Hubo suficiente tiempo entre que Chile se incorporó como participante al comité de la ISO a finales de Agosto y el voto del 2 de Septiembre, cuando - Barriga lo sabe bien - su empresa casi consiguió un voto afirmativo de Chile sin ni un minuto de estudio?
¿Hubo suficiente tiempo en los cuatro meses donde Chile estudio solo sus propios comentarios, ignorando los miles de comentarios de otros países, en violación de las instrucciones de la ISO?
¿Será por el exceso de tiempo que el BRM en Ginebra tuvo que terminar con un voto para aprobar en masa más de 800 comentarios (+80% del total) que jamás fueron discutidos, y aún así apenas 5 de los 32 países asistentes - entre ellos Chile - votaron por esta ridícula medida que significo aprobar cambios por secretaría?
Si la Universidad estimaba que no existía el tiempo suficiente para realizar una revisión acusiosa al nivel que ellos esperaban, debieron haberlo manifestado al momento de iniciarse las reuniones y en el peor de los cosas, haberse abstenido de participar. La ratificación por parte de la Universidad de Chile del reglamento de las sesiones del Comité Espejo el 16 de noviembre, es un reflejo de que el tiempo de análisis no era una objeción en ese momento.
La lógica de esto es insólita (me causa estupor, diría alguien): Microsoft, a pesar de las múltiples solicitudes desde múltiples instituciones a que por favor no usara el mecanismo de “vía rápida” para intentar estandarizar un formato de 6000 páginas en unos pocos meses, decide insistir y, cuando aún así instituciones participan en el proceso, ¿es culpa de ellos que no hubo suficiente tiempo para lidiar con la especificación? ¡El mundo al revés!
De más esta decir que el reglamento del comité espejo se formó con la idea de revisar los 217 comentarios de Chile, no la pregunta, más general, de la viabilidad del estándar en sí. De hecho, las actas muestran que cada vez que alguien trato de expandir la discusión, esos esfuerzos no llegaron a ninguna parte (eso, sin embargo, es tema para otro día).
DCC: b) La inconveniencia de apurar la estandarización de un producto a un 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.
Nuevamente, la aseveración anterior muestra un desconocimiento absoluto de lo que es el proceso de estandarización de ISO y en especial el BRM y lo que se estaba discutiendo en él. El proceso de ISO esta compuesto por una serie de normas a las cuales los participantes y proponentes se someten, independientemente de si gustan o no. En la misma reunión del BRM con 29 votos a favor y solo 2 abstenciones, se acordó qué se iba a votar y con qué modalidad: Lo que se iba a votar en bloque eran aquellos comentarios que cada Comité Espejo en su seno había aprobado. En el caso Chileno eran 214 de 217. Lo mismo con los demás países. Lo que se discutió fue justamente aquello que no había consenso en cada Comité Nacional y que una cantidad sustancialmente menor. Se discutió y votó quedando solo 16 observaciones rechazadas.
Claramente, Barriga no ha discutido el BRM con Carlos Recabarren, Presidente de la CCE y representante del comité espejo en Ginebra. Como comenté en este mismo espacio, Chile - junto con un número pequeño de países - votaron, como bien dice la DCC, por no discutir 80% de los comentarios, y aprobarlos “en bloque”. Repito: Chile voto por aprobar más de 800 comentarios (muchos más que los presentados por “nuestra” delegación) sin haberlos discutido.
DCC 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.
Barriga: La Universidad de Chile se marginó de la primera etapa de este proceso que duró 6 meses. En ese período se encargó un estudio en derecho sobre la legalidad de la norma respecto a las normas chilenas que norman el uso del documento electrónico. Igualmente, la Cámara de Comercio de Santiago entregó un informe sobre la conveniencia de contar con un Estándar con OOXML en el concierto de la economía Chilena.
Escaso, por supuesto, no es lo mismo que “inexistente”. Hay harto más que discutir que algunos aspectos legales limitados. Y según entiendo (no he podido encontrar la presentación), el informe de la la CCS tenía que ver con la conveniencia de tener un “estándar XML” en el concierto de la economía chilena. Pero eso ya existe, y se llama ODF.
DCC: 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).
Barriga: No entendemos esta aseveración de la Universidad de Chile pues el 100% de los problemas que sí presentaba la norma fueron modificados a plena satisfacción de las mismas recomendaciones que la propia Universidad de Chile hizo en el proceso. De hecho, el Comité Espejo acogió y aprobó estas recomendaciones -según consta en las actas publicadas en el sitio de la Cámara de Comercio Electrónico- con la aprobación de la Universidad de Chile. La casa de estudio sólo voto en contra de 1 observación que no consideró apropiadamente respondida, pero finalmente participó en un voto de minoría.
Es más, estos temas fueron tratados a profundidad entre los profesores del Departamento de Ciencias de la Computación y una eminencia mundial en este campo como Jean Paoli, co-autor de XML y OpenXML en las dependencias de la misma casa de estudios.
Es decir, el punto de la DCC es completamente correcto. Y esto lo hemos comentado hasta el cansancio: uno de los problemas centrales con OOXML es que reinventa la rueda, utilizando tecnologías poco probadas en vez de estándares internacionales ya existentes.
Y sobre la respuesta de Barriga, es improcedente porque el comité espejo, respondiendo a una moción de la CCE respaldada por Microsoft, se REHUSO a considerar temas de armonización (es decir, de considerar si otros estándares ISO ya cubrían la funcionalidad de OOXML) como parte de las tareas del comité (ver el acta del 23 de Noviembre [PDF]). Con eso, se dificulto la discusión sobre el uso de funcionalidades no estándar en OOXML. Copio del acta:
6.3. No obstante lo anterior, el Sr. Enrique Onetto [de IBM] comenta que la comparación entre normas tiene el mérito de evaluar posibles problemas de interoperabilidad que los productos derivados de ellas tendrán, de manera que si la norma en análisis tuviera observaciones que atentan contra dicha interoperabilidad, es atendible revisar desde esta perspectiva la norma.
6.4. El Sr. Wilson Pais [de Microsoft] indica que las observaciones contenidas en el grupo de “Harmonization” están comparando un producto contra una norma, lo cual es improcedente.
DCC: b) No hay consenso, aun después del BRM de febrero, que la traducción del formato binario de Office a OOXML este documentado. Esto es esencial para que otros desarrolladores puedan recrear el formato original.
Barriga: Definitivamente nunca va a ver consenso pues OOXML no mapea formatos Binarios por dos razones básicas:
OOXML fue diseñado para proveer compatibilidad con archivos binarios a nivel de Funcionalidad y no a nivel de archivo. OOXML es XML (ver punto siguiente) y lo que se busca es poder representar en XML lo que se puede representar en un archivo Binario versiones Office posteriores de Office: el archivo Binario se lee con Office y el resultado se guarda en OOXML.
Uno de los comentarios más fuertes que se tuvo sobre la versión de OOXML entregada por ECMA es que contenía mapeo a formatos binario y eso era inaceptable para XML. ECMA aceptó esto y procedió a sacar cualquier vestigio de Binario de OOXML (aunque lo que había no eran binarios, pero eso es harina de otro costal). Luego OOXML NO tiene binarios.
Lo confieso, no entendí el argumento de Barriga: ¿”vestigio de Binario”?¿”NO Tiene binarios”? Creo que la DCC esta hablando de peras (mapeo de un formato a otro), y Barriga de manzanas (bitmaps). Sería bueno que si Barriga lo tiene, muestre el “roadmap” para mapear de un formato a otro, que es el tema que esta mencionando la DCC.
DCC: 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.
Barriga: Cualquiera que haya programado en la vida sabe perfectamente que no es necesario y tal vez nunca lo haga, leer todo el manual. Es como decirle a alguien que si quiere usar OpenOffice (para no herir susceptibilidades) debe leerse el 100% del manual si quiere escribir una carta. O si quiero hacer un programa en C++ debo leerlo entero para hacer un programa. Si uno es relativamente prolijo, se lee la introducción y el Getting Started. Luego, a medida que me voy enfrentando a problemas, leo la sección del manual que habla sobre lo que estoy preocupado. La argumnetación del DCC cae en algo tan obvio o grotesco como lo siguiente: si estoy haciendo una aplicación para Word, para qué tengo que leerme lo que dice relación a Excel y PowerPoint. Y si estoy viendo cómo grabar un archivo, ¿para qué me tengo que meter en la incrustación de WordArts?
De hecho, la argumentación de la DCC es correcta y la analogía de Barriga esta claramente equivocada: es evidente que no necesito leerme el manual de OpenOffice para escribir una carta, o la especificación de C++ para escribir un programa. Por supuesto, pero ese no es el tema. No se trata acá de escribir cartas o programas en C++, pero de programas que puedan procesar esas cartas o programas. La diferencia es gigantesca.
“Cualquiera que haya programado” (y si, yo soy uno de esos) sabe que si uno desea escribir un programa que pueda leer cualquier carta (un procesador de texto), o ejecutar cualquier programa en C++ (un intérprete), la tarea requiere un especificación (un manual) de excelente calidad. Si no, ¿como va a poder un programa “implementar” un formato, o un intérprete que pueda “compilar” un programa? Por suerte, nos dice Barriga:
Claramente este comentario está absolutamente fuera de la realidad. Lo que sí es real, es que la norma es completísima y aquellas partes que no lo eran, ahora, por el mismo proceso de la ISO ser completaron. Ahora se van a agregar páginas, no quitar.
Así es, vienen más páginas en camino. Sálvese quien pueda.
El argumento de comparar una especificación con XML, es llevar la argumentación al extremo de la falacia. XML es la sustancia con la cual se crean los vocablos o esquemas, donde OOXML es uno. Estos esquemas van a ser más extensos en tanto en cuanto mayores sean las funcionalidades que ellos deban representar en el subset definido por XML. ODF tiene más de 2.000 páginas. Por ejemplo, lo que dice relación solo a Excel tiene 1.095 páginas. ¿Cuántos libros de cómo usar Excel son de mucho más de 1.000 páginas? La especificación de PowerPoint es de 265 páginas.!!! Creo que ni un libro de PowerPoint for Dummies tiene tan pocas páginas.
Este es un buen punto. OOXML debería ser comparado a un estándar como ODF, que cuando fue aprobado por la ISO, tenía aproximadamente 700 páginas. 700 vs. 6000. 6000 antes de las correcciones, digo. Porque se van a a agregar páginas.
DCC: d) Los temas legales de licenciamiento han sido objeto de muchas críticas debido a su falta de precisión. La insertes sobre si se ha cruzado una línea legal o no también desalienta las implementaciones alternativas.
Barriga: Realmente no entendemos esta aseveración. Simplemente nos remitimos a lo que plateamos al principio. La ISO es una organización de estándares, cuyo prestigio y seriedad no está en duda, pues por la misma razón, todos hemos acudido a ella como ente para que regule y norme estos estándares. Pues bien, la propia ISO, en su proceso de aceptar la norma ECMA 376 para convertirse en un estándar ISO, descartó , previa revisión, que esta norma tuviera cualquier problema de propiedad intelectual que se le exige a cualquier otra norma ISO.
Si dudamos de la claridad y seriedad de ISO en este aspecto tan relevante, ¿porque no dudamos cuándo ODF o PDF entraron a la ISO?
Está bien claro que después de las brutales manipulaciones a las que Microsoft ha sometido el proceso de estandarización en la ISO, el “prestigio y seriedad” de esta organización ha quedado bastante en duda. ¿Será por esto que la Unión Europea esta investigando las acciones de Microsoft en los comités espejo del viejo continente?
Sobre la pregunta de Barriga, no hay dudas sobre el status legal de ODF porque las condiciones de licenciamiento de este formato permiten que sea implementado por cualquier programador independiente. Un estudio reciente sobre la licencia de OOXML, sin embargo, que las garantías que ha entregado Microsoft para la implementación del formato de Office son insuficientes.
La ISO, cuando acepta una especificación para su posible estandarización, no revisa si la tecnología esta sujeta a patentes, o si estará a disposición de todos sin costo, o, por supuesto, si las licencias son compatibles con el uso de los estándares en código abierto. Es por eso que ODF dá más garantías que OOXML. Nada de patentes, nada de costos, y se puede implementar con programas propietarios y de código abierto.
DCC: 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.
Barriga: Nuevamente, nuestra sorpresa es mayúscula. Tal como se mencionaba anteriormente, la Universidad de Chile se marginó de la primera etapa de este proceso que duró 6 meses. En ese período se encargó un estudio en derecho sobre la legalidad de la norma respecto a las normas chilenas que norman el uso del documento electrónico. Sin perjuicio de lo anterior, este informe estuvo disponible a todos los miembros del comité y fue sometido a escrutinio en el subcomité de propiedad intelectual, al cual por cierto, a pesar de estar invitados no se excusó de asistir el representante de la Universidad de Chile.
Barriga debería saber muy bien que el citado es “un estudio jurídico y no técnico”. Es decir, en ese documento jamás se evaluó si OOXML era técnicamente compatible con la legislación existente. ¿Se puede decir más claro?
DCC 2. Modularidad. Es la capacidad de un software de ser tratado como un sistema coherente de varias partes independientes entre sí.
DCC: a) La propuesta carece absolutamente de modularidad. Esto es particularmente notorio en la dificultad para reemplazar formatos obsoletos por funcionalidades ISO estandarizados (por ejemplo fechas, formulas 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.
Barriga: Los problemas que se señalan fueron corregidos a completa satisfacción de lo solicitado por nuestro comité y la comunidad mundial de la ISO. No se logra entender porqué se insiste en quedarse con la primera versión de la norma como si todo el trabajo de corrección que hizo en estos últimos meses no hubiera existido. Todas las funcionalidades donde se pidió usar una norma ISO fueron acogidas y las partes obsoletas fueron sacadas de la especificación y colocada en un capítulo aparte para especificaciones Transitorias.
¿En serio? Sr. Barriga, ¿OOXML usará el estándar MathML para representar ecuaciones? Porque según el representante del comité espejo griego, esto no es así, y OOXML seguirá usando OOML, una especificación creada especialmente para OOXML, para muchos documentos. ¿Quién tiene la razón?
Lo increíble de la maratón que fue el BRM es que de hecho terminó en dos estándares: uno “transicional” para documentos existentes, y otro “strict” para documentos nuevos. Pague uno, llévese dos.
DCC 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.
Barriga: Totalmente de acuerdo en la premisa y en la conclusión siempre que una norma carezca de modularidad, cosa que por cierto no es lo que hoy tenemos en OOXML luego de 1 año de trabajo en ISO sobre ella. Es verdad que en ese año muchos se dedicaron a reclamar que no tenían tiempo para trabajar, pero hubo un grupo no menor, encabezado por la FSF e IBM que revisaron al máximo nivel de acuciosidad la norma. Nosotros como Microsoft no podemos estar más agradecidos pues el producto que salió de este proceso es infinitamente mejor que la que habríamos pensado.
Y la FSF, IBM, Google, y un número importante de países, después de esa breve revisión (ya sabemos que ODF tomó más de 2 años y medio de estudio por parte de OASIS, y fue aprobada en forma unánime por la ISO), llegaron a la conclusión de que OOXML debe ser rechazado como estándar.
DCC: 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.
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).
Barriga: Microsoft ya hace lo que señala la Universidad. Es más, esto ocurrió justamente a recomendación de ISO para poder entrar al proceso. La documentación está publicada en la página web de Microsoft y en la de la Biblioteca Nacional de Inglaterra (Miembro de ECMA). La publicación lleva consigo todos los temas de propiedad intelectual en las cuales, básicamente, los igualamos a los de OOXML. Nos causa una extrañeza profunda este comentario, pues esto fue profusamente analizado y discutido en las reuniones del comité y subcomités, además de ser expuesto a los profesores del DCC por Jean Paoli en forma particular y por Nick Tsilas en forma general a todos los miembros del comité. ¿No lo escucharon o no quieren escucharlo?
Buen punto. De hecho, la publicación de la documentación de los documentos binarios realizada por Microsoft y forzada por el proceso de estandarización de OOXML es una excelente noticia.
¿Qué busca el DCC? ¿Por qué quieren causar tanto daño? ¿Qué les hemos hecho para que nos traten de esta forma? Si tan mal piensan de nosotros, ¿por qué aceptan trabajar con nosotros en proyectos de mutuo beneficio?
Si por “daño” se refieren a evitar que una pésima especificación se convierta en un estándar internacional, esperemos que haya mucho “daño” más.
sino que es una de solo tres instituciones Chilenas (las otras dos son empresas) que son miembros de OpenXMLCommunity.org, una “comunidad” creada y administrada por Microsoft y que se define como:
“…un grupo de instituciones públicas, empresas, profesionales, académicos y desarrolladores que apoyan OOXML y su aprobación como un estándar ISO”
Como ya es bien sabido, OOXML, el formato de oficina creado por Microsoft, fue rechazado - en primera instancia - como estándar ISO 29300. Esta semana, representantes de organizaciones de normalización de todo el mundo están discutiendo en Ginebra, Suiza, los comentarios presentados que llevaron al rechazo inicial en Septiembre del año pasado, en miras a una segunda votación que será llevada a cabo hasta finales de Marzo. El representante que Chile eligió enviar a Ginebra - quizás el trabajo más importante en todo este proceso - nos debería decir mucho como se ha conducido este proceso, y cuál será el voto de Chile. Pero vamos por partes.
Aunque no tengo acceso a los memos internos de Microsoft, está claro que la estrategia general de la empresa para lograr la aprobación de OOXML incluía, al menos, estos elementos:
Si el país ya tenía participación activa en JCT1, el comité de ISO a cargo de la decisión sobre OOXML, intentar asegurar un voto positivo
Si el país no era participante activo (esto es, un país Observante, y no Participante, como el caso de Chile), incentivar a que el país en cuestión cambiara su membresía.
Asegurar una votación positiva en los comités nacionales al incorporar actores amigables a Microsoft
Aunque Microsoft tuvo cuidado de no aparecer impulsando esta estrategia en una manera pública, de forma de preservar la independencia del proceso, los antecedentes se acumularon rápidamente: llamadas personales de Bill Gates al ministro correspondiente en EEUU, ofertas de compensación por votos afirmativos en Suecia, irregularidades en la composición del comité nacional en Portugal, y un largo etc.
En Chile, la organización llamada a llevar a cabo esta estrategia fue la Cámara de Comercio Electrónico. No es casualidad que fuera la CCE la que le ofreció recursos al Instituto Nacional de Normalización (la organización que representa a Chile ante la ISO) para que cambiara su membresía en la ISO, y para que formara un “comité espejo” que evaluara el voto de Chile sobre OOXML, que con el cambio tendría mucho más peso. Aunque el voto inicial había sido aprobar, denuncias públicas parecieron resultar en que el INN cambiara su voto a abstención en la primera ronda de votación en Septiembre.
Y después de meses de trabajo, cuando llegó el momento de elegir a la comitiva que representaría a Chile en Ginebra para la segunda ronda, el comité espejo hizo una elección que en otra circunstancias hubiera sido la lógica: la CCE, al ser consultada, me ha comunicado que el comité decidió enviar a Carlos Recabarren, presidente del comité espejo.
El que sea el presidente del comité nos represente no sería, normalmente, ningún problema. Lo que si lo es es que Carlos Recabarren es también presidente de la CCE, una organización gremial de la cuál Microsoft es miembro y cuya misión - no muy sorprendentemente - es la de “defender los intereses del sector y sus asociados”. Como ya comenté antes, la posición de la CCE con respecto a OOXML es bien clara, y fue publicada en su sitio por muchos meses antes de la votación de Septiembre pasado.
Cuando el INN delegó la secretaría ejecutiva a la CCE, muchos apuntamos que dada la naturaleza de la CCE esto generaba un conflicto de interés que no es fácil de resolver: después de todo, José Antonio Barriga, CTO de Microsoft en Chile, es parte del directorio de la CCE… ¿o no?
Mientras investigaba los antecedentes para este artículo, me encontré con una tremenda sorpresa: desde que el papel de la CCE en el voto de Chile fuera denunciado (algo exageradamente, es cierto) en Liberación Digital, la CCE ha silenciosamente removido a José Antonio Barriga de su lista de directores:
Aunque no conozco el motivo de este cambio, no parece casualidad que Barriga ya no aparezca listado como una autoridad de la CCE meras semanas después de que su rol en esa organización haya creado dudas sobre el proceso de decisión del voto de Chile.
Y el problema con que Recabarren (y por lo tanto, la CCE) sea nuestro representante es simple, pero vale la pena decirlo una vez más: Cuando vuelva de Ginebra, presente su informe sobre lo que pasó en la reunión y haga una recomendación para el voto de Chile… ¿lo hará con el “manto” de presidente de la CCE, cuya misión es defender los intereses de sus miembros (Microsoft) o como representante del INN (y de Chile) ante un organismo internacional?
Esta semana, Chile, como muchos otros países alrededor del mundo, está terminando una nueva etapa en su participación en el proceso que está intentando estandarizar OOXML, el formato de documento creado por Microsoft. Y como en muchas otras partes del mundo, el proceso está dejando mucho que desear. Pero vamos por partes.
Un pequeño recuento: en Septiembre del año pasado se efectuó un primero voto que buscaba la aprobación, por vía rápida, de OOXML. Microsoft, a pesar de usar tácticas incalificables, perdió esa primera batalla, en la cuál Chile tuvo un rol menor. El Instituto Nacional de Normalización (INN) , encargado de decidir nuestro voto, había seguido en un principio un camino preocupante: sin ninguna discusión técnica o explicación, Chile cambio su membresía en la Organización Internacional para la Estandarización (ISO) de país “Observador” a “Participante”, con lo que su voto pesaría mucho más.
Como en otros países, este cambio hubiera sido un preludio para un voto positivo para Microsoft. Sin embargo, Chile ya cuenta con una joven pero entusiasta comunidad de activistas digitales, y el escrutinio al que fue sometido el proceso sin duda impidió un voto apresurado e incorrecto por parte del INN. Nunca sabremos, a menos que los involucrados nos cuenten, cuanta influencia tuvo el activismo en la red, pero dudo que el resultado final, la abstención de Chile, se hubiera logrado sin ese esfuerzo.
¿Y en que estamos ahora, meses después? Después del rechazo inicial, estamos casi al final de la segunda etapa del proceso después del rechazo inicial: ECMA (=Microsoft), la organización que presentó OOXML para su estandarización, ha respondido a muchos de los más de 3000 comentarios que fueron enviados por el INN y sus organizaciones hermanas alrededor del mundo. Esos comentarios, y las respuestas de ECMA, serán analizadas en lo que promete ser una meteórica jornada entre el 25 y 29 de Febrero en Ginebra, Suiza. Después de que termine esa reunión, organizaciones representantes como el INN tienen 30 días para definir su voto final con respecto a OOXML.
Y he aquí el quid del asunto. Mientras que en otros países son las organizaciones como el INN las que dirigen este proceso, el INN decidió dejarlo en las manos de la Cámara de Comercio Electrónico (CCE), una organización que, como bien han apuntadovarios, tiene a José Antonio Barriga, gerente de tecnologías de Microsoft en Chile. No digamos que la imagen de la independencia. Peor aún, la sección de documentos del sitio de la CCE no deja ninguna duda de cuál es la posición de la organización con respecto al tema:
(Nótese las cinco estrellas, ejem).
Esto es anecdótico, por supuesto, hasta que uno empieza a considerar algunas de las responsabilidades que, como entidad nombrada a la secretaria técnica, el INN le derivó a la CCE (PDF):
- Revisar y coordinar las respuestas, comentarios y votaciones del Comité Nacional hacia ISO;
- Remitir las respuestas, comentarios y votaciones sometidas por el Comité Nacional
a la secretaría responsable de Comité Técnico de ISO o Secretaría Central de ISO,
según sea aplicable;
- Entregar a los miembros la información necesaria para apoyarlos en el cumplimiento de sus roles dentro del Comité Nacional;
- Dirigir las reuniones ampliadas del Comité Nacional;
- Elaborar acta de las reuniones del Comité Nacional y someterla a la aprobación de
dicho Comité;
- Asistir a todas las reuniones de trabajo para:
dar consistencia a las discusiones
llevar un control del avance del estudio de los documentos
dar las pautas normativas
Es decir, el trabajo del “secretario” conlleva una inmensa responsabilidad y poder para dirigir la discusión. Tanto más preocupante, entonces, que la organización designada por el INN parezca tener un conflicto de interés tan evidente.
Después de la formación del comité se realizaron nueve reuniones para discutir los 217 comentarios hechos por Chile en Septiembre. Hasta el 7 de Enero, a ECMA le faltaba contestar 66 (30%) de los comentarios hechos por Chile. Y según el plan de trabajo del comité, solo queda una reunión, el martes 15 de Febrero, antes de la decisión final que se tomará (no conozco los detalles) antes (o el mismo) viernes 18.
Una lectura de las actas es reveladora (el análisis queda para próximos artículos). La influencia de Microsoft en el proceso no se limita a su membresía en la dirección de la CCE, sino que sus representantes, que religiosamente asistieron a todas las reuniones, también parecen haber sido una voz permanente en las discusiones (kudos por la disciplina).
De las actas queda claro que casi toda la información técnica tuvo una sola fuente (adivinen). Y como veremos más adelante, el comité decidió ignorar algunos de los mismos comentarios que había hecho Chile en Septiembre.
Es decir, la situación como esta hoy indica que:
El INN dejó a cargo del tema a una organización (la CCE) que tiene una preferencia declarada por OOXML, y que tiene en su directorio a un alto ejecutivo de Microsoft
Otros representantes en el comité tienen similares lazos financieros con Microsoft.
Las actas indican que con contadísimas excepciones, el comité recibió información técnica de una sola fuente, y que Microsoft actuó como juez y parte en el proceso.
Como las últimas dos actas no están publicadas, es difícil saber si el comité logró completar su tarea. Si no es así, es importante recordar que el plazo final para una decisión es el 28 de Marzo.
¿Es está la crónica de un voto anunciado? No lo sé, pero las acciones del INN parecen indicarlo así. A pesar de un loable esfuerzo por ser más transparente, este comité no dá garantías, y tengo pocas dudas de que, a menos que veamos una fuerte reacción dentro y fuera de la red, esta semana el comité decidirá darle su respaldo a OOXML.
Hay mucho más que decir sobre las actas, y los invito a todos a leerlas. Hubieron voces de razón que ya mencionaré, y esfuerzos honestos (aunque probablemente insuficientes) para que el comité hiciera su trabajo en vez de ser un vehículo para la estrategia de Microsoft. Y como acostumbra pasar la responsabilidad cae no tanto en el comité mismo, sino en el INN por haber abandonado este tema tan delicado. ¿Como hablamos de la importancia de la innovación y la tecnología, si ni siquiera mostramos la motivación y la independencia para tomar nuestras propias decisiones?
Ayer, con coordinación que solo se ve en un ballet, y mientras escribía el último correo antes de cerrar el computador, me llegó la noticia de que el INN ha decidido abstenerse en la votación sobre OOXML y mi (hasta ahora) extremadamente confiable Thinkpad tuvo un ataque de algo y murió. Nada de pánicos o mensajes de error. Pantalla negra y falta total de señales de vida. Un aneurisma electrónico.
Por supuesto, esto paso justo cuando estoy preparando maletas para llegar a Chile el lunes en la mañana (mis diculpas a los amigos que se enteran de esta forma). Gracias a nuestro excelente departamento informático, soy - por un par de semanas - un nuevo integrante de la comunidad Apple. Dada la obligación de abandonar a mi querido Debian, me dieron la opción de Windows o Mac. Así que aquí estoy, escribiendo con un PowerBook G4. Podría ser peor.
Y un aplauso para Lenovo: ingresé una solicitud de servicio bajo garantía (la diferencia de precio por un Thinkpad se explica en parte por los 3 años de garantía que incluyen) y me llamaron literalmente 8 minutos más tarde para ver cuál era el problema. Después de una breve explicación, me han enviado una caja por correo (con retorno pre-pagado) para que envié al difunto a ser revivido. Servicio al cliente de película.
Eso es todo por ahora. Espero reiniciar transmisiones pronto. Estaré aprendiendo como funciona el Powerbook (todo bien por el momento). Cambio y fuera.
Como muchos lectores sabrán a estas alturas, el próximo 2 de Septiembre es el plazo final para que las organizaciones nacionales que pertenecen a ISO (Chile incluido) decidan su voto con respecto a la propuesta de que OOXML, el formato de documentos del recién estrenado Microsoft Office 2007, se convierta en un estándar internacional. El proceso de votación es un poco complicado, así que vale explicar un poco como funciona la cosa, para que los leales lectores no se confundan cuando se empiecen a contar los votos la próxima semana.
La cosa funciona más o menos así: cada país miembro de ISO debe decidir entre tres posibles votos:
Aprobar: Este voto puede incluir comentarios, pero solo de carácter general o editorial.
Rechazar: Este voto puede incluir comentarios de cualquier tipo, incluyendo indicaciones de problemas técnicos que deberían ser corregidos y propuestas para su corrección.
Aprobación condicional debe ser enviada [a ISO] como un voto de rechazo.
Es decir, si una una organización nacional cree que OOXML estándar presenta problemas técnicos que deben ser solucionados, debe rechazar la aprobación del estándar, incluso en el caso en que crea que estos problemas pueden ser solucionados y el estándar puede ser aprobado más tarde.
El otro aspecto que es un poco complicado es como se determina el resultado. A pesar de que cada país tiene un solo votos (todos los países son iguales), no todos los votos tienen el mismo peso (hay países más iguales que otros). En términos simples, hay dos tipos de miembros de ISO que pueden votar: los países “P” (Participantes) y los países “O” (Observadores). Para que OOXML pueda ser aprobado, todas las siguientes condiciones deben cumplirse:
No más del 50% de países deben abstenerse.
Al menos 66% de los países “P” deben aprobar.
No más del 25% del total de los votos (Países “P” y “O” combinados) debe rechazar.
Como se imaginarán, la primera condición es relativamente fácil de cumplir en el caso de OOXML. Es cosa de tener suficientes votos, y no hay indicación hasta ahora de que muchos países “P” se van a abstener, aunque Finlandia e Italia han indicado su intención de hacerlo. Abstenciones no son consideradas cuando se calculan los porcentajes de los puntos (2) y (3).
El criterio (2) es más complicado para Microsoft. China, India, Brasil, Canadá y Japón, todos países “P”, han indicado que rechazarán OOXML. Es probable que otros países que han trabajado en ISO por mucho tiempo sigan esta tendencia.
Pero la guerra no está ni cerca de estar perdida para Microsoft. De hecho, hay varias indicaciones que Microsoft esta peleando dos batallas: tratar a convencer a países que voten a favor, o en el peor de los casos que se abstengan (¡esto es bastante obvio!), y la segunda estrategia es lograr que países pequeños voten “Aprobar” y cambien su membresía en ISO de observador (O) a participante (P). El genio de esta estrategia es evidente: Microsoft será capaz de contrarrestar la oposición de países al “diluir” los votos negativos que podrían cambiar generar un rechazo de OOXML debido al criterio (2). Hay indicaciones de Chile está considerando justamente esta medida, aunque es poco claro cuál será el voto del INN, ni tampoco si el cambio de O a P se hará antes del 2 de Septiembre. Estén atentos.
Y esto nos lleva al criterio número (3). En cierto sentido, este es el más difícil de influenciar, porque no toma en cuenta el tipo de membresía de cada país. Microsoft ha tenido que usar tácticas más conocidas, y esta usando toda su influencia. En un voto reciente en Estados Unidos, por ejemplo, Bill Gates llamó directamente al Ministro de Comercio norteamericano (Si señores, en todas partes se cuecen habas) para cambiar un voto poco favorable. Desde Tanzania a Portugal, pasando por Kenya, organizaciones nacionales están recibiendo una atención inusitada de Microsoft, que esta reclutando votos positivos a diestra y siniestra. Sin duda, lo mismo esta pasando en Chile, donde la amistad de Microsoft y el Gobierno es bien conocida.
Como ya contaba en el blog de Christian, hay sólidas razones técnicas para rechazar OOXML, razones que se son independientes de que opinión nos genere Microsoft como empresa. El INN tiene una opción clara para definir su voto la próxima semana, y debería rechazar la aprobación de OOXML.
