Y las cosas que debe hacer ISO/IEC 29500 (OOXML) para hacerse “util”

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.

Acerca de phenobarbital

http://about.me/phenobarbital

Publicado el 2 abril 2008 en Cultura Libre, La soda y la pastilla, Linux, PlanetaLinux, Política. Añade a favoritos el enlace permanente. Deja un comentario.

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: