Dalla base di dati alla stampa
Un asso nella manica
Di per sé, FrameMaker era una sofisticata applicazione per impaginare libri e giornali, ma non si può dire che fosse l'unica presente sul mercato. Anche QuarkXpress, per fare un esempio, permetteva di allestire pagine per una stampa di qualità, forse anche superiore a quella ottenibile con FrameMaker. Ma non aveva sgml.
Impiegando le altre applicazioni le pagine andavano preparate una per una, anche se erano ripetitive, e il copia e incolla aiutava fino a un certo punto, quando non faceva danni, come ha dovuto verificare almeno una volta chiunque abbia lavorato su un computer.
Con i lunghi documenti strutturati il rischio di perdere la coerenza era altissimo: il paragrafo 123 poteva presentare la data in tondo, mentre tutti gli altri ce l'avevano in corsivo; oppure poteva capitare che il titolo del paragrafo 321 risultasse centrato, e invece doveva essere allineato a sinistra, e così di seguito.
Bisogna immaginare sgml, e poi il suo derivato più maturo xml, come uno strumento astratto, utile per creare specifici linguaggi di markup, che a loro volta consentono di descrivere un oggetto ‒ una pagina stampata, ma anche un disegno oppure una formula ‒ in maniera minuziosa e coerente.
Non c'è solo html (HyperText Markup Language)...
Questa pagina, per esempio, è codificata secondo le specifiche html, derivate dalle direttive di sgml e adattate alle necessità particolari di un ipertesto da rappresentare sullo schermo di un computer per connettersi a innumerevoli altri computer: il web, insomma.
Ma html è solo il più conosciuto fra i linguaggi di markup derivabili da sgml, ne esistono molti altri, e se ne può inventare una quantità a piacere. Quello che sviluppai era incomparabilmente più semplice di html ma era tagliato su misura per la struttura della base di dati del progetto civita.
Ecco un microscopico esempio del linguaggo di markup modellato sul progetto civita. Il documento era generato da una procedura che estraeva in modo sistematico le informazioni strutturate presenti nella base di dati e le disponeva in una sequenza lineare.
L'esempio è uno stralcio del volume sulle istituzioni ecclesiastiche della provincia di Pavia, che subito dopo lo spoglio di quelle civili vennero schedate per completare il censimento.
...c'è anche pcml (Progetto civita Markup Language)
E qui finalmente entrava in gioco FrameMaker, con le sue capacità di Database publishing. L'applicazione leggeva il documento di markup e lo trasformava nel documento mostrato sotto.
Credo che il confronto sia eloquente. Mentre il documento di markup era una verbosa e ostica proiezione della base di dati, il documento di FrameMaker, che comunque poteva essere sottoposto a qualsiasi intervento redazionale, era chiaro e leggibile, e si prestava subito per la stampa.
Possono destare curiosità i piccoli simboli che si notano in calce ai profili. Sono il riflesso di una caratteristica tipica delle istituzioni ecclesiastiche, collegate spesso in maniera poco gerarchica, come invece avveniva per quelle civili, ma secondo relazioni più oblique, che fu necessario descrivere e implementare in maniera adeguata nella struttura della base di dati. Eccole:
Il markup generato dalla procedura dipanava il reticolo di relazioni istituzionali registrato nella base di dati, assegnando a ciascuna di queste relazione una lettera particolare. Dal canto suo FrameMaker si faceva carico di sostituire a questa lettera il simbolo grafico della corrispondente relazione. Come? Adoperando una fonte di caratteri disegnata per lo scopo, dove alle lettere abcdefghij e xyz corrispondevano i simboli delle varie relazioni.
Ma questo non era ancora tutto. C'era anche la questione degli indici.