Recentemente molti utenti dei redattori dei depositi del Processo Civile Telematico PCT si sono trovati di fronte a un campo misterioso nella creazione di depositi che prevedevano un'attestazione di conformità secondo le specifiche tecniche ultime pubblicate. E in molti hanno chiesto a cosa servisse il campo Complementare . La riposta più sarcastica è anche quella corretta a niente . Va semplicemente ignorato.
Il campo è uno zombie. Non è parto della fantasia di un autore di The Walking Dead. Ma lo è di quella del produttore del redattore? In realtà quel campo esiste nella documentazione ufficiale che regola i depositi. E sappiamo anche che prossimamente verrà utile, ma non sappiamo ancora perché. Lo standard PCT. La notizia sarebbe finita qui, il mio compito di giornalista dilettante sarebbe finito. Occupandomi da anni e a volte con battaglie aspre, di standard , di interoperabilità e delle interconnessioni di questi ambiti con la tematica della concorrenza e del pubblico accesso alle informazioni, una semplice spiegazione non può bastarmi. Siccome il tema viene affrontato tutte le volte che ne parlo con i responsabili che creano questi servizi, i quali mi vedono come se scendessi da Marte con l'ultimo treno cercherò di spiegare perché non è cosa da nulla, non in sé, ma per ciò che sta dietro. Come sapranno i lettori di Diritto e Giustizia, gli atti nel PCT si depositano con una PEC. La PEC di un deposito, per andare a buon fine, contiene una serie di file, dei quali almeno due obbligatori un atto processuale firmato digitalmente, e un elemento descrittivo del deposito che fornisce una serie di meta-informazioni necessarie al sistema di ricezione per correttamente indirizzare e trattare il deposito. Altri elementi sono facoltativi e dipendono dal tipo di deposito e da un misto di regole tecniche e processuali. Ad esempio, se si tratta di un atto introduttivo, sarà prevista una procura ad litem e le regole tecniche diranno come questa deve essere allegata. Se essa deve essere presente o no non lo devono decidere le norme tecniche, ma le norme processuali. Un normatore tecnico troppo solerte potrebbe pretendere che un documento descritto come procura venga sempre allegato, rifiutandosi di procedere se non lo trova, e dunque rifiutando il deposito. Ma noi sappiamo che non sempre la procura è necessaria nel caso la parte sia abilitata a stare in proprio in giudizio, art. 86 c.p.c. , o nel caso in cui l'Avvocato abbia una procura generale ad lites , oppure ancora quanto rappresenti ex lege un ente es l'Avvocatura di Stato . Nel caso descritto, il rifiuto sarebbe illegittimo . Ma se a rifiutare l'atto fosse un cancelliere, potremmo sempre insistere e sperare che il cancelliere, che conosce la normativa, cambi idea, convinto delle nostre idee. In un sistema automatizzato che non si limitasse a prevedere questo errore come bloccante , ma lo prevedesse come fatale , non consentirebbe nemmeno al cancelliere di prendere una decisione autonoma, il rifiuto avverrebbe automaticamente e inesorabilmente. Ci sarebbe un'illegittimità implicita, non sorretta da un provvedimento con una motivazione, ma da un fatto tecnico, senza un responsabile. Per questo è importante che le regole tecniche siano da un lato corrette e per quanto possibile indenni da errori di questo tipo, dall'altro lato sufficientemente elastiche da consentire un intervento umano per gestire l'eccezione. Personalmente trovo inaccettabile, se non addirittura amministrativamente illegittimo , che errori i quali non determinino un'impossibilità materiale di processare il deposito, vengano arbitrariamente qualificati come fatali . Da una irregolarità non è mai possibile derivare una nullità processuale se l'atto ha raggiunto il suo scopo. Non dovrebbe esser lecito impedire a un atto di raggiungere il suo scopo processuale per via tecnica, per quanto nobile sia il proposito. Possiamo derivare tale principio dall'abbondante casistica in tema di irregolarità fiscale. Mi pare questa un'affermazione piuttosto irrefutabile, anche se a confondere le acque viene una dizione ripetuta più volte nel codice di rito nel rispetto della normativa anche regolamentare , concernente la sottoscrizione, la trasmissione e la ricezione dei documenti informatici e teletrasmessi dizione che trovo orribile, pleonastica ed eversiva del sistema. Il sistema processuale è infatti assistito oltre ai principi di razionalità e buon andamento della pubblica amministrazione, anche da quelli costituzionalmente garantiti di tutela dei diritti soggettivi, dei quali trovo che l'art. 156 c.p.c. sia espressione immediata e diretta il processo non è un gioco, le regole servono ad attribuire alle parti responsabilità nel ruolo propulsivo di un processo di parti, non a consentire a una di mettere nel sacco l'altra . Insomma, le regole non deve farle chi scrive il software, ma il legislatore. Punto. Da un punto di vista tecnico, questi discorsi sono piuttosto noti tutto il modo della normazione, nazionale e internazionale conosce la tematica da molto tempo. Le norme tecniche, o standard sono un momento fondamentale del progresso tecnico e sociale, nonché un forte motore di risparmi di tempo e di sforzi. Senza standard non avremmo le telecomunicazioni. Internet, in senso stretto, non è che un ampio insieme di standard innestati l'uno nell'altro e sovrapposti. Lo stesso PCT è uno standard, anche se uno standard particolare. Esso serve a una serie di operatori esterni per interagire con uno e un solo sistema, quello del Ministero della Giustizia. Il Ministero è anche l'ente normatore, che a sua volta usa standard normati da altri. La normazione tecnica in campo informatico si compone solitamente di alcuni o tutti i seguenti elementi un testo naturale, in parte di valore prescrittivo, equiparabile alla legge ne mutua i tratti fondamentali e in parte semplicemente descrittivo o programmatico un insieme di codice comprensibile anche a un computer, che traduce in istruzioni operative tutte o parte o un sovrainsieme delle norme, e che può avere valore normativo o di semplice esempio una o più implementazioni di riferimento, ovvero un esempio di applicazione che rispetta gli standard è fa vedere come si fa una determinata operazione dal vero , e può anche servire come test di interoperabilità. Nel PCT abbiamo la stessa articolazione abbiamo le norme ministeriali, le specifiche tecniche emesse dal Direttore Generale dei Servizi Informativi Automatizzati DGSIA , le quali sono norme vere e proprie abbiamo inoltre del codice comprensibile alle macchine, in formato XML, il quale ha anch'esso valore normativo abbiamo infine una implementazione di riferimento, un tribunale di prova, dove si possono testare le implementazioni. Questo standard ha un valore assolutamente fondamentale. Il rispetto dello standard è ciò che consente all'Avvocato di pretendere di essere rimesso in termini in caso una decadenza è intervenuta per causa a lui non imputabile. Quando ci si recava in tribunale a depositare la carta, il timbro depositato era tutto ciò che serviva. Oggi invece occorre provare di aver fatto quanto era stato richiesto e ciò nonostante il deposito non è intervenuto, o la scadenza non è stata conoscibile perché l'atto che l'ha originato non era apparso, o la comunicazione di cancelleria non era avvenuta. Gli XSD, questi sconosciuti. Nel dialogo tecnico sul rispetto degli standard, gli XSD hanno un ruolo determinante. Una norma in linguaggio naturale è soggetta a interpretazione. Un XSD no. L'XSD XML Schema Definition descrive la struttura e definisce i limiti del contenuto di un file XML eXtensible Markup Language, l'HTML del web è un particolare tipo di XML , in questo caso per estensione ciò che una macchina il server al Ministero si attende di ricevere, può ricevere, si rifiuta di ricevere in un deposito. Il tutto in un linguaggio standard, privo di ambiguità, deterministico, autoesplicativo. Ciascun tipo di deposito è caratterizzato da una nomenclatura denominata RMO Ruolo, Materia, Oggetto , che ne definisce la struttura. Ad esempio il deposito di una comparsa conclusionale in un giudizio contenzioso in Corte d'appello ha determinati contenuti, l'iscrizione a ruolo di un pignoramento immobiliare ne ha altri. Una volta applicato l'RMO corretto, la generazione di un deposito dovrebbe conseguire in maniera pressoché meccanica e deterministica. Un deposito fatto dall'Avv. Mevio a Bologna e uno identico fatto dall'Avvocato Tizio a Brescia dovrebbero avere lo stesso destino. Ovviamente Mevio e Tizio hanno tutto il diritto di ignorare l'XSD relativo, fidandosi dell'implementazione che ne abbia fatta il fornitore della propria applicazione. Ovviamente il fornitore deve avere un certo tempo per conoscere la modifica delle specifiche in primo luogo dell'XSD , per apportare le modifiche a una versione di test della propria applicazione, poter collaudare la propria applicazione contro una versione di test del sistema di deposito, predisporre la distribuzione dell'applicazione alla propria clientela in tempo utile in una finestra in cui debbono per forza coesistere le versioni vecchia e nuova dei depositi se si tratta di una modifica di un atto già previsto oppure sperabilmente prima che il nuovo deposito sia disponibile, soprattutto nel caso in cui il deposito telematico sia obbligatorio. Questa implementazione significa che la tipologia dei documenti e degli atti da inserire in un deposito, il loro nome, le informazioni associate, siano conformi ai nuovi XSD. All'utente viene presentata di solito una maschera che prevede la possibilità di inserire o selezionare le informazioni richieste. Se un campo è obbligatorio, la maschera potrà non consentire di proseguire senza la sua valorizzazione, oppure a un certo punto l'applicazione metterà sull'avviso l'utente. Quello che l'utente vede è dunque il frutto finale di un flusso normativo che vede regole generali codificate in norme specifiche e descritte in modo algoritmico e deterministico ovvero, dato un certo input, si avrà o sempre un risultato positivo, o sempre uno negativo, non importa quante volte l'esperimento è ripetuto , tale per cui, in base alle convenzioni e alle regole generali degli standard XML e XSD, e alle regole specifiche descritte dal singolo insieme di file XSD applicabili, è possibile programmare un test che affermi in modo autoritativo e matematico se un file XML che dichiara di applicare quell'XSD sia un file ben formato e valido. In un mondo perfetto, la corretta implementazione dovrebbe eliminare gli errori, e in caso di errore dovrebbe essere immediato comprendere in cosa l'XML sia errato. Questa si chiama interoperabilità , ovvero la capacità di un sistema di scambiare informazioni e servizi con un altro sistema in maniera efficiente per essere efficiente e riusabile, essa viene conseguita attraverso standard formali di comunicazione resi pubblici, accessibili e neutrali rispetto alla scelta di una determinata piattaforma. In teoria, esattamente quello che il PCT cerca di conseguire. Ma il diavolo si annida nei dettagli. In realtà, l'XSD non è affatto sufficiente , qualora esso non descriva compiutamente tutte le caratteristiche necessarie di un deposito, per cui è possibile che un file perfettamente formato e valido secondo l'XSD ed eventuali altre specifiche esterne, non vada a buon fine. Ad esempio perché un nome di file risultava troppo lungo per circostanze poco conoscibili. A volte si tratta di configurazioni locali un deposito a Roma va, lo stesso a Udine no . A volte si tratta di altre idiosincrasie. Il campo zombie. Abbiamo visto che nell'XSD sono descritti campi che debbono essere valorizzati e campi che possono essere valorizzati. Difficilmente saranno presenti campi che non debbono essere valorizzati. A volte succede negli standard, ma questi vengono marcati come riservati per uso futuro , così l'implementatore è sull'avviso che essi non debbono essere utilizzati per non rischiare di inserire valori fuorvianti. Si tratta di circostanze eccezionali e nella documentazione descrittiva la parte leggibile da un essere umano viene di solito debitamente descritto perché quel campo è inserito e vi è una prevedibilità dell'evoluzione dello standard. Il campo Complementare , abbiamo appreso solo successivamente, non va utilizzato, per cui sarebbe stato meglio marcarlo come da non utilizzare . Fortunatamente questo tipo di omissioni crea soltanto imbarazzo e richieste di assistenza da parte degli utenti. E gli utenti, in questo caso, sono avvocati che tutelano un diritto costituzionalmente garantito. In altri casi le conseguenze sono state più importanti, come quando nel deposito degli F23 era richiesto come obbligatorio l'inserimento di un codice che negli F23 stessi non era ancora presente. La conseguenza di tale richiesta impropria e impossibile da rispettare è stata ovviamente che per un certo periodo non era possibile depositare telematicamente gli F23, con somma gioia di chi aveva ‒ senza saperlo ‒ già pagato tramite F23 e non poteva spendere tale pagamento in giudizio per via telematica. Ci si chiede chi abbia effettuato i collaudi, ma la domanda resterà retorica. Ciò che non deve risultare retorico è il ruolo che i sistemi informativi di accesso alla giustizia debbono mantenere essere un fattore abilitante, non impeditivo o distorsivo , né del funzionamento della giustizia, né del ruolo dell'avvocato, del cancelliere, del giudice, né del gioco della libera concorrenza. Discorso che lasciamo però ad altri contributi. È un compito difficile per chi lo realizza, sia dal lato di chi riceve, sia dal lato di chi invia quando un sistema diventa estremamente complesso, ci insegna Gödel, diventa impossibile da descrivere matematicamente. Proprio per questo, in tutti i campi dove esiste un problema di interoperabilità, nessuno sforzo può essere risparmiato per mettere assieme le parti e creare scambio di informazioni per risolvere le inevitabili difficoltà pratiche. Hackaton, plugfest, sono nate proprio da questa esigenza. E funzionano. A quando la prima PCT plugfest? * L'autore assiste professionalmente vari fornitori di servizi per il PCT nell'articolo sono contenute sue opinioni personali che non rappresentano necessariamente le posizioni delle rispettive parti rappresentate.