ISO/IEC 29500 (OOXML) aprobado – sobre el uso de estándares

Ayer se realizó el conteo final de votos del BRM para la aprobación como estandar ISO de 29500 Office Open XML (mejor conocido como Microsoft OOXML) con lo cual la DIS 29500 es ahora, un estandar ISO.

Cabe destacar que ningún estandar de la W3C o del proyecto OASIS (DocBook, ODF, SVG, etc) que tenga que ver con XML ha sido aprobado bajo “fast-track” ni mucho menos con una cantidad tan alta de comentarios no explicados (más de 1000 comentarios quedaron sin responder por parte de Microsoft durante el Ballot Resolution Meeting); basta decir que SVG ha tenido una evolución de más de 4 años de aportes y comentarios y ODF (aprobado en 2006 como ISO/IEC 23600) ha presentado 2 nuevas versiones mejorando sus características en aproximadamente 2 años.

Esta forma de generar estándares contrasta enormemente con VML (Vector Markup Language) el lenguaje de vectores de Microsoft; que desea ser aprobado “de cola” dentro de la aprobación de OOXML sin siquiera pensar en interoperatibilidad con SVG y ahora, ¿Esperan que nuestros proyectos de Software Libre sean interoperables con ellos cuando OOXML no es interoperable ni con DTD, MathML, SVG u otros estandares XML?.

Leyendo el blog de Bureado; es triste que la discusión en el comité espejo ISO JTC1 de Venezuela se haya disipado entre cosas sobre el software libre, ataques personales y lineamientos gubernamentales cuando; de hecho, la discusión se debió centrar en las normas técnicas detrás de OOXML y detrás de todo el esquema de documentos XML generados por Microsoft.

Un estandar para contenerlos a todos

Varias veces y en varios artículos he hecho revisión a esta idea; ODF es un estandar de no más de 800 páginas; ¿Como puede un estandar así contener formulas, tablas, ecuaciones matemáticas, graficos vectoriales, bitmaps, definiciones de estilo y más?; simple!, ¡Porque es REALMENTE interoperable!; puede manejar múltiples estilos porque reconoce a CSS (cascade Style Sheets), puede contener vectores porque reconoce SVG (Scalable Vector Graphics), puede contener bitmaps porque los transforma a un estandar único PNG (Portable Network Graphics), puede contener formulas y ecuaciones porque reconoce MathML; además, puede ser transformado limpiamente a otros formatos libres (Docbook, HTML, etc) ya que reconocemos su estructura gracias a un DTD (Doctype Definition) y podemos por ende; usar XSLT para transformarlo en lo que sea (HTML, PDF, etc); por ende su especificación no tiene por qué crecer hasta las 6000 páginas!.

Es realmente deprimente que un sistema (o motor como suelo llamarlo) de XML de Microsoft no reconozca adecuadamente los tipos más comunes de documentos XML; ya que ni siquiera es compatible con DTD o con algunas formas de XML Schema existentes; por ende, Microsoft debe “re-inventar” los lenguajes arriba expuestos para hacer los suyos propios; veamos:

ODF -> OOXML

SVG -> VML (una vulgar copia, solamente cambia las definiciones CSS por atributos)

CSS -> No posee, redefine estilos usando atributos (como el bendito bgcolor de HTML)

MathML -> SpreadsheetML

PNG -> DrawingML(un bitmap de windows codificado en base64)

XFORMS -> Microsoft Forms ML

Estilos en cascada -> atributos “inline”; cosas como “autoSpaceLikeWord95″ hacen imposible la interoperatibilidad entre aplicaciones.

