miércoles 26 de marzo, 2008

Chile y OOXML: Microsoft Responde

Personalmente, creo que dentro de toda las tácticas desplegadas por Microsoft para abogar por la estandarización de OOXML, el que sus empleados escriban artículos en sus blogs es una de las que aporta más positivamente a esta discusión. Y en ese sentido, los artículos de José Antonio Barriga, CTO de Microsoft Chile, son más que bienvenidos. Lo que no lo es, sin embargo, son las imprecisiones y, francamente, errores garrafales en su respuesta a la posición de rechazo que emitió la DCC de la Universidad de Chile. Como dicen por ahí, todos tenemos derecho a nuestra opinión, pero no a los hechos objetivos.

La bien argumentada posición de la DCC y la respuesta de Barriga son, combinadas, extremadamente largas, así que me disculpo de antemano por violar todas las reglas de los blogs de buena crianza por lo extenso de este artículo, pero acá van, comentados (la posición de la DCC en itálicas, la respuesta de Barriga, y mis comentarios en negrita):

DCC: a) El proceso que se ha seguido dista mucho de haber sido realizado con la profundidad técnica que una decisión de este tipo requiere. Es patente que ningún miembro del Comité estudió las más de 6.000 páginas que contiene la propuesta de estándar. Esta aparente desprolijidad es una consecuencia previsible de la decisión de los proponentes de apurar la discusión (Fasta Track), que fuerza a tomar una decisión en pocos meses.

Barriga: La argumentación arriba mencionada muestra una absoluta desinformación de cómo son llevados a cabo los procesos de revisión de normas en el seno de la ISO. ISO toma resoluciones de una manera colegiada en la cual, la suma de las partes revisadas por todos sus miembros dan la garantía que la totalidad de la norma fue revisada. En el caso chileno, se levantaron 217 observaciones que fueron parte de las 3.500 que se levantaron nivel mundial. Nadie puede reclamar que estas 3.500 observaciones no corresponden a la más acuciosa revisión que jamás se le haya hecho a norma alguna. Tal como lo señaló el propio representante de la Free Software Foundation, Oscar Valenzuela, en el Comité Espejo, ellos contaban con un equipo de 50 profesionales dedicados full time a revisar a profundidad la norma y encontrarle los errores más pequeños que se pudiera decir. Baste con ver el comentario CL 126 donde se menciona un error a nivel de un pixel corrido en un Word Art!

Barriga reconoce – implícitamente – que ni el ni nadie más en el comité espejo se leyó las 6000 páginas del documento que debía aprobarse. Y el que el proceso sea «colegiado» no tiene nada que ver con esto: evidentemente, es de esperar que lo mínimo que haga un comité que esta estudiando aprobar una norma es leérsela. El que se hayan encontrado 3.500 observaciones en la primera fase no significa que no hayan muchos más errores. Y como sabe (o debería saber) Barriga, varios de los comités nacionales que fueron a Ginebra tenían muchas otras observaciones que no pudieron presentar porque, francamente, más de 1000 comentarios demostraron ser bastante trabajo para una semana.

El tiempo que ha existido es más que suficiente para hacer un análisis acucioso si uno se dedica a esto. Si la gente no tiene tiempo, ¿es culpa del proceso o de las personas? Un caso para tomar en cuenta. Chile, después de la votación del 2 de septiembre, se juntó 13 veces. Brasil solo 2. Principal argumento de Brasil, no hay tiempo. A ese ritmo, concuerdo 100% que no alcanza el tiempo.

¿Hubo suficiente tiempo entre que Chile se incorporó como participante al comité de la ISO a finales de Agosto y el voto del 2 de Septiembre, cuando – Barriga lo sabe bien – su empresa casi consiguió un voto afirmativo de Chile sin ni un minuto de estudio?

¿Hubo suficiente tiempo en los cuatro meses donde Chile estudio solo sus propios comentarios, ignorando los miles de comentarios de otros países, en violación de las instrucciones de la ISO?

¿Será por el exceso de tiempo que el BRM en Ginebra tuvo que terminar con un voto para aprobar en masa más de 800 comentarios (+80% del total) que jamás fueron discutidos, y aún así apenas 5 de los 32 países asistentes – entre ellos Chile – votaron por esta ridícula medida que significo aprobar cambios por secretaría?

