In un precedente articolo in cui riportavo delle riflessioni su una notizia riguardante il plugin ODF di Oracle per Microsoft Office, è stata sollevata da un lettore (commento #13) la presunta mancanza di (piena) aderenza allo standard da parte del filtro di importazione realizzato da quest’ultima per la versione 2007 del suo noto pacchetto.
Si tratta di un’accusa che circola da tempo nei confronti della casa di Redmond, che a questo punto merita di essere analizzata e sviscerata alla luce del draft ufficiale dell’ODF (che trovate qui) e delle critiche che le vengono mosse.
Alcune di queste si trovano in un documento redatto dall’ODF Alliance che ne racchiude le tre più importanti, sostenute da diverse altre fonti anche autorevoli, come ad esempio Rob Weir di IBM, a capo della ODF Technical Committee, e che in proposito ha scritto due articoli (che trovate qui e qui) che esaminano nel dettaglio la più controversa delle tre, cioè quella relativa alle formule presenti nei fogli di calcolo.
Doug Mahugh di Microsoft spiega nel suo blog in che modo le formule sono implementate in Office 2007, e le motivazioni che hanno portato a quelle scelte, con esempi concreti e riferimenti ad altre implementazioni.
Al di là delle opinioni personali, per dirimere la questione penso sia necessario affidarci all’unico strumento che uno sviluppatore dovrebbe prendere in considerazione: il draft dello standard, per la lettura e comprensione del quale è necessario valutare per bene il significato e il peso delle parole utilizzate.
La parte che descrive sintassi e semantica delle strutture da utilizzare per racchiudere le formule si trova a partire da pagina 186 (“Formula”), all’interno della sezione 8.1.3 (“Table Cell”), che recita:
Formulas allow calculations to be performed within table cells. Every formula should begin with a namespace prefix specifying the syntax and semantics used within the formula. Typically, the formula itself begins with an equal (=) sign and can include the following components:
segue un elenco di possibili elementi e alcuni esempi. Mi sono permesso di evidenziare due parole, che rappresentano la chiave di lettura delle frasi in cui appaiono, e che sono state la fonte delle polemiche.
Chi ha avuto a che fare coi documenti ufficiali, conosce bene il significato del verbo should, che nello specifico non assume un valore condizionale, ma imperativo e, quindi, vincolante. Indica, infatti, un requisito che lo sviluppatore deve obbligatoriamente implementare secondo le indicazioni che vengono fornite, altrimenti non viene soddisfatta l’aderenza allo standard.
Pertanto una formula deve necessariamente far uso di un namespace che ne definisca la struttura sintattica e semantica, in modo tale che il parser possa essere in grado di interpretarne correttamente il contenuto.
Appare di tutta evidenza che questo meccanismo consente di definire formule aventi strutture diverse, persino all’interno dello stesso documento o addirittura fra le celle di una stessa tabella (o foglio).
Quest’enorme flessibilità che ne dovrebbe rappresentare un innegabile punto di forza si trasforma, però, in una pesante pietra al collo che è stata messa al concetto di interoperabilità, e il motivo mi sembra a dir poco lapalissiano.
Se ogni software house può decidere in che modo memorizzare le formule del suo applicativo nei file ODF, allora queste saranno interpretabili soltanto da programmi dotati di appositi parser. Basta, pertanto, che ognuno scelga un proprio formato, essendo l’unico a supportarlo, e il gioco è fatto: risulteranno illeggibili dagli altri.
Ovviamente, non so se per ignoranza (non si può conoscere tutto), buona fede, o volutamente, questo dettaglio spesso non viene citato e viene riportata, invece, la frase seguente, che però inizia per typically e fornisce poi un esempio di come potrebbe (e qui il condizionale ci sta tutto) essere strutturata una formula.
Il significato del vocabolo in questione è decisamente chiaro, e non potrebbe essere altrimenti: se lo standard prevedesse rigidamente un ben preciso formato, la parola usata non sarebbe certamente “tipicamente”…
Eppure le critiche che si leggono in giro giocano per lo più su questa frase, che a loro dire indicherebbe il formato da utilizzare, e servendosi dell’esempio fornito nella documentazione come “prova”: il formato è quello. Non si scappa.
Si tratta di un comportamento che, a voler essere buoni, è possibile etichettare come ingenuo, o come intellettualmente disonesto per chi, pur conoscendo i termini della questione, continua a propinare delle autentiche falsità pur di difendere ciecamente fantasie o ideologie che di carattere tecnico non hanno nulla a che spartire.
Rob Weir, che ho citato prima, arriva addirittura a sostenere che uno standard può anche essere ambiguo, e che non sarebbe giusto approfittare di ciò per minarne l’interoperabilità, citando come esempio l’HTML, che non specifica il colore del background (iniziale).
Questo signore, nonostante la posizione che ricopre, mostra scarsa conoscenza sia dell’HTML che della realizzazione degli standard. Per il primo perché dovrebbe ben sapere che HTML non nasce come standard di presentazione di documenti, cosa che avverrà soltanto anni dopo con l’introduzione di qualche tag e, meglio ancora, dei famigerati fogli di stile.
Il secondo, e ben più grave, è il fatto che uno standard nasce proprio per mettere ordine e dovrebbe essere quanto di più chiaro e meno ambiguo possibile, per permettere a chiunque di implementarlo e favorendo, appunto, l’interoperabilità.
Giusto per fare un esempio, è come se il comitato che ha realizzato il JPEG avesse definito tutto a puntino, ma omettendo la trasformata da applicare ai dati. Oggi ci sarebbe chi avrebbe scelto la DFT, chi la DCT, e altri ancora che avrebbero potuto andare a pescare dal calderone delle centinaia di trasformate wavelet finora a disposizione.
Il caos, insomma, come potete immaginare. La verità è che il gruppo che ha realizzato l’ODF ha commesso un madornale errore, lasciando aperta un’enorme falla che ha, di fatto, buttato nel cestino tutti gli sforzi atti ad arrivare a un formato che garantisse l’agognato Santo Graal: l’interoperabilità.
Le altre due critiche sono meno importanti, ma val la pena di analizzarle e spendere qualche parola per riportare analoghe conclusioni. Liquidiamo subito il più semplice che riguarda le “tracked changes”, cioè l’elenco delle modifiche apportate in un documento.
A pagina 78, nella sezione 4.6 (” Change Tracking”), si legge subito:
This section describes how changes in text documents can be represented.
dal termine che ho evidenziato si capisce subito la natura facoltativa della funzionalità, che se obbligatoria avrebbe dovuto usare, invece, should o specificare mandatory, com’è in uso in questi casi.
Essendo il supporto non vincolate, chi implementa l’ODF può, quindi, legittimamente evitare di prendere in considerazione quest’aspetto, rimanendo in ogni caso nella “legalità”, cioè nel rispetto dello stesso.
Merita più attenzione l’ultimo punto, quello che riguarda il mancato supporto alla crittazione con password dei documenti. Le informazioni su questa parte si trovano a pagina 698, sezione 17.3 (“Encryption”), ma prima bisogna fare un salto alla pagina precedente, che introduce il capitolo 17 (“Packages”) e dove si legge immediatamente:
This chapter describes the package format that optionally can be used in OpenDocument.
Qui, oltre al verbo can, che sarebbe già di per sé sufficiente a dirimere la questione, si sono sbottonati con un ridondante optionally. Si tratta, ancora una volta e inoppugnabilmente, di caratteristiche opzionali che la software house può, quindi, evitare di implementare.
Oltre alla crittazione troviamo quindi la compressione in formato zip di tutti i file facenti parte del documento, come l’immagine di preview. Tutto opzionale. Rimane da capire se il comitato si sia reso conto delle conseguenze che avrebbe la mancata adozione dello ZIP, in quanto facoltativo, sulle dimensioni di un documento.
La cosa si commenta da sé ed evidenzia la leggerezza, ma soprattutto l’inadeguatezza delle persone che sono state chiamate a definire questo “standard” che, da quanto detto, preferisco prender con le pinze usando le virgolette col termine.
Finita la disamina delle critiche, che sono state dimostrate del tutto infondate, all’implementazione ODF di Microsoft, riporto una critica che è stata mossa questa volta all’ODF, e che riguarda proprio l’adozione dello ZIP come struttura per archiviare tutti i file di un documento.
Ebbene, la beffa si aggiunge al danno se riflettiamo sul fatto che questo formato non è mai stato standardizzato, come si può leggere dall’apposita nota che rimanda a questo indirizzo, a cui tra l’altro nemmeno si può accedere (non permette di autenticarsi come utenti anonimi).
Poco importa (ma non per un documento standard, che dovrebbe essere quanto meno accessibile), perché con una rapida ricerca è possibile recuperarne una copia in qualche mirror. Aprendo il file ci si rende conto dell’ovvio (per chi ha studiato il formato ZIP), in quanto si tratta del documento di testo denominato “Info-Zip” che all’inizio recita:
Info-ZIP note, 970311: this file is based on PKWARE’s appnote.txt of 15 February 1996. It has been unofficially corrected and extended by Info-ZIP without explicit permission by PKWARE.
da cui risulta piuttosto eloquente l’ultima frase (in particolare nella parte evidenziata).
In ogni caso si tratta del lavoro fatto da un gruppo di persone che hanno applicato tecniche di reverse engineering agli archivi generati dal famoso programma che ha introdotto questo formato, realizzato da PKWARE, e lo stesso documento afferma che vi possono essere informazioni non accurate o errate.
Ricapitolando, abbiamo un documento ufficiale (ISO) che sui tre punti chiave e oggetto di discussione lascia completamente mano libera all’implementatore, e che si affida a un formato, quello ZIP (in ogni caso opzionalmente utilizzabile come contenitore), che a sua volta non è mai stato standardizzato (è soltanto uno “standard di fatto”, sebbene sia il più diffuso).
Il risultato è un documento che introduce uno standard che, di fatto, è inutilizzabile ai fini dell’interoperabilità. Se consideriamo che era proprio questo l’obiettivo con cui era stato approntato, possiamo affermare senza alcun dubbio che è un completo fallimento.
Il comitato sta lavorando alla versione 1.2 che dovrebbe porre rimedio (ma non alla standardizzazione del formato ZIP), ma ormai la frittata è fatta, perché esistono già documenti e applicazioni che adottano la 1.0 o la 1.1 (quest’ultima mai standardizzata).
Per rendere l’idea, quando la 1.2 sarà standardizzata ci si troverà in una situazione simile a quella che si ha attualmente col JPEG e il suo successore, il JPEG 2000. Sarebbe meglio utilizzare quest’ultimo in quanto molto più efficiente, robusto e versatile, ma il primo è estremamente diffuso e non si potrà interromperne il supporto; di conseguenza la gente, per essere sicura che chiunque potrà vedere le sue immagini, continuerà a utilizzare il primo, rendendo di fatto inutile il secondo…
