La scoperta di SGML

Meditando sulla problematica della documentazione ho iniziato nel 1999 una ricerca nelle metodologie di documentazione e mi sono subito imbattuto in sgml. Tecnologia di diversi anni fa che sta tornando in auge con l'avvento di xml.

Mi proverò a spiegare i concetti sottostanti sgml. Per farlo userò una nostra tecnologia che per certi versi gli assomiglia: le stampe.

Supponiamo di prendere la stampa del rendiconto e di volerla documentare. Innanzitutto dovremmo mettere in chiaro che la nostra tecnologia prevede una netta separazione tra il contenuto e il modo di presentarlo. Infatti la stampa non è altro che un insieme di record nominati che contiene un'elenco di campi prefissati. Esternamente alla stampa---in genere usando il postscript---ma in astratto con qualunque tool, si formatta e si predispone l'output. Dovrebbe risultare abbastanza chiaro a tutti che, previ ampliamenti della libreria, un nostro programma può produrre stampe o output nei formati più diversi.

Stabilita l'indipendenza tra contenuti e presentazione esaminiamo un'altro problema. Supponiamo di voler documentare la particolare stampa che è il rendiconto. Supponiamo inoltre di aver corredato il software di possibilità di formattazione tali che l'utente finale può autonomamente costruirsi il look della stampa. Arrivati a questo punto diventa essenziale descrivere in modo compiuto il contenuto della stampa.

La descrizione potrebbe essere una cosa di questo tipo:

1. Il rendiconto è un' insieme di documenti separati. Il numero varia da 1 a N in base alla richiesta di elaborazione. Tutti i documenti ricadono nel medesimo periodo di attività (cioè i dati sono tutti compresi tra una data inizio e una data fine).
2. Ogni documento contiene tutti i dati relativi ad un singolo portafoglio (reale o frutto di un cumulo di portafogli reali) in un determinato periodo. Ogni documento contiene:
1. Una parte di testata con informazioni generali.
2. La sezione riepilogativa E1.
3. Il quadro relativo ai movimenti di liquidità.
4. ....
5. Il quadro finale.
3. Ciascuna delle sezioni indicate viene rappresentata da uno o più records che hanno una sequenza ben definita. Ad esempio:
1. Inizio liquidità
2. Movimenti di liquidità.
3. Fine liquidità.
4. Ciascun record riporta un'insieme di campi definito.

Questa descrizione può essere generalizzata nel modo che segue:

1. Un documento è un contenitore nel quale vi sono:
1. Altri contenitori.
2. Dati elementari.

Immaginiamo ora di formalizzare questa descrizione, di prevedere nella formalizzazione il fatto che certe cose possono non esserci e che altre invece ci sono sempre. Di indicare se un dato elemento appare una sola volta o può apparire più volte. Se due elementi sono in alternativa esclusiva tra loro. Ecc.

Un tale linguaggio descriverebbe compiutamente il contenuto del rendiconto. In pratica si descrive il contenuto semantico del documento. Ovviamente tale linguaggio avrebbe dei vantaggi:

1. Si potrebbe prevedere una produzione guidata della formattazione, guidata sulla base dei dati presenti nel documento da formattare. Ovviamente non è facile produrre una cosa complessa come il rendiconto, ma è facile produrre le classiche formattazioni a lista dei documenti più semplici.
2. Sarebbe possibile salvare il rendiconto su file e un programma che legge i file potrebbe ricostruire la semantica di tale valori ed elaborarli.

sgml è un tale linguaggio, in grado di descrivere la struttura di un documento. Cioè che cosa ogni singolo pezzo del documento significa. In pratica si tratta di un metodo per creare tracciati generalizzati.

Rispetto al rendiconto e alle nostre stampe in generale vi è un'altra significativa differenza. Il nostro sistema di stampa ha come elementi costituenti il singolo campo. Non siamo in grado, per motivi pratici, di gestire testi a lunghezza variabile. In pratica un campo di stampa che prevede una stringa di 65Kb è tutto sommato ingestible. In sgml non esiste il concetto di campo bensì quello di testo, senza particolari limiti alla lunghezza di ciascun testo.

Ora può creare delle perplessità questa confusione tra campo e testo. Nella nostra accezione standard il campo ha un significato estremamente definito. Misura esattamente un determinato valore sulla base di una determinata unità di misura. Quando parliamo di testo parliamo di piccoli frammenti che hanno un preciso significato. Ad esempio il testo descrizione lunga del titolo ha un significato molto preciso, anche se a ben guardare il contenuto informativo esatto del testo ci è per certi versi oscuro. Per chiarire questo punto fornirei due esempi:

1. Il campo saldo euro fornisce un valore ben preciso. Conosciamo esattamente la semantica di tale campo.
2. Il campo descrizione titolo ha la funzione di descrivere all'utente il titolo. Ma in realtà il contenuto semantico esatto può variare. Ad esempio confrontiamo tre descrizioni del medesimo titolo:
1. "BTP"
2. "Il mio primo BTP"
3. "BTP 2003-03-01 4%"

E' evidente che in questo caso il contenuto del campo di testo svolge una funzione nel sistema, ma il contenuto semantico dipende da come l'utente compila le descrizioni.

In ogni caso, anche nelle nostre procedure i frammenti di testo se non hanno una semantica precisa hanno una precisa funzione.

sgml è nato per gestire documenti. I documenti per loro natura oscillano tra un testo completamente libero ed un testo che ha una determinata struttura. Tale struttura è funzione dell'applicazione per la quale il testo è stato prodotto. sgml rappresenta un metodo formale per descrivere tale struttura. Per cui un metodo formale per creare delle specie di data base di testi che si trovano a metà strada tra la libertà assoluta del testo da word processing ed un data base tradizionale a campi con un preciso significato.

sgml non si preoccupa di decidere come formattare il testo, ma unicamente di conservarne la semantica.