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

Mar Ago 28 15:19:53 ECT 2007

Esto no responde a ninguno de los argumentos técnicos planteados.

El mar, 28-08-2007 a las 12:34 -0700, Alvaro Villalba escribió:
> 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
> 
> 
> 
> 
> ______________________________________________________________________
> Got a little couch potato? 
> Check out fun summer activities for kids.
> _______________________________________________
> Openxml mailing list
> Openxml en mail.inen.gov.ec
> http://mail.inen.gov.ec/mailman/listinfo/openxml