Phenobarbital con Soda

Estuve leyendo los comentarios generados luego del BRM para la votación y aprobación de ISO/IEC 29500 (OOXML) y de verdad me he quedado atónito de las recomendaciones que hace ISO para convertir a OOXML en un estandar “util” (y así, inutil y todo, ¿votaron que sí?, que pena hombre!); le queda mucho trabajo a Microsoft, ECMA, ISO JTC1 y el SC34 (además de a FONDONORMA) para poder crear una versión completa e interoperable de este estandar.

Algunos puntos de interés

El NB Alemán (el DIN) propone generar una lista de compatibilidades e incompatibilidades ODF <-> OOXML para lograr una verdadera interoperatibilidad entre ellos; por ejemplo, a la hora de la conversión (aseguro que dicha conversión favorecerá más a ODF si viene de la comunidad de software libre y más a OOXML si viene de Microsoft); que dicha “hoja de ruta de conversión” venga de una oficina del ISO en Alemania permitirá para un futuro mejorar las relaciones entre ambos formatos.

De hecho, aproximadamente 7 Technical Bodies trabajan en distintas partes de la interoperatibilidad de ODF con OOXML (como la construcción de schemas compatibles con DTD) incluso ya ISO/IEC JTC1 SC34 ha iniciado un proceso de evaluación para indicar cual de los formatos responde mejor a un regimen de mantenimiento en el tiempo y que responda eficientemente a pruebas y posea suites que lo implementen; como sabemos, el único beneficiado de esta evaluación será ODF.

Permitiendo la modularidad

Como indiqué en el anterior post; OOXML posee dentro de sí una cantidad enorme de formatos (VML, XAML, SpreadSheetML, OMML, etc); para la mayor modularidad de la implementación; ISO ha solicitado una nueva votación para dividir en 4 la especificación de OOXML:

1.- OOXML en si mismo; todo lo que respecta al nucleo del formato

2.- OPC: el formato de compresión basado en ZIP (si estoy en linux, preferiría bzip2)

3.- Extensibilidad (compatibilidad con otros formatos, esto no existía en OOXML)

4.- Otras características: VML y otros lenguajes (WordML, OMML, etc) y características de migración.

Dentro de esta cuarta categoría se incluyen otros lenguajes de OOXML

Además, se debe forzar a OOXML a ser:

• Compatible con otros estándares ISO
• Usar una Sintaxis Backus-Naur (BNF)
• Se debe obligar a OOXML a usar siempre notaciones IANA/ISO en códigos (colores, nombres, country codes, etc)
• Permitir; por defecto, el uso de medidas ISO (y no formatos de papel anglo; ej. ISO A4 por sobre “US Letter”)
• Uso de formatos ANSI/ISO de fecha y no los personales de Excel
• Definir un sistema de validación basado en schemas (como Relax NG, Schematron o XSD)
• Definir el uso de DTD en sus documentos y la conformación de namespaces para la construcción de documentos complejos (ej.
• <math:derived>
• Sustituir spreadsheetML y OMML por un lenguaje más modular, como MathML y compatible con namespaces, como openFormula
• Excesivas referencias a “vocablos Microsoft” en el motor XML deben ser eliminadas y agregadas solo compatibilidades con la W3C

El nacimiento de un monstruo o el sacrificio del neo-nato

Puede Microsoft (quien despidió a David Robbins en 2004 por no poder modificar su motor XML .NET para hacerlo compatible con estandares) hacer todos estos cambios sin afectar tecnologías ya impuestas (que siguen las mismas reglas de OOXML) como XAML, .NET u otras?.

Puede Microsoft dedicarse de lleno a asesorar al grupo conformado por los NB, comité ISO y ECMA para evitar que su formato se convierta en un monstruo incapaz de manejarlo con sus propias tecnologías?

De plano, considero que si OOXML sigue las reglas fundamentales de crecimiento de todo estandar ISO (como ODF) será algo importante de ver en los proximos años y algo satisfactorio que .NET (y su contraparte Mono) sean ahora más estrictos con las normas de XML y no tan “relajados” y muy a lo “Microsoft-stylish development” (de hecho, ya quiero ver un modulo para silverlight-moonlight que use SVG en vez de XAML como lenguaje de vectores).

Es una tarea titánica lograr hacer funcionar a OOXML según las normas arriba expuestas; es más facil integrar las cosas que le faltan a ODF (pues al menos cumple con las reglas de ISO) que modificar a OOXML; considero que Microsoft comenzará a implementar a OOXML sin esperar estos cambios, causando (otra vez) que sus documentos sean incompatibles y renderizen mal en otras aplicaciones.

Esto es; Microsoft sacrificará a su neo-nato y se quedará con el Draft que metió a ECMA en diciembre del 2006; toda correción subyacente dentro de ISO tardará mucho tiempo en salir como para que Microsoft espere por ellas para empezar a implementar OOXML; es toda una cuestión de políticas de mercado, marketing y venta de licencias y aplicaciones; nada de apertura de estandares, buenas aplicaciones y mejora en la tecnología.

Y lo que viene

ODF inscribirá su versión 1.2 en ISO dentro de poco; como parte de su gradual expansión e inclusión de nuevas características; OOXML posee más de 3000 errores y más de 1000 características que implementar para ser un estandar válido para ser usado seguramente en aplicaciones en un futuro cercano; ejemplo:

No hay forma de determinar (al no existir validación DTD) si tengo un tipo incorrecto de archivo a la hora de abrir el documento, por ende, puedo agregar y ejecutar código malicioso haciendolo pasar por otro tipo de documento sin que existan dentro de OOXML reglas para prevenir esto (sigue Microsoft sin forma de prevenir Virus).

La eliminación de Bitmasks por atributos, es algo que OOXML usa demasiado y no hay una forma sana de corregirlo

Todos los errores de fechas no han sido corregidos …

OOXML debe soportar muchos más algoritmos de cifrado que los impuestos en su draft

Debe abrirse una ventana para la interoperatibilidad entre OOXML y otros formatos (SVG, por ejemplo)

Eliminar todo lo MS-centric (o US-Centric) de las especificaciones y agregar más como: soporte a unicode estricto, control de medidas ISO, soporte a escrituras no occidentales (escritura derecha-izquierda, por ejemplo) y más accesibilidad (para personas con discapacidades).

De hecho ODF agrega muchas características de accesibilidad en su versión 1.1; la industria verá con mejores ojos agregar nuevas características a ODF que corregir los errores y agregar nuevas a OOXML; por lo que OOXML quedará relegado al uso exclusivo de Microsoft y su séquito de seguidores.

Conclusiones

A estas alturas, quien se le ocurra instalar una beta de MS Office 2008 es un completo y cegado fanático Microsoft, de eso no hay duda …

Si Microsoft acepta corregir todas las observaciones, fallas, errores de diseño e implementar mejoras y ampliaciones, no veremos una implementación sana y segura de OOXML sino hasta MS Office 2010 (quien quita si MS Office 2021 jajaja) por lo que MS implementará a como de lugar su “estandar” de la manera como el sabe, “a lo arrecho y a su modo”; este año y el próximo será de evolución de ambos formatos y veremos el nacimiento de un creciente nicho de mercado para las aplicaciones de oficina “No-Microsoft” y un evidente ascenso de los formatos libres; incluyendo ODF.

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 …