Capitolo 249.   SGML: introduzione

Da quanto esposto in precedenza, dovrebbe essere stato inteso che l'SGML non è un «linguaggio di scrittura» da imparare e usare così com'è. Al contrario, è un linguaggio per definire il modo in cui il testo deve essere scritto: solo dopo si può iniziare a scrivere secondo le regole stabilite.

Volendo fare un abbinamento con i linguaggi di programmazione, sarebbe come se prima si dovesse definire il linguaggio stesso, per poi poter scrivere i programmi secondo quelle regole.

La descrizione fatta in questo capitolo potrebbe risultare noiosa, considerato che solo dopo molte sezioni si mostra in che modo realizzare effettivamente il proprio DTD e applicarlo a un documento. Considerata la complessità dei concetti espressi, si ritiene più conveniente una spiegazione che parte dal basso, piuttosto che usare un approccio inverso, che presumerebbe una conoscenza minima di partenza.

249.1   DTD: definizione del tipo di documento

Le regole che definiscono la struttura e la scomposizione del documento, assieme a quasi tutte le altre che governano la logica dell'SGML, sono contenute nel DTD.

Queste regole possono essere permissive o restrittive, in funzione degli obiettivi che ci si prefigge; ovvero, in funzione del contenuto di quel tipo di documento e delle cose che con questo ci si aspetta di fare.

La complessità del mondo reale, fa sì che non ci sia modo di realizzare un DTD unico che vada bene per tutti gli scopi. Un DTD ipotetico, che volesse andare bene un po' per tutto, dovrebbe essere anche qualcosa di estremamente generico e permissivo, annullando tutti i benefici dell'utilizzo dell'SGML.

Un esempio reale di un DTD «tuttofare» è quello delle prime versione dell'HTML, in cui tutto si concentra nella definizione di elementi il cui scopo prevalente è definire, anche se solo vagamente, l'aspetto finale che dovrebbe avere il risultato. Lo scopo dell'SGML non è quello di stabilire il risultato finale del documento, tuttavia, si può benissimo predisporre un DTD orientato a questo obiettivo. Ma questo, nel caso dell'HTML, giustifica poi l'estrema debolezza della sua struttura, dove è ammesso quasi tutto.

Tuttavia, è difficile comprendere subito il significato pratico di questo approccio: la definizione del tipo di documento e poi la scrittura del testo. Lo si può comprendere solo quando si lavora assiduamente nell'ambito della produzione di documentazione, quando ci si accorge che le proprie esigenze sono diverse da quelle degli altri, per cui diventa difficile adattarsi all'uso di modelli già esistenti.

249.2   Elementi

Dal punto di vista di SGML, una singola unità di testo la cui dimensione varia a seconda del contesto, è un elemento, a cui si impone l'attribuzione di un nome. SGML non fornisce alcun modo per attribuire un significato agli elementi del testo, tranne per il fatto di avergli dato un nome. Piuttosto, attraverso un analizzatore SGML, è possibile verificare che questi siano collocati correttamente secondo le relazioni stabilite.

I nomi degli elementi, sono definiti tecnicamente identificatori generici, utilizzando la sigla GI (Generic Identifier).

Nel sorgente SGML, gli elementi sono indicati normalmente attraverso l'uso di marcatori che hanno la forma consueta <...> e </...>, dove il primo inizia l'elemento nominato tra le parentesi angolari e il secondo chiude l'elemento. Per esempio, si potrebbe definire l'elemento acronimo e utilizzarlo nel testo nel modo seguente:

...Il gruppo <acronimo>ILDP</acronimo> si occupa di...

Il significato che questo elemento può avere, non è definito dall'SGML. Il fatto di avere delimitato l'elemento acronimo potrebbe servire per estrarre dal documento tutte le sigle utilizzate, per inserire queste in un indice particolare, oppure solo per fini stilistici di evidenziamento uniforme.

La difficoltà nella scrittura di un testo in SGML si riduce a questo: utilizzare i marcatori necessari a identificare correttamente i vari elementi del testo, secondo le regole stabilite nella definizione del documento stesso (il DTD).

249.2.1   Abbreviazioni nell'indicazione degli elementi

Prima ancora di iniziare a vedere il contenuto del DTD, è bene chiarire che esistono altri modi per delimitare un elemento SGML. Per la precisione, si tratta di abbreviazioni di cui alcuni autori non riescono a fare a meno. La scrittura di un sorgente SGML è un po' come quella di un sorgente di un linguaggio di programmazione: si può essere concisi o prolissi. Di solito, quando si è concisi si scrive del codice difficile da leggere, mentre in generale è meglio scrivere tutto in forma chiara senza risparmiare. L'esempio visto in precedenza,

...Il gruppo <acronimo>ILDP</acronimo> si occupa di...

può essere abbreviato in

...Il gruppo <acronimo>ILDP</> si occupa di...

e anche nel modo seguente, che però porta con sé un vincolo importante: non si possono usare delle barre oblique all'interno dell'elemento abbreviato in questo modo.

...Il gruppo <acronimo/ILDP/ si occupa di...

Con questi sistemi, oltre a rendere il sorgente SGML poco leggibile, si rischia di non ottenere i risultati che si attendono se gli strumenti di elaborazione utilizzati non riconoscono tali estensioni del linguaggio.

249.2.2   Primo impatto con un DTD

La definizione del DTD è ottenuta da una serie di istruzioni dichiarative composte secondo una sintassi molto semplice. L'esempio seguente rappresenta le istruzioni necessarie a definire gli elementi di un tipo di documento ipotetico definibile come relazione.

