Analisi tecnica di odf e ooxml
Un profilo tecnico del formato ODF
La maggior parte degli utenti di PC non percepisce come un problema l’uso del formato proprietario OOXML, che affida a Microsoft la gestione dei propri contenuti rinunciando alla propria sovranità digitale. Questa è una conseguenza dell’attività di comunicazione che l’azienda di Redmond riesce a sostenere grazie alle sue enormi risorse economiche, e allo spazio che le viene concesso a livello istituzionale.
Per ovviare a questo problema, visto che non abbiamo le stesse opportunità, cercheremo di spiegare nel modo più semplice possibile, utilizzando un linguaggio non tecnico, alcune caratteristiche tecniche di Open Document Format (ODF), che lo rendono la pietra angolare di un ecosistema aperto e indipendente dai fornitori, a difesa delle libertà digitali e dal governo dei contenuti degli utenti.
Inizieremo spiegando come decomprimere un file ODF, che non è altro che un insieme di file XML e di altri file (per immagini e video) contenuti all’interno di una cartella ZIP, per poi esaminarne i componenti interni e, in particolare, il file content.xml che contiene il corpo del documento (ovvero la proprietà intellettuale dell’utente).
L’obiettivo non è tanto valutare la conformità alle specifiche e l’interoperabilità, aspetti che saranno sempre gestiti da specialisti, ma comprendere i vantaggi per gli utenti del formato aperto e standard rispetto agli enormi svantaggi di quello chiuso e proprietario (che è un falso standard, poiché è stato approvato da ISO/IEC in contrasto con le “loro” definizioni di standard).
Per questo motivo, faremo una breve digressione conclusiva sulle caratteristiche del formato OOXML (Office Open XML), usato da Microsoft Office e Microsoft 365, per chiarire agli utenti i rischi che corrono e il danno che arrecano a se stessi e agli altri utenti quando utilizzano i formati DOCX, XLSX e PPTX, nonché il “regalo” che fanno a Microsoft, a cui affidano la gestione e il futuro dei loro contenuti.
Analisi di un file ODF
Prendiamo un qualsiasi documento creato con LibreOffice. Per comodità, iniziamo con un documento di testo ODT creato con LibreOffice Writer. Prima di procedere, è opportuno duplicare il file, perché un errore nella procedura potrebbe danneggiarlo e renderlo illeggibile, e spostare l’originale in un’altra cartella.
Rinominiamo la copia sostituendo l’estensione ODT con l’estensione ZIP, senza eliminare il punto. L’icona del file cambierà e diventerà quella di un file compresso. A questo punto, decomprimiamo il file per estrarre il contenuto in una cartella che avrà lo stesso nome del file, senza l’estensione.
La cartella conterrà i seguenti elementi:
– la cartella META-INF, che conterrà il file manifest.xml;
– la cartella Thumbnails, che può contenere il file thumbnail.png;
– il file content.xml, che contiene il corpo del documento;
– il file styles.xml, che contiene le definizioni degli stili;
– il file meta.xml, che contiene i metadati del file (autore, data di creazione, data dell’ultima modifica, ecc.);
– il file settings.xml, che contiene le impostazioni dell‘applicazione.
I file XML all’interno di un documento ODF devono essere conformi allo schema XML RelaxNG (Regular Language for XML Next Generation), creato da OASIS, che è più semplice e quindi più accessibile agli utenti non esperti rispetto ad altri schemi XML.
Inoltre, devono soddisfare una serie di condizioni:
– il file manifest.xml contenuto nella cartella META-INF deve elencare tutti i file presenti nell‘archivio ZIP, indicando il loro tipo di media;
– gli elementi dei file ZIP e manifest.xml devono essere strutturalmente conformi;
– tutte le funzionalità standard e opzionali (metadati, stili, tabelle, grafica, ecc.) devono essere conformi;
– le formule del foglio di calcolo devono essere compatibili con la semantica OpenFormula;
– i profili ODF, la crittografia e la firma digitale devono essere conformi in termini di sicurezza.
È sufficiente omettere un file o commettere un errore nella descrizione del suo tipo di supporto perché il file ODF diventi strutturalmente non conforme.
L’importanza del file content.xml
È sufficiente analizzare il file content.xml per comprendere i vantaggi del formato aperto e standard ODF, soprattutto se viene confrontato con il suo equivalente nel formato OOXML. Quest’ultimo varia a seconda del tipo di file, e questo da solo è un segno che lo sviluppo di OOXML non ha tenuto conto delle esigenze degli utenti ma si è concentrato sull’aumento della complessità.
Prendiamo a esempio una delle frasi più famose della letteratura mondiale: “Essere o non essere, questo è il problema”, dell’Amleto di William Shakespeare.
Il file content.xml di un file ODT che contiene solo questa frase è lungo 32 righe: le prime 18 forniscono i riferimenti agli standard (X-Forms, MathML, ecc.), elencano i caratteri impiegati negli stili del documento e definiscono gli stessi stili (in questo caso solo uno, vista la lunghezza del testo e l’assenza di formattazione).
Le successive 13 righe sono le seguenti:
<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″>To be, or not to be, that is the question</text:p>
</office:text>
</office:body>
Le prime righe definiscono il corpo del documento e ne specificano la natura. Le righe successive sono dichiarazioni che, in questo caso, non aggiungono nulla, ma che in altri contesti fornirebbero informazioni su altri elementi del documento.
La riga chiave è la seguente: “<text:p text:style-name=”P1″>To be, or not to be, that is the question</text:p>”, che definisce un paragrafo, ne dichiara lo stile (P1) e ne fornisce il contenuto. Il testo è chiaro e leggibile da qualsiasi utente.
Naturalmente, documenti e contenuti più complessi corrisponderebbero a un file content.xml più complesso, ma sempre nel rispetto della leggibilità dei contenuti e della semplicità dello schema XML.
Vediamo cosa succede nel caso dello stesso documento salvato in formato DOCX, chiuso e proprietario, e artificialmente complesso. Il file si chiama document.xml e non content.xml. Questo non avrebbe alcuna importanza se non fosse un ulteriore segno della complessità del formato, visto che nel caso di Excel il file si chiama workbook.xml, e nel caso di PowerPoint si chiama slide1.xml e così via.
Il file document.xml di un documento di testo che contiene solo la frase “To be, or not to be, that is the question” è lungo 41 righe: la prima fornisce i riferimenti a tutti gli elementi proprietari utilizzati (come wordprocessingCanvas, VML e WordML), mentre tutte le righe successive si riferiscono al contenuto.
<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”>To be, or </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”> to be, </w:t>
</w:r>
<w:r w:rsidR=”6B254FF6″>
<w:rPr/>
<w:t>that</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>is</w:t>
</w:r>
<w:r w:rsidR=”6B254FF6″>
<w:rPr/>
<w:t xml:space=”preserve”> the question</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>
Un file XML praticamente illeggibile. Sfido qualsiasi utente a ricostruire un testo, anche semplice, a partire da un documento XML come questo se il file originale è danneggiato.
Nel caso di ODF, invece, siamo stati in grado di ricostruire persino documenti di centinaia di pagine o presentazioni di decine di diapositive, perché il contenuto era leggibile da chiunque, anche da chi non ha competenze tecniche.
Proviamo a immaginare le dimensioni dei file content.xml e document.xml se al posto della frase del principe Amleto ci fossero le 5.566 righe dell’intera tragedia in versione originale. In questo caso, i numeri parlano: content.xml è lungo 5.598 righe (32 righe in più rispetto al testo), mentre document.xml è lungo 93.289 righe (87.723 righe in più rispetto al testo).
La complessità dei file è nascosta agli utenti, che sullo schermo vedono un documento dall’aspetto normale e non hanno idea del fatto che il file che stanno salvando sul proprio disco rigido o nel cloud ha caratteristiche simili a quelle dei file proprietari utilizzati nel secolo scorso: documenti illeggibili senza il software con cui sono stati creati.
Gli utenti ritengono di aver compiuto progressi significativi in termini di sovranità digitale, perché usano un formato che credono aperto e standard, ma che in realtà è peggiore dei formati binari del Novecento, che non erano altro che la trascrizione di quello che era in memoria.
Questo perché, essendo basato su XML, il file è di fatto un software, e può essere modificato da remoto con un semplice aggiornamento (come accade molto spesso, visto che la sintassi XML viene periodicamente modificata senza avvertimento, ogni volta completamente diversa, e basata su parametri noti solo a Microsoft).
OOXML, quindi, è un formato ancora più chiuso e proprietario dei formati binari che ha sostituito nel 2006. Questi ultimi, essendo il risultato della trascrizione su file del contenuto della memoria, potevano essere emulati, mentre OOXML è imprevedibile perché è un software, ed è quasi impossibile da emulare senza uno studio costante delle sue numerose evoluzioni.
OOXML rappresenta l’ultima evoluzione della strategia di lock-in Microsoft, a difesa di un fatturato stimato in decine di miliardi di dollari all’anno, con un utile netto pari almeno al 90% (queste cifre sono stime, in quanto i dati degli analisti non sono più disponibili e sono probabilmente inferiori alle cifre effettive).
È giunto il momento – per le organizzazioni sovranazionali, i governi centrali e locali, le aziende, e i singoli utenti – di aprire gli occhi e compiere un passo in avanti verso la sovranità digitale, adottando ODF e abbandonando OOXML.