¿Es Open XML un buen estándar?
Para aquellos que hoy están metidos en esta discusión, sin duda esta pregunta es tremendamente relevante. ¿Cómo es posible que un país como Alemania, cuna de OSS haya votado que si por Open XML así como ocurrió en Brasil que votó no con comentarios?
Sin embargo antes de tratar de esbozar una respuesta quiero fijar el marco sobre el cual me quiero referir.
Como ustedes saben, hoy la votación en Chile está en manos del INN en su calidad de miembro activo de la ISO. El INN estableció como regla para tomar una decisión al respecto, convocar a todas las instituciones relevantes del país a participar en una mesa de trabajo para discutir el tema. Esta decisión, la cual acatamos, implica que ninguna empresa persona natural podía participar sino que a través de sus representantes. Por lo anterior, debo ser respetuoso de esta institución y no entrar en el debate que ahí está ocurriendo a riesgo de ser imputado como que estamos haciendo presiones indebidas.
Por lo anterior y hasta que no se emita el voto no voy a entrar en la arena chica a discutir las diversas objeciones técnicas que se mencionan en la blogósfera. Una vez emitido el voto, voy al hueso.
Sin perjuicio de lo anterior, existen una serie de consideraciones de procedimientos y de arquitectura del estándar que, a ojos de un lector concienzudo, podrá inferir fácilmente las respuestas a las inquietudes técnicas que se manifiestan. Así que aquí voy:
¿Otro estándar más? Give me a break!
Es sumamente humano pensar que para qué queremos otro estándar si ya tenemos demasiados. Como muestra de esto, en solo XML existen más de 140 estándares de documentos. 141?...no way. Pero , no, ¿valdrá la pena entender porqué existen tantos estándares? Simplemente porque cada cual está inmerso en una realidad distinta y tienen un historia que no puede ser olvidada. Si vemos por ejemplo los estándares que existen en imágenes JPEG (es más, existen al menos tres tipos de JPEG – JPEG, LPEG-LS, y JPEG 2000), PNG, y CGM cada uno de los cuales es un estándar ISO, atienden diferentes necesidades en el mercado. Lo mismo sucede con los lenguajes de Esquema (Schema languages) – RELAX NG (ISO/IEC 19757-2:2003) versus DTDs como fue incluido en SGML (ISO/IEC 8879:1986). El correo electrónico es otro ejemplo – tenemos X.400, SMTP, POP3, IMAP . Porqué no nos ponemos de acuerdo y hacemos uno no más?. Simplemente por dos razones: cada cual tiene sus virtudes que se muestran en los diferentes ámbitos donde se desarrollan y, no menos importante que lo anterior, existe una inmensa base instalada de cada cual por lo que si adoptamos uno, ¿ que hacemos con lo que ya existe?
A la hora de diseñar un estándar tengo dos caminos que seguir: crear un perfecto de laboratorio que describe una realidad idílica pero que no existe. Hacer una pieza de arte, un estándar de laboratorio. Perfecto!. Otro camino sería crear uno que se haga cargo del pasado, del presente y a pesar de ello, pueda enmarcarse en las tendencias del futuro. A este lo llamaría un estándar de mercado pues está inmerso en una realidad de mercado.
OOXML fue diseñado inicialmente como uno de laboratorio pero al pasar por la ECMA, sus miembros exigieron que fuera uno de mercado. ¿Por qué? Pues la mitad de sus miembros son usuarios finales y dos de ellos en particular, son bibliotecas. Las bibliotecas no podían darse del lujo de ignorar la inmensa cantidad de documentos existentes por la sola promesa de tener la “última chupada del mate”. Entonces ahí comenzaron los desafíos. El acuerdo fue el siguiente: todo aquello que diga relación con compatibilidad reversa deberá ser opcional. Y así fue como un documento de unas 2.000 páginas se convirtió en 6.000 páginas: Backward compatibility. Al hacerse cargo de este problema, había que hacerse cargo de definir en las lista de posibles valores, formatos que definitivamente no tienen nada de estándar, como VLM o WMF. Pero nuevamente son opcionales y no son por defecto.
Nice, pero ¿de qué sirve todo esto si las especificaciones de esos binarios no están en el estándar?. Bueno dos cosas, si hoy nos “fríen” por que son 6.000 páginas,¿ qué dirían si este tuviera 20.000 o más? ¿ Cómo se soluciona esto? Igual como lo hacen otros estándares: hacen referencia a ellos y la especificación se busca en la documento del referenciado. OOXML hace lo mismo pero con una diferencia que pone de punta a los “puristas”: se referencia cosas que no son estándares. Algún suspicaz tendrá en la punta de su teclado la siguiente pregunta: “… buena oh!..ahora para poder usar OOXML finalmente tengo que pagarle a Microsoft para que me “suelte” las especificaciones de los binarios!!! …”
No mis amigos, eso ya no es así (lo fue pero no mas). Hoy cualquiera que quiera los estándares los puede pedir y obtiene una licencia indefinida , irrevocable de uso de los formatos para el propósito que desee.
Estimados, ¿ustedes creen, a pesar de lo que traten algunos cabezas calientes hacernos pensar, que la ECMA se habría prestado para eso? La ECMA es un ícono de soberanía intelectual de Europa y los europeos cuando se meten con americanos no andan jugando. Estas opciones incluyen la Promesa de Especificación Abierta de Microsoft (Microsoft’s Open Specification Promise), el Convenio de Microsoft (Microsoft’s Covenant) y una licencia Razonable y No Discriminatoria (Reasonable and Non-Discriminatory (RAND)) libre de regalías.
Ha habido muchos comentarios recientes de que Microsoft y otros miembros del Ecma TC45 deberían haberse unido al Comité Técnico OASIS que trabaja en ODF en lugar de crear otro estándar en Ecma. Pero Office Open XML y ODF tienen principios base de diseño diferentes: Ecma puso gran importancia en la fidelidad del legado existente de documentos Microsoft Office, mientras que OASIS se ha opuesto activamente a cualquier principio de diseño que haga relación a compatibilidad retroactiva con documentos Microsoft Office existentes. Los comentarios hechos por un miembro del TC de OASIS que desarrolló ODF (el Presidente actual de la Fundación ODF, Gary Edwards) son muy claros en que ni Microsoft ni su principio de diseño de compatibilidad retroactiva serían bienvenidos en OASIS en su blog:
“¡No hay manera posible en que ninguna persona pueda reclamar que el OASIS ODF TC de hoy le daría la bienvenida a Microsoft y haría cambios para acomodar la especificación! ¡De ninguna manera! Y la prueba de esta hostilidad puede ser vista en las discusiones actuales y en los rechazos de las propuestas específicas de interoperabilidad de Microsoft.”
Entonces ¿Por qué fue que Microsoft no trabajó simplemente con la gente original de ODF para que le ayudaran a construir su especificación? Bueno yo diría que hay al menos cuatro buenas razones para tomar esta decisión:
1. El alcance de la especificación ODF no incluyó nunca ni siquiera los requerimientos básicos que necesitaba para apoyar un formato completamente abierto – y el comité técnico de OASIS no quería incluir estos requerimientos. Estos incluyen:
a. Hojas de cálculo
b. Tablas en presentaciones
c. Características de accesibilidad para gente con discapacidad
d. Soporte de Esquema de Personalizados (Custom-defined schema support)
e. Personalización de Metadata (Custom metadata)
2. No fue sino hasta el 2005 que la especificación ODF se ofreció como formato de documento general office XML y fue en consecuencia rebautizado ODF.
3. ODF empezó y fue completado en su mayoría como un formato específico XML que soportaba Sun OpenOffice con un alcance cerrado en torno a ese producto.
4. No hubo oportunidad para Microsoft de participar en este proceso dado tanto el alcance original y los 6 meses transcurridos entre que fue rebautizada la especificación ODF y su consecuente aprobación por OASIS como un estándar.
Se debe recordar que el Capítulo del Comité Técnico de OASIS ODF específicamente dijo que los esquemas de Sun OpenOffice eran el punto de partida para todo el trabajo y esquemas, y no fue mucho después que el nombre del Comité Técnico (TC) cambió a “Open Document Format (Formato de Documento Abierto)” u “ODF”. El comité técnico mantuvo un foco muy claro y cerrado para presentar las funcionalidades del producto original Sun StarOffice.
Por más que lo traten los “chicos” de StarOffice, no son lo mismo de Office y menos que Office 2007 ( Works 95, maybe ) por lo que si nos metíamos debíamos volver atrás como 10 años!
Es más, esto fue lo que dijo Gary Edwards, editor de ISO 26300 ODF, cuando respondió a esta cuestión en su “blog ”:
“La membrecía del OASIS ODF TC está clara e inequívocamente en el record a diferencia de la interoperabilidad que el mercado está pidiendo. Los temas de "compatibilidad, interoperabilidad y convergencia", como se describen arriba, han sido llamados por miembros actuales del TC: "fuera de límites", "fuera de alcance", "no nuestro problema", "dejen que los convertidores y transformadores lidien con eso", y "hablen con Microsoft".
¡Si Microsoft quisiera unirse al OASIS ODF TC hoy en día, buscando adoptar ODF para satisfacer las necesidades documentos “legacy” -características propias de MSOffice-integración de línea de negocios de su base monopolística, el TC tendría que lidiar con los mismos problemas que en forma sumaria han rechazado en sus actuales discusiones de compatibilidad-interoperabilidad-convergencia!”
En definitiva, la pregunta si es un buen estándar no se refiere a sí que si es el mejor o que es superior a ODF. No, OOMXL es un estándar más: abierto, completo y libre que por cierto puede y va a ser mejorado que se hace cargo de los miles de millones de documentos que hoy existen en el mercado y los lleva a una plataforma 100% interoperable.
Recordemos que la interoperabilidad no solo dice relación con lo que pueda construir en el futuro sino que tengo que hacerlo con lo que hoy existe. Si no me creen, pregúntele a los de CORBA!