Una de las características más patéticas del motor XML de Microsoft (usado en .NET, silverlight, OOXML, etc) es su incomprensible uso de DTD o de schemas definidos; la ausencia de CSS en favor de una cantidad inconmensurable de atributos inline en cada elemento (veremos cosas como <br font=”arial”><br font=”arial”><br font=”arial”> en vez de una simple definición css br { font-family: arial }); en algunos casos ni siquiera hay convenciones en la forma de los tags (representación de los elementos) en algunos “estandares” de Microsoft, su nombre es en mayuscula, minuscula, capitalizado e incluso CamelCase (ej:

VML:
<Ellipse CenterX="80" CenterY="80" RadiusX="50" RadiusY="50" Fill="PaleGreen" Stroke="DarkBlue" StrokeThickness="5"/>
SpreadSheetML:
<m:f><m:num><m:mr>a+b</m:mr></m:num><m:den> <m:mr>c</m:mr> </m:den> </m:f>

Veremos cosas como “Center” o “m:num” pero tambien como “StrokeThickness” (mayúsculas, minusculas versus camelcase); veremos un predominio de atributos sobre definición de estilos (CSS):

(La misma elipse, pero en SVG):

<ellipse cx="80" cy="80" rx="50" ry="50" style="fill:rgb(255,229,242); stroke:rgb(242,0,125); stroke-width:5"/>

Fijense en algo importante; en SVG, puedo ejecutar <ellipse class=”elipse_verde”/> y definir cuantas elipses verdes quiera en pantalla; en VML y XAML no puedo, debo colocar el atributo Fill=”PaleGreen” a todas y cada una de las elipses verdes que desee en pantalla; ¿es esto interoperatibilidad con otros estándares? … no creo …

Lo más triste del caso es que TODOS (drawingML, VML, SpreadSheetML, etc) han sido aprobados EN CONJUNTO al haber aprobado OOXML; por ende, ahora tendremos que pelear con formatos XML que se solapan y que hacen las mismas cosas; si el mismo Microsoft tiene hasta  4 formatos distintos para manejar gráficos en XML; ¿como podemos estandarizarnos?; podemos desarrollar soluciones realmente interoperables?

Estaremos igual que antes

ODF ha existido desde hace algún tiempo; y es ISO estandar desde hace 2 años, ¿Alguien ha hecho algo?, ¿FONDONORMA ha evaluado su correspondiente aprobación y traducción como norma COVENIN ISO 23600?; no realmente, y dudo que lo haga en un futuro cercano; de hecho, Microsoft ha creado una serie de estándares que son simple y vulgar copia de otros existentes pero que si son completa y 100% compatibles con sus aplicaciones (de escritorio, de desarollo, etc); este es un “estandar” para satisfacer las aplicaciones Microsoft, su plataforma .NET y para interoperar con sus propias aplicaciones; nadie va a poder crear modos sencillos de interoperar con todas las aplicaciones .NET; es más, si crearemos interoperatibilidad con OOXML (tarda más Microsoft en pensar las cosas que la comunidad de SL en implementarlas); pero Microsoft implementará ODF?, agregará ODF a su lista de “abrir …” en MS Office?, creará formas de agregar SVG a sus documentos OOXML y Silverlight podrá usar SVG en vez de XAML?; todos sabemos la respuesta; ¡NO LO HARAN!; porque OOXML es una satisfacción de mercado, de niño malcriado y no una apuesta por la integración de documentos.

Por ende, seguiremos como estamos, una cuota del mercado de oficina para MS Office; todo el que quiera abrir un ODF tendrá que instalar cualquiera de las aplicaciones que lo abren (Excepto Microsoft Office) y las cosas se mantendrán más o menos como estamos (ej. Adobe seguirá generando SVG como formato de exportación de vectores y dudo que veamos a Adobe Flash aceptando XAML como grafico de vectores); incluso hay sectores de la implementación OOXML en sectores oscuros llenos de patentes que Microsoft no ha develado todavia (ni resolvió los comentarios dispuestos por los NB para este BRM); por lo que una implementación completamente libre y abierta (y lejos del acuerdo “anti-guerra” de Novell-Microsoft) se vislumbra como algo completamente lejano.

Conclusiones

Yo ya habia renunciado a la lucha hace algún tiempo; no me considero el hombre “con la marca del cazador” para cruzar medio planeta y matar un faraón de un lanzazo; 83 National Bodies (NB) del comité ISO JTC1 fueron intervenidos, saboteados o sobornados de alguna u otra forma por Microsoft (como llevar “alumnos universitarios” pero vestidos con camisetas de Microsoft, que patético!) por lo que era una labor titánica el lograr un triunfo contra el actual estandar ISO/IEC 29500 OOXML.

Aun cuando sigo insistiendo que el cambio no va a ser muy grande; ODF y las tecnologías XML generadas por OASIS y la W3C son el futuro (XFORMS2, XHTML2, HTML5, SVG, XDS, Docbook5, etc); OOXML nació (como el mismo Microsoft lo informa y lo admite) no como un estandar “para el futuro” sino como un formato “para lograr preservar para el futuro los documentos creados en las últimas 2 décadas por aplicaciones (privativas como MS Office) que se han convertido en incompatibles y obsoletas debido a los continuos avances en el campo de las tecnologías de la información”.

Al menos admiten que han llegado tarde al campo de los avances de las tecnologías de la información y que OOXML no es más que un intento de rescatar los millones de documentos que el mercantilismo de una compañia ha dejado atrás …

Lo más irónico de todo es caso; es que MS Office 2007 ya no permite abrir documentos viejos (MS 97/2000/XP)(y hay que descargarse un “conversor” de documentos aparte); por lo que ese “gesto de nobleza” de querer rescatar para la posteridad millones de documentos en viejos formatos binarios incompatibles se va por el caño …

Y que pasó con el futuro?

Para finales del 2008 tendremos un ODF versión 1.2 (con grandes dosis de interoperatibilidad, sobre todo en el sector de aislar completamente datos y presentación, además de normas de accesibilidad e integración con MathML); cada uno como dije, representando dos vertientes distintas; una, para mantener un enlace con el pasado y lograr la conversión de documentos de MS Word, MS Excel y MS powerpoint a OOXML; por otra parte, un estandar maduro, futurista; que ha agregado 2 nuevas versiones (1.1 y 1.2) en menos de 2 años, que crece abiertamente y comienza a gozar de gran popularidad. ISO JTC1, comité técnico SC34 debe encargarse ahora de las correcciones a ISO 29500; enviarlas a Microsoft (o a su comité en ECMA) y estos realizar los cambios; en ODF quedan solo mejoras por hacer, en OOXMLquedan más de 3000 defectos por corregir; todos conocemos la velocidad de Microsoft para resolver problemas; todos conocemos la velocidad de la comunidad de software libre en lanzar nuevas soluciones; es solo cuestión de tiempo (y sinceridad de parte de las organizaciones) que la gente se de cuenta de la única verdad posible; OOXML es un “legacy-standard” del pasado; ODF, es el futuro, verás tú donde desees guardar tus documentos importantes …

Acerca de phenobarbital

http://about.me/phenobarbital

Publicado el 2 abril 2008 en Cultura Libre, La soda y la pastilla, Linux, PlanetaLinux y etiquetado en , , , , , , , , . Guarda el enlace permanente. 3 comentarios.

  1. Otra cosa es el descrédito que gana ISO con este hecho. Aceptar un formato que no ha respetado los lineamientos para su aprobación, cuyo proceso ha estado viciado desde el principio le quita seriedad a la organización, además de perder credibilidad y respeto.

    Ahora cualquier cosa puede llegar a ser estándar ISO (si se tiene poder, claro).

  2. La Organización Internacional para la Estandarización o International Organization for Standardization (ISO), es una red de institutos de normas de 157 países, cuya finalidad es la coordinación de las normas nacionales, en consonancia con el Acta Final de la Organización Mundial del Comercio. La ISO es un organismo que no depende de ningún otro organismo internacional, sin embargo, posee vinculación con la Organización de las Naciones Unidas (ONU) como órgano consultivo y coopera estrechamente con la Comisión Electrotécnica Internacional (IEC) que es responsable de la estandarización de equipos eléctricos.

    Cabe destacar que la ISO no tiene autoridad para imponer sus normas a ningún país y que estas normas no constituyen una obligación para el desarrollo de productos y para la seguridad de las empresas. Sin embargo, es claro que las decisiones que toma en torno a la estandarización de procesos de fabricación, comercio y comunicación tienen un importante efecto en el desarrollo e instauración de tecnologías.

    Desde este punto de vista, la ISO tiene la obligación de velar por el desarrollo de un trabajo independiente de los intereses de las empresas y de las industrias que se ven afectadas por sus estándares. No puede permitir manipulaciones de ningún tipo. Si esto llega a ocurrir, la ISO, como organismo, debe responder ante la opinión pública, ante la ONU y ante la IEC.

    Si efectivamente hubo irregularidades en el proceso de estandarización de OOXML (IS 29500) y esas irregularidades son demostrables, es imprescindible que aquellos que cuenten con antecedentes serios los den a conocer a través de la red o a través de los medios de comunicación. La manipulación de una norma de esta naturaleza es un asunto muy grave, concierne a los gobiernos y a todo ciudadano que necesita utilizar formatos electrónicos de documentos, independiente si es o no usuario de ODF o de software libre.

    Normalización en cada país

    Independiente de los vicios que haya tenido el proceso de estandarización de OOXML (IS 29500), son los gobiernos y los organismos de normalización nacionales quienes determinan, en mayor medida, la adopción o no adopción de una norma. Es, por tanto, en este ámbito, donde hay que presionar más fuertemente para defender nuestros intereses como usuarios. En la actualidad, más del 70% de las personas en Chile que utilizan la suite ofimática de Microsoft lo hacen de manera ilegal. Si el formato OOXML, efectivamente, queda relegado a las aplicaciones propietarias de Microsoft, es inmoral y, tal vez, hasta inconstitucional, que el gobierno chileno adopte OOXML como estándar, ya que estaría forzando a los ciudadanos a comprar el producto de una empresa privada o a obtenerlo de manera ilegal. Hay que tomar en cuenta que, cada vez más, contar con estas herramientas para manejar información deja de ser el privilegio de unos pocos, para convertirse en una necesidad de la mayoría, sobretodo si se considera que muchos de los procesos que los mismos organismos de gobierno impulsan requieren del uso de aplicaciones ofimáticas.

    Conclusión

    Que la ISO haya reconocido OOXML (IS 29500) como estándar, no significa, en absoluto, que sea el formato que deben adoptar los países que tienen participación en este organismo, ni tampoco el que debamos utilizar nosotros como usuarios.

    Es importante defender nuestros derechos, y presionar en los ámbitos en los que tenemos influencia, para comunicarnos mediante tecnologías que se adapten a nuestros requerimientos e intereses.

    No porque Microsoft haya logrado posicionar un formato propio como estándar internacional, se ha solucionado la contradicción que hay entre el uso masivo de sus productos y la situación de ilegalidad en que se encuentra la gente por las definiciones de licenciamiento que hace la empresa.

    No porque Microsoft haya conseguido dar reconocimiento a OOXML, este formato ha pasado a ser una mejor opción que ODF. De hecho las aplicaciones basadas en ODF pueden llegar a beneficiarse si dan la posibilidad de mejorar la importación y exportación de los productos Office de Microsoft. Además de ser gratuitas, de código abierto, con archivos más estables y más livianos, sin problemas de licencias para las empresas y para los usuarios, serán más compatibles con los documentos que ya existen y que manejan la mayoría de las personas.

    Por último, si se llega a demostrar que el proceso de estandarización de OOXML ha sido irregular, no sólo veremos como la la ISO, una institución de reconocimiento mundial, se hunde en el desprestigio, sino que probablemente seremos también los espectadores de la manera en que se desploma un dinosaurio (Microsoft), que está dando sus últimas sacudidas antes de desaparecer junto a un modelo de negocios y junto a un paradigma de sociedad.

  3. En efecto, no pongo en duda que alguien esté obligado a tener que seguir las normas de la ISO; de hecho, nunca he peleado en el campo de los derechos del software libre con respecto a este tema (pero si en otros temas); con respecto a OOXML me he dedicado más a la crítica técnica; ya no es de extrañar que se indique que son estandares ISO algunas bobadas de empresas; pero OOXML con sus 6000 páginas y sus 4 sub-formatos (además del core ooxml) aprobados subterfugiamente y de plumazo porque iban de brazos del papá es como una inmensa distorsión al mecanismo legal que posee la ISO; es como que ODF hubiera “abrazado” a SVG, mathML, PNG, SMIL, XForms y todos hubieran convertido en ISO de un solo plumazo al aprobar ODF.
    En el artículo siguiente a este post agrego la infinidad de detalles técnicos que se deben solventar para que OOXML sea un estandar de calidad; aprobado o no, no posee la calidad necesaria y veremos como las cosas no se van a mover mucho de como estamos ahora …
    Aunque en un futuro a mediano plazo, veremos como ODF ganará terreno en aquellos espacios donde se pueda comenzar a migrar de MS a suites de oficina libres …
    Esto vendrá de como en un futuro las personas se defenderán de la imposición tecnológica …

    Muchas gracias por tu comentario, le ha agregado todo lo que le faltaba al artículo …

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: