BRM = ¿"Estafa" y/o "Fracaso"? PDF  | Imprimir |  E-Mail

El BRM en ISO fracasa sin llegar a consenso ni arreglar el OOXML

En declaraciones de Tim Bray, delegado de Canadá:
"El proceso fue una completa, total y auténtica mierda" (sic)

Amo el BRM
Diseño de João Neves (Portugal)
Notificación importante (última actualización 2008-03-05):

El BRM o "Reunión de Resolución de la Votación" ("Ballot Resolution Meeting") ha fracasado rotúndamente y no ha conseguido que finalmente sea arreglada la especificación de DIS 29500, OOXML u Office OpenXML, que fue rechazada el 2 de setiembre del 2007. No se ha producido un consenso suficiente entre los más de 30 países participantes para que se acepten las propuestas de arreglo de ECMA que se han podido discutir en el BRM. Tampoco de las alternativas provistas por varias de las delegaciones. Sólo se han incorporado sin ningún consenso  alrededor de 900 parches, votados en bloque y a ciegas, ya que no se han podido discutir (más del 95% de los técnicos). También se han añadido, o rechazado, las pocas enmiendas técnicas que se han discutido en base a las propuestas de ECMA. Ninguna de ellas ha sido incorporada sin cambios. Un delegado brasileño presente en la reunión nos lo cuenta de primera mano.

Pese a que se han sumado nuevas irregularidades a este ya de por sí irregular proceso de estandarización, la empresa promotora del mismo, Microsoft a través de ECMA, no ha logrado reunir los suficientes apoyos para que salgan adelante las propuestas de arreglos que se han discutido en el BRM (la minoría). La votación por contra ha acabado admitiendo, sin discusión alguna y en bloque, alrededor del 95% de arreglos técnicos propuestos por ECMA. Esto ha sido permitido con el apoyo de una pequeña minoría de los delegados. Los resultados de esa votación en bloque, según fuentes internas del BRM, fueron los siguientes:

- Recuento entre Miembros P (principales):

4 "A FAVOR" - 4 "EN CONTRA" - 15 "ABSTENCIÓN" - 2 votos de rechazo al proceso

- Recuento entre Miembros P y O (observadores):  

6 "A FAVOR" - 4 "EN CONTRA" - 18 "ABSTENCIÓN" - 4 votos de rechazo al proceso

Y aunque las reglas dicten que se tengan en cuenta sólo los miembros P en esas votaciones (con lo que el gran bloque de comentarios habría sido rechazado), se tuvieron en cuenta por contra la suma de miembros P más miembros O. De ahí se explica el supuesto alto grado de aceptación que Microsoft declara a partir de los resultados finales de comentarios de ECMA admitidos.

Así, al contrario de lo que interesadamente pregona Microsoft el BRM nunca tuvo por misión probar o rechazar el OOXML. La misión del BRM era exclusivamente intentar arreglarlo con el máximo consenso, cosa que obviamente no se ha logrado. Porque 4 votos de entre todos los miembros P de ISO (el 13% de los mismos) no representa nigún consenso. Por todo ello el BRM se podría calificar sólo de dos posibles formas ambas válidas a la vez:

a) Fracaso en el cometido: no ha habido consenso en más del 95% de los comentarios que no fueran meramente editoriales. Tampoco se ha arreglado la especificación y en algunos casos incluso se han agrandado sus problemas.

b) Estafa al público: no se han discutido alrededor del 95% de las enmiendas técnicas propuestas por ECMA y se han sólo aprobado la mayoría de ellas en bloque por parte de una minoría del 17.6% de las delegaciones (sumando irregularmente miembros P más O). Por otro lado, no se ha permitido a las delegaciones exponer a estudio muchas de sus propuestas para que fueran discutidas. El ejemplo es Estados Unidos que sólo fue capaz de exponer una. Otros países, debido al orden alfabético, pudieron llegar hasta dos. Esas dos circunstancias jamás se habían dado antes en ISO... y mucho menos la vanal justificación por la que ambas han sido permitidas: la (más que previsible) falta de tiempo.