Si la Universidad estimaba que no existía el tiempo suficiente para realizar una revisión acusiosa al nivel que ellos esperaban, debieron haberlo manifestado al momento de iniciarse las reuniones y en el peor de los cosas, haberse abstenido de participar. La ratificación por parte de la Universidad de Chile del reglamento de las sesiones del Comité Espejo el 16 de noviembre, es un reflejo de que el tiempo de análisis no era una objeción en ese momento.

La lógica de esto es insólita (me causa estupor, diría alguien): Microsoft, a pesar de las múltiples solicitudes desde múltiples instituciones a que por favor no usara el mecanismo de «vía rápida» para intentar estandarizar un formato de 6000 páginas en unos pocos meses, decide insistir y, cuando aún así instituciones participan en el proceso, ¿es culpa de ellos que no hubo suficiente tiempo para lidiar con la especificación? ¡El mundo al revés!

De más esta decir que el reglamento del comité espejo se formó con la idea de revisar los 217 comentarios de Chile, no la pregunta, más general, de la viabilidad del estándar en sí. De hecho, las actas muestran que cada vez que alguien trato de expandir la discusión, esos esfuerzos no llegaron a ninguna parte (eso, sin embargo, es tema para otro día).

DCC: b) La inconveniencia de apurar la estandarización de un producto a un inmaduro quedó en evidencia en la reunión BRM (Ballot Resolution Meeting) de Ginebra el pasado febrero. En ella sólo fue posible discutir técnicamente menos del 20% de las observaciones hechas por los distintos países.

Nuevamente, la aseveración anterior muestra un desconocimiento absoluto de lo que es el proceso de estandarización de ISO y en especial el BRM y lo que se estaba discutiendo en él. El proceso de ISO esta compuesto por una serie de normas a las cuales los participantes y proponentes se someten, independientemente de si gustan o no. En la misma reunión del BRM con 29 votos a favor y solo 2 abstenciones, se acordó qué se iba a votar y con qué modalidad: Lo que se iba a votar en bloque eran aquellos comentarios que cada Comité Espejo en su seno había aprobado. En el caso Chileno eran 214 de 217. Lo mismo con los demás países. Lo que se discutió fue justamente aquello que no había consenso en cada Comité Nacional y que una cantidad sustancialmente menor. Se discutió y votó quedando solo 16 observaciones rechazadas.

Claramente, Barriga no ha discutido el BRM con Carlos Recabarren, Presidente de la CCE y representante del comité espejo en Ginebra. Como comenté en este mismo espacio, Chile – junto con un número pequeño de países – votaron, como bien dice la DCC, por no discutir 80% de los comentarios, y aprobarlos «en bloque». Repito: Chile voto por aprobar más de 800 comentarios (muchos más que los presentados por «nuestra» delegación) sin haberlos discutido.

DCC c) Los temas relativos al contexto nacional chileno fueron escasamente tratados en las reuniones del Comité chileno, sobre todo debido a la premura del tiempo por responder comentarios técnicos propios de la propuesta.

Barriga: La Universidad de Chile se marginó de la primera etapa de este proceso que duró 6 meses. En ese período se encargó un estudio en derecho sobre la legalidad de la norma respecto a las normas chilenas que norman el uso del documento electrónico. Igualmente, la Cámara de Comercio de Santiago entregó un informe sobre la conveniencia de contar con un Estándar con OOXML en el concierto de la economía Chilena.

Escaso, por supuesto, no es lo mismo que «inexistente». Hay harto más que discutir que algunos aspectos legales limitados. Y según entiendo (no he podido encontrar la presentación), el informe de la la CCS tenía que ver con la conveniencia de tener un «estándar XML» en el concierto de la economía chilena. Pero eso ya existe, y se llama ODF.

DCC: 2. Las características técnicas de la propuesta OOXML

1. Interoperabilidad. Es la capacidad que permite a los sistemas heterogéneos comunicarse y operar entre sí.

a) Este es un tema crucial para ISO en la estandarización de datos. La propuesta presentada está lejos de satisfacer este requerimiento, debido a uso de múltiples funcionalidades que no son estándar (ej. fechas, fórmulas matemáticas, referencias).

