Respondiendo a NoOOXML


A través del Blog de Héctor Sánchez (por uno de sus comentaristas al post Informando y actualizando OpenXML) he conocido la iniciativa Dile NO al formato de Microsoft Office como estándar ISO.

Y creo que se deben dar respuesta a sus argumentos.

  • Ya hay un estándar, ISO 26300, llamado Open Document Format (ODF): un doble estándar supondrá incertidumbre, confusión y un coste añadido para la industria, gobiernos y ciudadanos.;

Existen múltiples estándares para montones de cosas tales como redes inalámbricas, o alámbricas, de diferentes cuerpos de estandarización e incluso para un mismo tema, del mismo organismo normalizador. Sólo en el ámbito del XML, y ciñéndome a un tema que conozco bien, hay montones de estándares para la factura electrónica. ODF es un estándar de OASIS, organismo del que soy miembro y que defiendo. En particular defiendo el ODF, como defiendo el UBL. Lo cual no es óbice para poder defender el formato facturae o el OOXML cuando ayudan a impulsar las ventajas de las tecnologías en las empresas. En particular, el OOXML aporta una compatibilidad hacia atrás con millones de documentos existentes, que no forma parte de los objetivos de diseño de ODF.

  • No hay ninguna implementación de referencia de la especificación de OOXML: Microsoft Office 2007 produce una versión especial de OOXML que no cumple con la especificación de OOXML propuesta en ISO;

Al contrario, hasta la publicación del estándar OOXML muchas empresas se han basado en conjeturas, en ingeniería inversa o en publicaciones no oficiales para lograr la compatibilidad con los formatos de Microsoft. Existen millones de documentos de versiones anteriores de los productos de Microsoft, que es posible interpretar de manera abierta gracias a la publicación del estándar OOXML (ECMA 376). Por otro lado, Microsoft simplifica las versiones futuras de los formatos dentro de las posibilidades de OOXML para adoptar las últimas tendencias de buenas prácticas en XML. Existen ya programas que no son de Microsoft que manejan OOXML y programas vinculados a los de Microsoft que manejan ODF.

  • En el documento de especificación falta información como, por ejemplo, cómo implementar un “autoSpaceLikeWord95” o un “useWord97LineBreakRules”;

No existe ninguna especificación que no pueda perfeccionarse. Es por ello que los grupos de trabajo de normalización están siempre revisando las propuestas a iniciativa de sus miembros. Incluso se descartan estándares por no ser de aplicación en la época actual. En particular esto sucede en grupos de trabajo de AENOR en los que yo participo. En ocasiones las normas se rehacen completamente (como las ISO 9000) y en algunas ocasiones se definen generaciones de normas en base a otras (como la serie BS-7799, UNE 71502, ISO 17799, o ISO 27001).

  • Más del 10% de los ejemplos de su especificación no validan la conformidad con XML;

No olvidemos que hay dos contextos en la norma: los marcados por requisitos legacy, y los que se orientan a mejores prácticas. En el primer caso es de prever que esta limitación no pueda obviarse, pero es al mismo tiempo una de las mayores ventajas del estándar. En el segundo caso se tratará de un error que puede mejorarse en siguientes revisiones.

  • No existe garantía alguna para que cualquiera pueda implementar parcial o totalmente la especificación de OOXML sin arriesgarse a que Microsoft le exija daños y perjuicios por infracción de patentes o el pago de licencias de patentes;

Al contrario, esta es una de las garantías de los procesos de normalización: la gestión de IPR (intelectual property rights) de forma que se satisfagan las necesidades de todos los participantes. En todo caso, la existencia del estándar OOXML no prohibe el uso de ODF, de forma que al final las implementaciones dependerán de las diferentes ventajas que encuentren sus implementadores en sencillez de uso o en mercado potencial.

  • Esta propuesta de estándar entra en conflicto con otros estándares ISO, como ISO 8601 (representación de fechas y tiempos), ISO 639 (códigos de representación de nombre e idiomas) o ISO/IEC 10118-3 (funciones hash de criptografía);

