Una inmersión técnica en ODF
por Italo Vignoli
Para escribir este artículo, he ido más allá de los límites de mis conocimientos técnicos, que son los de un usuario avanzado que ha estudiado a fondo los formatos estándar y sus características, para entender por qué los formatos estándar -uno de los pilares de la soberanía digital- y los formatos privativos -su opuesto, y uno de los mayores obstáculos a la soberanía digital- no son percibidos como un problema por la mayoría de los usuarios de PC, que siguen utilizando los formatos privativos de Microsoft y ponen el acceso y la disponibilidad de sus contenidos en manos de la empresa estadounidense.
Para tratar de remediar este problema, intentaré explicar de la forma más sencilla posible, utilizando un lenguaje no técnico (que puede chocar a los desarrolladores, pero este artículo no va dirigido a ellos), algunas características técnicas del Formato de Documento Abierto (ODF), que lo convierten en la piedra angular de un ecosistema abierto e independiente del proveedor para los documentos ofimáticos, que defiende las libertades digitales de todos los usuarios y la gobernanza de sus contenidos.
Empezaré explicando cómo desempaquetar un archivo ODF, que no es más que un conjunto de archivos XML y otros archivos (para imágenes y vídeos) contenidos en una carpeta ZIP, para examinar sus componentes internos y, en particular, el archivo content.xml, que es el que contiene el cuerpo del documento (es decir, la propiedad intelectual del usuario).
No se trata tanto de evaluar la conformidad (el cumplimiento de las especificaciones) y la interoperabilidad (la capacidad de intercambiar archivos de forma coherente entre herramientas), ya que de estos aspectos se ocuparán siempre los especialistas, sino de comprender las ventajas para el usuario del formato abierto y estándar frente al formato cerrado y privativo (que es falsamente estándar, ya que fue aprobado por ISO/IEC desafiando «sus» definiciones de estándares).
Por este motivo, haré una breve digresión final sobre las características del formato OOXML (Office Open XML) utilizado por Microsoft Office y Microsoft 365, de nuevo para aclarar a los usuarios los riesgos a los que se enfrentan y el daño que se hacen a sí mismos y a otros usuarios cuando utilizan los formatos DOCX, XLSX y PPTX, así como el «regalo» que están haciendo a Microsoft, a quien de hecho están confiando la gestión y el futuro de sus contenidos.
Análisis de un archivo ODF
Toma cualquier documento que haya creado con LibreOffice. Por comodidad, recomiendo empezar con un documento de texto creado con LibreOffice Writer, con la extensión ODT. Antes de hacer nada, duplica el archivo, porque un error en el procedimiento podría hacerlo ilegible, y mueve el original a otra carpeta.
Cambia el nombre de la copia, sustituyendo la extensión ODT por la extensión ZIP, sin borrar el punto. El icono del archivo se convertirá en el de un archivo comprimido. Si se vuelve blanco o vacío, es que has hecho algo mal o has borrado el punto. Sigue todos los pasos hasta que el icono se convierta en el de un archivo comprimido.
En este punto, haz clic con el botón derecho en el icono y selecciona «descomprimir» o «expandir» para extraer el contenido del archivo comprimido en una carpeta con el mismo nombre que el archivo sin la extensión.
La carpeta contendrá los siguientes elementos
- la carpeta META-INF, que contendrá el archivo manifest.xml
- la carpeta Thumbnails, que puede contener el archivo thumbnail.png
- el archivo content.xml, que contiene el cuerpo del documento
- el archivo styles.xml, que contiene las definiciones de estilo
- el archivo meta.xml, que contiene los metadatos del archivo (autor, fecha de creación, fecha de la última modificación, etc.)
- el archivo settings.xml, que contiene la configuración de la aplicación.
Cada archivo XML de un documento ODF debe ajustarse al esquema XML RelaxNG, o REgular LAnguage for XML Next Generation, creado por OASIS en 2001 y 2002, que es más sencillo -y por tanto más accesible para usuarios no técnicos- que otros esquemas XML. Las reglas de empaquetado se definen en las especificaciones OpenDocument Packaging.
Además de la validación del esquema, debe cumplir una serie de condiciones.
- Conformidad estructural: los elementos de los archivos ZIP y manifest.xml
- Conformidad de funcionalidad: toda la funcionalidad estándar y opcional (metadatos, estilos, tablas, gráficos, etc.)
- Conformidad de fórmulas: las fórmulas de las hojas de cálculo deben ser compatibles con la semántica de OpenFormula
- Conformidad de seguridad: Perfiles ODF, cifrado, firma digital
El archivo manifest.xml contenido en la carpeta META-INF debe enumerar todos los archivos del archivo ZIP, con su tipo de soporte:
<manifest:manifest xmlns:manifest=”urn:oasis:names:tc:opendocument:xmlns:manifest:1.0″>
<manifest:file-entry manifest:full-path=”/” manifest:media-type=”application/vnd.oasis.opendocument.text”/>
<manifest:file-entry manifest:full-path=”content.xml” manifest:media-type=”text/xml”/>
<manifest:file-entry manifest:full-path=”styles.xml” manifest:media-type=”text/xml”/>
<!– thumbnails, settings, etc. –>
</manifest:manifest>
Basta con omitir un archivo o cometer un error en la descripción de su tipo de medio para que el archivo ODF sea estructuralmente no compatible.
ODF: la importancia del archivo content.xml
Para comprender las ventajas para el usuario de un formato estándar abierto como el ODF frente a un formato privativo, incluso uno teóricamente abierto como el OOXML, basta con un rápido análisis del archivo content.xml de los archivos ODF y su equivalente en los archivos OOXML, que difiere en función del tipo de archivo (y esto por sí solo es señal de que el desarrollo del OOXML no tuvo en cuenta en absoluto las necesidades del usuario, sino que se centró en aumentar artificialmente la complejidad).
Tomemos un primer ejemplo, basado en una de las frases más famosas de la historia de la literatura universal, a saber, «Ser o no ser, ésa es la cuestión», pronunciada por el protagonista de Hamlet, de William Shakespeare.
El archivo content.xml de un documento de texto que sólo contiene esta frase tiene 32 líneas: las 18 primeras proporcionan referencias a todos los estándares utilizados (como X-Forms y MathML), enumeran las fuentes utilizadas en los estilos del documento y definen los estilos (en este caso sólo uno, dada la longitud del texto y la ausencia de formato).
Las 13 líneas siguientes son las siguientes:
<office:body>
<office:text>
<office:forms form:automatic-focus=”false” form:apply-design-mode=”false”/>
<text:sequence-decls>
<text:sequence-decl text:display-outline-level=”0″ text:name=”Illustration”/>
<text:sequence-decl text:display-outline-level=”0″ text:name=”Table”/>
<text:sequence-decl text:display-outline-level=”0″ text:name=”Text”/>
<text:sequence-decl text:display-outline-level=”0″ text:name=”Drawing”/>
<text:sequence-decl text:display-outline-level=”0″ text:name=”Figure”/>
</text:sequence-decls>
<text:p text:style-name=”P1″>Ser, o no ser, esa es la cuestión</text:p>
</office:text>
</office:body>
Las primeras líneas definen el cuerpo del documento y el hecho de que se trata de un texto. Las siguientes líneas son declaraciones que, en este caso, no añaden nada, pero que en otros contextos proporcionarían información sobre otros elementos del documento.
La línea clave es la siguiente: <text:p text:style-name=“P1”>Ser, o no ser, esa es la cuestión</text:p>, que define un párrafo, declara su estilo (P1) y proporciona el contenido: Ser o no ser, esa es la cuestión. Claro y legible por cualquier usuario, que ahora tiene las claves para acceder al documento y gestionar su contenido, es decir, el producto de su cerebro.
Por supuesto, documentos y contenidos más complejos corresponderían a un archivo content.xml más complejo, pero siempre respetando la legibilidad de los contenidos y la simplicidad del esquema XML.
OOXML: qué ocurre dentro del archivo
Veamos qué ocurre en el caso del mismo documento guardado en formato DOCX, cerrado y privativo, y artificialmente complejo. El archivo se llama document.xml y no content.xml, y esto -obviamente- no sería significativo si no fuera una muestra más de la complejidad del formato, dado que en el caso de Excel el fichero se llama workbook.xml y en el caso de PowerPoint se llama slide1.xml, y así sucesivamente.
El archivo document.xml de un documento de texto que sólo contiene la frase «Ser o no ser, ésa es la cuestión» tiene 41 líneas: la primera proporciona referencias a todos los elementos privativos utilizados (como wordprocessingCanvas, VML y WordML):
<w:body>
<w:p xmlns:wp14=”http://schemas.microsoft.com/office/word/2010/wordml” wp14:paraId=”2DC08235″ wp14:textId=”776AF5CB”>
<w:r w:rsidR=”6B254FF6″>
<w:rPr/>
<w:t xml:space=”preserve”>Ser, o </w:t>
</w:r>
<w:r w:rsidR=”6B254FF6″>
<w:rPr/>
<w:t>not</w:t>
</w:r>
<w:r w:rsidR=”6B254FF6″>
<w:rPr/>
<w:t xml:space=”preserve”> no ser, </w:t>
</w:r>
<w:r w:rsidR=”6B254FF6″>
<w:rPr/>
<w:t>esa</w:t>
</w:r>
<w:r w:rsidR=”6B254FF6″>
<w:rPr/>
<w:t xml:space=”preserve”> </w:t>
</w:r>
<w:r w:rsidR=”6B254FF6″>
<w:rPr/>
<w:t>es</w:t>
</w:r>
<w:r w:rsidR=”6B254FF6″>
<w:rPr/>
<w:t xml:space=”preserve”> la cuestión</w:t>
</w:r>
</w:p>
<w:sectPr>
<w:pgSz w:w=”11906″ w:h=”16838″ w:orient=”portrait”/>
<w:pgMar w:top=”1440″ w:right=”1440″ w:bottom=”1440″ w:left=”1440″ w:header=”720″ w:footer=”720″ w:gutter=”0″/>
<w:cols w:space=”720″/>
<w:docGrid w:linePitch=”360″/>
</w:sectPr>
</w:body>
Oscuro e ilegible. Desafío a cualquier usuario a reconstruir un texto de cualquier complejidad a partir de un documento XML como éste, si el archivo original está dañado. En el caso del ODF, pudimos reconstruir incluso documentos de cientos de páginas, o presentaciones de decenas de diapositivas, porque el contenido era legible por cualquier usuario, incluso los no técnicos.
Intentemos imaginar el tamaño del archivo content.xml y del archivo document.xml si, en lugar de la frase del príncipe Hamlet, estuvieran las 5.566 líneas de toda la tragedia, en la versión original escrita por William Shakespeare. En este caso, la diferencia habla por sí sola: content.xml tiene 5.598 líneas (32 líneas más que el texto), document.xml tiene 93.289 líneas (87.723 líneas más que el texto).
La complejidad de los archivos como nueva estrategia de bloqueo
Esta complejidad de los archivos se oculta intencionadamente al usuario, que ve un documento de aspecto normal en la pantalla y no tiene ni idea de que está escribiendo un archivo en su disco duro o en la nube que tiene características muy similares a las de los archivos privativos que se usaban en el siglo pasado, que son ilegibles sin el software con el que se escribieron.
Un usuario que cree haber avanzado mucho en términos de soberanía digital porque utiliza un formato que cree abierto y estándar pero que, por el contrario, es aún peor que los formatos binarios de 1900 -que no eran más que la escritura de lo que había en la memoria- porque, al estar basado en XML, es hijo de un algoritmo que puede modificarse a distancia con una actualización rutinaria (como ocurre en la realidad, donde el mismo documento se escribe en formato DOCX pero con una sintaxis XML completamente distinta cada vez, basada en parámetros que sólo conoce el vendedor, es decir, Microsoft).
Por tanto, es un formato aún más cerrado y privativo que los formatos binarios a los que sustituyó en 2006. Estos últimos, al ser el resultado de escribir en ficheros lo que había en memoria, eran predecibles y podían emularse, mientras que el OOXML es impredecible debido al algoritmo, y por tanto casi imposible de emular sin un estudio constante de sus múltiples evoluciones.
OOXML es un formato teóricamente abierto y estándar, que en realidad es cerrado y privativo, y representa la última evolución de la estrategia bloqueo que sustenta todos los productos de Microsoft para la productividad individual, defendiendo un volumen de negocio estimado en más de 25.000 millones de dólares anuales, con un beneficio neto estimado en más de 20.000 millones de dólares anuales (todas las cifras son estimaciones, ya que las cifras de los analistas ya no están disponibles y probablemente sean inferiores a las cifras reales).
Tal vez haya llegado el momento de que las organizaciones supranacionales, los gobiernos centrales y locales, y probablemente también los usuarios individuales, abran los ojos y den un sencillo paso adelante hacia la soberanía digital, es decir, la gobernanza de los documentos y su contenido con independencia de las opciones comerciales de una única empresa, adoptando ODF y abandonando OOXML.