Barriga: No entendemos esta aseveración de la Universidad de Chile pues el 100% de los problemas que sí presentaba la norma fueron modificados a plena satisfacción de las mismas recomendaciones que la propia Universidad de Chile hizo en el proceso. De hecho, el Comité Espejo acogió y aprobó estas recomendaciones -según consta en las actas publicadas en el sitio de la Cámara de Comercio Electrónico- con la aprobación de la Universidad de Chile. La casa de estudio sólo voto en contra de 1 observación que no consideró apropiadamente respondida, pero finalmente participó en un voto de minoría.

Es más, estos temas fueron tratados a profundidad entre los profesores del Departamento de Ciencias de la Computación y una eminencia mundial en este campo como Jean Paoli, co-autor de XML y OpenXML en las dependencias de la misma casa de estudios.

Es decir, el punto de la DCC es completamente correcto. Y esto lo hemos comentado hasta el cansancio: uno de los problemas centrales con OOXML es que reinventa la rueda, utilizando tecnologías poco probadas en vez de estándares internacionales ya existentes.

Y sobre la respuesta de Barriga, es improcedente porque el comité espejo, respondiendo a una moción de la CCE respaldada por Microsoft, se REHUSO a considerar temas de armonización (es decir, de considerar si otros estándares ISO ya cubrían la funcionalidad de OOXML) como parte de las tareas del comité (ver el acta del 23 de Noviembre [PDF]). Con eso, se dificulto la discusión sobre el uso de funcionalidades no estándar en OOXML. Copio del acta:

6.3. No obstante lo anterior, el Sr. Enrique Onetto [de IBM] comenta que la comparación entre normas tiene el mérito de evaluar posibles problemas de interoperabilidad que los productos derivados de ellas tendrán, de manera que si la norma en análisis tuviera observaciones que atentan contra dicha interoperabilidad, es atendible revisar desde esta perspectiva la norma.
6.4. El Sr. Wilson Pais [de Microsoft] indica que las observaciones contenidas en el grupo de “Harmonization” están comparando un producto contra una norma, lo cual es improcedente.

DCC: b) No hay consenso, aun después del BRM de febrero, que la traducción del formato binario de Office a OOXML este documentado. Esto es esencial para que otros desarrolladores puedan recrear el formato original.

Barriga: Definitivamente nunca va a ver consenso pues OOXML no mapea formatos Binarios por dos razones básicas:

  • OOXML fue diseñado para proveer compatibilidad con archivos binarios a nivel de Funcionalidad y no a nivel de archivo. OOXML es XML (ver punto siguiente) y lo que se busca es poder representar en XML lo que se puede representar en un archivo Binario versiones Office posteriores de Office: el archivo Binario se lee con Office y el resultado se guarda en OOXML.

  • Uno de los comentarios más fuertes que se tuvo sobre la versión de OOXML entregada por ECMA es que contenía mapeo a formatos binario y eso era inaceptable para XML. ECMA aceptó esto y procedió a sacar cualquier vestigio de Binario de OOXML (aunque lo que había no eran binarios, pero eso es harina de otro costal). Luego OOXML NO tiene binarios.

Lo confieso, no entendí el argumento de Barriga: ¿»vestigio de Binario»?¿»NO Tiene binarios»? Creo que la DCC esta hablando de peras (mapeo de un formato a otro), y Barriga de manzanas (bitmaps). Sería bueno que si Barriga lo tiene, muestre el «roadmap» para mapear de un formato a otro, que es el tema que esta mencionando la DCC.

DCC: c) La extensiva y compleja documentación (más de 6.000 páginas; comparar por ejemplo con las 40 páginas del estándar XML) hace muy difícil extender y desarrollar aplicaciones que interoperen con este formato.

Barriga: Cualquiera que haya programado en la vida sabe perfectamente que no es necesario y tal vez nunca lo haga, leer todo el manual. Es como decirle a alguien que si quiere usar OpenOffice (para no herir susceptibilidades) debe leerse el 100% del manual si quiere escribir una carta. O si quiero hacer un programa en C++ debo leerlo entero para hacer un programa. Si uno es relativamente prolijo, se lee la introducción y el Getting Started. Luego, a medida que me voy enfrentando a problemas, leo la sección del manual que habla sobre lo que estoy preocupado. La argumnetación del DCC cae en algo tan obvio o grotesco como lo siguiente: si estoy haciendo una aplicación para Word, para qué tengo que leerme lo que dice relación a Excel y PowerPoint. Y si estoy viendo cómo grabar un archivo, ¿para qué me tengo que meter en la incrustación de WordArts?

