Estamos a pocos días de una votación de los miembros de la ISO para aprobar un estándar de formato de documentos ofimáticos, OOXML (ISO DIS 29500), tecnología desarrollada por Microsoft, el 29 de marzo de 2008. Este nuevo "estándar" será sometido a votación por parte de los representantes de los países que tienen voto en ISO/IEC, y nuestro país es miembro "P" (principal), es decir, que tiene voto decisivo en la aprobación. Tengo una fuerte posición frente a esta decisión, y es mi deseo, como el de mucha gente alrededor del mundo, que este estándar no sea aprobado. Y no es que sea un capricho, a continuación hago un extracto de las razones por las que este formato no debe ser aprobado.

OOXML.info, en su página lista tres razones principales:

No es abierto: Para que un formato pueda ser considerado abierto, ha de estar libre de regalía o condición alguna por patentes, y no puede ser controlado por una única empresa (...que además en este caso cuenta con un amplio historial de amenazas a sus competidores mediante patentes de software). Por otro lado, el formato en cuestión debe ser multiplataforma por naturaleza. Office OpenXML no cumple ninguna de esas condiciones.

No es estándar: Un estándar debe estar totalmente documentado públicamente. Además, su proceso de estandarización (ECMA) debería haber garantizado que todas las patentes de los proponentes del mismo fueran desveladas y licenciadas como mínimo en términos RAND. Finalmente, es necesario que una propuesta de estándar ISO cumpla y no contradiga los estándares ISO ya preexistentes para no obligar a "reinventar la rueda". Office OpenXML no cumple ninguna de esas condiciones.

No es XML: Para que un formato de representación de información pueda ser considerado XML, éste debe plasmar íntegramente dicha información en estructuras XML. Para que algo se denomine XML no basta con que que simplemente utilice etiquetas XML cuando en ellas guarda información en formatos binarios, con códigos de control e incluso dependiente de plataformas concretas. En resumen, debe validar el estándar XML. Office OpenXML no cumple estas condiciones.

NOOOXML.org también se suma a esta lucha, es una página en la que se puede firmar digitamente en rechazo a OOXML, y se puede encontrar material técnico y un historial de la lucha en contra de este formato y de las reuniones de la ISO que ya se han dado con respecto a la aprobación. En dicha página se exponen la siguientes razones:

1. 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;
2. 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;
3. En el documento de especificación falta información como, por ejemplo, cómo implementar un “autoSpaceLikeWord95” o un “useWord97LineBreakRules”;
4. Más del 10% de los ejemplos de su especificación no validan la conformidad con XML;
5. 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;
6. 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);
7. 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 16 bits de la aplicación MS-Office;
8. 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.

NOOOXML.org, en las últimas fechas ha expuesto 20+1 buenas razones para rechazar a OOXML como estándar ISO. De dicha lista expongo las que me parecen más importantes:

• El objetivo de OOXML en ISO es minar la adopción de un estándar ISO ya existente: El evangelista OOXML Mahugh explicó: "Cuando ODF se convirtió en estándar ISO, Microsoft tuvo que reaccionar rápidamente dado que ciertos gobiernos procuran políticas que prefieren estándares ISO. Microsoft, por lo tanto, tenía que apresurar este estándar. ¡Es una simple cuestión de intereses comerciales!"

Como siempre, Microsoft trata de dominar y monopolizar el mercado.

• El texto no está conforme a las reglas para la estructura y borradores de estándares internacionales: El texto es heterogéneo, sin convenciones de denominación, y en muchos casos un mismo término tiene varias definiciones.

• Microsoft reinventa la rueda: No se basa en el uso de estándares maduros existentes, sino que inventa sus propios procedimientos, argumentando ridículamente que no se puede extender los lenguajes XML existentes para sus propósitos, cuando XML por definición es extensible (eXtensible Markup Language).

• OOXML requiere material oculto y con copyright de Microsoft, material que no se ha liberado: Un estándar debe ser abierto. No se podrá hacer implementar de OOXML sin tener que pagar licencias por el uso de dichos materiales.

• El mercado no puede depender de estándares ISO con errores de cálculo: Las fórmulas de hojas de cálculo todavía dan resultados erróneos, por ejemplo la función FLOOR que tiene imprecisiones con números negativos. Es un problema de debe ser cuidadosamente estudiado. Esto es particularmente grave. Las finanzas de muchas empresas y cálculos de variado tipo se llevan a cabo en hojas OOXML de Office 2007. ¿Se puede admitir ese tipo de errores? (recuerden la operación maldita en Excel 2007...)

• La especificación del estándar está escrita en 6000 páginas, lo cual es un exceso para un estándar. Y además, es un infierno buscar algo en la especificación.

Varias grandes compañías como Oracle, IBM, Google y Red Hat expresan su rechazo a la aprobación de este estándar, y vale destacar que ni siquiera se molestan en mencionar la corrupción que rodea a OOXML, sino que se enfocan en los aspectos técnicos. Textualmente, lo dice una cita de Rob Wier de IBM en The Disharmony of OOXML:

"I sometimes hear it said that OOXML, or ODF for that matter, are simply XML serializations of particular applications’ native representations. This is said, seemingly, in an attempt to justify quirkiness or outright infelicitous file format representations. “We had not choice. Office 97 did it that way, so OOXML must as well”. This variety of technological determinism indicates poor engineering judgement, laziness or both.

An easy counter-example is HTML. Does HTML reflect the internals of NCSA Mosiac? Does it represent the internals of Netscape Navigator? Firefox? Opera? Safari? Are any faults in HTML justified by what a single browser does internally? Applications should follow standards, not the other way around.

[…]

What is the engineering justification for this [OOXML] horror? I have no doubt that this accurately reflects the internals of Microsoft Office, and shows how these three applications have been developed by three different isolated teams. But is this a suitable foundation for an International Standard?"

"A veces oigo que OOXMl, u ODF ya que lo mencionan, son simplemente serializaciones XML de representaciones nativas de aplicaciones particulares. Eso se dice, aparentemente, como un intento de justificar la arbitrariedad o las representaciones de archivo indiscutiblemente no aptas. "No tuvimos elección. Office 97 lo hizo de esa forma, así también como OOXML". Esta variedad de determismo tecnológico indica un pobre juicio de ingeniería, pereza, o ambas cosas.

Un fácil contraejemplo es HTML. ¿HTML refleja la estructura interna de NCSA Mosaic? ¿Representa la estructura interna de Netscape? ¿Firefox? ¿Opera? ¿Safari? ¿Son los defectos de HTML justificados por lo que un solo navegador hace internamente? Las aplicaciones deben seguir los estándares, no al revés.

[...]

¿Cuál es la explicación de ingeniería para el horror OOXML? No tengo duda de que refleja con precisión la estructura interna de Microsoft Office, y muestra cómo estas tres aplicaciones (Word, Excel y Powerpoint) se han desarrollado por tres equipos diferentes y aislados. ¿Pero, es eso una cimiento apropiado para un estándar internacional?"

Para terminar, es inconcebible que se pretenda obtener una certificación como estándar para una tecnología tan mal diseñada y con problemas no sólo técnicos sino de patentes y copyright.

¿Qué podemos hacer?

• Como informáticos ecuatorianos, rechazar OOXML y escribir a INEN para evitar un voto positivo a una tecnología mediocre. Información de contacto en este link, recordando mencionar los recursos en que nos basamos para expresar nuestra opinión.
• No sé cuánta utilidad pueda tener esta acción, pero podemos firmar en contra de OOXML en http://www.noooxml.org/petition-es.
• Suscribirnos a la lista de correo de INEN con respecto a OOXML: http://mail.inen.gov.ec/mailman/listinfo/openxml
• ¡Rezar! Rezar porque no se logre comprar conciencias en la reunión de la ISO...

Fuentes:

• NoOOXML: OOXML is not ready to be an ISO standard: http://www.noooxml.org/start
  20 Good Reasons to Dissasprove OOXML: http://www.noooxml.org/open:rejectooxmlnow
• Dile NO al formato de Microsoft Office como estándar ISO: http://www.noooxml.org/petition-es
• OpenXML no debe ser ISO 29500 - ECUADOR => NO (95 coms.):: http://www.openxml.info/index.php?option=com_content&task=category&sectionid=5&id=12&Itemid=24
• Página de Información de Openxml INEN : http://mail.inen.gov.ec/mailman/listinfo/openxml
• Boycott Novell » OOXML Against ODF a Case of Microsoft Against the Rest of the Industry:: http://boycottnovell.com/2008/03/14/ms-spec-vs-industry-standard/
• Red Hat Opposes OOXML: http://www.press.redhat.com/2008/03/13/red-hat-opposes-ooxml/
• Unresolved Technical Concerns in DIS http://odfalliance.org/resources/Oracle%20Technical%20Concerns%20DIS29500.pdf
• Fun With Microsoft OOXML: http://www.kdedevelopers.org/node/3322

Menurut Cerita legenda Masyarakat Gayo Inen mayak dalam bahasa indonesia mempelai atau pengantin wanita. Putri Pukes Dulunya seorang wanita yang berubah menjadi batu karna kawin dengan pria asing dan tidak mau menuruti perintah ibunya.Ibunya berpesan setelah menikah jangan memandang kebakang,karna Putri Pukes memandang kebakang akhirnya Berubah menjadi Batu,Kuburan Suaminya Tidak Jauh Dari Gua Putri Pukes sekitar 1 Km Mendaki.

Semua peralatan Seperti Pisau dan hewan didalam Gua Putri Pukes juga menjadi batu.Kemudian ada sebuah Sumur 3 bulan ber-air dan 3 bulan tidak,Tepat Dibawah Ular yang Menjadi batu Menurut Cerita kalau diliat dengan kamera nampak muka merah itu adalah Penjaga Gua Putri Pukes. See More Photos
Ada sebuah batu yg Dinamakan Batu 1000 Khayalan Karna Kalau dipandang Lama kelamaan Maka Akan Berubah-ubah Bentuk.(Ariga)