Informando y actualizando OpenXML


 














Escribo este post como continuación a “Desinformando openXML” de hace algunas semanas. Y mucho me temo que no será el último ;-).


Estandarizar no es una batalla ni a favor ni contra nadie. Tan solo es un trabajo honesto y profesional en el que los cuerpos de normalización examinan una propuesta, opinan, proponen, con el fin último de evaluar y/o en su caso mejorar el estándar.


Los comentarios remitidos por los países sobre el estándar de formato de documento OpenXML, están siendo la base del trabajo del editor del estándar, ECMA, quien trabaja actualmente de forma muy intensa en su mejora, guiado por dichos comentarios.


 


“El espíritu del proceso de normalización es que las normas salgan”.


La frase no es mía, si no de responsables de la normalización en España. Frase que reposiciona el espíritu positivo y constructivo que se encuentra detrás de estos procesos, y que tras el autentico huracán sin precedentes originado en torno a éste, es de agradecer ese reposicionamiento.


ECMA trabaja sobre todos y cada uno de los comentarios remitidos por los países, agrupados y clasificados en una forma comprensiva, y según se producen avances, estos se comparten con los cuerpos de normalización Ojo, según establece la directiva de ISO, no ECMA, ni mucho menos Microsoft, que no es más que un participante del TC45 de ECMA y nada tiene que decir/hacer sobre cualquier procedimiento al respecto. Por lo que cualquier objeción sobre el proceso en sí, si lo hubiera, debería ser remitida a ISO, no a Microsoft.


El resultado será una propuesta muy mejorada que recogerá el conocimiento, experiencia y aportaciones de los cuerpos de normalización de muchos países. Y este proceso de mejora de un estándar es lo realmente relevante, e ilustra la bondad de tales procesos.


Aunque desafortunadamente sospecho que será de esperar de nuevo (como ya lo fue) una asociación entre este proceso y una especie de plebiscito público sobre Microsoft, sin considerar, en primer lugar, que es ECMA el editor de la norma, y en segundo lugar que los cuerpos de normalización no se constituyen para ser el “marco” de estas hist@rias.


¿Quien tiene tantísimo interés en entorpecer este proceso?¿Por qué? ¿Que intereses esconde? ¿Por qué pasó desapercibido el proceso de estandarización en ISO de ODF para la mayoría? ¿Por qué acaba de finalizar el proceso Fast Track de PDF 1.7 sin que apenas nos hayamos enterado? ¿Por qué he escuchado ya críticas al trabajo de ECMA antes incluso de haberse hecho público?



Es una pena que una iniciativa que entre otras muchas cosas, incide en “liberar” los billones de documentos binarios existentes en el mundo, de la aplicación que los generó (algo que en cualquier caso ya es posible gracias a ECMA376), como siempre se ha querido, y en consecuencia poder incluso enviar al garete al fabricante de la aplicación originaria, Microsoft, si éste no nos satisface con su tecnología, sin mayores problemas de lock-in, se cruce en el tiempo con intereses muy particulares de una compañía que contempla este estándar como una amenaza a su modelo de negocio, y su oposición “activa” no es más que una pura estrategia comercial, lícita por otra parte, pero una estrategia de competencia, que se aleja sin rubor de los intereses de los usuarios.


Que nadie se lleve a engaño. Esto es simple y llanamente lo que está ocurriendo en torno a este proceso.


 


 


 