De hecho, la argumentación de la DCC es correcta y la analogía de Barriga esta claramente equivocada: es evidente que no necesito leerme el manual de OpenOffice para escribir una carta, o la especificación de C++ para escribir un programa. Por supuesto, pero ese no es el tema. No se trata acá de escribir cartas o programas en C++, pero de programas que puedan procesar esas cartas o programas. La diferencia es gigantesca.

«Cualquiera que haya programado» (y si, yo soy uno de esos) sabe que si uno desea escribir un programa que pueda leer cualquier carta (un procesador de texto), o ejecutar cualquier programa en C++ (un intérprete), la tarea requiere un especificación (un manual) de excelente calidad. Si no, ¿como va a poder un programa «implementar» un formato, o un intérprete que pueda «compilar» un programa? Por suerte, nos dice Barriga:

Claramente este comentario está absolutamente fuera de la realidad. Lo que sí es real, es que la norma es completísima y aquellas partes que no lo eran, ahora, por el mismo proceso de la ISO ser completaron. Ahora se van a agregar páginas, no quitar.

Así es, vienen más páginas en camino. Sálvese quien pueda.

El argumento de comparar una especificación con XML, es llevar la argumentación al extremo de la falacia. XML es la sustancia con la cual se crean los vocablos o esquemas, donde OOXML es uno. Estos esquemas van a ser más extensos en tanto en cuanto mayores sean las funcionalidades que ellos deban representar en el subset definido por XML. ODF tiene más de 2.000 páginas. Por ejemplo, lo que dice relación solo a Excel tiene 1.095 páginas. ¿Cuántos libros de cómo usar Excel son de mucho más de 1.000 páginas? La especificación de PowerPoint es de 265 páginas.!!! Creo que ni un libro de PowerPoint for Dummies tiene tan pocas páginas.

Este es un buen punto. OOXML debería ser comparado a un estándar como ODF, que cuando fue aprobado por la ISO, tenía aproximadamente 700 páginas. 700 vs. 6000. 6000 antes de las correcciones, digo. Porque se van a a agregar páginas.

DCC: d) Los temas legales de licenciamiento han sido objeto de muchas críticas debido a su falta de precisión. La insertes sobre si se ha cruzado una línea legal o no también desalienta las implementaciones alternativas.

Barriga: Realmente no entendemos esta aseveración. Simplemente nos remitimos a lo que plateamos al principio. La ISO es una organización de estándares, cuyo prestigio y seriedad no está en duda, pues por la misma razón, todos hemos acudido a ella como ente para que regule y norme estos estándares. Pues bien, la propia ISO, en su proceso de aceptar la norma ECMA 376 para convertirse en un estándar ISO, descartó , previa revisión, que esta norma tuviera cualquier problema de propiedad intelectual que se le exige a cualquier otra norma ISO.

Si dudamos de la claridad y seriedad de ISO en este aspecto tan relevante, ¿porque no dudamos cuándo ODF o PDF entraron a la ISO?

Está bien claro que después de las brutales manipulaciones a las que Microsoft ha sometido el proceso de estandarización en la ISO, el «prestigio y seriedad» de esta organización ha quedado bastante en duda. ¿Será por esto que la Unión Europea esta investigando las acciones de Microsoft en los comités espejo del viejo continente?

Sobre la pregunta de Barriga, no hay dudas sobre el status legal de ODF porque las condiciones de licenciamiento de este formato permiten que sea implementado por cualquier programador independiente. Un estudio reciente sobre la licencia de OOXML, sin embargo, que las garantías que ha entregado Microsoft para la implementación del formato de Office son insuficientes.

