Segnatura XML, #1: la segnatura per tutti (a tutela del contesto)

Riprendiamo il tema della segnatura interoperabile (segnatura XML) definita nell’allegato 6 delle linee guida del documento informatico e ricordiamo che, archivisticamente, la segnatura è il legame fra l’evidenza materiale del documento e i suoi dati di descrizione presenti in un registro. La segnatura XML ha invece lo scopo principale di accompagnare un documento trasmesso fra due pubbliche amministrazioni; anche se contiene informazioni di descrizione del documento trasmesso, è pensata per guidare le operazioni di registrazione da parte dell’amministrazione destinataria e non per essere associata in modo stabile al documento per descriverlo e contestualizzarlo. Quest’ultimo compito dovrebbe invece essere assolto dai metadati definiti nell’allegato 5 alle stesse linee guida, con una sovrapposizione funzionale e una duplicazione operativa di cui si è già detto.

Facciamo un passo indietro per inquadrare la questione, senza la pretesa di arrivare a conclusioni perentorie ma solo per evocare le entità in gioco,

Se l’impiegato di un’azienda vuole comunicare al direttore le consistenze degli articoli presenti in magazzino ha varie forme (documentarie) per farlo. Prendiamone tre, che hanno in comune l’uso di un messaggio e-mail con eventuale file di foglio di calcolo allegato, giusto per avere degli esempi su cui fissare le idee.

Forma 1: un messaggio e-mail con

• oggetto “Consistenze del magazzino – 12 ottobre 2024“;
• corpo del testo: “Egregio Direttore, le invio in allegato le consistenze del magazzino centrale che ho personalmente rilevato oggi 12 ottobre 2024. Francesco Angiolieri“;
• allegato un file di foglio di calcolo, con nome “consistenze.ods” e contenuto con tre colonne: codice articolo, articolo, quantità.

Forma 2: un messaggio e-mail con

• oggetto “Consistenze“;
• corpo del testo: “Egregio Direttore, in allegato le consistenze di oggi Francesco Angiolieri“;
• allegato un file di foglio di calcolo, con nome “consistenze_2021_10_12.ods” e contenuto con descrizione del magazzino, data e autore della rilevazione e tre colonne: codice articolo, articolo, quantità.

Forma 3: un messaggio e-mail con

• oggetto “Consistenze del magazzino – 12 ottobre 2024“;
• corpo del testo: “Egregio Direttore, di seguito le consistenze del magazzino che ho personalmente rilevato oggi 12 ottobre 2024:”, segue tabelle con tre colonne: codice articolo, articolo, quantità, e infine la firma “Francesco Angiolieri“.

Tralasciando questioni di riuso dei dati per elaborazioni automatiche, di opponibilità a terzi dei documenti scambiati, di distinzione fra dati e istruzioni di rappresentazione dei dati o di conservazione a lungo termine, qui ci interessa evidenziare come tutte le tre forme siano in grado di veicolare il medesimo contenuto informativo, affidabile, completo e contestualizzato. Variano invece le operazioni che il destinatario deve compiere per acquisire quanto ricevuto nel proprio patrimonio informativo-documentale. In altre parole, cambiano attività di gestione documentale da parte del destinatario.

Forma 1: il destinatario ha bisogno di mantenere sia il messaggio e-mail sia il file allegato (nessuno dei due, infatti. è esaustivo) e stabilire fra essi una connessione stabile. Probabilmente sceglierà di mantenere tutto nella casella di posta. [NB: il direttore di un esempio può farlo, se sei un funzionario pubblico e conti di usare la tua casella e-mail come archivio… meriti un’amichevole bacchettata sulla mano!]

Forma 2: il destinatario potrebbe scegliere di memorizzare il solo file allegato in una cartella ad hoc sul suo PC. [NB: di nuovo, il direttore di un esempio didascalico potrebbe anche usare una cartella del file system per tenere dei documenti, se tu sei un funzionario pubblico e pensi di usare una cartella – anche se di rete, anche se condivisa – come archivio… porgi pure l’altra mano, please!]

Forma 3: il destinatario sembra avere come unica scelta quella di mantenere i messaggi nella casella email. Potrebbe anche salvare il messaggio e-mail come stampa PDF (che salvaguarda solo le parti visibili del messaggio e-mail) o come file .eml (che preserva ulteriori dati relativi al messaggio e-mail, per esempio le intestazioni nascoste) nella solita cartella ad hoc.

Generalizziamo e annotiamo intanto due questioni, senza dar loro una soluzione definitiva, ma solo perché siano ben presenti nella riflessione:

• che rapporto esiste fra file e documento? il file è un documento? il file è una componente di un documento?
• come mantenere associati fra loro contenuto informativo e dati di contesto?

Tornando alla segnatura XML per il protocollo interoperabile, questa è un codice che ha un significato solo per chi ne ha condiviso le regole, cioè la pubblica amministrazione. A ben vedere però la segnatura ha poco senso per chi non aderisce alla convenzione linguistica del suo codice. Del resto la segnatura.xml è pensata per essere interpretata da una macchina, da un sistema di gestione informatica dei documenti che, a sua volta, è un lusso che nessun cittadino può permettersi e che le imprese, se lo hanno, implementano in modo funzionale al proprio business più che a quello della pubblica amministrazione con la quale interloquiscono. Risultato è che le utili informazioni contenute nella segnatura XML sono ignorate se non vanno addirittura irrimediabilmente perse.

C’è, infatti, una domanda annosamente ricorrente che riguarda il documento informatico formato da una pubblica amministrazione: “ma il numero di protocollo dove lo vedo?!“. Domanda ragionevole con alcune risposte, nessuna definitiva. Il punto teorico è che non esiste protocollo senza un documento perfezionato, ma se il documento perfezionato è informatico allora non vi si può “apporre sopra” il numero di protocollo a meno di modificare la sequenza dei bit e pregiudicarne l’integrità. Quindi, a meno di casi particolari, il numero di protocollo viaggia esternamente al file-documento ed è a questo associato con qualche artificio (che solitamente coinvolge l’impronta del file). Se il documento è in formato PDF, con ulteriori artifici (descritti e regolamentati anche da AgID) si può stampigliare successivamente un numero di protocollo (e altri dati di segnatura – la segnatura quella “vera”, archivisticamente parlando), sfruttando alcune caratteristiche di versionamento della firma PAdES. Ci sono poi casi più raffinati, in cui il documento è magari una registrazione in una banca dati e ciò che viene comunicato non è il documento nel suo stato di originale ma nel suo stato di copia che quindi potrebbe avere incorporati anche i dati di registrazione dell’originale: dimensione affascinante, ma qui vogliamo rimanere distanti dai confini della metafisica e mantenerci ancorati a un materiale presente dove il documento informatico risente ancora della secolare tradizione del documento analogico.

Nella comunicazione fra pubbliche amministrazioni il numero di protocollo con cui l’amministrazione mittente ha registrato il documento è annotato nella segnatura XML e il sistema ricevente lo elabora e lo annota nei dati di registrazione del documento ricevuto. Chi poi visualizzerà quel documento tramite il sistema di gestione documentale lo vedrà sempre mostrato in una cornice di dati descrittivi e di contesto (fornita dal sistema di gestione documentale stesso) che conterrà quindi anche il numero di protocollo assegnato al documento dal mittente, indispensabile per futuri riferimenti.

E quando il destinatario non è una pubblica amministrazione? La maggior parte dei protocolli informatici, quando invia un documento tramite e-mail o PEC, tende a ripetere il numero di protocollo anche nell’oggetto del messaggio e/o nel testo (corpo) dell’e-mail. Tuttavia, il ricevente potrebbe non essere in grado di mantenere l’informazione del numero di protocollo associata in modo stabile al contenuto informativo (il file) ricevuto. In questo caso l’amministrazione mittente opera come l’addetto del magazzino nel primo caso dell’esempio, ma il destinatario potrebbe operare come il direttore nel secondo caso (memorizzare il file e non il messaggio e-mail) anche e soprattutto perché potrebbe avere bisogno di impiegare il documento ricevuto per altri usi (es.: un certificato di destinazione urbanistica da usare in un atto notarile).

Da un punto di vista archivistico, quando si perde il numero di protocollo, si dice che si perde il contesto del documento. E per un archivista un documento senza contesto non è documento. Memorizzare un file ricevuto via e-mail o posta certificata, senza conservare l’intero messaggio e-mail/PEC (analogo della busta cartacea con timbro postale) e/o la segnatura.xml è in effetti un rischio concreto di perdita di contesto.

Ci sono quindi due fronti su cui intervenire:

• ampliare la platea dei fruitori della segnatura XML a tutela del contesto;
• impiegare i dati di contesto contenuti nella segnatura XML per successivi (ri)usi del documento.

Ampliare la platea di destinatari della segnatura XML

La segnatura XML, si è detto, è pensata per l’elaborazione automatica dei dati che veicola. Eppure, una soluzione semplice, da affiancare alla segnatura XML e utile all’elaborazione (e alla consapevolezza) umana potrebbe essere… un foglio di stile! Un foglio di stile consente di dare una forma umanamente intellegibile e “formattata” a un contenuto memorizzato con esclusiva attenzione alla semantica dell’informazione, proprio come nel caso della segnatura XML. Le informazioni della segnatura potrebbero essere rappresentate in un documento (PDF, eventualmente firmato o sigiallto) che possa fare da copertina ai file-documento trasmesso. La forma documentaria del foglio di stile potrebbe contenere:

• l’intestazione dell’amministrazione che ha formato il documento, con eventuale logo e recapiti;
• la descrizione del documento, articolata in dati strettamente descrittivi, dati procedurali e dati archivistici:
• oggetto;
• autore (ufficio e/o responsabile e/o firmatario);
• data di formazione del documento;
• numero di protocollo (o altro registro) e data di registrazione;
• fascicolo archivistico in cui è conservato il documento (o, meglio, indicazione del fascicolo archivistico del procedimento a cui il documento afferisce);
• la lista delle componenti digitali che costituiscono il documento (i file) con i rispettivi dati identificativi (nome del file e impronta digitale);
• informazioni testuali che illustrano brevemente il significato dei dati sopra elencati e le modalità di verifica dell’integrità dei file.

Invero, esisterebbe anche un’altra soluzione per evitare la perdita di contesto, una soluzione a monte, sistemica ma di più complessa implementazione: non inviare mai originali informatici ma loro copie (informatiche) con indicazioni del percorso (magari codificato in un glifo o contrassegno elettronico – un QR-ode per intenderci) per accedere all’originale conservato nel sistema documentale dell’amministrazione che lo ha prodotto. Questo sarebbe anche l’obbligo di legge (art. 43 comma 1-bis e dintorni, tutto il Capo IV insomma) e verrebbe in aiuto anche nei casi in cui ci sia necessità di stampare il documento informatico.

Vantaggi della segnatura intellegibile? Mantenere i file ricevuti da una pubblica amministrazione insieme alle loro informazioni di contesto e così trovarsi a conservare davvero un documento. Possibilità, in caso di stampa, di unire la stampa del documento alla stampa della segnatura, a mo’ di copertina. Inoltre, si diffonderebbe un po’ di consapevolezza sul documento informatico, che, appunto non è un file.

Riutilizzare il documento

Se ricevo un documento informatico da un pubblica amministrazione tramite posta elettronica certificata, lo strumento al momento più formale possibile, capace di garantire certezza e integrità del contenuto, nel caso in cui volessi memorizzare l’intero messaggio per mantenerlo esternamente al client di posta elettronica (o all’interfaccia web messa a disposizione dal gestore della casella certificata), ben potrei salvare l’intero messaggio nel formato .eml (formato standard definito nella RFC 822). In questo caso, oltre al testo eventualmente contenuto nel corpo del messaggio e ai file allegati (che potrei anche salvare singolarmente), riuscirei a memorizzare e preservare:

• la busta di trasporto firmata dal gestore della casella PEC e, conseguentemente,
• la data certa della comunicazione;
• il mittente certo (inteso almeno come indirizzo di posta certificata);
• la garanzia che i file allegati siano quelli salvati e non altri e che non siano stati alterati dopo la ricezione.

Si tratta di un’operazione realizzabile con i comuni client (software) di posta elettronica e che le interfacce web dei gestori PEC solitamente consentono. Il file .eml poi si può aprire con il client di posta elettronica o con appositi visualizzatori, che si occupano anche di verificare la validità della busta di trasporto e quindi l’affidabilità complessiva del messaggio. A ben vedere, poi, se dovessi condividere con una terza persona un file ricevuto via PEC e altri dati di contesto non riscontrabili direttamente nel file, potrei condividere l’intero messaggio .eml (in questo caso utilizzato anche come “formato contenitore”). Tuttavia:

• quanti lo fanno?
• quali destinatari sarebbero disposti ad accettare come valido o utile un file .eml? Lo aprirebbero agevolmente?

Sul secondo punto si può purtroppo sottolineare come anche nelle sentenze di tribunale, almeno quelle che talvolta arrivano all’attenzione dei records manager perché trattano e sembrano stabilire giurisprudenza in tema di gestione documentale, quando si parla di messaggi e-mail o PEC si fa molto spesso riferimento a loro stampe, corredate, nel caso della posta certificata, dalle stampe delle relative ricevute di accettazione e consegna. Non ricordo di aver mai letto qualcosa del tipo “il resistente produce la memorizzazione in formato standard RFC 882 dei messaggi di posta elettronica/certificata…”.

Per inciso, anche il file .eml ottenuto da un messaggio e-mail non certificato si porta dietro, oltre ai dati di contesto di cui abbiamo fin qui parlato, anche ulteriori dati (es.: una manciata di indirizzi IP) utili se non all’immediata validazione di certe entità (date e mittenti certi) almeno ad una loro ricostruzione da realizzare, se necessario, accedendo ai sistemi dei gestori coinvolti nella trasmissione.

Concludento, la produzione di una segnatura interpretabile dall’uomo con il corretto corredo di contenuto didascalico, verrebbe in aiuto anche della (ri)condivisione di un documento: insieme al documento, potrei inviare la segnatura-copertina che indentifica in modo certo quel documento e lo collega al suo produttore, fornendo, se necessari, ulteriori elementi per la sua validazione. Come accennato, sembrerebbe più appropriato, per questo scopo, fare affidamento ai metadati del documento come definiti nell’allegato 5, ma nell’attesa che questi siano realmente implementati insieme a prassi consolidate per mantenerli associati al documento anche quando questo abbandona il sistema documentale che lo ha prodotto….

(Foto di Thomas B. da Pixabay)