Comments (39)

  1. @Miguel Angel, solo un comentario mas al respecto. ¿Sabes quien decide la evolución y futuro de ODF a fecha de hoy? Lo hace OASIS … El ODF Comitee está coliderado por IBM y SUN.

    Es curioso que tan solo imaginar un grupo conjunto entre ECMA e ISO para dar evolución a openXML (en el caso de que sea finalmente un estandar ISO), cause una tormenta …  De nuevo, el nombre Microsoft está pesando mas de la cuenta, arrojando "anormalidad" donde no la hay.

  2. Miguel Angel, no estoy pensando en Pamela Jones, y la asociación con IBM las has hecho tú. Pero vamos, el nombre de la empresa era "blanco y en botella". Estoy pensando mas bien en Rob Weier de IBM por ejemplo y de otras personas que solo dedican su tiempo
    a "colaborar" en el "éxito" de este estandar.

    Respecto a arrojar dudas sobre ECMA, y compararlo con OASIS en base a la cuota de entrada, pues no se a que te refieres ¿Que sugieres, que ECMA es un club de millonarios y OASIS es la casa del pueblo?

    Aquí tienes las condiciones de entrada en ECMA,
    aquí
    las de OASIS (que te adelanto son muy parecidas), y aquí lo que ECMA dice al respecto en su WEB:

    For each class of company membership the annual fee shall be:

    • Ordinary members:   The full nominal fee
    • Associate members:   One half of the full nominal fee
    • SME members:   One quarter of the full nominal fee.
    • SPC members:    Five percent of the full nominal fee.

    There is no fee for NFPs (Not-For-Profit organizations).

    Y si quieres ver los procesos de OpenXMl en ECMA y de ODF en OASIS, pues mira el
    informe de IDC que referencio en el post "Desinformando OpenXML". Lo que no puede
    ser es que en cuanto aparezca el nombre Microsoft, todo el mundo se convierta en sospechoso de algo. Y ésto último, en mi opinión, responde a tu pregunta sobre el proceso de ODF y el de OpenXML, donde existe un interés en convertir este proceso en un plebiscito
    sobre Microsoft, compañía que a nadie deja indiferente.

    El formato de ECMA és excelente y no deja dudas. Sabes quién acaba de unirse al TC45 de ECMA para trabajar en primera persona sobre este formato, independientemente de que sea ISO o no?. Pues la Gnome Foundation… Y no por que sean "supporters" de openXML. Están
    en las antípodas de Microsoft en estrategia, visión y objetivos, pero si entienden que la forma constructiva de avanzar es monitorizando, contribuyendo y opinando, mas que dedicar ingentes cantidades de personas y tiempo a simplemente destruir (incluso lo
    que no está construido).

  3. @Jorge, razón de mas … No estoy tratando de comparar la "popularidad" de los formatos(el mas popular sería PDF, seguido de los .doc).

    Lo que digo es que ninguno debe pretender ser un formato "exclusivo". No hay razón para ello, ni para nadie (excepto para el que defiende dicho formato), y menos un formato que no llega al 0,00%. ¿Que OpenXMl tampoco? Estupendo. No es de sorprender con menos de un año de existencia, pero es que no es OpenXML quien busca exclusividad.

  4. @NoName, nadie tergiversa nada. Estoy hablando de "Formatos de documento", categoría en la que está PDF (Portable DOCUMENT FORMAT). Si solo quisiera hablar de archivos de impresión, hablaría de PDF/X (ISO 15930), PDF/A(ISO 19005) para archivado de documentos digitales o PDF/E (ISO 24517) para el intercambio de documentos de ingenieria.

    Pero estoy hablando de PDF 1.7 a punto de ser ISO 32000.

    Y reitero que no se trata de popularidad. Estandarizar no es poner medallas en un "hit parade". Y vuelvo a recordar que OpenXML ya es un estandar abierto de ECMA (ECMA376) con mas de 200 aplicaciones NO MICROSOFT. Esa no es la cuestión. La cuestión es si además es ISO o no.

  5. Gracias todos por vuestros comentarios. Me he prometido a mi mismo (y a mi familia) no coger la PDA durante el puente, y he cumplido ;-), aunque reconozco que estaba con ganas de leer reacciones al post.

    @Miguel Angel. La fuente de esa información, es el origen de todas, y te invito a ver la compañía de pertenencia de esa persona, y su dedicación casi absoluta a dinamitar OpenXML a cualquier precio. El 90% de sus post van en esa línea. En primer lugar, y
    por enésima vez, ECMA no es Microsoft. Microsoft no es ECMA. Que el futuro de OpenXML recaiga en un grupo de trabajo conjunto TC45 de ECMA, JTC1 de ISO no es una mala propuesta, pero como tal, será discutida en  Tokio en la plenaria del SC34. Y lo que decidan
    ECMA e ISO, pues bienvenido sea. No hay mas problemas. Se busca la mayor eficacia.

    @Arturo, te invito a ver las respuestas de Julian Inza en su blog. Te reconozco que me han venido al pelo para no hacer una respuesta muy larga. Gracias Julian.

    Pero si te añadiría algo: Ninguno de los 8 puntos de NOOXML es correcto… por ser fino. Muchas respuestas las encontrarás en el post "Desinformando OpenXML",
    aunque si entre ambos posts no vieras todas las respuestas, por favor, coméntalo de nuevo.

    @Pentapolin, realmente el trabajo que ECMA está acometiendo en este momento es 100% técnico. No se trata de que el estándar presente problemas. Todo lo contrario. Las aplicaciones que lo usan, funcionan perfectamente. Las respuestas se refieren a resolver
    aspectos técnicos remitidos por países, no en cuanto a la calidad del estándar, sino a aspectos que deben modificarse para ser un estándar ISO.

    Pero lo mejor es invitar a cualquiera que tenga el conocimiento y la oportunidad, de conocerlo a descargarse la especificación desde ECMA, examinarla en la parte que consideres de interés, y utilizarla. Algunos aspectos son realmente punteros (incorporación
    de esquemas de terceros por ejemplo, accesibilidad) y la existencia ya de mas 200 aplicaciones son la mejor prueba de que mucho de los aspectos que se comentan tienen mas que ver con que es Microsoft quien ha estado detrás, que con cualquier otra cosa.

  6. Como quieras Federico (no querrás ser tu mi asesor, verdad ;-)), pero creeme que no lo pondré mas veces (creo que ya van 5):

    • NO NECESITAS UN SOLO BYTE DE MICROSOFT PARA REALIZAR UNA IMPLEMENTACIÓN COMPLETA (incluyendo recuperación de binarios) DE OPENXML (que es de lo que va este post, no de otra cosa). Es curioso que mantener esta propiedad en ECMA376, haya sido objeto de enorme crítica entre sus detractores… ¿Y ahora resulta que ni siquiera era verdad ? … 😉

     

    • NO HAY NINGÚN SECRETO QUE GUARDAR EN LOS BINARIOS DE MICROSOFT. ACCESIBLES HACE AÑOS COMO HAS PODIDO COMPROBAR.

    Pero bueno, en el “buen rollo” que hemos mantenido en esta “conversación”, te invito seguir participando. Me da que esta “charla” no será la última 😉

  7. @Federico, lamentablemente creo que o no me he explicado bien, o no me has entendido la respuesta. Mas bien creo que lo primero. Las especificaciones de binarios de Microsoft, dejaron de ser un secreto para nadie hace mucho tiempo. Era curioso ver como se
    seguía argumentando que el "secreto" del éxito de Microsoft estaba en el "secretismo" de los formatos de fichero binarios, al mismo tiempo que estos estaban accesibles, y siguen estándolo, libres de ningún tipo de royalties para cualquiera. Sigue
    este enlace,  y en un par de dias aprox, tendrás el "gran secreto de Microsoft". Los ejemplos que te he puesto, no eran para ilustrar el uso de OpenXML. Incluyen suites ofimáticas completas,
    como WordPerfect de Corel, o incluso openOffice de Novell, desarrolladas sin una sola línea de código de Microsoft, y capaces de entender perfectamente cualquier archivo binario.

    Pero en cualquier caso, ¿Qué insinuas? ¿Qué hay una especie de engaño universal por parte del TC45 de ECMA, ya desde la primera página, mintiendo en el propósito del estandar?

    "OpenXML was designed from the start to be capable of faithfully representing the pre-existing corpus of word-processing documents, presentations, and spreadsheets that are encoded in binary formats defined by Microsoft Corporation. The standardization
    process consisted of mirroring in XML the capabilities required to represent the existing corpus, extending them, providing detailed documentation, and enabling interoperability. At the time of writing, more than 400 million users generate documents in the
    binary formats, with estimates exceeding 40 billion documents and billions more being created each year."

    No solo se trata de recuperar el dato, sino, reproducir en un esquema XML el comportamiento binario asociado a los .doc, .xls etc..

    Respecto a la confusión sobre aplición y formato, créeme que no es tal, y me parece que en este momento has podido confundirte, aunque realmente no me sorprende, dado que la riqueza de este formato no tiene precedentes.

    Una correcta implementación es capaz de dar origen a una potente aplicación ofimática que compita de tú a tú con cualquiera de las de Microsoft (p.e. gnumeric vs Excel), dada además la extrema documentación del estandar, en el que los aspectos y comportamientos
    mas importantes, son descritos en el mismo formato (a diferencia de ODF por ejemplo, donde si haces un search sobre "application defined", te encontraras con mas de 100 "settings" dejados a la aplicación, lo que hace prácticamente imposible la interoperabilidad
    entre documentos ODF salvados por aplicaciones diferentes y te obliga a hablr del ODF de ISO, del de Openoffice etc..).

    En cualquier caso, la evolución no es tan "sorprendente" si se tiene la perspectiva real de la evolución de los formatos de fichero de Office, y como a partir de XP, hasta 2007, se evoluciona en torno a XML. Echa un vistazo a esta gráfica:

    En fin, no me extenderé mas … bueno si … ;-).

    Me parece muy injusta esa insinuación de "falta de calidad" o "ridículo" por los comentarios remitidos. Te invito a echar un vistazo al

    blog de Jan van den Beld
    , secretario general de ECMA internacional hasta Abril del 2007, donde explica que
    el número de comentarios está en la línea de cualquier otro estandar Fast Track,   y ese es mas o menos 1 comentario único por cada 6 páginas… y ese es el ratio de OpenXML, de la misma forma que ha sido el ratio de PDF (ISO/IEC 32000) hace
    unos días.
    No seamos injustos !!!

  8. @Federico, lo que comentas en tu comentario no es correcto. Y me temo que responder a todos los puntos es reiterativo con todas las respuestas a comentarios que he ido poniendo en los post relacionados con OpenXML (no lo consideres una descortesía, pero
    por favor te invito a echarles un vistazo: el tema de Suecia, el tema de que solo Microsoft puede implementar adecuadamente openXML, con mas de 200 aplicaciones que incluyen la conversión de binarios, el tema de las especificaciones sobre binarios, accesibles
    desde hace años etc.).

    Si veo como novedad tu comentario al respecto de la "paralización"  del SC34 que un miembro dice. Pues aquí tienes la opinión totalmente positiva de otro …

    Easy SC34 meeting
    :  y seguramente, habrán tantas opiniones como asistentes ¿Cuantos? ¿Cientos?

    Y por último, te diré que los comportamientos infantiles vas a tener que buscarlos en otros lugares, y te aseguro que los vas a encontrar a cientos. Aquí solo vas a encontrar trabajo serio.

    También te dire, que los comentarios de los paises no identifican errores o falta de calidad como pretendes hacer ver. Identifican funcionamientos que un estandar debe considerar. Por ejemplo, tratar la fecha como un entero, es una decisión de diseño que
    aumenta el rendimiento de la aplicación. Sin embargo, ¿Ese comportamiento no cumple con ISO 8601 y debe hacerlo?, pues se agradece la revisión, el comentario, se modifica, y se sigue adelante. Esa es la utilidad de un proceso de estandarización, pero eso no
    es un error "bochornoso" como quieres hacer ver. Como tampoco lo son los mas de 90 comentarios que el SC34 Japones acaba de hacer sobre ODF.

    ECMA está haciendo un trabajo exhaustivo, profesional, serio y ojalá que se vaya reconociendo poco a poco. Miembros del SC34 en Kyoto se han mostrado sorprendidos por la enorme disponibilidad del TC45 de ECMA a la modificación en respuesta a los comentarios
    de los paises.

    Literalmente:
     

    "Ecma TC45 were meeting in Kyoto in the four days preceding the SC 34 meetings to work on the DIS 29500 responses, and a number of SC 34 delegates attended (I myself did not, for fearing of tainting my neutrality). The feedback I have heard, from those
    whom I would normally count as OOXML skeptics, was that they were favourably impressed with Ecma’s diligence. As one put it, “I don’t care what their motivation is, what I care about is they take account of our comments and respond properly to them”. That
    is precisely the kind of politics-free, technically focused view which I hope will characterise the onward process …"

    Pues esta persona, no es ni mas ni menos que Alex Brown (ISO BRM Convenor)

    Si quieres "empaparte" un poco mas sobre este particular, aqui tienes un
    link
    del antiguo Head de ECMA internacional al respecto de este trabajo.

    Buen fin de semana a todos…

  9. @Consejo, ¿A político? 😉 …. No, creo que no.. Me gusta la tecnología, me gusta hablar de ella, pero bastante complicada tengo ya la vida … Además, créeme que en el uno
    a uno pierdo mucho 😉

     

    @Miguel Angel. Nada, ya está borrado.

    Te reconozco que no sé por dónde empezar. Pero una buena idea es hacerlo desde el principio.

     

    ¿De todos los miembros de ECMA *quiénes* tiene derecho efectivo a voto? ¿Y en OASIS?.

    Por favor, revisa el documento de
    IDC. Es un trabajo hecho a este respecto donde compara los procesos que OASIS y ECMA siguen. Pero te extraigo un texto
    al hilo de tu pregunta, especialmente en lo referente a “Open Process”:

     

    In general we do not find any substantial difference in the "openness" of Open XML

    versus ODF, evaluated on the basis of the three consensus requirements for open

    standards:
    Open process, open documentation and open IPR.

     

    Por qué la especificación ODF (http://docs.oasis-open.org/office/v1.1/OS/OpenDocument-v1.1.pdf)
    está contenida en un documento de 738 páginas y Office Open XML son más de 6.000?

     

    ·        
    Buena documentación: cuanto mejor se documentan las cosas, menos problemas tendremos de falta de interoperabilidad. Es Obvio. Te invito a revisar la especificación ODF de OASIS, y hagas un search sobre
    “Application defined”. Encontrarás muchas entradas. Eso significa que cuando no documentas y dejas settings a la aplicación, te encuentras con problemas de interoperabilidad cuando los documentos son generados por aplicaciones diferentes que usan el mismo
    estándar. Y eso es algo que los usuarios de formatos ODF conocen muy bien.

     

    ·        
    Muuucha diferencia en funcionalidad: Accesibilidad (colectivos discapacitados), extensibilidad a esquemas de terceros, definición de formulas en hojas de cálculo, metadatos y así hasta 6.000 páginas.
    Siempre me ha sorprendido este tema como crítica. Me parece que evidencia un excelente trabajo de ECMA. El estándar es modular. No hace falta implementarlo en su totalidad (en respuesta a críticas sobre su supuesta “complejidad”). ¿Por que voy a usar SpreadsheetML
    si voy a desarrollar un procesador de textos que solo necesita WordprocessingML?

     

    ¿Por qué si Microsoft YA es miembro de pleno derecho de Oasis y por consiguiente aprobó ese estándar, duplica esfuerzos en otro comité para crear uno prácticamente
    desde 0, y realizando todo tipo de maniobras para que se apruebe por la vía rápida?.

     

    El proceso de ODF en OASIS comenzó EXCLUSIVAMENTE como estandarización de un formato de fichero de OpenOffice. DE hecho, su primer nombre incluía la coletilla OpenOffice Document
    Format …. Lo que excluía tácitamente en sus inicios de forma directa a todo aquel fabricante sin interés en la aplicación OpenOffice. El cambio de nombre ocurrió tiempo después.
     

     

    Lo realmente relevante y que pretende responder a tu pregunta, es el hecho de que los objetivos de ODF y OpenXML no son iguales. Uno de los motivos fundacionales de OpenXML
    es la compatibilidad hacia atrás con los billones de documentos binarios generados por Microsoft Office. Liberar a los usuarios de ningún tipo de lock-in con ningún fabricante. Y eso hace de openXML un estándar único, además de suponer un avance tecnológico
    importante en el entorno de “formatos de fichero”. Y respecto a las maniobras, te sigo negando la mayor. La única maniobra es un trabajo exhaustivo del TC45 de ECMA para hacer un estándar potente, y nada mas. Me temo que “las maniobras” las vas a tener que
    buscar en otro sitio.

     

    Si Microsoft *realmente* hubiera querido estandarizar algo, ya habría liberado sus especificaciones para archivos .xls o .doc hace mucho tiempo.
    Y un ejemplo meridiano lo tenemos en PDF.

     

    Eso es precisamente lo que es OpenXML ¡!!!!
    Cada funcionamiento recogido en esos documentos binarios, han sido puestos en un esquema abierto XML recogido en el estándar.
     De hecho, la gran petición pública a este respecto hacia Microsoft, era la apertura del WordprocessingML, y no solo se ha hecho esto, sino que se ha añadido SpreadsheetML y DrawingML, aspectos recogidos todos ellos en OpenXML.

    Y créeme… Ese es el auténtico “secreto de la Cocacola”, objeto de todo tipo de ingeniería inversa durante mucho tiempo, y que ahora solo tienes que leerlo en un documento
    de ECMA.

     ¿Que tienes además una necesidad imperiosa, de conocer los secretos de los antiguos binarios? Pues aquí tienes un
    link, fuera del estándar, donde esa información, totalmente innecesaria y obsoleta por cierto,
    la tienes accesible desde hace años. No hay trampas … aunque algunos las vean en todo lo que les rodea.

     

    Ostras, se me olvidaba que el año pasado firmásteis un pacto de "no agresión" con Novell…

     

    Esto es el FUD más evidente. ¿Qué tiene que ver? La Gnome Foundation no es Novell. De hecho es de las organizaciones menos “amigables” hacia Microsoft, y si no, mira la
    nota de prensa que acaban de lanzar.
     No son muy “partidarios”. Pero sin embargo si son suficientemente inteligentes como para sacar partido de esto. Y si no, ahí tienes Gnumeric utilizando OpenXML y resolviendo el problema de una hoja de cálculo con un tratamiento de
     formulas como el de ODF (ninguno).

    Y respecto a Novell, competimos a “muerte” en miles de oportunidades, pero previamente resolvemos nuestros problemas de Propiedad Intelectual, asegurando que eso nunca repercuta
    a ningún cliente. Sabes cuánto ha aumentado la facturación de Novell (y por tanto extensión de SUSE Linux) en 9 meses desde la firma del acuerdo?. Un 245%… Eso significa ni más ni menos que los usuarios quieren dejarse de historias y elegir sin más lo que
    más les satisfaga sin más complicaciones, y que esos acuerdos tan criticados, cumplen su función: INTEROPERABILIDAD

     

     

    En fin Miguel Angel …. Como ves, me haces trabajar mucho
    J (es broma estoy encantado de hacerlo)… Pero aunque estoy seguro que no habré movido en mucho tu opinión, ya que en España nos cuesta bastante cambiar de opinión en
    Política, Religión, etc … y añado, en informática ;-), espero que al menos pongas de vez en cuando en cuarentena, o contrastes, mucha de las informaciones que circulan por ahí.

     

    El hecho de que vengan desde muchos sitios, no significan que sean más veraces. Significan que su capacidad para extender informaciones (verdaderas o falsas) y crear opinión,
    es muuucho mas efectiva que la de Microsoft.

     

  10. @Jorge, los estandares deben competir, resolver necesidades reales de usuarios, y ser escogidos por los usuarios en base a su eficacia.

    Si no fuera así, no tendriamos por ejemplo TCP/IP y tendríamos OSI de ISO. O solo tendriamos TokenRing, y no Ethernet …

    La competencia promueve la innovación. Microsoft no tiene nigún problema en soportar ODF y no somos “enemigos” de ODF. En absoluto. Apoyamos la coexistencia de estandares, la conversión entre unos y otros, y no dejar al usuario sin la capacidad de elegir. No es realista pretender que un solo formato de fichero es capaz de responder a las necesidades de usuarios/empresas/administraciones con requisitos tan dispares.

    ¿Cual es el problema? Pues en mi opinión, que a algunos les asusta el resultado de la competencia directa por el usuario entre formatos de fichero.

    Y yo me pregunto: Si promueves un estandar tan bueno y excelente, ¿Por qué no le dejas que fluya y arrase en las preferencias de los usuarios?, ¿Por qué en su lugar intentas evitar, o reducir a toda costa las posibilidades de libre elección en un mercado libre?

  11. @Miguel Angel, me parece un lujo debatir en base a argumentos como los que se están exponiendo, y te lo agradezco. Cerremos el debate si quieres. En efecto creo que es dificil el cambio de postura, pero solo querría apuntar como a Microsoft se le pide permanentemente que demuestre su inocencia frente a cualquier acusación, por peregrina que sea.

    Esto debería ser al revés. ¿Acusas?…Pues demuestra. ¿Alguien dice que ECMA no ha dado login y password a los cuerpos de normalización para que accedan a la resolución de comentarios?

    Bueno, pues pidámosle que lo demuestre, que hable algún miembro de un cuerpo de normalización y diga: "me llamo xxx, y ECMA no me ha dado acceso a esa WEB". No pidais a Microsoft que demuestre que eso no es así. ¿REsulta que a fecha de hoy solo los NB pueden acceder a esos comentarios? claro, es el característico ocultismo de Microsoft: Bien, que se demuestre… Ah, no, que si se indaga un poco resulta que eso forma parte de la directiva de ISO… Bueno es igual. ¿Quién va a defender a Microsoft?.

    En fin. Hay mucho de eso. Yo lo vivo en primera persona, y no dejo de sorprenderme.

    @Jorge, por no ser muy reiterativo solo te diré que la competencia de estándares es un hecho. Es una realidad que ha ido promoviendo la innovación. Los estándares exitosos son los que resuelven problemas reales de los usuarios, los que se enfrentan exitosamente a nuevos requisitos y los usuarios los escogen en consecuencia. Eso es así, y seguirá siendo así. Si haces una busqueda en internet sobre el número de docuentos colgados en WEBS en ODF, te encontraras con la sorpresa de que no llegan ni a mover el 2º decimal. Es decir: 0,00%. Con todos mis respetos hacia ODF, que no tengo ninguna intención de polemizar sobre este formato de fichero, pero ¿Está ese estandar en disposición de constituirse en el único posible? ¿Está en esa situación de resolver auténticos problemas y en consecuencia haber sido escogido por los usuarios libremente?¿Que opinarían los usuarios de PDFs que representan el 70%? ¿o los de Microsoft que representan el 20%? ¿A que viene ese intento de "exclusividad"?

    La convivencia y la traslación entre formatos es el camino mas rico, y me temo que el único. ¿O tampoco vamos a aceptar el inminente estandar CFD del W3C? Ah.. ya. Que W3C es cool, y ECMA no…

  12. @Federico, te agradezco tu profundo interés en este asunto. Aunque desde ópticas evidentemente diferentes, es algo que compartimos.

    Sin embargo, esto es un blog personal, no es un "Pregunta a Microsoft cualquier cosa que se te ocurra y pídele además que demuestre que No"… a no ser que lo que busques sea un perfecto DoS.

    No me invites a demostrarte permanentemente asuntos. Si tienes pruebas REALES, de lo que dices, mas allá de referenciarte a ti mismo, exponlas, pero no me pongas a mi en ese caso la carga de la prueba, ni mucho menos proponerme retos ni historias.

    No es admisible que Microsoft sea "culpable de algo hasta que no se demuestre lo contrario", que es la tesis de partida que va guiando tus comentarios, por cierto, muy contradictorios.

    "Es cierto que hay programas hoy que pueden leer .DOC sin usar software de Microsoft, pero esos programas lo han logrado a través de un esfuerzo enorme de ingeniería inversa, y sin un ápice de ayuda en la forma de documentación de Microsoft.".

    Amigo mio. ¿En que quedamos? ¿Se puede o no se puede? La respuesta es SI. Y desde luego sin tanta ingeniería inversa como pretendes, ¿O crees que los programadores de por ejemplo Corel se dedican a hacer ingeniería Inversa sobre Microsoft? No amigo no. Pero
    luego tu mismo te respondes

    "If you have to extract information from Microsoft Excel workbooks, Microsoft PowerPoint presentations, or Microsoft Word documents, you can use several methods. These methods include API programming calls, Office Open XML, XML, RTF, or HTML.".

     Vaya … Ninguno de estos necesita un solo byte Microsoft…!!Que cosas !!

    Pero bueno, puestos a extraer información de los links que te he puesto, yo extraigo este otro párrafo (te reconozco que de penosa traducción, por cierto) que era el que queríe indicarte al referenciarte el enlace:

    Formatos de archivo binario de Microsoft Office

    loadTOCNode(3, ‘moreinformation’); Microsoft hace su .doc que están disponibles bajo un covenant libre de regalías que no lo demanda a cualquiera que desea implementar todos o parte de estas especificaciones en sus productos. La implementación incluye
    la capacidad de utilizar la documentación de especificación para análisis y propósitos de referencia forense. También Formato de archivo de Dibujo de Microsoft Office para 2007 y Formato de archivo de Visual Basic para Aplicaciones (VBA) para 2007 están disponibles
    para este programa.

    La documentación que cubre las especificaciones binarias de formato de archivo es acumulativa y cubre el formulario más actual de los formatos binarios de archivo así como de las versiones anteriores. Si desea recibir la documentación, póngase en contacto con
    Microsoft en la dirección de correo electrónico siguiente para iniciar el proceso de registro de acuerdo … bla, bla bla …

    ¿Vaya, osea que esa documentación de binarios (que no se necesita para nada con OpenXML), objeto de las ingenierías inversas mas complejas y arriesgadas está disponible by the face … Y desde hace años? Que de tiempo perdido, ¿no?

    Pero vamos, el debate es sobre OpenXML, formato de fichero que ADEMÁS de permitirte recuperar y reproducir FIDEDIGNAMENTE la información almacenada en esos binarios… y "liberarlos" de la aplicación primaria que los generó (vuelvo a utilizar la palabra
    que tanto te gusta, por si se te ocurre alguna otra interpretación original.) te posibilita implementaciones (aplicaciones) que recogen el máximo conocimiento existente a fecha de hoy sobre formatos de fichero. Y eso es mucha tecnología y conocimiento. aunque
    parece que algunos prefieren obviarlo sistemáticamente, y en su lugar, dedicar todo el tiempo al "descrédito".

    Y respecto a ECMA, te recuerdo la palabra ÚNICOS. Cometarios ÚNICOS. Por ejemplo. El asunto de las fechas ha sido remitido por… digamos, ¿20 paises? Bien. Pues eso es UN comentario, no 20.

    Pero vamos, en cualquier caso, eres muy libre de quitar de entrada credibilidad a cualquiera que salga a contar una historia diferente, como acaba de hacer el exSecretario General de ECMA en su recien iniciada aventura de blogger.

    Pero claro, ya sabemos…¿Que va a saber este buen señor sobre Fast-track, estandares, procesos, comentarios etc..? Pues nada …

  13. Miguel Angel Fernández dice:

    Héctor, me gustaría conocer tus comentarios al respecto de esta noticia:

    http://www.groklaw.net/article.php?story=20071206131310362

    Como tu bien dices, que nadie se lleve a engaño. Microsoft no piensa permitir, de ninguna manera, perder el control sobre *su* formato.

    Saludos.

  14. required dice:

    PDF es un estandar unico, la movida la va a tener XPS cuando la querais estandar.

    De siempre la idea de un estandar es que sea unico para el dominio para el que funciona.

    Por eso y por que pdf esta implementado en cientos de lectores tanto libres como privativos y en decenas de editores tanto libres como privativos, desde hace lustros.

    Odf tardo 5 años en estandarizarse y conto con un numero insignificante de comentarios, porque Spectra OpenXML como lo llamais, va a salir de la nada y aprobarse por fast-track con los cientos de comentarios que tiene. Cualquier otra iniciativa con esos comentarios habria sido descartada sin mas.

  15. ArturoMD dice:

    Hola Héctor,

    leí con atención la entrada a la que haces referencia, la que titulaste como "desinformando sobre OpenXML".

    Tras ella, y movido por el interés que suscitó en mí los argumentos que esgrimías, me he dedicado a ratos a investigar y profundizar en el tema.

    No dudo que Microsoft tenga, esta vez, la voluntad de lanzar un formato abierto que permita realmente interoperar ¡por fín!.

    Sin embargo, la visión que das en tu blog, en comparación con otras hacen que de verdad no pueda concebir que OpenXML de verdad sea bueno para la industria. Para empezar, porque no has argumentado algunas de los motivos por los que se ha creado la "plataforma" NoOOXML. http://www.noooxml.org/petition-es/

    Quizás, ¿Podrías rebatirlas técnicamente?

    Muchas gracias.

  16. FilEMASTER dice:

    @requiered: sabes cuantas clases de tornillos estandar hay??????

  17. required dice:

    Pero sabras que unos tipos de tornillos son de hidrauilica, otros son para mecanica del automovil, otros para mecanica industrial, otros para electronica, en fin lo que yo habia dicho cada tipo de tornillo para un ambito especifico.

    Gracias por tu comentario

  18. Pentapolin dice:

    Según parece las objeciones desde el punto de vista técnico son claras y concretas. Me gustaría conocer la respuesta desde el punto de vista técnico a las mismas.

    Más que nada por saber si realmente son así; lo que dejaría al margen cualquier otra discusión.

  19. FILEMASTER dice:

    @Pentapolin Pero los errores que comentas son estan presentes para mantener la compatibilidad con versiones anteriores de office. No interesa que el standar este libre de errores sino que sea compatible con las herramientas de Microsoft.

  20. Pentapolín dice:

    @FILEMASTER, bueno, lo que quería decir es que si las objeciones se basan en fallos técnicos de la especificación habría que conocer cuáles son para así corregirlos.

    Yo no estoy muy puesto (sic) en el tema, por eso intentaba decir que si las únicas objeciones son por problemas técnicos, en ese caso el fabricante, Microsoft, deberá revisarlas. Pero me temo que como todo lo que rodea a esa empresa tiene muchas más connotaciones que van más allá. No sé hasta que punto hay mucho, una vez más, de: no puede ser bueno pues viene de Microsoft.

  21. Miguel Angel Fernández dice:

    Estimado Héctor:

    Que yo sepa, y a pesar de los múltiples intentos de "desenmascarar" a Pamela Jones (¿Maureen 0’Gara?) que existe y es real, asociándola con algún "enemigo" con cara corporativa, han fracasado estrepitosamente. El que Groklaw esté alojado en un sitio *patrocinado* por IBM no significa que P. Jones tenga relación profesional alguna con IBM.

    Además, y como tu resaltas siempre que puedes, el hecho de que tu blog esté alojado en technet.com no signfica necesariamente que esté sancionado por Microsoft…

    En otro orden de cosas, si tienes pruebas fehacientes de que Pamela Jones es miembro de IBM o alguna de sus subsidiarias, harías bien en enviar esa información a tus superiores jerárquicos en Redmond. El coste humano y financiero que ahorrarías a tu compañía sería tremendo. No vale con dejar caer "te invito a comprobar…" casi como un "todo el mundo sabe…". Esos argumentos no sirven. Ah, y curiosamente, no sólo de OpenXML vive esa web…

    Por otro lado, comparar ECMA con OASIS es un poco aventurado. Sólo hay que echar un vistazo a la lista de miembros y lo que *se necesita* ($$$) para serlo.

    Si una y otra son fuentes fiables, ¿por qué SI ODF pasó a ser ISO via Fast-Track y OOXML no?.

    Muy simple. No hay manos negras. El formato propuesto por Microsoft deja más dudas de las que despeja. Y eso, en un estandar ISO, no puede dejarse al azar.

    Saludos.

  22. jorge dice:

    esta va a ser la pregunta mas simple -pero quizas mas dificil de responder-: ¿por que se intenta hacer un estandar nuevo cuando ya existe opendocument? si no fuese lo suficientemente bueno, ¿por que no ayuda microsoft a mejorarlo y lo adopta? estamos otra vez ante el dvd+r y el dvd-r, ante el blueray y el hd-dvd.. la incertidumbre de que haya varios estandares/sistemas para un mismo fin no hace mas que confundir al usuario y entorpecer la interoperabilidad.. ¿porque le cuesta tanto a microsoft aceptar formatos de otros y se molesta en reinventar la rueda una y otra vez?

  23. Consejo dice:

    Sr Montenegro metete a politico, ganarias mas dinero.

    Creo que se te daria bastante bien.

  24. Miguel Angel Fernández dice:

    Hector:

    ¿De todos los miembros de ECMA *quiénes* tiene derecho efectivo a voto? ¿Y en OASIS?. ¿Por qué la especificación ODF (http://docs.oasis-open.org/office/v1.1/OS/OpenDocument-v1.1.pdf) está contenida en un documento de 738 páginas y Office Open XML son más de 6.000? ¿Por qué si Microsoft YA es miembro de pleno derecho de Oasis y por consiguiente aprobó ese estándar, duplica esfuerzos en otro comité para crear uno prácticamente desde 0, y realizando todo tipo de maniobras para que se apruebe por la vía rápida?.

    Y no. No es un plebiscito contra Microsoft. Si Microsoft *realmente* hubiera querido estandarizar algo, ya habría liberado sus especificaciones para archivos .xls o .doc hace mucho tiempo. Y un ejemplo meridiano lo tenemos en PDF.

    Y en cuanto a la Fundación Gnome…

    Bueno, sólo decirte que aunque Gnome es un extraordinario entorno de escritorio, sus cabezas visibles, los que guían su desarrollo y dictan hacia dónde van (un tal Nat Friedman y otro tal Miguel de Icaza) son desde hace unos años empleados de Novell, tras la adquisición de Ximian.

    Ostras, se me olvidaba que el año pasado firmásteis un pacto de "no agresión" con Novell…

    Lo dicho, demasiadas sombras y poca luz.

    Saludos.

  25. Miguel Angel Fernández dice:

    Héctor, por un problema con mi navegador he posteado por duplicado la última entrada. Te pido disculpas y te rogaría tuvieses a bien eliminar la última.

    Gracias.

  26. Maligno dice:

    Héctor, enhorabuena por tu blog, me parece un trabajo encomiable que alguien cómo tú tenga la paciencia de dedicarnos tanto tiempo en responder todas y cada una de las dudas.

    Saludos … y no pongas alga así antes de las vacaciones de navidad!

    😉

  27. jorge dice:

    @Hector lo que dices no tiene ningun sentido, que haya varios estandares similares pero incompatibles para documentos, soportes, etc no ayuda en nada, al contrario, entorpece la interoperabilidad. ¿en que ayuda que haya dvd+r y dvd-r? solo genera confusion. ¿en que ayuda que haya guerras de formatos como blueray o hd-dvd? no ayuda, perjudica a la sociedad, que ve como sus peliculas favoritas pueden no funcionar en su reproductor porque se lanzan exclusivamente para el reproductor de la competencia para presionar al mercado. el estandar no esta para competir y para usarse como arma, esta para armonizar, para que todas las partes puedan llegar al consenso, para que todos puedan participar y mejorar ese estandar y trabajar con una base comun. ese estandar ya existe, se llama opendocument y nace del consenso de todas las partes interesadas.

  28. Miguel Angel Fernández dice:

    Hola Héctor:

    He leído tu réplica con mucha atención. Si bien hay algunos, pocos, puntos en los que te podría dar la razón, el hecho cierto es que hasta que no se demuestre lo contrario, sois sospechosos de muchas cosas. Y eso, amigo mio, pesa y mucho.

    Estaba redactando una entrada, respondiendo punto por punto a todas tus observaciones, cuando he caido en la cuenta de que no estoy hablando con alguien, digamos, neutral. Sois parte interesada. Legítimamente interesada, si. Pero interesada. Con lo cual *siempre* me vas a rebatir, de una u otra forma todos los argumentos que te doy.

    El debate sobre Office OpenXML y ODF no es un debate meramente técnico. Tenéis mucho que perder en este debate, y vosotros os jugáis vuestro monopolio de facto.

    ¿Sabes lo que sinceramente pienso?. Que Office OpenXML será estándar ISO. Antes o después. Pero que sea un estándar de verdad, eso sólo el tiempo lo dirá.

    Mientras tanto, entrar en este tipo de disquisiciones contigo me parece harto improductivo.

    En otro orden de cosas, me hace sonreírme un poco por dentro el que saques a la luz,como miembro de Microsoft Corporation aunque sea de forma personal, términos como FUD, interoperabilidad y cuarentena.

    Estas mismas palabras son las que, actualmente y debido a vuestro historial y cultura de empresa, han impedido que se mirara con otro enfoque este estándar. Naturalmente es sólo mi opinión.

    Yo personalmente con este post doy por cerrada mi participación en este hilo, ya que no va a llevarme a ningún lado salvo, claro está, mantener una interesante y enriquecedora charla.

    Sólo me resta agradecer el tiempo que dedicas a escribir.

    Saludos.

  29. jorge dice:

    @Hector ese "intento de exclusividad" como tu lo llamas es pura logica y viene de la poca necesidad que tiene el sector de duplicar costes y esfuerzos por implementar dos formatos equivalentes pero incompatibles sin que ello aporte ni una sola ventaja. viene de que solo perjudica al usuario tener dos estandares "iguales", como en el caso de blueray y hd-dvd o dvd-r y dvd+r como te he dicho. opendocument esta siendo adoptado por grandes empresas y administraciones de muchos paises y se estan migrando los documentos a este formato. todos estan invitados a utilizarlo, incluso microsoft office lo soporta. ¿que sentido tiene entonces seguir confundiendo a los usuarios con formatos incompatibles entre si, si ya hay un estandar y es absurdo duplicar esfuerzos? (y tambien es aplicable a CFD)

  30. jorge dice:

    "Si haces una busqueda en internet sobre el número de docuentos colgados en WEBS en ODF, te encontraras con la sorpresa de que no llegan ni a mover el 2º decimal. Es decir: 0,00%"

    y mientras que google solo encuentra 67200 documentos en formato de texto odt, del formato de microsoft ooxml hay la inmensa y abrumadora cantidad de..  ¡541 documentos en todo el mundo! que barbaridad.. eso debe ser un 0,0000000000% ..se ve que la gente esta deseando adoptar ese formato

  31. uptokiss dice:

    El pdf no es un formato para documentos ofimaticos, es un formato para archivos de impresion.

    No terjiversemos las cosas. Se trata de cual es mas popular si odf o ooxml.

    Por el momento el odf es estandar ISO y ademas es mucho mas popular que el ooxml, por que habria que estandarizar un formato impopular y ligado a una sola compañia.

  32. Federico Heinz dice:

    Hector,

    tu artículo repite el mantra de que ECMA 376 permite “liberar” billones de documentos almacenados en formatos binarios.

    Lamentablemente, esta afirmación no es cierta. Te invito a leer <a href="http://federratas.codigolibre.net/?p=36">un artículo en mi blog</a> en el que explico por qué
    no lo es. La versión sencilla y excesivamente abreviada del argumento es que una aplicación que soporte el 100% de ECMA&nbsp;376 sigue sin poder leer un archivo .DOC o .XLS a menos que <b>también</b> soporte estos formatos que Microsoft sigue negándose a publicar,
    y para cuya decodificación ECMA&nbsp;376 sigue sin ofrecer ayuda alguna, o utilice software provisto por Microsoft.

    Acerca de quién tiene tanto interés en entorpecer el proceso, te sugiero que le preguntes a tus propios colegas, los que por un lado los expusieron al bochorno de presentar una especificación tan pobre que dio lugar a no menos de 1795 observaciones técnicas,
    y por otro no pudieron resistir la tentación de <a href="http://ec.europa.eu/idabc/en/document/7186">comprar los votos que no podían obtener por medio de la persuasión</a>.
    Afortunadamente, los procedimientos de ISO soportaron razonablemente bien la actitud destructiva de Microsoft, pero no ha sido gratis: como consecuencia directa de las acciones de lobby de Microsoft, <a href="http://federratas.codigolibre.net/?p=51">ISO/IEC
    JTC1 SC34 ha quedado paralizado</a>, y no encuentra manera de continuar con su importante trabajo.

    Sólo nos queda esperar que ECMA ofrezca respuestas aceptables a todas las observaciones técnicas, y que Microsoft deje de comportarse como un niño rico de cinco años a quien le niegan un caramelo. Bajo esas condiciones, OOXML puede ser aceptable. De ahí
    a que sea un motivo de celebración, hay un largo camino, por cierto.

  33. jorge dice:

    "es que no es OpenXML quien busca exclusividad."

    recordemos que microsoft SI es quien ha buscado siempre la exclusividad y ha atormentado a sus usuarios con formatos cerrados para garantizar el vendor-lock-in (igual que otras empresas, todo sea dicho). que exista openxml solo se debe a la popularidad que esta teniendo opendocument, por desgracia para unos pocos y beneficio de los demas. microsoft lleva ya una larga tradicion de tacticas muy cuestionables por las que ha sido demandada por muchas empresas en varios paises, con varias condenas a sus espaldas. es simple y llanamente normal que haya una gran desconfianza (se recoge lo que se siembra)

    "con mas de 200 aplicaciones"

    que no tienen mas remedio que soportar los formatos de microsoft, como han intentado hacer siempre.. pero es curioso que algunos se llenen la boca mencionando la cantidad de programas que soportan su formato cuando nisiquiera microsoft office sigue el estandar ooxml.. (y ahora viene lo de que se puede soportar "a varios niveles" el estandar, algo muy "habitual" y que "facilita" la interoperabilidad ante todo..)

    ahora la pregunta del millon, quien apoya OOXML? (y soportar ese formato no significa apoyarlo) alguien aparte de microsoft?

  34. Federico Heinz dice:

    Héctor,

    lamentablemente, no me conformo con que afirmes que lo que digo no es correcto: sería bueno que fundamentes por qué no es correcto. Sobre todo porque no contestas a ninguno de mis argumentos, sino sólo a argumentos que a primera vista son parecidos, pero revelan ser completamente distintos cuando los lees con atención.

    Por ejemplo, en mi comentario no hablé de que sólo Microsoft puede implementar OOXML, que es lo que tu pretendes "refutar" con las "más de 200 aplicaciones" (entre las cuales hay de todo menos programas que compitan con MS Office). Lo que dije es que no es cierto que OOXML ayude en lo más mínimo a "liberar billones de documentos almacenados en formatos binarios", y te apunté a un artículo en el que fundamento mi afirmación. Si pretendes falsear mi afirmación, todo lo que tienes que hacer es explicar cuál es la manera de convertir un archivo .DOC, .XLS o .PPT a sus equivalentes OOXML *sin usar software de Microsoft*. Espero ansioso tu respuesta.

    Me permito señalarte que el documento al que vinculé no es simplemente un artículo de un miembro, sino *el informe oficial del convocador saliente de SC34*, en el que no habla meramente de la reunión de Tokio en particular, sino de lo que estuvo pasando en el último semestre, que comienza expresando su conmiseración con el convocador entrante por tener que asumir una tarea imposible, y termina sugiriendo que quizás lo mejor sea tratar los estándares que faltan fuera de ISO, porque SC34 ha quedado tan golpeado por la actitud de los países que entraron a él con el único propósito de votar a favor de OOXML que ya no puede operar. Por supuesto que el encuentro de Tokio debe haber sido fácil: cuando no hay avances gracias a que no se pueden hacer votaciones, no hay mucho que trabajo que hacer…

    Acerca de la calidad de OOXML, pareces ser víctima del mismo tipo de confusión que muchos de los que hablan en favor de esta especificación: confundes a la aplicación con formato (lo que no es sorprendente, ya que OOXML es más una especificación de producto que un estándar).

    En concreto: a nadie le importa si Excel representa a las fechas internamente como un entero. Puede ser una excelente decisión de diseño de la aplicación (aunque lo del año 1900 como bisiesto, y la incapacidad de manejar fechas anteriores al 1900 probablemente lo sean menos). ¡Pero no existe ninguna razón por la que deba exportar esa decisión de diseño al formato de almacenamiento, forzando así a todas las implementaciones posibles de OOXML de implementarlo del mismo modo! En otras palabras: internamente, Excel puede usar numerales romanos para representar la fecha, pero cuando va a *almacenarlos* en un formato que pretende ser un estándar ISO, lo correcto es hacerlo de acuerdo a ISO 8601.

    Veo que ECMA ya ha hecho una propuesta para resolver este tema, lo que es un avance (aunque entiendo que lo que hará es *permitir* que la fecha esté en ISO 8601, y sigue aceptando que se las almacene en la errónea representación anterior… una pregunta: ¿Excel abrirá hojas de cálculo con fechas almacenadas en ISO 8601? ¿A partir de cuál versión?). Pero el argumento no es si OOXML puede modificarse hasta convertirse en un estándar decente (estoy seguro de que sí), sino si fue razonable presentarlo en el proceso fast-track.

    Si Microsoft hubiera presentado la especificación a través del proceso normal de estandarización de ISO, no tendría nada que objetar: ese proceso asume que la especificación inicial probablemente es incompleta y contiene errores, y prevé todo un proceso para encontrarlos y corregirlos.

    En vez de eso, eligieron el camino del fast-track, que está pensado como una manera acelerada de aprobar estándares que ya están maduros y han sido minuciosamente estudiados por otro órgano de estandarización. Aquí es donde Microsoft y ECMA se expusieron al ridículo al presentar en este proceso un estándar que evidentemente no estaba lo suficientemente maduro, al punto de recibir cientos de comentarios técnicos, cuando se supone que una especificación que llega a la instancia de fast-track sólo debería suscitar unos pocos.

    Coincido, por otra parte, con Alex Brown: no me interesa la motivación de Microsoft. Lo que me interesa es que aprendan a comportarse como seres civilizados, respeten las reglas, y dejen de intentar subvertir un proceso que tradicionalmente ha estado basado en un esfuerzo común de buena fe para convertirlo en lo que el convocador saliente de SC34 llama en su informe "standardization by corporation".

  35. Fede Heinz dice:

    Héctor,

    no te preocupes, ya había visto ese vínculo en tus comentarios anteriores. Lamentablemente, ninguno de los métodos descriptos en ese artículo satisface mi requerimiento de poder leer un archivo .DOC con 100% de fidelidad <b>sin usar software de Microsoft</b>. En el primer párrafo de esa página dice:

    <i>"If you have to extract information from Microsoft Excel workbooks, Microsoft PowerPoint presentations, or Microsoft Word documents, you can use several methods. These methods include API programming calls, Office Open XML, XML, RTF, or HTML."</i>

    Es decir: allí están descriptos los mecanismos a través de los cuales puedo usar software de Microsoft para convertir el archivo de formato .DOC a .DOCX, .XML, .RTF o .HTML (en varios de estos casos se pierde información), o usar llamadas al API de Microsoft Word para acceder a los datos representados en el archivo binario. En ninguno de los casos puedo acceder a los datos codificados dentro del archivo .DOC directamente y <b>sin usar software de Microsoft</b>.

    Es cierto que hay programas hoy que pueden leer .DOC sin usar software de Microsoft, pero esos programas lo han logrado a través de un esfuerzo enorme de ingeniería inversa, y sin un ápice de ayuda en la forma de documentación de Microsoft. Te invito, por cierto, a que desmientas lo que digo: publica aquí la URL oficial de Microosft en la que está documentado el formato binario de los archivos .DOC, .XLS y .PPT.

    Acerca de la afirmación de ECMA sobre que OOXML fue diseñado con el objeto específico de representar fielmente el cuerpo de documentos que están codificados en formatos heredados de Microsoft Office, no me consta su veracidad ni falsedad. Lo que sí afirmo es que aún si esto fuera cierto, eso no implica para nada que OOXML permita acceder a el contenido de un archivo .DOC.

    Nuevamente, te invito a demostrar que lo que digo no es correcto. Para ello, diseñemos un experimento. Supongamos que yo tengo un documento en .DOC, y un programa que lee OOXML a la perfección, y sólo OOXML. ¿Puedo leer el archivo con ese programa, sin auxilio de software de Microsoft? ¿Cómo, exactamente? Si no puedo, evidentemente el .DOC sigue siendo prisionero de Microsoft.

    Dicho sea de paso, un elogio: me alegro de ver a gente de Microsoft hablando de "liberar" los documentos, ya que admitir que los tienen prisioneros es el primer paso a darse cuenta de que los clientes les van a exigir, cada vez más fuertemente, que se los devuelvan.

    Ya que estamos hablando de experimentos, te agradecería que averiguaras internamente una respuesta a la pregunta que hice en mi comentario anterior: ¿Excel estará en condiciones de leer y procesar adecuadamente planillas de cálculo almacenadas en OOXML cuyas fechas estén codificadas en ISO 8601, tal como propone ECMA? Si lo hará, ¿a partir de cuál versión? Una forma más general, y probablemente más interesante, de la misma pregunta: ¿Microsoft se compromete a implementar OOXML de acuerdo a lo que ISO finalmente apruebe?

    El gráfico que me muestras es muy bonito, especialmente para la gente a la que le gusta mucho el color azul, pero lamentablemente no quiere decir absolutamente nada. Cualquiera puede dibujar una flecha que va de abajo a la izquierda hacia arriba a la derecha, pero el contenido de información de eso es <b>cero</b> a menos que me expliques qué dimensión mides en el eje X y cuál en el eje Y.

    Por lo demás, el texto dentro del gráfico contiene algo que no es cierto: dice que los formatos binarios son estándares de facto, rápidos, difundidos, libres (¿o gratuitos?), documentados, interoperables y disponibles para todos, pero XML es mejor. Acepto que son estándares de facto (que es todo lo contrario a un estándar), que son muy difundidos, que son más rápidos que XML y que XML es mejor. Pero toda la evidencia con la que contamos contradice que sean libres, gratuitos, documentados, interoperables o disponibles para todos.

    Acerca del blog de Jan van den Beld, es muy interesante ver cómo intenta defender lo indefendible. Primero que nada, no entiendo sus matemáticas: habla de que un comentario cada seis páginas es el par de la cancha, al tiempo que menciona que la especificación de OOXML tiene 6546 páginas y recibió 3522 comentarios, lo que en mi calculadora da aproximadamente un comentario cada 1.86 páginas, más de tres veces el ratio normal. Aún si asumiéramos que se confundió al calcular, y usó el número de propuestas de solución ya presentadas (1795) en vez del número de comentarios, el ratio es de uno cada 3.65 páginas, casi el doble de lo que, toma como "norma".

    Además, si leemos atentamente, veremos que además está comparando peras con manzanas: el número un comentario cada seis páginas parece ser, en realidad, el promedio de comentarios en el mecanismo <i>normal</i> de standardización, no en el fast-track, de modo que los casos no son comparables.

    Peor aún, su artículo no discrimina entre comentarios editoriales ( "acá falta una coma", "la palabra "byte" está mal escrita") y comentarios técnicos ("este formato no permite almacenar fechas anteriores al 1900 en hojas de cálculo", "usar máscaras de bits en una especificación XML es como ponerle estribos a un jet de combate"). Lo interesante sería calcular el promedio de comentarios <b>técnicos</b> promedio en el proceso fast-track, y ver cómo se compara con el de ECMA 375 (idealmente, usando una calculadora que funcione, no la del Sr. van den Beld).

  36. Fede Heinz dice:

    Héctor,

    te sugiero, con toda la buena onda del mundo, que antes de contestar te hagas asesorar por técnicos que entiendan del tema. Te ahorrarías así errores groseros como afirmar que se puede usar HTML para acceder al contenido de un archivo .DOC sin usar software de Microsoft. El procedimiento que las páginas a las que apuntaste sugieren consiste, básicamente, en usar Word (que,la última vez que me fijé era de Microsoft) para grabar el archivo en HTML, y luego usar un programa que soporte HTML para leer el contenido. El mismo procedimiento es el sugerido para OOXML, XML, RTF. Y el método restante, las llamadas a la API de Word, exige incluso que haya una instancia de Word corriendo en la máquina en la que lo haces.

    En otras palabras: si quieres acceder a un .DOC directamente usando un programa que sólo sabe leer OOXML, no puedes.

    Acerca de tu protesta de "ser culpable hasta demostrar lo contrario", no te he acusado de nada, de modo que mal puedes ser culpable. Tan sólo estoy aplicando el estándar habitual de discurso racional: toda afirmación debe ser fundamentada. Esa es la razón por la que mis artículos (los que tu llamas "autorreferencias") siempre contienen referencias a las fuentes originales, para que nadie tenga que creerme a mí, sino puedan verificar por sus propios medios que lo que digo es cierto.

    Por lo demás, me temo que la formulación de mi tesis no fue todo lo clara que podía ser: no afirmo que no haya aplicaciones de terceros que leen archivos .DOC, sino que OOXML no juega ningún rol en esa operación (lo que resulta evidente cuando reflexionamos que esos programas ya existían mucho antes de OOXML).

Skip to main content