En realidad no existen conflictos mientras exista un método de representación que permita la traducción a otros formatos cuando sea necesario. Por ejemplo, el estandar para definir paises es el ISO 3166, en el que a España le corresponde el código numérico 724, el Alfa-2 ES y el Alfa-3 ESP. Sin embargo para la ITU (antigua CCITT) España es el 34 en el estándar para definir el pais (y establecer el prefijo de llamada internacional) que evolucionó hasta la «Recommendation  E.164 (tras recogerse en la E.163, antes E.161/Q.11, antes E.29). En la simbología EAN-13, utilizada en los códigos de barras (que a nivel internacional normaliza GS1) España tiene el Código 84.

  • Hay un error en la especificación del fichero de formatos de hoja de cálculo que impide introducir cualquier fecha previa al año 1900. Esto es un error que se arrastra desde las obsoletas versiones de 16bits de la aplicación MS-Office;

Este es un problema que afectaría solo a algunas partes legacy de la especificación. Te prometo que yo he puesto fechas anteriores a 1900 en muchas hojas de cálculo.

  • Esta propuesta de estándar no ha sido creada aunando la experiencia y mejores prácticas de todas las partes interesadas (tales como productores, distribuidores, consumidores, usuarios y reguladores), sino por Microsoft en solitario.

No es la primera ocasión en la que interesa adoptar un estándar creado por expertos en debates internos, y que después se somete a los criterios generales de los procesos de estandarización. Un caso importante y reciente es el PDF/A aprobado como ISO 19005-1:2005 y basado en el formato propietario de uso libre de Adobe PDF 1.4.

Por tanto, como puede apreciarse, mi idea es que no se puede perder la oportunidad de aprobar el estándard ECMA 376 – OOXML  dentro de ISO y disponer de el a través de los procedimientos de normalización en curso.