La ISO, cuando acepta una especificación para su posible estandarización, no revisa si la tecnología esta sujeta a patentes, o si estará a disposición de todos sin costo, o, por supuesto, si las licencias son compatibles con el uso de los estándares en código abierto. Es por eso que ODF dá más garantías que OOXML. Nada de patentes, nada de costos, y se puede implementar con programas propietarios y de código abierto.

DCC: e) Para nuestra comunidad local, el determinar cómo armoniza cualquier propuesta de formato de datos con el decreto de firma electrónica y el Decreto 81 sobre interoperabilidad documental en Chile, es un aspecto crucial, que no se alcanzó a discutir en el proceso.

Barriga: Nuevamente, nuestra sorpresa es mayúscula. Tal como se mencionaba anteriormente, la Universidad de Chile se marginó de la primera etapa de este proceso que duró 6 meses. En ese período se encargó un estudio en derecho sobre la legalidad de la norma respecto a las normas chilenas que norman el uso del documento electrónico. Sin perjuicio de lo anterior, este informe estuvo disponible a todos los miembros del comité y fue sometido a escrutinio en el subcomité de propiedad intelectual, al cual por cierto, a pesar de estar invitados no se excusó de asistir el representante de la Universidad de Chile.

Barriga debería saber muy bien que el citado es «un estudio jurídico y no técnico». Es decir, en ese documento jamás se evaluó si OOXML era técnicamente compatible con la legislación existente. ¿Se puede decir más claro?

DCC 2. Modularidad. Es la capacidad de un software de ser tratado como un sistema coherente de varias partes independientes entre sí.

DCC: a) La propuesta carece absolutamente de modularidad. Esto es particularmente notorio en la dificultad para reemplazar formatos obsoletos por funcionalidades ISO estandarizados (por ejemplo fechas, formulas matemáticas, algoritmos de seguridad, algoritmos de cálculo, etc.). Los editores optaron por agregarlas junto a (no en vez de) las antiguas no recomendables.

Barriga: Los problemas que se señalan fueron corregidos a completa satisfacción de lo solicitado por nuestro comité y la comunidad mundial de la ISO. No se logra entender porqué se insiste en quedarse con la primera versión de la norma como si todo el trabajo de corrección que hizo en estos últimos meses no hubiera existido. Todas las funcionalidades donde se pidió usar una norma ISO fueron acogidas y las partes obsoletas fueron sacadas de la especificación y colocada en un capítulo aparte para especificaciones Transitorias.

¿En serio? Sr. Barriga, ¿OOXML usará el estándar MathML para representar ecuaciones? Porque según el representante del comité espejo griego, esto no es así, y OOXML seguirá usando OOML, una especificación creada especialmente para OOXML, para muchos documentos. ¿Quién tiene la razón?

Lo increíble de la maratón que fue el BRM es que de hecho terminó en dos estándares: uno «transicional» para documentos existentes, y otro «strict» para documentos nuevos. Pague uno, llévese dos.

DCC b) La experiencia demuestra que la alta complejidad de las especificaciones no modulares tiende a producir una sola implementación (la del autor de la propuesta). En consecuencia, la adopción de formatos con este tipo de deficiencia puede limitar seriamente el desarrollo de la industria de software en Chile.

Barriga: Totalmente de acuerdo en la premisa y en la conclusión siempre que una norma carezca de modularidad, cosa que por cierto no es lo que hoy tenemos en OOXML luego de 1 año de trabajo en ISO sobre ella. Es verdad que en ese año muchos se dedicaron a reclamar que no tenían tiempo para trabajar, pero hubo un grupo no menor, encabezado por la FSF e IBM que revisaron al máximo nivel de acuciosidad la norma. Nosotros como Microsoft no podemos estar más agradecidos pues el producto que salió de este proceso es infinitamente mejor que la que habríamos pensado.

Y la FSF, IBM, Google, y un número importante de países, después de esa breve revisión (ya sabemos que ODF tomó más de 2 años y medio de estudio por parte de OASIS, y fue aprobada en forma unánime por la ISO), llegaron a la conclusión de que OOXML debe ser rechazado como estándar.

DCC: b) La experiencia demuestra que la alta complejidad de las especificaciones no modulares tiende a producir una sola implementación (la del autor de la propuesta). En consecuencia, la adopción de formatos con este tipo de deficiencia puede limitar seriamente el desarrollo de la industria de software en Chile.

