[Openxml] ¿Es Open XML un buen estándar? ... CLARO QUE SI

Mar Ago 28 14:34:58 ECT 2007

Estimados/as miembros del comité DIS-29500:

Me permito transcribir un artículo muy interesante, que aclara muchas de las inquietudes y preguntas dadas en este foro.
¿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!

Link de donde se tomo el artículo: http://blogs.technet.com/joseantoniobarriga/archive/2007/08/24/es-open-xml-un-buen-est-ndar.aspx

Saludos

Ing. Alvaro Villalba

Consultor Soluciones Informáticas

(593 9) 8 128 – 061

alvillalba en yahoo.com

____________________________________________________________________________________
Be a better Heartthrob. Get better relationship answers from someone who knows. Yahoo! Answers - Check it out. 
http://answers.yahoo.com/dir/?link=list&sid=396545433
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: http://mail.inen.gov.ec/pipermail/openxml/attachments/20070828/85c5279d/attachment-0001.html