Obviamente ese argumento no representa justificación alguna, sino más bien escusa. Un estándar ISO/IEC no debe ser aprobado hasta que no está totalmente listo técnica y legalmente. Si el proceso de fast-track no es suficiente para que OOXML esté listo, que en este caso no lo ha sido, hay que proceder a pasarlo al proceso normal de ISO y que se en él se enmiende todo lo que necesite, empleando todo el tiempo que necesite. En caso contrario se ha de rechazar sin paliativos, cosa que probablemente le ocurrirá a DIS 29500 en vista del camino de abusos por el que se encamina.

Sin embargo, la estrategia de Microsoft parece ser justo la contraria, aprovechar la incapacidad del proceso de fast-track para arreglar este estropicio de especificación bruta y en bruto, para así poder aprobarlo mediante la política y la velada compra de votos (como en Suecia se demostró y en Nigeria ocurrió recientemente en el caso de los 17.000 PCs con Mandriva para sus escuelas).

En cualquier elección democrática esas técnicas fraudulentas orientadas a adulterar el resultado final estaría prohibidas o incluso tendrían penas de cárcel, pero en el cándido mundo de ISO/IEC, desgraciadamente, esta es la primera vez que tienen que lidiar con cantidades de intereses económicos de dinero tan grandes, y eso parece estar resquebrajando todas las buenas voluntades y débiles e imprecisas normas existentes.

El siguiente y posiblemente definitivo paso 

Lo que sique al BRM ahora es un periodo de 30 días, hasta final de marzo, en el que los comités de estandarización podrán cambiar los votos que emitieron el 2 de setiembr del 2007. En ese proceso se votará sobre el nuevo texto que se supone que tendrán que preparar ECMA y Microsoft en base a los pobres resultados del BRM. Sin embargo, las dudas son muchas de que puedan realizar tamaña tarea de rejuntar en algo distinto a un monstruo de Frankenstein las más de 6000 páginas iniciales, más aquellas de las más de 2000 que hayan obtenido consenso en el BRM. Sobre eso es ese hipotético texto de especificación es sobre lo que tendrán que redefinir su voto los comités de estandarización.

La presión política que se espera sobre muchos de ellos probablemente alcance unas cuotas jamás conocidas en ningún proceso de estandarización anterior.

Las impresiones de algunos ilustres participantes

Frank Farance, cabeza de delegación (EE.UU.)

- "Es probable que haya cientos de defectos [en la especificación de OOXML resultante del BRM]
- "Prácticamente ninguno de los comentarios que analizamos sobrevivió sin corrección"
- "No le veo la razón por la que se nos limitó el tiempo. No sé cómo se puede tratar con 6000 páginas con 3500 comentarios en una semana. Es como intentar correr una milla en dos minutos"
- "El ochenta por ciento de los cambios no fueron debatidos... es como si tienes un proyecto de software muy grande y no pasas por los controles de calidad el 80% del mismo. ...Es un gran problema... Nunca he visto nada como esto, y llevo haciendo esto desde hace 25 años."
- "Un montón de reglas fueron decididas sobre la marcha"
- "Fuimos capaces de conseguir corregir algunas cosas, pero era algo así como taponar un agujero con tu dedo en una presa y entonces ver otro agujero y entonces otro agujero más."

Tim Bray, "creador del XML" (Canadá)

Lo que estuvo mal · El proceso fue una completa, total y auténtica mierda (sic). No soy un experto en ISO, pero sea lo que sea para lo que su proceso de "Fast Track" fue diseñado, es seguro que no fue para esto. Simplemente no puedes revisar seis mil páginas de especificación profundamente compleja en el tiempo que se proveyó para el proceso. [...]
Como el tiempo fue tan corto, hubo cierto pánico real porque nos quedáramos sin tiempo para tratar las propuestas; algunas de ellas, en mi opinión, eran cosas que realmente hubieran ayudado a la calidad del borrador.
Eso fue un horrible y representativo abuso de proceso e ISO debería estar totalmente avergonzado por permitir que esto haya ocurrido. Su reputación, según mi perspectiva, está hecha jirones. Mi opinión sobre ECMA era ya de por sí muy negativa: esto no la mejorado, y si ISO no es capaz de arreglar esta sanguijuela tóxica, este tipo de abusos va a pasar una y otra y otra vez más.
[Fuente su blog OnGoing, "Now that the BRM is over"]
 