3. Aspectos rescatables. De estandarizarse correctamente una propuesta de este tipo, Microsoft debería hacer pública la documentación de los formatos usados en las suites Office. Esto debiera acompañarse de la apertura de licencias correspondientes. Estas acciones al menos en principio permitirían a otros productores de software que no sean MS desarrollar aplicaciones para intercambiar datos con esos formatos.

Adicionalmente, se conseguiría la existencia de un estándar para la documentación legada que está en esos formatos (MS Office).

Barriga: Microsoft ya hace lo que señala la Universidad. Es más, esto ocurrió justamente a recomendación de ISO para poder entrar al proceso. La documentación está publicada en la página web de Microsoft y en la de la Biblioteca Nacional de Inglaterra (Miembro de ECMA). La publicación lleva consigo todos los temas de propiedad intelectual en las cuales, básicamente, los igualamos a los de OOXML. Nos causa una extrañeza profunda este comentario, pues esto fue profusamente analizado y discutido en las reuniones del comité y subcomités, además de ser expuesto a los profesores del DCC por Jean Paoli en forma particular y por Nick Tsilas en forma general a todos los miembros del comité. ¿No lo escucharon o no quieren escucharlo?

Buen punto. De hecho, la publicación de la documentación de los documentos binarios realizada por Microsoft y forzada por el proceso de estandarización de OOXML es una excelente noticia.

¿Qué busca el DCC? ¿Por qué quieren causar tanto daño? ¿Qué les hemos hecho para que nos traten de esta forma? Si tan mal piensan de nosotros, ¿por qué aceptan trabajar con nosotros en proyectos de mutuo beneficio?

Si por «daño» se refieren a evitar que una pésima especificación se convierta en un estándar internacional, esperemos que haya mucho «daño» más.

 

~