<!ELEMENT relazione     - - (titolo?, data, contenuto) >
<!ELEMENT titolo        - o (#PCDATA) >
<!ELEMENT data          - o (#PCDATA) >
<!ELEMENT contenuto     - o (paragrafo+, firma+) >
<!ELEMENT paragrafo     - o (#PCDATA) >
<!ELEMENT firma         - o (#PCDATA) >

Ognuna delle righe che appaiono nell'esempio rappresenta una dichiarazione di un elemento SGML. Una dichiarazione, di qualunque tipo, è delimitata da una parentesi angolare aperta (il simbolo di minore), seguita immediatamente da un punto esclamativo (<!) e da una parentesi angolare chiusa (>).

La dichiarazione di un elemento si compone poi della parola chiave ELEMENT, seguita dal nome dell'elemento, dalle regole di minimizzazione rappresentate da due caratteri e da un modello del contenuto.

<!ELEMENT titolo        - O (#PCDATA) >
|   |      |            ^^^    |      |
|   |      |             |     |      delimitatore conclusivo
|   |     nome           |     |      dell'istruzione
|   |     dell'elemento  |     |
|   |                    |     modello del contenuto
|   dichiarazione        |
|   di un elemento       regole di minimizzazione
|
delimitatore di apertura dell'istruzione SGML

Le varie parti che compongono qualunque tipo di dichiarazione SGML sono separate da spazi orizzontali (caratteri spazio, o tabulazioni orizzontali) oppure anche da interruzioni di riga, permettendo così di proseguire le istruzioni su più righe distinte.

249.2.3   Regole di minimizzazione

Le regole di minimizzazione, rappresentate da due caratteri staccati, indicano l'obbligatorietà o meno dell'utilizzo del marcatore di apertura e di chiusura per l'elemento dichiarato. Il primo dei due simboli rappresenta l'apertura, il secondo la chiusura. Un trattino indica che il marcatore è obbligatorio, mentre la lettera O sta per «opzionale» e indica così che può essere omesso:

• - -

  sono obbligatori entrambi i marcatori;

• - O

  è obbligatorio il marcatore iniziale, mentre quello finale è facoltativo;

• O -

  il marcatore iniziale è facoltativo, mentre quello finale è obbligatorio (di solito non capita questa situazione);

• O O

  sono facoltativi entrambi i marcatori.

Nell'esempio mostrato in precedenza, solo l'elemento relazione richiede l'utilizzo di marcatori di apertura e di chiusura, mentre tutti gli altri possono essere indicati utilizzano il solo marcatore di apertura. In pratica, il contesto permette di individuare dove finiscano tali elementi nel testo.

La possibilità o meno di rendere facoltativo l'uso dei marcatori di apertura e di chiusura non è solo un fatto di gusto, in quanto dipende anche dall'organizzazione del tipo di documento. Se le dichiarazioni diventano ambigue, non si possono più distinguere gli elementi nel testo SGML.

249.2.4   Modello del contenuto

La parte finale della dichiarazione di un elemento SGML è il modello del contenuto, che si distingue perché è racchiuso tra parentesi tonde. Serve a descrivere il tipo di contenuto che può avere l'elemento e si può esprimere attraverso parole riservate che hanno un significato preciso, come #PCDATA (Parsed character data) che rappresenta una qualunque sequenza di caratteri valida, oppure attraverso l'indicazione di nomi di altri elementi che possono (o devono) essere contenuti in qualche modo.

Il modello del contenuto, può articolarsi in modo molto complesso, allo scopo di definire le relazioni tra gli elementi contenuti.

Per il momento, è bene osservare che un elemento, il cui modello del contenuto sia composto esclusivamente della parola riservata #PCDATA, non può contenere al suo interno altri tipi di elementi. Il significato di alcune delle parole riservate più comuni, utilizzabili per definire il contenuto di un elemento, sono riportate più avanti in questo capitolo, dopo la presentazione di altri concetti essenziali, necessari per comprenderne il senso.

249.2.4.1   Indicatori di ripetizione

Il modello del contenuto utilizza un sistema abbastanza complesso per definire la possibilità di contenere più elementi dello stesso tipo e per indicare raggruppamenti di elementi. Per indicare la ripetizione, viene usato un simbolo alla fine dell'oggetto a cui si riferisce, chiamato indicatore di ripetizione (occurrence indicator).

• Il segno + usato come suffisso, rappresenta una o più ripetizioni dell'elemento.

• Il segno ? usato come suffisso, rappresenta zero o al massimo un'occorrenza dell'elemento.

• Il segno * usato come suffisso, rappresenta zero o più ripetizioni dell'elemento.

• Se non viene usato nessun suffisso, l'elemento indicato deve essere usato esattamente una volta.

Dall'esempio mostrato in precedenza viene ripreso l'estratto seguente, nel quale si può osservare che: l'elemento titolo può apparire al massimo una volta all'interno di relazione (precisamente all'inizio di questo elemento); l'elemento paragrafo deve essere contenuto almeno una volta all'interno dell'elemento contenuto (lo stesso vale per l'elemento firma); l'elemento firma può contenere solo caratteri normali senza altri elementi.

<!ELEMENT relazione     - - (titolo?, data, contenuto) >
<!ELEMENT contenuto     - O (paragrafo+, firma+) >
<!ELEMENT firma         - O (#PCDATA) >

249.2.4.2   Connettori

Quando un elemento deve poter contenere diversi tipi di elementi, è necessario usare dei simboli, detti connettori, per stabilirne la relazione.

• La virgola (,) indica che l'elemento precedente e quello successivo devono apparire nell'ordine in cui sono.

• La e-commerciale (&) indica che l'elemento precedente e quello successivo devono essere presenti entrambi, ma possono apparire in qualunque ordine.

• la barra verticale (|) indica che solo uno tra i due elementi che connette può apparire.

Riprendendo il solito estratto dell'esempio già mostrato precedentemente, si può osservare l'uso della virgola in qualità di connettore:

<!ELEMENT relazione     - - (titolo?, data, contenuto) >
<!ELEMENT contenuto     - O (paragrafo+, firma+) >
<!ELEMENT firma         - O (#PCDATA) >

L'elemento relazione può contenere al massimo un titolo all'inizio, quindi deve apparire un elemento data e dopo di questo anche un elemento contenuto. L'elemento contenuto deve contenere uno o più elementi paragrafo a partire dall'inizio, mentre in coda deve avere uno o più elementi firma.

<!ELEMENT nominativo    - - (nome & cognome) >
<!ELEMENT voce          - - (punto | numero) >

Per completare gli esempi sull'uso dei connettori, si osservi quanto mostrato sopra. L'elemento nominativo deve contenere un elemento nome e un elemento cognome, in qualunque ordine; l'elemento voce può contenere solo un elemento a scelta tra punto e numero.

249.2.4.3   Raggruppamenti

All'interno di un modello di contenuto, è possibile indicare dei raggruppamenti che esprimono in pratica dei sottomodelli, a cui poter applicare gli indicatori di ripetizione e i connettori. Per questo si usano le parentesi tonde. Si osservi l'esempio seguente:

<!ELEMENT figure - - ( (eps | ph), img*, caption?) >

L'elemento figure deve contenere un'occorrenza del sottogruppo (eps | ph), zero o più ripetizioni dell'elemento img e al massimo un'occorrenza di caption, nell'ordine descritto. Il sottogruppo (eps | ph) rappresenta una singola occorrenza di eps oppure ph.

Quando si utilizzano gli operatori di ripetizione assieme ai raggruppamenti, possono nascere degli equivoci. Ammesso che ciò possa avere senso, si osservi la variante seguente dell'esempio già presentato:

<!ELEMENT figure - - ( (eps | ph)+, img*, caption?) >

È stato aggiunto il segno + dopo il gruppo (eps | ph). In questo modo, si intende che sia possibile l'inserimento iniziale di una serie indefinita di elementi eps o ph, in qualunque ordine, purché ce ne sia almeno uno dei due. Quindi, non è necessario che si tratti solo di elementi eps o solo di ph.

249.2.4.4   Eccezione

Se nella definizione di un elemento si vogliono indicare delle eccezioni a quanto definito dal modello di contenuto, si può indicare un gruppo di elementi successivo al modello del contenuto.

Questo gruppo può essere preceduto dal segno + o dal segno - indicando rispettivamente un'eccezione di inclusione, o un'eccezione di esclusione.

Esempi

<!ELEMENT address - O (#PCDATA) +(newline) >

L'elemento address contiene caratteri normali, ma può includere eccezionalmente anche l'elemento newline.

<!ELEMENT acronimo - - (#PCDATA) -(acronimo) >

L'elemento acronimo contiene caratteri normali e non può includere se stesso (a essere precisi, non è necessario dichiarare una cosa del genere, dal momento che il contenuto #PCDATA non ammette altri elementi al suo interno).⁽¹⁾

249.2.4.5   Elementi vuoti

Alcuni tipi di elementi non sono fatti per circoscrivere una zona di testo, ma solo per rappresentare qualcosa che si trova in un certo punto. Questi elementi, non vengono dichiarati con un modello di contenuto tra parentesi, ma con l'utilizzo della parola chiave empty.

L'esempio seguente, dichiara l'elemento toc che non può contenere alcunché.

<!ELEMENT toc - O EMPTY>

Tipicamente, tali elementi, sono dichiarati in modo che il marcatore di chiusura sia solo facoltativo. Non potendo contenere alcunché, sarebbe perfettamente inutile renderlo obbligatorio.

249.2.5   Dichiarazione multipla

Eventualmente, un gruppo di elementi che abbiano le stesse caratteristiche, cioè le stesse regole di minimizzazione e lo stesso modello del contenuto, può essere dichiarato in una sola istruzione. L'esempio seguente dovrebbe essere sufficiente a comprendere il meccanismo.

<!ELEMENT ( annotazione | avvertimento | pericolo ) - - (#PCDATA) >

249.2.6   Attributi

Un elemento può prevedere la presenza di uno o più attributi. Si tratta di informazioni che non compongono il contenuto dell'elemento, ma di qualcosa che, non potendo apparire nel testo, serve per qualche ragione ai programmi che elaborano successivamente il documento. Il classico esempio è costituito da quei marcatori utilizzati per i riferimenti incrociati. L'esempio seguente mostra l'uso di un elemento vuoto, denominato ref, contenente l'attributo point a cui viene dato il valore esempio:

Si veda il capitolo <ref point="esempio"> che contiene
molti esempi utili al riguardo.

È importante osservare che il valore assegnato a un attributo deve essere delimitato attraverso apici doppi (come mostrato nell'esempio), oppure attraverso apici singoli. Eccezionalmente, è possibile assegnare un valore senza alcuna delimitazione, quando si tratta di una sola parola composta da lettere alfabetiche, cifre numeriche, trattino normale (-), trattino basso (_), due punti (:).

L'esempio seguente mostra la dichiarazione dell'elemento ref, già presentato nell'esempio, tenendo conto che il suo scopo è quello di essere utilizzato come riferimento a una parte del documento identificata attraverso il valore assegnato all'attributo point.

<!ELEMENT ref - O EMPTY>
<!ATTLIST ref
        point IDREF #REQUIRED
        name CDATA "riferimento">

Attraverso l'istruzione ATTLIST si definiscono gli attributi di un elemento. Dopo l'indicazione del nome dell'elemento a cui si fa riferimento, segue l'elenco degli attributi, ognuno dei quali inizia con un codice di interruzione di riga seguito eventualmente da altri tipi di spazi. Ciò significa che l'istruzione ATTLIST deve essere composta proprio come indicato dall'esempio, solo i rientri sono facoltativi.

L'esempio indica che l'elemento ref contiene due attributi: point e name. Il primo è obbligatorio (#REQUIRED), mentre per il secondo è stato indicato un valore predefinito, nel caso non venga specificato espressamente (riferimento).

Il tipo di contenuto di un attributo viene definito attraverso delle parole chiave, che possono essere indicate usando lettere maiuscole o minuscole indifferentemente. Di seguito ne vengono descritte alcune:

• CDATA

  rappresenta una stringa di qualunque tipo di carattere, ammettendo anche simboli di punteggiatura o altro, che comunque mantiene solo il suo significato letterale (Character data);

  Questo è un punto delicato. La parole chiave CDATA viene usata anche in altre situazioni con un significato simile, ma non identico. Nel caso definisca il contenuto di un attributo, è ammesso l'uso di macro (entità) che vengono espanse.

• NMTOKEN

  rappresenta qualunque tipo di carattere alfanumerico (lettere, numeri e spazi soltanto), che dovrebbe comporre un nome (Name token);

• NUMBER

  rappresenta solo cifre numeriche, cioè un numero;

• ID

  rappresenta un identificatore unico per quel tipo di documento, costituito da un nome senza caratteri speciali o segni di punteggiatura, che viene utilizzato successivamente per farvi riferimento;

• IDREF

  indica che l'attributo deve essere un puntatore valido a un identificatore di un attributo ID, corrispondente in un altro elemento.

Il tipo di contenuto di un attributo, può essere indicato in modo preciso attraverso una serie di scelte alternative. In tal caso, invece di utilizzare le parole chiave già elencate, si indicano le stringhe alternative, separate dalla barra verticale, tra parentesi tonde. Per esempio, (bozza | finale) rappresenta la possibile scelta tra le due parole bozza e finale.

L'ultimo dato da inserire per ogni attributo è il valore predefinito, oppure una parola chiave a scelta tra le seguenti:

• #REQUIRED

  rappresenta l'obbligatorietà dell'inserimento del valore;

• #IMPLIED

  rappresenta un attributo facoltativo;

• #CURRENT

  in mancanza di un'indicazione esplicita, rappresenta l'utilizzo dell'ultimo valore assegnato allo stesso attributo dello stesso elemento.

Tra tutti, merita attenzione la coppia ID e IDREF. Questi tipi di attributi possono essere molto utili per definire dei riferimenti incrociati all'interno del documento, quando la loro validità deve essere controllata con gli strumenti di convalida SGML. Si osservi l'esempio seguente:

<!ELEMENT label - O EMPTY>
<!ATTLIST label
        identity ID #REQUIRED>

<!ELEMENT ref - O EMPTY>
<!ATTLIST ref
        point IDREF #REQUIRED>

Nell'esempio si mostra la dichiarazione di un elemento label che non può contenere testo, in quanto serve solo per definire l'attributo identity, di tipo ID. Questo permetterà l'utilizzo di marcatori simili a <label identity="miaetichetta">, dove viene assegnato all'attributo identity un nome sempre diverso, allo scopo di identificare qualcosa. Sotto, la dichiarazione dell'elemento ref mostra un altro elemento che non può contenere testo, ma solo un attributo denominato point, di tipo IDREF, che può quindi contenere solo il nome di un identificatore già usato in un altro elemento con l'attributo ID.

In pratica, se nel testo SGML si dovesse utilizzare da qualche parte il marcatore <label identity="miaetichetta">, in un altro punto sarebbe valido il marcatore <ref point="miaetichetta">, perché l'identificatore miaetichetta esiste effettivamente.

Ricapitolando, un attributo ID di un marcatore è valido quando è unico nel documento SGML che si scrive, mentre un attributo IDREF è valido quando esiste il valore corrispondente di un attributo ID.

249.3   Entità

Con questo termine, entità, si fa riferimento a due tipi di oggetti: macro per la sostituzione di stringhe (entità generali) o macro per la sostituzione di nomi all'interno di istruzioni SGML (entità parametriche).

Le macro per la sostituzione di stringhe, una volta dichiarate, si utilizzano all'interno del sorgente SGML come abbreviazioni o come un modo per identificare lettere o simboli che non possono essere usati altrimenti. Per esempio, utilizzando le entità ISO 8879:1986, la frase

Wer bekommt das größte Stück Torte?

può essere scritta nel sorgente nel modo seguente:

Wer bekommt das gr&ouml;&szlig;te St&uuml;ck Torte?

Le entità generali, quindi, sono identificate nel testo SGML perché iniziano con la e-commerciale (&) e terminano con un punto e virgola. È bene osservare che il punto e virgola non è obbligatorio in ogni situazione, ma solo quando il carattere successivo sia diverso da uno spazio orizzontale o da un codice di interruzione di riga. In generale, però, sarebbe bene usare sempre il punto e virgola. La tabella 249.1 elenca alcune macro delle entità standard più importanti.⁽²⁾

Tabella 249.1. Alcune macro delle entità standard secondo le specifiche ISO 8879:1986.

L'altro tipo di macro, riguarda invece la sostituzione all'interno delle istruzioni SGML, cioè nella dichiarazione del DTD.

L'esempio seguente mostra la dichiarazione dell'elemento p che può contenere l'elemento o gli elementi indicati all'interno della macro %inline;.

<!ELEMENT p - O (%inline;) >

La dichiarazione di un'entità avviene utilizzando l'istruzione ENTITY. L'esempio seguente mostra la dichiarazione di un'entità da utilizzare nel sorgente SGML.

<!ENTITY agrave "\`a">

In questo caso, si vuole che la macro &agrave; venga sostituita con la stringa \`a. Evidentemente, questa trasformazione non ha niente a che vedere con SGML. È semplicemente una scelta motivata dal tipo di programma utilizzato successivamente per rielaborare il risultato generato dall'analizzatore SGML.

L'esempio seguente mostra la dichiarazione di due entità da utilizzare all'interno delle istruzioni SGML.

<!ENTITY % emph " em | concept | cparam ">
<!ENTITY % inline "(#PCDATA | %emph;)*">

La dichiarazione di questo tipo di entità si distingue perché viene utilizzato il simbolo di percentuale subito dopo la parola ENTITY, staccandolo da questa e anche dal nome dell'entità successivo. Anche in questo caso si utilizza solo come pura sostituzione di stringhe, per cui la dichiarazione di %inline;, facendo a sua volta riferimento a %emph;, è equivalente a quella seguente:

<!ENTITY % inline "(#PCDATA | em | concept | cparam )*">

Naturalmente, una macro può contenere anche il riferimento a un'altra macro. Per esempio, la dichiarazione dell'ipotetico elemento p, fatta nel modo seguente,

<!ELEMENT p - O (%inline;) >

è equivalente alla dichiarazione:

<!ELEMENT p - O ((#PCDATA | em | concept | cparam )*) >

249.3.1   Acquisizione dall'esterno

Le entità di qualunque tipo, possono essere dichiarate abbinando una stringa a una macro, come è stato mostrato in precedenza. In alternativa, a una macro si può abbinare un file esterno (file inteso nel senso più ampio possibile). In tal caso, si utilizza la parola chiave SYSTEM come nell'esempio seguente:

<!ENTITY capitolo2 SYSTEM "capitolo2.sgml">

In tal modo, quando nel documento SGML si utilizza la macro &capitolo2; e poi lo si elabora attraverso un analizzatore SGML, si ottiene l'inserimento del file capitolo2.sgml. Più o meno ciò che si fa normalmente con le direttive di un preprocessore di un linguaggio di programmazione.

Nello stesso modo si può fare per dichiarare un'entità parametrica, come nell'esempio seguente:

<!ENTITY % isoent SYSTEM "isoent.txt">

L'esempio mostra la dichiarazione della macro %isoent;, riferita al file isoent.txt. Per utilizzare questa macro, bisogna sapere a cosa si riferisce; trattandosi di un file, è logico pensare che si tratti di un testo articolato su più righe, quindi inadatto all'inserzione all'interno delle istruzioni. Generalmente, una macro del genere serve a incorporare un pezzo di DTD dall'esterno.

%isoent;

Come si vede dall'esempio, è normale vedere la chiamata di una macro di questo tipo, da sola, all'esterno di qualunque istruzione del DTD. L'esempio mostrato è comunque significativo: rappresenta l'inclusione di un file che presumibilmente, dal nome, serve a incorporare le entità ISO, cioè quelle standard riferite alle lettere accentate e ai simboli speciali.

A questo proposito, potrebbero esistere diversi file, del tipo: isoent.latex.txt, isoent.html.txt,... che prima di avviare l'analizzatore SGML vengono sostituiti al file isoent.txt, in modo da ottenere la sostituzione corretta in base all'elaborazione successiva che si vuole ottenere (LaTeX, HTML, ecc.).

Se non fosse ancora chiaro, ecco come potrebbe essere composto l'ipotetico file isoent.txt quando si vogliono le sostituzioni corrette per LaTeX.

<!ENTITY agrave "\`a">
<!ENTITY Agrave "\`A">
<!ENTITY egrave "\`e">
<!ENTITY Egrave "\`E">
<!ENTITY eacute "\'e">
<!ENTITY Eacute "\'E">
...

L'acquisizione di una macro da un file esterno può essere dichiarata senza specificare esplicitamente il file, lasciando che l'analizzatore trovi il file corretto in base a un catalogo SGML. L'argomento verrà ripreso in seguito, comunque, in questo tipo di dichiarazione, manca il nome del file.

<!ENTITY capitolo2 SYSTEM>

<!ENTITY % isoent SYSTEM>

Solitamente, si preferisce includere in questo modo solo le macro parametriche, cosa che potrà essere compresa intuitivamente in seguito.

249.3.2   Codici macro speciali

È bene ribadire che l'uso delle entità standard (ISO), permette di rendere il testo SGML indipendente dalla piattaforma utilizzata. Tuttavia, la dichiarazione della sostituzione dipende dalla piattaforma e, come si è mostrato, si tendono a predisporre diversi schemi di sostituzione per le diverse piattaforme a cui si vuole fare riferimento.

In situazioni eccezionali, può essere conveniente indicare i caratteri per numero, decimale o esadecimale, attraverso una notazione simile a quella delle entità normali. Per esempio, se si usa la codifica ISO 8859-1 (Latin 1), la macro &#232;, oppure la macro &#xe8; corrisponderà alla lettera è (la «e» accentata normale).

Questa possibilità è fondamentale proprio quando si definiscono le stringhe di sostituzione per una piattaforma determinata (hardware-software), in cui si debbano indicare caratteri speciali identificati dal numero corrispondente.

<!ENTITY egrave "&#232;">

249.4   Sezioni marcate

Le sezioni marcate sono una specialità di SGML, poco usata e poco conosciuta. Si tratta di istruzioni che vengono inserite nel testo SGML (non nel DTD) e servono a vario titolo per delimitare del testo per qualche scopo.

Una sezione marcata si compone di un sorta di marcatore di apertura e di una sorta di marcatore di chiusura. Il marcatore di apertura contiene una parola chiave che ne identifica il comportamento. Si osservi l'esempio seguente:

<![INCLUDE[
Questa parte del testo è inclusa nell'elaborazione SGML.
]]>

Come si può intuire, la sezione marcata dell'esempio è introdotta da <![INCLUDE[ ed è terminata da ]]>. In questo caso, la parola chiave INCLUDE indica che il testo contenuto nella sezione marcata deve essere incluso nell'elaborazione (anche se ciò, per ora, può sembrare perfettamente senza significato).

Le parole chiave utilizzabili per definire la sezione marcata sono diverse; di seguito ne appare l'elenco.

• INCLUDE

  Il contenuto della sezione marcata deve essere incluso nel documento SGML e deve essere elaborato normalmente.

• IGNORE

  Il contenuto della sezione marcata deve essere escluso dal documento SGML. Se l'analizzatore SGML genera un qualche tipo di output, questo non conterrà tale sezione.

• CDATA

  Il contenuto della sezione marcata deve essere incluso e trattato come testo letterale, in modo da ignorare ciò che altrimenti potrebbe essere interpretato come un marcatore o un'entità. Ciò vale per tutto, tranne il simbolo di chiusura della sezione marcata (]]>), che quindi è l'unica cosa che non può essere rappresentata all'interno di questa.

• RCDATA

  Il contenuto della sezione marcata deve essere incluso e trattato come testo letterale, in modo da ignorare ciò che altrimenti potrebbe essere interpretato come un marcatore, ma continuando a espandere le entità.

• TEMP

  Il contenuto della sezione marcata deve essere inteso come «temporaneo». Ciò serve solo come riferimento umano, per localizzare facilmente una parte del documento che richiede una revisione o che dovrà essere rimossa.

L'utilizzo di sezioni marcate di tipo INCLUDE e IGNORE è utile solo in abbinamento a entità parametriche. Prima di proseguire, è bene chiarire che quella specie di marcatore che apre una sezione marcata è come un'istruzione SGML, di quelle che appaiono nel DTD, anche se viene usata al di fuori di questo, nel documento. In questo senso, al suo interno si possono usare le entità parametriche; quindi, una di queste macro può servire per definire in modo dinamico la parola chiave INCLUDE oppure IGNORE, per decidere di includere o escludere quel blocco (e probabilmente anche altri) con la modifica di una sola macro.

Per esempio, nel DTD del documento potrebbe apparire la dichiarazione di un'entità parametrica denominata commentato.

<!ENTITY % commentato "INCLUDE">

Nel documento SGML potrebbero esserci una serie di sezioni marcate la cui inclusione deve dipendere da questa macro.

...
1 + 2 = 3
<![%commentato;[
La matematica non è un'opinione.
]]>
...

Quando il testo viene analizzato, la macro viene espansa e trovando che corrisponde a INCLUDE, il testo delle sezioni marcate che l'hanno usata, vengono incluse. Al contrario, basta modificare la macro, assegnandole il valore IGNORE, per fare in modo che tutte quelle sezioni marcate vengano ignorate.

Questo tipo di approccio potrebbe sembrare ugualmente scomodo per l'utilizzatore che non vuole toccare il DTD. Però, si vedrà in seguito che si possono inserire delle eccezioni al DTD nel preambolo di un documento SGML. Oppure, si può benissimo progettare un DTD con una componente esterna, destinata a questo tipo di ritocchi.

249.5   Dettagli importanti

Prima di passare alla descrizione dell'abbinamento di un DTD a un testo SGML, è bene chiarire alcuni dettagli che sono stati trascurati fino a questo punto.

249.5.1   Commenti

All'interno del documento sorgente SGML, come nel DTD, possono essere indicate delle righe di commento da non considerare parte del documento o della codifica. Queste si ottengono con i delimitatori <!-- e -->.

Volendo approfondire meglio il problema, la sequenza <!> rappresenta l'istruzione SGML nulla e può essere usata indifferentemente nel DTD o nel sorgente SGML. In qualità di istruzione nulla viene ignorata semplicemente.

All'interno delle istruzioni SGML è possibile inserire dei commenti, attraverso una sequenza di due trattini (--), per aprire e chiudere il commento. Per esempio,

<!ELEMENT itemize - - (item+) -- elenchi puntati -- >

dichiara l'elemento itemize con un commento incorporato.

Questo dovrebbe chiarire il senso del commento composto da <!-- e -->: si tratta di un'istruzione (nulla) che contiene un commento.

Questa particolarità di SGML ha delle conseguente: nel testo che compone il commento, non possono apparire sequenze di due o più trattini.

249.5.2   Maiuscole minuscole

Per convenzione, i nomi di entità sono sensibili alla differenza tra lettere maiuscole e minuscole, per cui &Agrave; e &agrave; rappresentano rispettivamente la lettera «A» maiuscola con accento grave e la «a» minuscola con accento grave.

Per convenzione, i nomi degli elementi, i simboli delle regole di minimizzazione, i nomi degli attributi e le parole chiave, non sono sensibili alla differenza tra lettere maiuscole e minuscole. Quindi, nelle dichiarazioni del DTD,

<!element ref - o empty>
<!attlist ref
        id cdata #required
        name cdata "riferimento">

è identico a

<!ELEMENT REF - O EMPTY>
<!ATTLIST REF
        ID CDATA #REQUIRED
        NAME CDATA "riferimento">

così come nel testo SGML

... <ref id="capitolo-introduttivo" name="Intro"> ...

è identico a

... <REF ID="capitolo-introduttivo" NAME="Intro"> ...

indifferentemente dal modo (maiuscolo o minuscolo) in cui l'elemento ref è stato dichiarato nel DTD.

Evidentemente, in generale, il contenuto delle stringhe delimitate è sensibile alla differenza tra maiuscole e minuscole.⁽³⁾

249.5.3   Delimitatori di stringa

In varie situazioni, all'interno del DTD e all'interno dei marcatori utilizzati nel testo SGML, può essere necessaria l'indicazione di stringhe. I simboli utilizzati per delimitare le stringhe possono essere gli apici doppi ("..."), oppure gli apici singoli ('...'). La scelta tra i due tipi di delimitatori dovrebbe essere indifferente, a parte la possibile necessità di inserire nelle stringhe proprio questi caratteri. Si osservi l'esempio seguente, in cui vengono dichiarate le entità riferite ad alcune lettere accentate da usare con LaTeX.

<!ENTITY uuml   '\"u'>
<!ENTITY Uuml   '\"U'>
<!ENTITY yacute "\'y">
<!ENTITY Yacute "\'Y">

In situazioni più complesse, potrebbe essere necessario indicare i caratteri con l'aiuto delle macro &#nnn;, che permettono di identificare l'oggetto attraverso il numero corrispondente riferito al tipo di codifica utilizzato (purché il contesto preveda la successiva ulteriore espansione di tali macro).

249.5.4   Tipo di contenuto di un'entità generale

In precedenza, quando è stato mostrato in che modo possa essere definita un'entità, si è trascurato il fatto che si deve definire in che modo la stringa di sostituzione vada interpretata. Per questo, si aggiunge una parola chiave prima della stringa.

Se non si usa alcuna parola chiave, si intende che la stringa vada interpretata come appare, espandendo eventuali entità contenute al suo interno. Si osservi l'esempio.

<!ENTITY attenzione "&lt;ATTENZIONE&gt;">

Quando dovesse essere utilizzata la macro &attenzione;, si otterrebbe la stringa <ATTENZIONE>, perché le entità &lt; e &gt; vengono espanse ulteriormente.

Se si indica la parola chiave CDATA, si intende che la stringa di sostituzione deve essere utilizzata in modo letterale, senza espandere alcuna sequenza che potrebbe sembrare un'entità.

<!ENTITY attenzione CDATA "&lt;ATTENZIONE&gt;">

L'esempio, modificato con l'introduzione della parola chiave CDATA, fa sì che la macro &attenzione; si traduca in pratica in &lt;ATTENZIONE&gt;, perché le entità &lt; e &gt; non vengono riconosciute come tali e quindi non vengono espanse.

Se si utilizza la parola chiave SDATA (Special data), si intende che la stringa di sostituzione deve essere utilizzata in modo letterale, senza espandere alcuna sequenza che potrebbe sembrare un'entità. Però, a differenza di CDATA, l'informazione viene filtrata in modo particolare quando l'analizzatore SGML genera un risultato transitorio da riutilizzare con un altro programma di composizione.

249.5.5   Contenuto elementare degli elementi

In precedenza è già stata spiegata la dichiarazione degli elementi e la dichiarazione del contenuto. In particolare si è visto che attraverso la parola chiave #PCDATA si fa riferimento a testo normale che viene elaborato normalmente (parsed). Ciò significa che questo tipo di testo è soggetto alla sostituzione delle entità, come fino a questo punto si è dato per scontato.

Tuttavia esistono altre parole chiave per definire tipi di testo differenti. Segue l'elenco di quelle più comuni.

• #PCDATA

  Parsed character data. Si riferisce a testo normale soggetto alla sostituzione delle entità. Questo testo non può contenere altri elementi.

• CDATA

  Il contenuto dell'elemento deve essere trattato come testo letterale, in modo da ignorare ciò che altrimenti potrebbe essere interpretato come un marcatore o un'entità.

  In pratica, la definizione di elementi con contenuto CDATA è decisamente sconsigliabile. Se esiste la necessità di delimitare una zona di testo da trattare in modo letterale, solitamente, si preferisce utilizzare una sezione marcata del tipo <![CDATA[...]]>.

• RCDATA

  Il contenuto dell'elemento deve essere trattato come testo letterale, in modo da ignorare ciò che altrimenti potrebbe essere interpretato come un marcatore, ma continuando a espandere le entità.

249.6   Abbinare il DTD al documento SGML

L'abbinamento di un DTD a un documento SGML avviene generalmente in modo formale. In presenza di situazioni eccezionali, questo abbinamento può essere implicito, come nel caso dell'HTML, ma è bene utilizzare ugualmente l'approccio generale anche in questi casi estremi.

Un sorgente SGML inizia normalmente con la dichiarazione del tipo di DTD utilizzato. Può trattarsi di un file esterno o di dichiarazioni incorporate nel documento stesso. Per esempio, la dichiarazione seguente indica all'analizzatore SGML di utilizzare un DTD esterno, denominato linuxdoc e contenuto nel file linuxdoc.dtd.

<!DOCTYPE linuxdoc SYSTEM "linuxdoc.dtd">

L'esempio seguente mostra invece una dichiarazione iniziale che contiene le istruzioni che compongono il DTD, racchiuse tra parentesi quadre.

<!DOCTYPE personale [
...
-- istruzioni SGML --
...
...
]>

Una terza possibilità permette di definire un file esterno e di aggiungere altre istruzioni particolari riferite al documento, come nell'esempio seguente, sempre utilizzando le parentesi quadre.

<!DOCTYPE linuxdoc SYSTEM "linuxdoc.dtd" [
...
-- istruzioni SGML --
...
...
]>

Inoltre, come è stato visto nel caso delle entità, l'acquisizione dall'esterno di un file contenente un DTD, può avvenire anche senza stabilire espressamente il nome di un file, lasciando che questo venga determinato da un catalogo. Così, l'esempio già visto del DTD linuxdoc si potrebbe trasformare nel modo seguente:

<!DOCTYPE linuxdoc SYSTEM>

Esiste anche un'altra alternativa: quella di indicare un identificatore pubblico, anch'esso riferito a un catalogo. Quello che segue è il preambolo di un file SGML scritto secondo il DTD HTML 3.2. Si osservi, a questo proposito, l'uso della parola chiave PUBLIC.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">

249.6.1   Strategie

La scelta di incorporare il DTD nel documento, o di lasciarlo all'esterno, dipende da delle preferenze organizzative. Di sicuro, può essere sensato l'inclusione del DTD nel documento SGML quando si tratta di un DTD specifico che non viene usato altrove.

Nella realtà, si utilizzerà quasi sempre un DTD esterno, probabilmente predisposto da altri, abbinato a una serie di strumenti che permettono di produrre dei documenti in formato finale a partire dai sorgenti SGML scritti seguendo quel DTD particolare.

L'estensibilità del DTD resta sempre una possibilità utile per poter aggiungere delle entità interne o delle entità parametriche allo scopo di gestire opportunamente le sezioni marcate.

249.6.2   Entità interne

Come si è visto nella sezione precedente, la dichiarazione del DTD può includere delle istruzioni del DTD, generalmente estendendolo. Questo meccanismo permette, tra le altre cose, di inserire le cosiddette entità interne (internal entity). Si osservi l'esempio.

<!DOCTYPE linuxdoc SYSTEM
[
<!ENTITY pericolo "!!">
<!ENTITY posix    "POSIX">
<!ENTITY unix     "Unix">
<!ENTITY xwin     "X Window System">
<!ENTITY edizione "1999.12.31">
]>

L'esempio appena mostrato permette di utilizzare le macro &pericolo;, &posix;, &unix;, &xwin; e &edizione;, all'interno del sorgente SGML, ottenendo la loro sostituzione automatica. Per intenderne l'utilità, basta pensare al caso della macro &xwin; dell'esempio precedente: non occorre più ricordare come si deve scrivere (X, X Window o X Window System); se si decidesse di cambiare, basterebbe modificare la dichiarazione dell'entità. Il concetto è analogo a quello delle macro del preprocessore nei linguaggi di programmazione.

La definizione di entità interne è consentita anche quando queste dovessero essere già state dichiarate nel DTD. Le entità dichiarate nelle istruzioni aggiuntive, dovrebbero prendere la precedenza e sostituirsi a quelle eventualmente già dichiarate nel DTD.

249.6.3   Entità parametriche

Come nel caso delle entità interne, nelle estensioni del DTD può essere conveniente aggiungere la dichiarazione di entità parametriche da utilizzare per controllare l'inclusione o l'esclusione di sezioni marcate. Si osservi l'esempio, già mostrato in precedenza, in cui la macro commentato serve per controllare alcune sezioni marcate, stabilendone il tipo.

<!DOCTYPE linuxdoc SYSTEM
[
<!ENTITY pericolo "!!">
<!ENTITY posix    "POSIX">
<!ENTITY unix     "Unix">
<!ENTITY xwin     "X Window System">
<!ENTITY edizione "1999.12.31">
...
<!ENTITY % commentato "INCLUDE">
]>
...
...
1 + 2 = 3
<![%commentato;[
La matematica non è un'opinione.
]]>
...
...

249.6.4   Ancora sulla dichiarazione del DTD

Si è visto in che modo inizia un sorgente SGML. Quello che non è ancora stato chiarito è che il tipo di documento deve essere stato dichiarato nel DTD, anche se ciò può sembrare ridondante. In effetti è necessario dire di cosa è composto il documento. Nel DTD potrebbe apparire un'istruzione come quella seguente:

<!ELEMENT linuxdoc O O ( article | report | book | letter ) >

In questo esempio, si comprende che non è necessario usare marcatori del tipo <linuxdoc> </linuxdoc> per delimitare il sorgente SGML. Infatti, la coppia di O afferma che queste sono opzionali. Invece, il tipo di documento linuxdoc deve contenere esattamente un elemento del tipo article, oppure report, oppure book, o ancora letter.

Il sorgente SGML che fa riferimento al tipo di documento linuxdoc e che utilizza il formato definito dall'elemento article, sarà composto schematicamente come segue:

<!DOCTYPE linuxdoc SYSTEM>
<article>
...
...
...
</article>

Un tipo di documento potrebbe essere definito in maniera diversa, per esempio nel modo seguente:

<!element miodoc - - ( sezione+ ) >

In questo caso, il documento può contenere solo elementi sezione, ed è obbligatorio l'utilizzo dei marcatori per indicare l'inizio e la fine del tipo di documento.

<!doctype miodoc system>
<miodoc>
        <sezione>
        ...
        ...
        ...
</miodoc>

249.7   Mappe di sostituzione (shortref)

Fino a questo punto, si è vista la filosofia dell'SGML applicata alla struttura del documento e all'indipendenza rispetto alla piattaforma. L'analizzatore SGML standard, oltre che convalidare il documento in base al DTD, si occupa di rielaborare il sorgente SGML per generare un risultato intermedio, più facile da gestire per altri programmi di composizione.

In un certo qual modo, questo risultato intermedio può essere controllato, all'interno del DTD, attraverso la definizione di mappe di sostituzione, o shortref.

Con questo meccanismo, si punta normalmente ad attribuire significati speciali a simboli determinati, oltre che a controllare la spaziatura orizzontale e verticale del testo.

249.7.1   Dichiarazione e abbinamento delle mappe di sostituzione

La mappa di sostituzione definisce un abbinamento tra un simbolo e un'entità che ne prenderà il posto. L'esempio seguente è solo un pezzo ipotetico della dichiarazione di una mappa del genere.

<!SHORTREF miamappa
...
        "[" lsqb
        "]" rsqb
        "~" nbsp
        "_" lowbar
        "#" num
        "%" percnt
        "^" circ
        "{" lcub
        "}" rcub
        "|" verbar >

Dall'esempio si può osservare che alcuni simboli vengono sostituiti con le relative entità, indicate solo per nome, senza bisogno della e-commerciale e del punto e virgola finale. Questo fatto, di per sé, potrebbe sembrare assolutamente inutile dal punto di vista di SGML: se si può scrivere una parentesi quadra aperta, perché sostituirla automaticamente con la sua entità corrispondente. Il fatto è che il software utilizzato per la composizione, potrebbe attribuire un significato speciale a una parentesi quadra, mentre quello che si vuole nel testo SGML è che questa valga solo per quello che appare. In tal modo, chi scrive dovrebbe utilizzare necessariamente la macro &lsqb; per non creare problemi al programma di composizione o di elaborazione successiva.

Nello stesso modo, attraverso la mappa di sostituzione, si può attribuire un significato completamente diverso alla parentesi quadra aperta: per assurdo, potrebbe diventare una parentesi graffa...

<!SHORTREF miamappa
...
        "[" lcub
        "]" rcub
...
        "{" lcub
        "}" rcub
        "|" verbar >

Volendo fare delle acrobazie, si può associare un simbolo a un'entità che poi si traduce in un marcatore. Si osservi l'esempio.

<!ENTITY formula1 '<formula>'>
<!ENTITY formula0 '</formula>'>
<!SHORTREF miamappa
...
        "[" formula1
        "]" formula0
...
        "{" lcub
        "}" rcub
        "|" verbar >

In questo modo, quando nel testo si utilizzano le parentesi quadre, ciò che si ottiene è l'apertura e la chiusura dell'elemento formula.

Gli elementi SGML vanno abbinati alle mappe che si ritiene siano più adatte per i loro scopi. Tuttavia, un elemento può non essere stato abbinato esplicitamente ad alcuna mappa; in tal caso eredita quella dell'elemento che lo contiene effettivamente, di volta in volta, nel documento. Di conseguenza, diventa importante abbinare esplicitamente una mappa almeno all'elemento più esterno, ovvero a quello che corrisponde al nome del tipo stesso di documento.

Dagli esempi mostrati, sarà stato notato che la mappa ha un nome, indicato subito dopo la parola chiave SHORTREF che apre il comando. Se si vuole abbinare la mappa miamappa all'elemento acronimo, si procede come nell'esempio seguente:

<!USEMAP miamappa acronimo>

249.7.2   Spaziature e interruzioni di riga

In linea di principio, il risultato dell'elaborazione dell'analizzatore SGML contiene tutti gli spazi orizzontali e verticali esistenti nel sorgente di partenza. Però, per quanto possibile, si cerca normalmente di evitare che il sorgente SGML sia vincolato dalla spaziatura utilizzata, che in realtà potrebbe servire solo per facilitarne la lettura umana con rientri, allineamenti, spazi verticali come si farebbe con un linguaggio di programmazione.

Per questo ci deve essere un modo per poter identificare le spaziature orizzontali, le righe vuote e quelle bianche, in modo da poterle sopprimere nel risultato dell'elaborazione SGML. Naturalmente, bisogna poter distinguere, perché ci sono situazioni in cui gli spazi e le righe vuote hanno un significato e vanno mantenuti.

Per queste cose si utilizzano delle macro speciali, ma prima di descriverle, occorre definire alcuni concetti. Dal punto di vista dell'SGML, una riga è una sequenza di caratteri, con un inizio e una fine, ignorando completamente la codifica che si utilizza in pratica per separare una riga dall'altra.

Nei sistemi Unix, il codice di interruzione di riga è composto dal carattere <LF> mentre in altri sistemi si utilizza la sequenza <CR><LF>. Per l'SGML è come se questi codici non esistessero: le righe finiscono prima del codice di interruzione di riga e iniziano dopo tale codice. Si osservi l'esempio seguente:

<paragrafo>Ciao,
come stai?
Io bene; e tu?</paragrafo>

L'idea che ha l'SGML di ciò che è stato scritto, può essere rappresentata dallo schema seguente, dove è stato utilizzato il simbolo ^ per segnalare l'inizio della riga, il simbolo $ per segnalarne la fine, i simboli > e < per indicare l'inizio e la fine dell'elemento.

>Ciao,$
^come stai?$
^Io bene; e tu?<

Può sembrare strano, ma all'inizio e alla fine del testo mancano questi margini: esiste solo l'inizio e la fine dell'elemento. Se si dovesse sopprimere una riga, si eliminerebbe implicitamente anche il suo inizio e la sua fine.

Da qualche parte si potrebbe leggere che il codice di inizio riga equivale al codice <LF>, mentre quello di fine riga corrisponde a <CR>. Evidentemente questo ragionamento può valere solo per le piattaforme che utilizzano file di testo con un'interruzione di riga <CR><LF>, ma si tratta di una semplificazione che non corrisponde alla logica di SGML e può essere solo forviante.

La tabella 249.2 mostra le macro più importanti che possono essere usate per il controllo delle spaziature superflue.

Tabella 249.2. Simboli di definizione di spaziature e delimitazione delle righe.

L'esempio seguente mostra una mappa di sostituzione tipica, in cui si vogliono ignorare (e di conseguenza, eliminare) gli spazi orizzontali superflui, le righe vuote, quelle bianche, infine si vuole che tutto il testo si traduca in una riga sola.

<!shortref miamappa
        "BB"            space
        "&#RS;B"        null
        "B&#RE;"        space
        "&#RS;B&#RE;"   null
        "&#RS;&#RE;"    null
        "&#RS;"         null
        "&#RE;"         space
        "[" lsqb
        "]" rsqb
        "~" nbsp
        "_" lowbar
        "#" num
        "%" percnt
        "^" circ
        "{" lcub
        "}" rcub
        "|" verbar >

Le macro &space; e &null; si riferiscono rispettivamente a un solo carattere spazio e alla stringa nulla. Generalmente devono essere dichiarate nel DTD nel modo seguente:

<!ENTITY space " ">
<!ENTITY null "">

Per comprendere meglio l'effetto della mappa di sostituzione proposta, conviene partire da un esempio e analizzare gli effetti di ogni dichiarazione, una alla volta. In particolare, gli utenti dei sistemi Unix devono dimenticare per un po' il comportamento del codice di interruzione di riga (newline), perché SGML considera solo la stringa nulla all'inizio e alla fine della riga: solo quando la fine di una riga e l'inizio della successiva sono stati rimossi, allora queste due vengono unite assieme.

Supponiamo di cominciare da una variante dell'esempio già descritto, dove sono stati aggiunti tanti spazi orizzontali e verticali superflui.

>     Ciao,      $
^$
^         $
^come stai?$
^$
^     Io         bene;         e      tu?     <

Applicando la trasformazione "BB" space, vengono sostituiti gli spazi orizzontali all'inizio dell'elemento, alla fine e all'interno delle frasi con uno spazio singolo normale.

> Ciao,      $
^$
^         $
^come stai?$
^$
^     Io bene; e tu? <

Si può osservare che le frasi si sono ricompattate; inoltre, all'inizio e alla fine dell'elemento è rimasto un solo spazio superfluo (che non potrà essere rimosso). Si continua applicando "&#RS;B" null; si ottiene l'eliminazione dell'inizio delle righe (quelle che contengono effettivamente qualcosa) fino al primo carattere diverso da uno spazio orizzontale.

> Ciao,      $
^$
^         $
^come stai?$
^$
 Io bene; e tu? <

Quando si applica anche "B&#RE;" space; si ottiene la sostituzione degli spazi orizzontali nella parte finale, fino alla fine delle righe (quelle che contengono effettivamente qualcosa), con uno spazio singolo. Nell'esempio, dal momento che nella prima riga è scomparso il simbolo che segnalava la fine della riga, appare un trattino basso, ma solo per aiutare il lettore.

> Ciao,_
^$
^         $
^come stai?$
^$
 Io bene; e tu? <

La sostituzione "&#RS;B&#RE;" null elimina le righe bianche, ma non vuote.

> Ciao,_
^$
^come stai?$
^$
 Io bene; e tu? <

La sostituzione "&#RS;&#RE;" null elimina le righe vuote.

> Ciao,_
^come stai?$
 Io bene; e tu? <

Si può osservare che la riga contenente la frase «come stai?», è rimasta intatta. Infatti, non contenendo spazi aggiuntivi all'inizio o alla fine, non è mai stata interessata dalle trasformazioni applicate fino a questo momento.

Finalmente entrano in gioco "&#RS; null e "&#RE; space, per eliminare l'inizio e la fine delle righe rimaste. Per la precisione, la fine delle righe deve essere sostituito con uno spazio singolo, altrimenti si rischia di attaccare assieme delle parole. La trasformazione viene mostrata in due passaggi.

> Ciao,_
 come stai?_
 Io bene; e tu? <

> Ciao, come stai? Io bene; e tu? <

249.7.3   Limitazioni ed esagerazioni

Da quanto visto nella sezione precedente si potrebbe supporre che il meccanismo delle mappe di sostituzione permetta di sostituire quello che si vuole. Non è così, solo alcuni simboli sono considerati dei possibili shortref. In ogni caso, ci si accorge subito quando si usa qualcosa di sbagliato: l'analizzatore SGML avvisa immediatamente.

Attraverso le mappe di sostituzione si possono realizzare anche delle acrobazie che spesso sono poco giustificabili e che sarebbe meglio evitare. A parere di chi scrive, la cosa meno utile che si possa richiedere a un sistema SGML è quella di fare in modo che le righe vuote e quelle bianche nel sorgente siano trasformate in separazioni tra i paragrafi. Infatti, l'SGML non ha questo scopo, eppure molti sistemi si impegnano in questo senso. LinuxDoc raggiunge questo risultato intervenendo proprio nelle mappe di sostituzione, facendo in modo che le righe bianche, identificate dal simbolo &#RS;B&#RE;, e quelle vuote, identificate dal simbolo &#RS;&#RE;, siano sostituite da </p><p>, ovvero dai marcatori che servono a chiudere e a riaprire un paragrafo.

...
<!ENTITY psplit '</p><p>' >
...
<!SHORTREF pmap
        "&#RS;B" null 
        "&#RS;B&#RE;" psplit
        "&#RS;&#RE;" psplit
...
        "{" lcub
        "}" rcub
        "|" verbar >
...

Quello che si vede sopra è proprio un estratto dal DTD di LinuxDoc, dove si vede che la macro &psplit; viene poi rimpiazzata dai marcatori già descritti.

249.7.4   Soluzione normale

Dopo aver visto in quanti modi si possono usare le mappe di sostituzione, vale la pena di mostrare una soluzione «normale», in cui il problema che si vuole risolvere è l'eliminazione degli spazi superflui all'inizio e alla fine delle righe, oltre che l'eliminazione delle righe bianche e quelle vuote:

<!ENTITY space " ">
<!ENTITY null "">
<!ENTITY recordstart "&#RS;">
<!ENTITY recordend "&#RE;">

<!SHORTREF standard
        "&#RS;B"        recordstart
        "B&#RE;"        recordend
        "&#RS;B&#RE;"   null
        "&#RS;&#RE;"    null
>

In questo modo, come si vede, è stato necessario dichiarare due entità nuove, recordstart e recordend, per poter sopprimere gli spazi iniziali e finali superflui, pur mantenendo la separazione in righe distinte.

249.8   Elementi di testo riportato letteralmente

La predisposizione di un elemento SGML che consenta la scrittura di testo da riportare in modo letterale costituisce un problema. Si possono scegliere soluzioni diverse, ma nessuna perfetta secondo tutti i punti di vista.

Questo tipo di problema è particolarmente sentito nella scrittura di documenti tecnici, in cui ci può essere la necessità di mostrare porzioni di codice scritto in un qualche linguaggio di programmazione. Per evitare che simboli determinati vengano interpretati dall'analizzatore SGML, occorrerebbe utilizzare continuamente delle macro alternative.

Si possono seguire due direzioni per cercare di risolvere il problema: l'uso di elementi predisposti per un tipo di contenuto più o meno letterale, oppure l'uso di elementi normali con l'aggiunta di una sezione marcata di tipo CDATA.

249.8.1   Tipo di contenuto letterale

Nella definizione di un elemento occorre stabilite il tipo di contenuto. A livello elementare, quando l'elemento non può contenere altri elementi, si utilizza normalmente la parola chiave #PCDATA, con cui si fa riferimento a testo che viene analizzato alla ricerca di entità generali da espandere, senza ammette altri elementi al suo interno.

Per ottenere un elemento adatto al contenuto letterale, si usa solitamente il tipo di contenuto definito dalla parola chiave RCDATA, che non è perfettamente letterale, ma vi si avvicina molto. Per la precisione, la forma del testo viene mantenuta, con tutte le sue spaziature e le interruzioni di riga, ma le entità generali vengono espanse, mentre vengono ignorati eventuali marcatori di apertura. Ciò significa che, la e-commerciale (&) non può essere usata in modo letterale, a meno di usare una macro adatta al suo posto. Lo stesso ragionamento riguarda la sequenza di minore e barra obliqua (</), che è ammessa solo nel marcatore di chiusura di questo elemento.

<!ELEMENT formattato - - RCDATA>

L'esempio mostra la dichiarazione dell'elemento formattato, di tipo RCDATA. Generalmente, per poter utilizzare questo elemento nel modo corretto, si devono dichiarare anche due entità generali specifiche.

<!ENTITY ero   CDATA "&">
<!ENTITY etago '</' >

In tal modo, al posto del simbolo & si dovrà utilizzare la macro &ero;, mentre al posto della sequenza </, si dovrà usare la macro &etago;. È il caso di osservare che l'entità generale ero è volutamente diversa da un'entità analoga, necessaria a indicare una e-commerciale in un testo normale. Infatti, in questo caso, si vuole generare un testo letterale, che si presume possa essere interpretato nello stesso modo letterale anche da altro software di composizione successivo.

In alternativa, si potrebbe usare anche un tipo di contenuto definito dalla parola chiave CDATA, che dovrebbe essere in grado di ignorare sia i simboli dei marcatori, che le macro delle entità generali. Di fatto però, questo tipo di elemento non dà normalmente i risultati sperati.

249.8.2   Sezioni marcate

Nel sorgente SGML, all'interno di un elemento che non sia stato predisposto per un contenuto letterale, è possibile inserire una sezione marcata di tipo CDATA, come nell'esempio seguente:

<![CDATA[
Testo letterale: &amp;, &etago;, <ciao>, </ciao>,
ecc., vengono trattati in modo letterale.
]]>

In tal modo, vengono preservati anche gli spazi, orizzontali e verticali, e ogni eventuale mappa di sostituzione (shortref) viene ignorata temporaneamente. L'unica cosa che non può contenere questo ambiente, è la sequenza ]]>, che serve a concludere la sezione marcata.⁽⁴⁾

Questa tecnica ha il vantaggio di potersi applicare anche a un DTD che non sia stato predisposto con elementi atti all'inserimento di testo letterale. Purtroppo, non tutti gli strumenti SGML sono in grado di riconoscere le sezioni marcate; si pensi ai navigatori, che pur sapendo interpretare l'HTML, non sono sempre in grado di riconoscere tali particolarità.

249.9   Cataloghi

Nelle sezioni precedenti si è visto che il DTD può essere composto da diversi file fisici nel sistema. Lo stesso preambolo di un sorgente SGML prevede la dichiarazione e l'inclusione di un DTD. È stato mostrato come includere un blocco di DTD esterno, attraverso la dichiarazione e il successivo utilizzo di un'entità parametrica che fa riferimento a un file esterno.

Quando si vogliono utilizzare componenti esterni senza fare riferimento a un file preciso, si possono predisporre dei cataloghi, con i quali si esplicitano questi dettagli riferiti al sistema di cui si dispone effettivamente.

Questo tipo di approccio viene usato tipicamente per due motivi: evitare di dover fare riferimento a un file preciso per il DTD nella dichiarazione del tipo di documento all'inizio del sorgente SGML; includere in modo dinamico le entità standard riferite alle lettere accentate e ai simboli speciali. Per quanto riguarda il secondo problema, si deve tenere presente che l'SGML si astrae dalla piattaforma, quindi, il modo in cui le entità di questo tipo vanno rappresentate dipende da quello che si vuole fare dopo.

249.9.1   Riferimenti esterni

Generalmente, quando si vogliono usare i cataloghi, si possono fare due tipi di riferimenti a componenti esterne: l'identificatore pubblico e l'identificatore di sistema. Seguono quattro esempi significativi a questo proposito: nei primi due si tratta della dichiarazione del tipo di documento HTML e di un'entità parametrica, attraverso un identificatore pubblico (una stringa piuttosto lunga); negli ultimi due si tratta delle stesse dichiarazioni, ma fatte attraverso un identificatore di sistema.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">

<!ENTITY % ISOlat1 PUBLIC "ISO 8879:1986//ENTITIES Added Latin 1//EN">

<!DOCTYPE HTML SYSTEM>

<!ENTITY % ISOlat1 SYSTEM>

Si tratta, evidentemente, di due approcci equivalenti, ma che hanno delle conseguenze differenti nell'applicazione pratica. Dalle parole chiave utilizzate, PUBLIC e SYSTEM, si può intuire che l'identificatore di sistema è legato alla situazione del sistema, anche se non è obbligatoria l'indicazione immediata del file corrispondente.

L'uso degli identificatori pubblici è quindi una scelta più conveniente, essendo meno vincolata alla piattaforma. Infatti, questi vengono utilizzati prevalentemente per tutto ciò che è già stato standardizzato: i DTD standard e le entità esterne standard.

249.9.2   Il catalogo in pratica

Quando si usano strumenti di analisi ed elaborazione SGML comuni, il catalogo è un file. A seconda degli strumenti utilizzati, potrebbe essere necessario configurare una variabile di ambiente, o usare un'opzione opportuna nella riga di comando, per comunicare a questi la sua posizione.

Il catalogo serve a esplicitare tutte le componenti esterne che non sono state indicate in modo preciso (il nome del file). Si osservi l'esempio seguente:

-- Entità standard richiamate attraverso un identificatore di sistema --
-- Sarebbe meglio non usare questo metodo --
ENTITY %ISOlat1            "ISOlat1"
ENTITY %ISOnum             "ISOnum"
ENTITY %ISOdia             "ISOdia"

-- Entità standard richiamate attraverso un identificatore pubblico --
-- Questo tipo di indicazione è preferibile in generale --
PUBLIC "ISO 8879:1986//ENTITIES Added Latin 1//EN"                "ISOlat1"
PUBLIC "ISO 8879:1986//ENTITIES Numeric and Special Graphic//EN"  "ISOnum"
PUBLIC "ISO 8879:1986//ENTITIES Diacritical Marks//EN"            "ISOdia"

-- DTD predefinito per il tipo HTML --
DOCTYPE "HTML"                                  "html32.dtd"

-- Identificatori pubblici per le varie forme dell'HTML 3.2 --
PUBLIC "-//W3C//DTD HTML 3.2//EN"               "html32.dtd"
PUBLIC "-//W3C//DTD HTML 3.2 Draft//EN"         "html32.dtd"
PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"         "html32.dtd"

Ogni direttiva dell'esempio occupa una riga e si compone di tre parti, dove l'ultima informazione rappresenta il file da utilizzare per quel particolare tipo di entità, documento o identificatore pubblico.

Si noti che i commenti sono delimitati da coppie di trattini, --, come si fa all'interno delle istruzioni SGML.

Alcune direttive

PUBLIC identificatore_pubblico identificatore_di_sistema

Stabilisce l'identificatore di sistema effettivo (il file) corrispondente all'identificatore pubblico indicato. Quando possibile, è preferibile utilizzare gli identificatori pubblici per definire gli oggetti.

DOCTYPE nome identificatore_di_sistema

Stabilisce l'identificatore di sistema effettivo (il file) corrispondente al nome del tipo di documento indicato. Dal momento che questo nome può fare riferimento a uno tra diversi DTD alternativi (si pensi al caso dell'HTML con le sue versioni), questa dichiarazione serve prevalentemente per stabilire un DTD predefinito nel caso in cui non sia stato specificato un identificatore pubblico nel documento che si elabora.

ENTITY nome identificatore_di_sistema

Stabilisce l'identificatore di sistema effettivo (il file) corrispondente all'entità generale indicata.

ENTITY %nome identificatore_di_sistema

Stabilisce l'identificatore di sistema effettivo (il file) corrispondente all'entità parametrica indicata. Si osservi il fatto che il simbolo di percentuale è attaccato al nome dell'entità.

Esempi

Negli esempi seguenti, viene mostrata prima l'istruzione utilizzata nel DTD, o nel preambolo del sorgente SGML, quindi si presenta la direttiva corrispondente, necessaria nel catalogo.

---

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">

Si tratta della dichiarazione, all'inizio di un sorgente SGML, dell'utilizzo del DTD HTML, definito in base all'identificatore pubblico -//W3C//DTD HTML 3.2 Final//EN. Perché da questo si possa arrivare a identificare un file particolare, occorre che nel catalogo appaia una direttiva come quella seguente:

PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"         "html32.dtd"

In tal caso, all'identificatore pubblico -//W3C//DTD HTML 3.2 Final//EN, viene abbinato il file html32.dtd.

---

<!DOCTYPE HTML SYSTEM">

Si tratta della dichiarazione, all'inizio di un sorgente SGML, dell'utilizzo del DTD HTML, utilizzando un identificatore di sistema che non viene precisato in modo effettivo. Perché da questo si possa arrivare a identificare un file particolare, occorre che nel catalogo appaia una direttiva come quella seguente:

DOCTYPE HTML            "html32.dtd"

In tal caso, all'identificatore di sistema HTML, viene abbinato il file html32.dtd (l'identificatore di sistema effettivo).

---

<!ENTITY % ISOlat1 PUBLIC "ISO 8879:1986//ENTITIES Added Latin 1//EN">

All'interno del DTD, dichiara l'entità parametrica ISOlat1 definita secondo l'identificatore pubblico ISO 8879:1986//ENTITIES Added Latin 1//EN. Perché da questo si possa arrivare a identificare un file particolare, occorre che nel catalogo appaia una direttiva simile a una delle due mostrate di seguito:

PUBLIC "ISO 8879:1986//ENTITIES Added Latin 1//EN" "ISOlat1.latex"

ENTITY %ISOlat1 "ISOlat1.latex"

Nel primo caso, all'identificatore pubblico ISO 8879:1986//ENTITIES Added Latin 1//EN, viene abbinato il file ISOlat1.latex; nel secondo, si specifica direttamente che l'entità parametrica ISOlat1 corrisponde al contenuto del file ISOlat1.latex.

---

<!ENTITY % ISOlat1 SYSTEM>

Nel DTD, viene dichiarata l'entità parametrica ISOlat1, utilizzando un identificatore di sistema che non viene precisato in modo effettivo. Perché da questo si possa arrivare a identificare un file particolare, occorre necessariamente che nel catalogo appaia una direttiva come quella seguente, dal momento che non è possibile fare riferimento a un identificatore pubblico:

ENTITY %ISOlat1            "ISOlat1.latex"

In questo modo si definisce l'identificatore di sistema effettivo dell'entità parametrica ISOlat1, facendola corrispondere al file ISOlat1.latex (l'identificatore di sistema effettivo).

249.10   Riferimenti

• C. M. Sperberg-McQueen, Lou Burnard, Guidelines for Electronic Text Encoding and Interchange (TEI P3), in particolare il secondo capitolo: A gentle introduction to SGML

  <http://etext.virginia.edu/TEI.html>

• The SGML Newsletter

  <http://architag.com/tag/>

• The SGML/XML Web Page

  <http://www.oasis-open.org/cover/>

• The SGML Centre

  <http://www.sgml.u-net.com/>

1) In questo momento può apparire strano l'uso di questa forma di eccezione. Tuttavia, per comprenderne meglio il senso, occorrerebbe conoscere come funzionano le entità parametriche che sono descritte più avanti. Con queste si può definire un modello del contenuto attraverso una sorta di variabile e, in tal caso, potrebbe essere conveniente l'indicazione di una o più eccezioni, sia in aggiunta che in detrazione.

2) Le entità standard ISO 8879, sono distinte in 19 gruppi, che in parte si sovrappongono (a volte si ripetono alcune dichiarazioni nello stesso modo). Questi 19 gruppi di entità corrispondono ad altrettanti file, per i quali esiste anche un nome stabilito.

3) Il contenuto delle stringhe delimitate riguarda i programmi che fanno uso del documento dopo l'analisi SGML. Dipende da loro il senso che hanno queste informazioni.

4) Bisogna tenere presente che la sequenza ]]> può essere rappresentata anche con l'inserzione di spazi; per esempio come ] ]>, ]] > o ] ] >. Si tratta sempre della stessa cosa.