James Mason, durante 20 años presidente del comité ISO/IEC JTC1 SC34 (antes SC18 WG8), y representante del Departamento de Energía de EEUU

Antes del BRM escribió a sus compañeros del comité V1 del INCITS estadounidense: "el proponente [ECMA] obviamente no leyó -ni editó- esta propuesta como un todo consistente." y añadió "Si hubiera venido por el proceso normal de ISO, yo hubiera dicho que estaría en el estado de un Borrador de Trabajo y no listo aún para su registro como un Borrador de Comité y la asignación de un número [el 29500]".
 

Andrew Updegrove, abogado experto en estándares, The Consortium 

Hay dos formas en que posiblemente oigas resumidos los resultados del BRM por aquellos que emitan declaraciones y notas de prensa en los próximos días. Quizá inevitablemente, sean diametralmente opuestos, tal y como tan frecuentemente ha ocurrido en la saga ODF - OOXML hasta la fecha. Los dos resultados serán como sigue:

98,4% de los Disposiciones Propuestas al OOXML fueron aprobadas por una mayoría de dos tercios del BRM, validando OOXML. 

Las Disposiciones Propuestas al OOXML fueron rechazadas de manera abrumadora por las delegaciones que atendieron al BRM, indicando al inadaptación de OOXML para ser tratado en un proceso de "Fast Track"

En esta artículo, explicaré por que la última de esas posiciones es la única conclusion plausible, y además te ayudará a leer debidamente contextualizados las notas de prensa y declaraciones que van a aparecer.
 

La anterior votación... aún vigente

Los resultados oficiales de la votación del 2 de setiembre del 2007 mostraron que OOXML fue derrotado en la fase DIS 29500 del proceso de aprobación en ISO. Un total de 15 países miembros Participantes de ISO votaron en contra de la especificación, mientras que 17 lo hicieron a favor (la mayoría nuevas incorporaciones como participantes) y cerca de una decena se abstuvieron. En total la propuesta de Microsoft consiguió un 53% de los votos cuando necesitaba más de un 66% para obtener así el consenso requerido por ISO. En el recuento de miembros Observadores más Participantes, Microsoft tampoco reunió el consenso necesario que estaba establecido en un 75% de los votos eliminando las abstenciones".

Resultado oficial del voto DIS 29500 en ISO/IEC: no aprobadoPese a todas las innumerables irregularidades que se han producido a lo larto del proceso de estandarización y pese a no haberle dado tiempo suficiente a ISO para estudiar los cerca de 10.000 problemas técnicos (comentarios) que han acompañado a los votos, ISO ha anunció que continuaría con el proceso de estandarización y que a partir de la última semana de febrero se llevaría a cabo el BRM ("Ballot Resolution Meeting"). Sin duda cualquier otra especificación que hubiera sufrido el varapalo que sufrío OOXML el 2 de setiembre del 2007 estaría descartada de ISO con sólo contar los votos y sin siquiera mirar los comentarios técnicos. Sin embargo, esta propuesta de estándar es de Microsoft y claro.

Es por ello que es probable que pese ha haber fracasado también en su enmienda en el BRM debido a que los principales arreglos a la especificación no han sido aprobados al no obtener consenso, el proceso continúe y los comités de estandarización se vean obligados a tomar una desión política sobre si mantienen o cambian su voto emitido en el verano del 2007. Lo que aún está por ver es "¿sobre qué especificación votarán?", porque la nueva con las enmiendas aprovadas (principalmente de orden menor) es muy probable que aún tarde bastante y que incluso no tengan que votar a ciegas sin disponer de ella.

 
 

  Por favor, ponga este banner bien visible en su web apuntando a http://www.openxml.info/
Office OpenXML no es apto para ISO

Por favor, ponha este banner bem vissible na sua web apontando á http://www.openxml.info/
Office OpenXML no es apto para ISO

Portal web creado, mantenido y alojado por OPENTIA, diseño por OPENTIA y Joomlashack
Sitio creado por OPENTIA, diseño por JoomlaShack y OPENTIA y JoomlaShack Joomla Templates by Compass Design