18 Comentarios »

  1. Qué buen trabajo Carlos, gracias.

    Quisiera agregar que Oracle también recomienda rechazar el estándar.

    Saludos.

    Felipe Sologuren — 26 de marzo de 2008 @ 10:10 am
  2. notable el post Carlos, muy buen análisis.

    la verdad, creo que a estas alturas se puede esperar cualquier cosa de los de Microsoft. todo el mundo sabe que sus prácticas en este proceso han sido, digamos, «poco decorosas» (por decir lo menos). los tipos se han burlado olímpicamente de todo el mundo, con esta maquiavélica obsesión por que se apruebe el OOXML.

    y es lógico que ellos lo tienen clarísimo.

    a propósito, ¿supieron la última, lo que pasó con Cuba?

    tomás pollak — 26 de marzo de 2008 @ 10:43 am
  3. […] ACTUALIZACIÓN: Extendiendo (literal y metafóricamente) la discusión, Carlos ha presentado su requetocontra-argumentación. Esto va tomando ribetes dramáticos. Ojalá se hubiera dado en un foro en persona… […]

  4. Excelente lectura para esta mañana, carlos. Muchas gracias por este post clarificador. ;)

    Carlos Riquelme — 26 de marzo de 2008 @ 12:50 pm
  5. Gracias por el articulo. A veces parece que Microsoft no lee los diarios o sus empleados no se informan de las contiendas legales que su empresa enfrenta por su actitud global de marketing. ¿Les bloquearán la internet?

    See no Evil, Hear no Evil, Talk Evilly.

    Freddy de la Cruz M. — 26 de marzo de 2008 @ 1:03 pm
  6. En parte entiendo al Señor Barriga (no al que le cobra la renta a Don Ramón, sino a este otro), por ejemplo, no es correcto comparar XML, con solo 40 paginas, versus las 6000 de OOXML, son dos cosas que no son comparables semánticamente, creo que hay algunos argumentos del dcc en ese estilo, bien poco rigurosos.

    Por otro lado creo que no es relevante la extensión del estándar, porque eso se puede suplir de dos maneras: poniendo mas gente a analizar la propuesta, o aumentando el tiempo para analizar el mismo.

    Lo malo es el proceso (fast track), no que OOXML sea un documento extenso (se me ocurren ejemplos de estandares que serían tan grandes como OOXML, por ejemplo, Java J2EE, y al parecer SQL es un estandar de más 4.000 paginas).

    Efectivamente, si OOXML hubiera incorporado estándares previos (como MathML) en vez de crear unos propios (en realidad, incrustar productos de Microsoft) el documento sería menos extenso, y en este sentido el argumento de modularidad esgrimido por el DCC es muy relevante. Pero hay que entender las intenciones, mantener una compatibilidad hacia atrás.

    Ahora, sobre el asunto de tener dos estándares, me parece interesante lo que dice Durusau:

    «..one very fundamental fact about markup vocabularies, a fact that both OpenDocument and OpenXML share. Both are semantic claims about the representation of documents and as such, neither one is either true or false but at best can be claimed to be useful for some purpose. »

    y además cita una norma estándar que dice:

    «There is no single DTD which encompasses any kind of absolute truth about a text, although it may be convenient to privilege some DTDs above others for particular types of analysis.»

    Aparte de estas consideraciones, ¿qué opinión te merece la posición del editor de ODF? que ha escrito bastante y tiene una posición a favor de aprobar OOXML, incluso considerándolo beneficioso para ODF:

    http://www.durusau.net/

    Saludos.

    Eduardo Diaz — 26 de marzo de 2008 @ 1:32 pm
  7. Las concecuencias para la reputación de Chile, en este melodrama son preocupantes. ¿Cómo estamos quedando frente a la comunidad internacional? Este punto les tiene sin cuidado a Microsoft. Ellos solo quieren ganar. Por eso su fuerte loby, aun a costa de mostrarnos a nosostros como unos putos vendidos. Típico de las grandes corporaciones.

    Andrés — 26 de marzo de 2008 @ 2:06 pm
  8. Muy bueno el artículo Carlos, pero estoy de acuerdo con el comentario de eduardo diaz en cuanto al tamaño del estándar. El tema no es que la especificación tenga 6000 páginas (para comprender ODF se necesita leer un poco más de 4000 páginas de distintas especificaciones) sino la poca modularidad. Al no reutilizar estándares preexistentes, se hacía necesario leer cuidadosamente todo el material para validarlo y si a esto le sumamos la gran cantidad de errores editoriales, la tarea se complejizaba aún más.

    @eduardo diaz, el tema del soporte al legacy me parece una mala excusa en varios casos. Por ejemplo, no es necesario representar las fechas en el formato propuesto, basta que la aplicación traduzca de ese formato a ISO-8601, no hay pérdidas de información en el proceso. Lo mismo se aplica para los códigos de países y representación de colores. Tampoco era necesario incluir mecanismos de encriptación obsoletos.

    thermosilla — 26 de marzo de 2008 @ 10:18 pm
  9. Hola a Todos,

    @felipe: asi es. y varios mas.

    @tomas: lo de Cuba parece accidente, pero es rarísimo que no se hubiera sabido antes. ¿Muy ocupados disfrutando de la playa y el baile para preocuparse de estos geekismos?

    @andres: «Por suerte»… Chile no fue, ni lejos, el peor ejemplo de las irregularidades. Estamos ahí en el medio, diria yo.

    @eduardo: Tal vez me salió con sarcasmo, pero lo de «es un buen punto» era completamente sincero, y estoy de acuerdo con que comparar las 40 páginas de XML con OOXML no corresponde. La comparación con ODF si es mas relevante. Y también es relevante (y esto es comentario para @thermosilla) es cuantas de esas 6000 paginas son funcionalidades que ya son provistas por otros estándares, como bien dices tu, y que OOXML está reinventando.

    Por otro lado, el que la propuesta sea tan larga pone en duda que el proceso de «vía rápida» sea el adecuado, a menos que sea de excelente calidad. El BRM dejo clarito que esto no es así.

    Sobre lo de Durusao, solo te puedo decir que respeto su opinion como las de otra gente (de Icaza, etc) que estan del lado de los estándares abiertos y han decidido apoyar a OOXML. Pero ojo que son sus opiniones personales, no sus opiniones profesionales como editor de ODF. Gran diferencia (y se nota en los argumentos, que no son, en su mayoría, técnicos).

    Saludos.

    Carlos — 26 de marzo de 2008 @ 10:57 pm
  10. Excelente… Siempre se puede responder, requeteresponder y contrarequeteresponder… Notable síntesis de ideas en cualquier caso.

    Matias — 26 de marzo de 2008 @ 10:58 pm
  11. Gracias por tu respuesta Carlos, por supuesto que los argumentos de Durusau son personales, pero bastante sólidos hay que decirlos. Estamos de acuerdo en que probablemente más que el estándar, lo peor es el proceso, y el comportamiento escandaloso de MS.

    Eduardo Diaz — 27 de marzo de 2008 @ 10:31 am
  12. Estimados, han pensado que es lo que pasa si IBM que es el impulsor de la politica anti OOXML queda sola? ustedes creen que ellos les van a agradecer? Acuérdense que la política de IBM siempre fué un monopolio que usa y abusa de incautos. tanto se habla del ODF pero el ODF que se usa hoy no es el mismo que fué aprobado por la ISO. Tengan cuidado porque por estar en contra de una marca, están creando un Leviathan que puede llegar a ser tan fuerte por la ayuda de ustedes que en un futuro, cuando quieran luchar contra él no tendrán foros, ni páginas, ni nada… La discusión técnica parece que no les interesa y eso que se supone que ustedes son informáticos, lo que veo es que son personas técnicamente pobres y obnubiladas porque llevan todo a un lado del tipo político, o incluso religioso, o además, hasta fundamentalista. Se habló de Cuba en los posts anteriores, pero ustedes tienen la misma postura de una dictadura… ser contra algo que se les antoja sin ver la parte que sí interesa, la parte técnica. Bueno, por lo que he visto, todo este tema le ha dado de comer a los dueños de estos foros ya que necesitan las visitas para comprar su pan. Pero vean la parte técnica… y no se olviden… ODF no es lo mismo que el estándar que fué aprobado y en el futuro, quiero ver si ustedes mismos hacen la revolución cuando IBM les dé la espalda después de hacerles el trabajo de forma grátis y estén bajo la misma dictadura que IBM trató de hacer años atrás..

    Asmodeus — 28 de marzo de 2008 @ 1:10 am
  13. […] Barriga de Microsoft, que tuvo una todavía más dura (sí, esto podría auspiciarlo Pfizer) respuesta de Carlos desde su bitácora, esta semana insospechados new players joined the […]

  14. Gracias por el post, se agradece la precisión y el detalle. Felicitaciones y gracias por compartirlo.

    Sergio Uribe — 28 de marzo de 2008 @ 8:40 am
  15. El párrafo:

    Con estupor he podido ver la carta «declaración» del DCC respecto a su rechazo a OOXML. No me produce estupor el voto sino que los argumentos que ahí se presentan los cuales no se condicen con la idoneidad y ética de profesores de la Casa de Bello.

    Con qué ropa duda de la idoneidad y etica de los profesores de la U. Nos está diciendo que los argumentos de los profesores del DCC dejan ver atisbos de falta de idoneidad y ética?

    Rafael Hernandez — 28 de marzo de 2008 @ 12:18 pm
  16. @asmodeus,

    Estás asumiendo que lo único que podemos hacer en este tema es elegir entre el monopolio de Microsoft o uno (inexistente) de IBM. Obviamente, eso es una elección falsa, y hay otras opciones.

    Sobre que los formatos (como ODF) evolucionan fuera de la ISO, eso es obvio: la ISO no es una organización dedicada al desarrollo de estándares, sino que genera acuerdos sobre cuáles formatos/estándares nacionales deben tener el «sello de aprobación». El trabajo de desarrollo se dá en otras instancias, como OASIS o ECMA.

    Saludos.

    Carlos — 28 de marzo de 2008 @ 2:55 pm
  17. Muy buen articulo super claro… hay que ver que pasara

    Valericio — 28 de marzo de 2008 @ 8:13 pm
  18. […] (la Universidad de Chile llamando a rechazar OOXML, Microsoft defendiéndolo, y algunos bloggers respondiendo de vuelta) y el panorama no era claro respecto a que posición tendría Chile finalmente ante el organismo […]

Los contenidos de este blog están publicados bajo una licencia Creative Commons Atribución-Compartir-Igual. (c) 2005-2021 El Diablo en los Detalles | Usando WordPress y una versión modificada de Barecity.