18 comentarios en “Respondiendo a NoOOXML

  1. maharba

    Bueno todas esas decisiones cupulares que buscan afianzar Monopolios y beneficiar multimillonarios no me extrañan la corrupción de los gobiernos se nota en esta votación vean a europa en la corrupción y pongo la lista:

    1. Azerbaijan
    2. Cote-d’Ivore
    3. Cyprus
    4. Czech Republic (link)
    5. Denmark (link)
    6. Finland (link)
    7. Germany (link)
    8. Ireland (link)
    9. Japan
    10. Jamaica
    11. Kazakhstan
    12. Lebanon
    13. Malta
    14. Norway (link, another link)
    15. Pakistan
    16. Saudi Arabia
    17. Singapore
    18. Slovenia
    19. South Korea (link, another link)
    20. Switzerland
    21. Trinidad and Tobago
    22. United Kingdom (link)
    23. USA (link)
    24. Uruguay

    les dejo un link para que vean como Noruega se corrompe, México se corrompe, Alemania y hasta Finlandia, se ve que no sólo en México se comportan como muertos de hambre se ve que en todo el mundo están igual y se ponen la marca del anticristo, allá ellos habrá que generar una nueva organización de estándares no corrupta y en la que no puedan intervenir con dinero, habrá que cambiar a la ISO como muchos otros centros de control político y económico espero que alguien siga en ese camino.

    Responder
  2. Fede Heinz

    Julián,

    bien, entonces lo que ingresaste no fue una fecha, sino un string. Así es fácil, y también podemos ingresar el «45 de octiembre del quichicientos cuaentitreinta antes de Angelina Jolie», pero no ayuda mucho 🙂

    Coincido en que si ECMA efectivamente resuelve todos los problemas técnicos presentados, incluyendo cosas como usar W3C SVG en vez de DrawingML y VML, W3C MathML en vez de su propio MathML gratuitamente incompatible, y toda la música, calificaría para ser aprobado como estándar.

    Lamentablemente, hasta ahora hay pocas indicaciones de que puedan lograrlo en el futuro cercano: la página a la que vinculas habla en términos generales de la solución propuesta a cinco de 1795 comentarios. A este ritmo, me da la impresión de que falta un buen rato.

    Responder
  3. Fede Heinz

    Julián,

    OK, comprendo de dónde salió la confusión entre straw man y ad logicam. De todos modos, el nudo de esta discusion no es ese, sino comprender si OOXML está suficientemente maduro como para que sea aceptado en el proceso fast-track. Al fin y al cabo, fue la inmensa cantidad de observaciones técnicas (y no una cuestión de antipatía hacia MS, como tú dices) la que llevó a que ese proceso se frenara.

    En esa discusión, estamos esperando aún al menos dos cosas: 1) una planilla de cálculo con la fecha 1/1/1899 en la celda A1, codificada de acuerdo a la especificación de ECMA 376, tal cual nos prometiste, y 2) las razones a favor de que OOXML sea sancionado como estándar, que dices que son tantas y tan valederas como las que hay en contra, para poder evaluar si es así no.

    Responder
  4. Fede Heinz

    Julián,

    No puedo hablar por Gustavo, pero creo que el asunto de los estándares abiertos en la era digital es crucial para una sociedad democrática e igualitaria, por lo que merece que le dediquemos tiempo a debatirlo.

    Lamentablemente, lo único que tienen en común el argumentum ad logicam y el straw man es que son dos formas distintas de falacia. No creo que hayas querido anunciar que tu argumento es falaz, de modo que no entiendo qué quisiste decir.

    Volviendo a ECMA 376, el proceso fast-track está pensado para acelerar la aprobación de una especificación cuando una propuesta viene pre-aprobada por otro organismo normalizador, precisamente porque se supone que éste ya ha realizado el necesario due diligence y verificado que la propuesta sólo puede necesitar cambios editoriales para ser aceptada.

    Lamentablemente, ECMA no hizo bien las tareas en este caso, e hizo el papelón de recomendar una especificación a medio cocinar. Así, la votación sobre el proceso fast-track de hace un par de meses no «entorpeció» la sanción, sino que cumplió exactamente su función: actuar de filtro para que no entre basura en el sistema (y eso pese a las trampas que Microsoft no pudo resistirse a hacer, y que lamentablemente han tenido la consecuencia de paralizar a ISO/IEC JTC1 SC34).

    Nos dices que hay tantas y tan valederas razones para aceptar la publicación de OOXML como estándar ISO como para rechazarla. Bueno, hasta ahora hemos hablado solamente de las que hay para oponerse a esa publicación. ¿Qué te parece si, mientras preparas esa planilla de cálculo con la fecha 1/1/1899 en la celda A1, que dices que puedes almacenar en OOXML, nos cuentas cuáles son las razones a favor de aceptar a OOXML como estándar?

    Responder
  5. inza Autor

    Fede, Gustavo, gracias por el tiempo que estáis dedicando en vuestros comentarios.

    No quería entrar en debates «punto por punto» (aunque admito que es así como he empezado el post) y eso hará que mis próximas argumentaciones sean de nuevo argumentum ad logicam (straw man).

    Por mi parte, sostengo que hay valiosos argumentos en contra de que esta especificación se publique como estándar ISO, y al menos otros tantos a favor.

    Y que la posición en uno o en otro lado de cada persona poco tiene que ver con las cualidades de la especificación o sus carencias.

    Y en este sentido, la antipatía que algunas personas sienten por Microsoft es el verdadero lastre del proceso, que ha impedido el procedimiento «fast track» ISO en su curso habitual (cuando una propuesta de estándar ya viene avalada por otro organismo normalizador).

    Responder
  6. Gustavo Boksar

    Otra cosa… respecto al punto que hablas que el problema podría haber sido que lo haya presentado Microsoft… evidentemente no has leido muy bien nada de lo que hemos escrito, ya que creo que ese puntualmente es uno de los puntos a favor!

    Que una empresa como MS se hacerque a los formatos estándares es algo muy bueno! La única diferencia entre ISO y ECMA, es que ISO es menos permeable a ciertas presiones… y no vale de mucho solamente el nombre para convertirse cualquier cosa que presentes como estándar.

    El mejor ejemplo de eso fue la aprobación del formato PDF como estándar ISO! Tambien hablamos de un formato muy utilizado a lo largo y ancho de todo el mundo, eso deja millones de documentos en multiples plataformas y creados por diversas aplicaciones… y sin embargo, su proceso de estandarización no tuvo mayores contratiempos. Y ojo, Adobe también es una empresa privada, que se especializa en el desarrollo de software privativo.

    Responder
  7. Gustavo Boksar

    No creo que sean insuficientes… además, malinterpretas las intenciones de muchos de los que hemos luchado por el no al ooxml…

    En ningún momento se dice que no al formato(al menos yo no lo he hecho) por el mero hecho que existieran otros estándares para el mismo fin. El hecho es que OOXML no cumplía con los requisitos mínimos para convertirse en un estándar ISO.

    Eso no lo digo yo, lo dice la propia ISO en sus declaraciones de qué condiciones debe reunir un formato para convertirse en estándar ISO:

    Por otro lado, creo que es importante aclarar, que no se trata de «tumbar un estándar» pues OOXML no era un estándar ISO, sino un estándar wannabe. ECMA, si bien es uno de las instituciones que «declaran» estándares está demasiado involucrada con la industria, lo que no hace demasiado transparente el proceso de declaración de un estándar. Eso no quita que puedan generar algunos muy buenos! De hecho, OOXML tenía todo para convertirse en un excelente estándar, salvo que quien tiene el control sobre el formato se niega a corregir las cosas que se les han planteado. Ergo, qué garantías ofrecen que eso vaya a suceder una vez aprobado el estándar?

    Microsoft está más interesada en mantener compatibilidad con sus aplicaciones legadas que con la creación de un formato abierto, útil e implementable libremente por cualquiera.

    Creo que no estás haciendo foco sobre los puntos que te exponemos en éstos comentarios, como por ejemplo, OOXML no es compatible con los formatos anteriores de Microsoft ni lo será, es un formato nuevo que intenta documentar errores como el del manejo de fechas que viene legado desde la época del Lotus 1-2-3(según palabras del Sr. García de Microsoft Uruguay). Una cosa es que Excel no pueda manejar fechas anteriores al 1900(a quien le puede interesar…?) otra muy diferente es permitir la aprobación de un formato estándar y abierto que documente eso!

    La realidad es que no fuimos 4 locos aislados los que dijimos OOXML no está preparado para convertirse en un estándar ISO, fueron muchos paises, muchos profesionales de IT que han elevado sus discrepancias y han documentado las mismas para que ECMA/Microsoft pudiera hacer uso de ellas y corregirlas.

    De hecho, muchos de los paises han expresado su intención de modificar el voto si ECMA hacía oidos a sus planteos. Sin embargo, el camino fue el de la presión y otros medios menos ortodoxos pero muy efectivos en el tipo de mundo en el que vivimos.

    Tal y como dice Fede, te invito a demostrar lo que planteas mediante implementaciones sencillas en lugar de rebatir nuestros argumentos con palabras, pues eso fue lo que nosotros hicimos, probamos el formato.

    Reitero, OOXML promete ser un buen estándar, pero de la promesa al hecho existe un paso, y es escuchar lo que el resto del mundo tiene para decir respecto al mismo y llegar a un formato aceptado por la mayoría… de lo contrario… qué sentido tendría darle el nombre de estándar?

    Que OOXML esté en la cuerda floja y haya recibido tantas negativas no es culpa de los que protestamos, sino de los que se niegan a escuchar las protestas!

    Responder
  8. Fede Heinz

    Julián,

    nuevamente estás usando un «straw man»: mi argumento en el primero de los puntos es que tener más de un estándar en una misma área de aplicación produce confusión y mayores costos, y tú me contestas presentando un ejemplo de estándares distintos para distintas áreas de aplicación.

    Tu dirás que OOXML en realidad tiene un área de aplicación distinta, que es la de «brindar compatibilidad hacia atrás con los formatos heredados». Te invito a leer un artículo en mi blog en el que explico en detalle por qué esa afirmación es falsa.

    Acerca de que la evolución del estándar se regirá por las reglas del organismo que la promulga, te cuento que ECMA no parece dispuesta a someterse a las reglas de ISO, y que Microsoft ya ha indicado de que no se compromete a soportar futuras versiones del standard.

    En fin, si lo que argumentas es que en tu opinión las objeciones de NOOOXML no son suficientes para bloquear la estandarización, evidentemente no tenemos mucho para discutir: es tu opinión, y es tan válida como la de cualquier otro. Pero yo leo tu artículo como un intento de mostrar que las objeciones de NOOXML no son meramente insuficientes, en tu opinión, sino que además no son ciertas.

    Si tu intención era esta última, creo que aún tienes bastante tarea para el hogar. Por ejemplo, esa planilla de cálculo con 1/1/1899 en la celda A1.

    Mientras tanto, tu apreciación de que mi propuesta es de aplazamiento más que de rechazo es una forma un tanto particular de expresarlo. Los problemas que OOXML tiene no se resuelven por el mero paso del tiempo, sino haciendo modificaciones serias y profundas. Si OOXML efectivamente cambiara lo suficiente como para ser aceptable como estándar (es decir, si estuviera definido completamente, reusara estándares preexistentes, no incluyera burradas como el formato de fecha, y pudiera ser implementable por cualquiera en igualdad de condiciones), mi única objeción sería que es una pérdida de tiempo que podría ser usado en avanzar en otras áreas de estandarización que requieren atención más urgente que «yet another office document standard».

    Por lo demás, sugiero que no descalifiques tan ligeramente a las personas que miran a Microsoft con desconfianza, porque ésta es justificada. No sólo se trata de una empresa que ha sido encontrada reiteradamente culpable de abuso de poder monopólico a ambos lados del Atlántico, sino que además tiene una historia de diseñar sus programas de tal modo de impedir la interoperabilidad con programas de otros proveedores.

    PS: ¡hombre, habilita los tags <ol>, <ul> y <li>, que no son peligrosos! Mi comentario anterior quedó formateado horrible 🙂

    Responder
  9. inza Autor

    Fede,

    Creo que puede ser cansado para ambos, y para nuestros lectores reincidir en detalles que por sí solos son insuficientes, en mi opinión, para justificar que OOXML no llegue a ser estándar ISO.

    Por ejemplo, según tu argumento, una vez que existe el formato PDF/A (ISO 19005-1:2005) no tendría setido que hubiera un formato ODF (ISO/IEC 26300:2006).

    La mera existencia de implementaciones de gestores/editores de documentos (estén o no respaldadas por un estándar) hace recomendable, en mi opinión, la disponibilidad libre de sus especificaciones. Si además es un estándar, su evolución se regirá por las reglas del organismo que lo promulga. Que suele contemplar la revisión y mejora del estándar (de ahí la redenominación de las normas o su versionado por años)

    Y en ocasiones un estándar tiene ventajas sobre otro (por ejemplo, JPG gestiona más colores que GIF, pero GIF se basa en un algoritmo sin pérdidas, permite crear animaciones y pemite establecer colores «transparentes»).

    De todas formas, entiendo tus argumentos, me parecen sólidos, y creo que en el detalle se esconde más una propuesta de aplazamiento que una negativa a que OOXML sea un estándar ISO.

    A no ser que el problema sea que OOXML lo ha propuesto Microsoft.

    Responder
  10. Fede Heinz

    Julián, permíteme analizar tus argumentos por separado, tal como tú lo has hecho:

    Sobre múltiples estándares, argumentas que hay otras áreas en las que los hay. Pero la tesis a falsear no era «no existen múltiples estándares en una misma área», sino «los multiples estándares suponen incertidumbre, confusión y coste añadido». Creo que cualquier persona que alguna vez conectó un dispositivo de 110V a un tomacorrientes de 220V sabe que esta afirmación es cierta, pero te invito a que argumentes por qué es falsa.
    Sobre la inexistencia de una implementación de referencia, efectivamente, hay programas que pueden leer archivos OOXML en forma parcial. Pero no hay, hasta donde yo sé, una implementación de referencia, es decir, un programa que soporte el 100% de la norma tal como está escrita.
    Sobre la compatibilidad hacia atrás repites el argumento de que OOXML permite acceder a «millones de documentos de versiones anteriores de Microsoft Office». Si esa aseveración fuera cierta, entonces cualquier programa que lea OOXML podría automáticamente abrir un archivo .DOC, de modo que, para que este argumento se sostenga, debes demostrar que es posible leer un archivo .DOC usando un programa que sepa leer OOXML y nada más que OOXML.
    Sobre la falta de información argumentas que «ninguna especificación es perfecta». Estamos de acuerdo, pero nadie está pidiendo perfección. Lo que muchos decimos es que la cantidad y el tipo de información que la especificación de OOXML omite es inaceptable, y por lo tanto es necesario completarla antes de sancionarla como norma, y no sancionarla primero y luego esperar a que la arreglen, cuando ya no tengan mucho incentivo para hacerlo.
    Sobre la invalidez del XML incluido en los ejemplos hablas de dos tipos de problemas: los que no pueden resolverse usando XML válido por razones de «legacy», y los que sí pueden resolverse. Sobre los segundos, repito lo del argumento anterior: primero arreglémoslos, luego discutamos la estandarización. Sobre los que supuestamente no pueden resolverse usando XML válido, te ruego que nos muestres un ejemplo.
    Sobre los derechosde patentes, me temo que las políticas de patentes de los distintos cuerpos de estandarización son demasiado complicadas como para despacharlas en un solo párrafo. Muchos especialistas en derecho de patentes han revisado las promesas de no agresión ofrecidas por Microsoft para la implementación de OOXML (que no serían necesarias si el proceso de normalización las garantizara, como argumentas), y todavía no queda claro si son suficientes o no como para dormir tranquilos.
    Sobre el conflicto con otros estándares ISO argumentas que no hay problemas mientras se pueda convertir de un formato a otro. Aquí el problema es doble. Por un lado, esa conversión no siempre es posible: por ejemplo en el caso de la fecha, es posible ingresar un valor (29/2/1900) que no tiene correspondiente en ISO8601, y éste tiene muchos valores (todos los anteriores a 1900) que no son representables en OOXML. Por otro lado, en los casos en los que la traducción es posible: ¿por qué habríamos de agregarle esa complejidad a la compatibilidad entre formatos, agregando costos a todos los que quieran desarrollar aplicaciones compatibles con OOXML, cuando podríamos sencillamente usar un formato ya existente?
    Sobre el tema de las fechas en particular nos prometes que has puesto fechas anteriores a 1900 en planillas de cálculo. En realidad, puedes hacer algo mucho mejor que prometerlo: demostrarlo. Adelante: confecciona una planilla de cálculo que tenga, en la celda A1, la fecha 1/1/1899, guárdala en un archivo OOXML, y postéalo aquí, en tu blog. Postulo que ocurrirá una de dos cosas:

    no lo lograrás, o
    el archivo OOXML resultante no será conforme a la especificación de ECMA, ya que ésta no permite fechas anteriores al 1900.

    En síntesis, creo que has hecho un buen intento de responder a argumentos parecidos a los de NOOXML, pero no a ellos mismos. Tal como está, tu artículo está basado en la técnica del «straw man argument»: en vez de rebatir el argumento de tu oponente, rebates otro más sencillo, y afirmas que eso era lo que tu oponente decía.

    Responder
  11. Gustavo Boksar

    Me he tomado un tiempo para digerir tus argumentos sobre OOXML, lamentablemente no logro hacer un trackback desde mi blog(http://www.boksar.info) como me gustaría así que te pongo un comentario normal…

    Haces algunas exposiciones razonables, aunque basado en algo que no es correcto. Por un lado hablas de compatiblidad con formatos anteriores y los millones de documentos ya existentes.
    Me ha tocado estudiar el documento presentado por ECMA pues formé parte del comité que estudió dicho formato en mi país(Uruguay) y lo cierto es que en ningun lado ofrece compatibilidad ninguna. Es un formato nuevo, y los documentos existentes deberán ser convertidos manualmente al este nuevo formato y los tags son exclusivamente para compatibilizar el comportamiento de sus apps. legadas y no sus formatos!

    Otro punto es el de la fecha, definitivamente EXCEL no soporta fechas anteriores a 1900, y el formato OOXML no prevee el manejo de dias laborales diferentes a los occidentales. Voy a realizar una respuesta más adecuada en mi blog… si te interesa te invto a leerla, probablemente lo haga hoy por la noche.

    Responder
  12. Miguel Angel Fernández

    «De hecho tengo una anécdota en ese sentido. Tenía un fichero salvado con Microsoft Office que no podía abrir con una versión posterior. Lo abrí con StarOffice y lo volví a salvar en formato Microsoft, y esta vez sí pude abrirlo.»

    Y con estos antecedentes aún se sigue criticando a los que no confiamos en Microsoft ni un ápice.

    Si ellos que son los propietarios de SUS formatos, son incapaces (cosa que dudo, técnicamente hablando) de mantener compatibilidad, ¿qué puede hacerme pensar que con OOXML va a ser distinto?

    Saludos.

    Responder
  13. inza Autor

    Como bien dices, aunque OOXML «solo» sea standard ECMA ya es un estándard y hemos ganado mucho a la hora de interpretar sus formatos pasados y futuros.

    Para mi es importante que sea ISO porque garantizará la futura lectura de documentos legacy en las administraciones públicas y en las empresas de todo el mundo, con productos que no sean de Microsoft.

    De hecho tengo una anécdota en ese sentido. Tenía un fichero salvado con Microsoft Office que no podía abrir con una versión posterior. Lo abrí con StarOffice y lo volví a salvar en formato Microsoft, y esta vez sí pude abrirlo.

    Un estandar es una fuente de información para todos los desarrolladores, y no necesariamente las implementaciones de Microsoft serán las mejores.

    Criticarlo porque procede de Microsoft aflora la escasez de argumentos serios en su contra.

    Responder
  14. Grayskull

    La especificación del OOXML muestra lo bien que Microsoft programa. ¿Porque no quisieron cumplir con el estandar del calendario gregoriano ? ¿será porque prefirieron heredar una limitacion del Excel antiguo en su nuevo formato, en vez de hacer un formato nuevo y mejor ?

    El estandar dice que ciertos comportamientos se tienen el Emular de productos comerciales como Word 6.0. Todos sabemos que al emular nos pueden demandar. Ej. Sony demandó a Emuladores de Playstation (en donde no había para nada código de Sony)

    He probado el Plugin de OOXML para OpenOffice y no funcionó. Aparentemente el único que tiene ventaja para implementar el OOXML es Microsoft.

    En las reuniones de defensa de OOXML en cada país MS llevó a gente engañada diciendo que si no aprueban el OOXML se les estaría prohibiendo su uso y atentando contra la libertad de cada persona. Una clara mentira porque el OOXML ya es un estandar de ECMA y puede ser usado sin problemas.

    MS quiso confundir a la gente diciendo que ningún software es perfecto. Pero el OOXML es una especificación en texto (no un software), todos la podemos leer y no aceptarla si encontramos fallas.

    Recordemos que historicamente Bill Gates no quiso compartir y removió de la luz pública las especificaciones de los formatos de office para que Lotus SmartSuite y otros no los puedan abrir.

    A mi criterio MS solo quiere que el OOXML sea estandard ISO para subir sus ventas del Office 2007 y tener control sobre el estandard.
    Estoy seguro que luego MS va a sacar un OOXML mejorado y no documentado para mantener su monopolio y va a mentir a las instituciones diciendo que el formato es público.

    Responder

Deja una respuesta

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. Salir /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Salir /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Salir /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Salir /  Cambiar )

Conectando a %s

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.