Nei semplici casi descritti finora si presuppone che sia sempre possibile identificare i componenti di ogni elemento definito in una struttura testuale. Una poesia contiene stanze e un'antologia contiene poesie. Le stanze non possono trovarsi fuori delle poesie o combinate con qualche altro elemento; una poesia non può contenere un'antologia. Tutti gli elementi di un determinato tipo di documento possono essere ordinati in una struttura gerarchica in forma di un albero con una radice unica e tanti elementi terminali (per lo più contenenti #PCDATA). Questa semplificazione risulta sorprendentemente utile per molti scopi. Non è tuttavia adatta alla complessità della struttura dei testi reali. In particolare non funziona quando ci sono elementi più o meno liberi che possono trovarsi in tutti i livelli della struttura o quando possono essere identificate diverse gerarchie nello stesso documento. Nel primo caso SGML risolve con il meccanismo della eccezione, nel secondo con la definizione di strutture "concorrenti".
In molti documenti si possono trovare elementi che ricorrono in ogni livello della struttura. Ad esempio le note possono essere riferite a tutto il contenuto di una poesia, ad una stanza, ad un verso di una stanza o ad una singola parola. Nell'edizione critica può accadere lo stesso con le varianti. L'operazione di aggiungere un elemento <nota> come componente facoltativo di tutte le dichiarazioni non è particolarmente onerosa quando la struttura è semplice, ma in altri casi, dove i livelli della gerarchia sono dieci o venti, un approccio del genere non funziona. SGML consente di modificare tutti i modelli mediante la lista delle eccezioni. Esistono due tipi di eccezioni: inclusioni, cioè elementi che possono essere inclusi in qualsiasi punto del modello o in uno degli elementi che lo costituiscono; e le esclusioni, elementi che non possono essere presenti nel modello corrente.
Per introdurre nelle precedenti dichiarazioni le note e le varianti, che riteniamo poter apparire in qualsiasi parte del testo, dobbiamo prima introdurre la dichiarazione dei due elementi:
<!ELEMENT (nota | variante) - - (#PCDATA)>
Gli elementi nota e variante devono avere sempre il tag di apertura e quello di chiusura dal momento che possono trovarsi in qualsiasi posizione. Invece di aggiungerli nel contenuto di ogni tipo di poesia, possiamo aggiungerli mediante il meccanismo dell'inclusione all'elemento poesia:
<!ELEMENT (poesia) - O (titolo?, (stanza+ | coppia_di_versi+ | verso+) ) + (nota | variante)>
Il segno + prima della lista (NOTA | VARIANTE) indica che si tratta di un'eccezione di inclusione. Con questa aggiunta note e varianti possono ricorrere in qualsiasi parte del contenuto di una poesia, persino in quegli elementi (come <titolo>) per il quale è stato definito un contenuto #PCDATA. Essi possono trovarsi anche dentro note o varianti!
Se vogliamo evitare che note e varianti si trovino dentro titoli, si potrebbe aggiungere un'eccezione di esclusione alla dichiarazione di <titolo>:
<!ELEMENT (titolo) - O (#PCDATA) - (nota | variante)>
Il segno - all'inizio della lista (NOTA | VARIANTE) indica che si tratta di un'eccezione di esclusione. Con questa aggiunta note e varianti non potranno trovarsi dentro titoli, annullando la loro potenziale inclusione implicata dalla precedente aggiunta alla definizione di <poesia> .
Allo stesso modo possiamo impedire che note e varianti siano contenute dentro se stesse modificando anche la loro definizione:
<!ELEMENT (nota | variante) - - (#PCDAT) - (nota | variante)>
Il lettore attento noterà che questa modifica impedisce che varianti si trovino nelle note e note nelle varianti. Le eccezioni di inclusione e di esclusione dovranno tuttavia essere usate con attenzione perché le implicazioni sullo sviluppo dell'albero potrebbero non essere immediatamente evidenti.
Tutte le strutture finora considerate sono semplicemente gerarchiche: ciò vuol dire che ad ogni livello dell’albero i nodi sono sempre interamente contenuti nel nodo padre. La successiva figura rappresenta la struttura di un documento costruito sulla base della semplice DTD definita precedentemente. Abbiamo già visto come la poesia di Blake può essere divisa in un titolo e due stanze, ciascuna composta da 4 versi. In questo schema aggiungiamo una seconda poesia composta da una stanza e un titolo, in modo da costituire un’antologia.
FIGURA p. 24
Chiaramente potrebbero essere disegnati molti schemi ad albero di questo tipo per rappresentare la struttura di questa o di altre antologie. Alcuni di essi potrebbero essere introdotti come ulteriori suddivisioni di questo albero: per esempio, potremmo dividere i versi a livello delle singole parole dal momento che nessuna parola travalica il limite del verso. Ma ci sono molte altre strutture gerarchiche che non possono essere adattate all’interno di questo albero. Potremmo essere interessati alle strutture sintattiche - che di rado rispettano i limiti formali del verso. O, per fare un altro esempio, potremmo voler rappresentare la divisione in pagine di diverse edizioni dello stesso testo.
Un sistema per ottenere questo risultato sarebbe quello di raggruppare versi e titoli in pagine. Una dichiarazione per l'elemento pagina è abbastanza semplice:
<!ELEMENT pagina - - ((titolo?, verso+)+) >
In tal modo si stabilisce che una pagina consiste in uno o più gruppi composti da un titolo facoltativo seguito da una sequenza di versi. (Notare per inciso che questo modello impedisce l’inserimento di un titolo da solo alla fine di una pagina). Il semplice inserimento dell’elemento <pagina> nella gerarchia prima definita non è comunque un compito facile. Alcune poesie sono più lunghe di una singola pagina, mentre alcune pagine contengono più di una poesia. Pertanto non possiamo inserire l’elemento <pagina> tra <antologia> e <poesia>, né tra <poesia> e <stanza>, né infine in entrambe le posizioni allo stesso tempo. Serve dunque la creazione di un’altra gerarchia con gli stessi elementi alla base (stanze, versi, titoli) combinati però in una struttura differente. Questo è possibile grazie al meccanismo del CONCUR presente nello standard SGML.
Si deve creare una definizione di tipo di documento (DTD) per ciascun albero gerarchico riconoscibile nel testo. La definizione che abbiamo finora elaborato per l’antologia è la seguente:
<!DOCTYPE antologia [ <!ELEMENT antologia - - (poesia+) >; <!ELEMENT poesia - - (titolo?, stanza+) > <!ELEMENT stanza - O (verso+) > <!ELEMENT (titolo|verso) - O (#PCDATA) > ] >
Come mostra l’esempio il nome di un tipo di documento deve essere sempre uguale al nome dell’elemento più grande, quello che si trova al vertice della gerarchia. La sintassi usata viene analizzata più avanti (sezione 2.9.2. "La DTD"). Per il momento limitiamoci ad aggiungere a questa dichiarazione una seconda definizione per un tipo di documento "concorrente" che chiameremo antologia divisa in pagine o <p.ant> per brevità
<!DOCTYPE p.ant [ <!ELEMENT p.ant - - (pagina+) > <!ELEMENT pagina - - ((titolo?, verso+)+) > <!ELEMENT (titolo|verso) - O (#PCDATA) > ] >
Abbiamo quindi definito due modi diversi di considerare lo stesso testo - i componenti PCDATA sono titoli o versi in entrambe le document type definition. Secondo un punto di vista i versi sono raggruppati in stanze e poemi; secondo l’altro sono ragguppati in pagine. Notare che si tratta esattamente dello stesso testo anche se descritto in due modi diversi; le due gerarchie consentono semplicemente di codificarlo in due modi diversi.
Per introdurre i codici necessari, si dovrà indicare a quale gerarchia appartiene ogni elemento. Questo si fa inserendo il nome del tipo di documento tra parentesi prima dell’identificativo relativo, sia nello start- sia nell’end-tag. Le pagine (visibili solamente nel tipo di documento <p.ant>) devono essere delimitate con un tag <(p.ant)pagina> all’inizio e </(p.ant)pagina> alla fine. Allo stesso modo poesie e stanze, che sono presenti solamente nella struttura <antologia>, devono essere delimitati usando i tag <(antologia)poesia> e <(antologia)stanza> rispettivamente. Per gli elementi verso e titolo, che sono presenti in entrambe le gerarchie non è necessario dare ulteriori specificazioni: ogni tag contenente solo un nome viene automaticamente attribuito a tutti i tipi di documento attivi.
Come semplice esempio facciamo l’ipotesi che la poesia di Blake sia edita in un’antologia divisa in pagine e che l’interruzione di pagina ricorra in mezzo alla prima stanza. La poesia può essere codificata nel modo seguente:
<(antologia)antologia> <(p.ant)p.ant> <(p.ant)pagina> <!- - Altri titoli e versi su questa pagina - -> <(antologia)poesia> <titolo>The SICK ROSE <(antologia)stanza> <verso>O Rose thou art sick. <verso>The invisible worm, </(p.ant)pagina> <(p.ant)pagina> <verso>That flies in the night <verso>In the howling storm: <(antologia)stanza> <verso>Has found out thy bed <verso>Of crimson joy: <verso>And his dark secret love <verso>Does thy life destroy. </(antologia)poesia> <!- -segue il resto della pagina- -> </(p.ant)pagina> </(p.ant)p.ant> </(antologia)antologia>
È ora possibile selezionare solo gli elementi collegati ad una struttura del testo anche se entrambe sono rappresentate nella codifica. Un programma per l’imaginazione considererà solamente gli elementi i cui tag includono l’indicazione P.ANT oltre a quelli privi di riferimento ai modelli. Un programma che lavora con l’altra struttura, ANTOLOGIA, non terrà conto dell’indicazione di fine pagina. Infine un programma finalizzato all’analisi della relazione esistente tra le due strutture potrà valutare allo stesso tempo tutti i tag.
Occorre tuttavia ricordare che CONCUR è un'opzione facoltativa di SGML e che non tutti i programmi SGML la supportano necessariamente, o nel caso in cui ciò avviene, la supportano esattamente nel modo previsto dallo standard. Per questo motivo, anche se sono state descritte le potenzialità di CONCUR, nelle Guidelines si suggeriscono sistemi alternativi per ottenere gli stessi risultati. Per una discussione approfondita sull’argomento si ramanda al Cap. 31 "Multiple Hierarchies".
Notare inoltre che non possiamo introdurre un nuovo elemento, ad esempio il numero di pagina, nel modello <p.ant> dal momento che non ci sono dati nel tipo di documento <antologia> da inserirvi. Nella successiva sezione verrà introdotto un modo per ottere tale risultato.
Nel contesto SGML la parola attributo, come altre parole, ha un significato particolare. Viene usata per descrivere informazioni che hanno una funzione descrittiva rispetto ad una specifica occorrenza di un elemento ma non fanno parte del suo contenuto. Per esempio potrebbe essere richiesta l’aggiunta di un attributo status alle occorrenze di determinati elementi in un documento per indicare il loro grado di completezza, o ancora di un attributo identificativo per poter inserire dei riferimenti ad una particolare occorrenza di un elemento da altre parti del documento. Gli attributi servono proprio in circostanze del genere.
Sebbene diversi elementi possano condividere attributi che hanno lo stesso nome (per esempio, nello schema TEI, ogni elemento ha un attributo id), essi vengono considerati sempre diversi e possono avere valori diversi. Se ad un elemento sono stati assegnati degli attributi, i valori possibili di tali attributi vengono inseriti nel documento all’interno dello start-tag di una particolare occorrenza dell'elemento. Un end-tag non può contenere attributi.
Esempio: <poesia id=P1 status="bozza"> ... </poesia>
All'elemento <poesia> sono stati assegnati due attributi: id e status. La poesia codificata in questo esempio presenta come valore dell'attributo id P1 e come valore dell'attributo status bozza. Un programma SGML può usare i valori degli attributi in qualsiasi modo; ad esempio per stampare una poesia con l'attributo "status=bozza" in modo diverso da quelli con l’attributo "status=corretto"; un altro programma potrebbe servirsi degli attributi per decidere se una poesia deve o meno essere trattata. L’attributo id è particolare perché per convenzione viene sempre usato per assegnare un valore unico e identificativo ad una particolare occorrenza di un elemento allo scopo di costruire riferimenti incrociati nel testo.
Come gli elementi, anche gli attributi vengono dichiarati nella DTD SGML usando una sintassi simile. Si può specificare nella dichiarazione il nome dell’attributo e dell’elemento al quale si riferisce, quale tipo di valore è accettato e il valore di default.
Le seguenti dichiarazioni potrebbero esser usate per definire i due attributi introdotti precedentemente per l’elemento <poesia>.
<!ATTLIST poesia id ID #IMPLIED status (bozza | corretto | pubblicato) bozza >
La dichiarazione comincia con la parola chiave ATTLIST che introduce una lista di attributi. La prima parte della lista contiene il nome dell’elemento cui si riferscono gli attributi. Nell’esempio sono stati dichiarati attributi solamente per l’elemento <poesia>. Se più elementi hanno in comune gli stessi attributi, si può usare una dichiarazione unica; allo stesso modo delle dichiarazioni di elementi, si possono introdurre più nomi in una lista tra parentesi. Dopo il nome dell’elemento (o la lista di nomi) si trova una serie di righe, una per ogni attributo da dichiarare, composte di tre parti. Nelle righe viene indicato il nome dell’attributo, il tipo di valore da assegnargli, il valore di default.
I nomi di attributi (id e status nell’esempio) sono soggetti alle stesse restrizioni degli altri nomi SGML; non è necessario che ricorrano una sola volta nella DTD, tuttavia non possono essere ripetuti due volte nella medesima lista.
La seconda parte della dichiarazione di un attributo può avere due forme, come visto in precedenza. Si può usare una parola chiave per dichiarare il tipo di valore dell’attributo. Nell’esempio precedente ID indica che l’attributo conterrà un identificativo univoco per ciascuna poesia. Altre possibili parole chiave sono:
Nell’esempio precedente è stata introdotta una lista di possibili valori per l’attributo status. Ciò vuol dire che un parser può verificare se il valore dell’attributo status di ogni poesia corrisponde a "bozza", "corretta" o "pubblicata". Se il valore fosse stato dichiarato come CDATA o NAME un parser avrebbe accettato qualunque stringa di caratteri (status=awful o status=12345678 nel caso di NMTOKEN; status="anything goes" o status = "well, ALMOST anything" nel caso di CDATA). Qualche volta non è possibile stabilire tutti i valori legali; quando è possibile, è meglio farlo.
L’ultima parte della definizione di attributo specifica come un parser deve interpretare l’assenza dell’attributo. Questo è possibile introducendo una delle parole chiave prima elencate o un valore specifico da attribuire a ogni occorrenza di elemento per la quale non viene esplicitamente dichiarato un valore nel testo elettronico. In riferimento al precedente esempio, se una poesia viene codificata semplicemente come <poesia>, il parser la tratterà come se lo start-tag fosse <poesia status="bozza">. In alternativa si può introdurre una delle seguenti parole chiave:
#REQUIRED: deve essere sempre specificato
un valore per l'attributo
#IMPLIED: non è sempre necessario definire l'attributo (come nel precedente caso di ID)
#CURRENT: se l'attributo non è definito prende come valore l'ultimo introdotto nelle
precedenti occorrenze dell'elemento.
Ad esempio se la defnizione fosse riscritta con la forma
<!ATTLIST poesia id ID #IMPLIED status (bozza | corretto | pubblicato) #CURRENT>
le poesie dell'antologia codificate semplicemente come <poesia> sarebbero trattate tutte come se avessero lo stesso status della poesia precedente. Se la parola chiave fosse #REQUIRED, il parser considererebbe queste poesie come codificate in modo sbagliato, perché sarebbe sempre richiesta l'introduzione di un valore. L'uso di #CURRENT implica che il valore specificato per la prima poesia viene applicato a tutte le successive poesie fino ad introduzione di un nuovo valore. Solo lo status della prima deve essere dichiarato se è lo stesso per tutti.
Talvolta è necessario fare riferimento ad un elemento testuale da un'altra parte del documento; un esempio sono le frasi "vedi nota 6" o "come discusso nel capitolo 5". Al momento della composizione di un testo i numeri da associare alle note e ai capitoli non sono definitivi. Se si utilizza una codifica descrittiva i numeri di pagina o di capitolo vengono assegnati al momento della presentazione e non dovranno essere presenti nel testo (potrebbero per altro cambiare da una applicazione ad un'altra). SGML dispone di un meccanismo grazie al quale si può assegnare ad ogni occorrenza di un elemento un identificativo speciale da usare poi per i richiami. I riferimenti incrociati sono a loro volta un elemento che va dichiarato nella DTD. In ogni caso l'etichetta con funzione di identificatore (del tutto arbitraria nella forma) viene introdotta come valore dell'attributo.
Supponiamo ad esempio di voler includere un riferimento nelle note a una poesia che contiene riferimenti ad un'altra poesia. Per prima cosa dobbiamo trovare il modo di attaccare un'etichetta ad ogni poesia definendo un attributo per l'elemento <poesia>:
<!ATTLIST poesia id ID #IMPLIED >
Definiamo un attributo id il cui valore deve essere del tipo ID. Non è richiesto che ogni attributo del tipo ID abbia come nome id; tuttavia è un'utile convenzione che viene in genere rispettata, Non tutte le poesie devono avere un attributo id e il parser può ignorare quelle che non lo hanno. Solo le poesie alle quali intendiamo fare riferimento hanno bisogno dell'attributo; per queste si deve inserire nello start-tag un identificativo univoco, ad esempio:
<poesia ID=Rose> Testo della poesia con identificativo "Rose" </poesia> <poesia ID=P40> Testo della poesia con identificativo "P40" </poesia> <poesia> Testo della poesia senza identificativo </poesia>
Di seguito definiamo un nuovo elemento per il riferimento incrociato. Esso non avrà alcun contenuto - è solo un puntatore - ma un attributo il cui valore sarà l'identificativo dell'elemento verso il quale punta.
<!ELEMENT rif_poesia - O EMPRY > <!ATTLIST rif_poesia target IDREF #REQUIRED>
L'elemento <rif_poesia> non ha bisogno dell'end-tag perché non ha contenuto. Ha un solo attributo chiamato target il cui valore deve essere del tipo IDREF (parola chiave usata per i puntatori) e deve essere sempre specificato.
Con queste dichiarazioni possiamo ora codificare un riferimento alla poesia con id Rose nel seguente modo:
Blak's poem on the sick rose <RIF_POESIA TARGET=Rose> ...
Quando un parser SGML incontra questo elemento vuoto verifica se esiste un elemento con identificativo Rose. Diversi programmi SGML possono eseguire varie azioni: un impaginatore può costruire un riferimento con numero pagina e di riga per localizzare la poesia e inserirlo nel documento, o mettere tra virgolette il titolo della poesia. Un programma per gli ipertesti potrebbe usare questo elemento vuoto per attivare un collegamento verso la poesia cui si fa riferimento. Lo scopo della codifica SGML è, solo quello di dichiarare che esiste un riferimento incrociato; non cosa deve fare il programma.
Gli aspetti di SGML finora considerati riguardano tutti la codifica di elementi strutturali in un documento. SGML mette a disposizione anche un metodo semplice e flessibile per codificare parti del contenuto di un documento che non hanno una specifica funzione strutturale. La parola entità ha in SGML un significato speciale: indica una parte di un documento codificato alla quale è stato assegnato un nome indipendentemente da considerazioni relative alla struttura. Un'entità può essere una stringa di caratteri o un intero file contenente testo. Per includerla in un documento si usa un metodo chiamato entity reference. Ad esempio la seguente dichiarazione:
<!ENTITY tei "Text Encoding Initiative">
definisce una entità, il cui nome è tei e il contenuto la stringa "Text Encoding Initiative"9. Si tratta di un caso di dichiarazione di entità, che dichiara un'entità interna. La seguente dichiarazione dichiara invece una entità di sistema:
<!ENTITY ChapTwo SYSTEM "sgmlmkup.txt">
Essa definisce un'entità di sistema il cui nome è ChapTwo , mentre il contenuto è il testo associato all'identificatore di sistema - in questo caso l'identificatore di sistema è il nome di un file presente nel sistema e il testo da sostituire al nome dell'entità quello contenuto nel file.
Una volta che l'entità è stata dichiarata, può essere inserita in qualunque punto del documento. Il nome dell'entità va inserito nel documento delimitandolo con la "e-commerciale" e il "punto e virgola". Quest'ultimo può essere omesso se il riferimento all'entità è seguito da spazio o dalla fine del record.
Quando un parser SGML incontra una entity reference sostituisce il valore dichiarato al nome dell'entità. Quindi la frase "The work of the &tei has only just begun" sarà interpretata da un programma SGML come se fosse scritta "The work of the Text Encoding Initiative has only just begun". Nel caso di un'entità di sistema viene introdotto al suo posto tutto il contenuto del file dichiarato come valore, così che il passaggio "The following text has been suppressed: &ChapTwo;" sarà allargato includendovi il contenuto del file sgmlmkup.txt10.
Questo metodo risparmia il lavoro di digitazione del testo e semplifica il compito di garantire l'uniformità in un insieme di documenti. Se si deve eseguire la stampa di un documento complesso in luoghi diversi, nel corpo del documento può essere introdotta un'entità, ad esempio &sito; nel punto in cui deve essere inserito il nome del luogo dove avviene la stampa. Diverse dichiarazioni di entità possono essere introdotte nelle diverse località in modo da far scrivere al programma il nome corretto senza bisogno di dover intervenire nel testo.
Il meccanismo di sostituzione della stringa può essere sfruttato anche per altri scopi. Ad esempio per risolvere l'incapacità di molti sistemi informativi di rappresentare tutti i caratteri grafici necessari all'inglese moderno (senza considerare le altre lingue moderne e antiche). I cosiddetti "caratteri speciali" non accessibili direttamente dalla tastiera (o non correttamente tradotti quando si cambia sistema informatico) possono essere rappresentati con un'entità
Supponiamo ad esempio di voler codificare l'uso delle legature in edizioni antiche. Le forma legata di ct può essere distinta dai casi in cui non è usata la legatura codificandola come &ctlig; invece di inserire semplicemente i due caratteri ct. Altre speciali caratteristiche tipografiche possono essere ugualmente rappresentate con entità scegliendo nomi intuitivi. Quando questi testi vengono sottoposti ad elaborazione, viene aggiunta una dichiarazione di entità per specificare quale rappresentazione deve essere sostiuita all'entità stessa. Se non interessa studiare le legature si può aggiungere la seguente dichiarazione:
<!ENTITY ctlig "ct">
così da rimuovere la distinzione presente nel documento. Se d'altra parte si utilizza un programma in grado di rappresentare il carattere con legatura, si può introdurre una dichiarazione in cui si associa al nome di entità l'opportuna sequenza di caratteri.
Una lista di dichiarazioni di entità è chiamata entity set o insieme di entità. Molti programmi SGML contengono insiemi di entità standard i cui nomi sono presi da liste pubblicate in un allegato allo standard SGML.
I valori da sostituire inseriti nella dichiarazione sono fortemente legati al sistema. Se i caratteri non possono essere digitati direttamente, SGML consente di specificarli mediante il loro valore numerico con il meccanismo del character reference. Un riferimento al carattere si distingue da altri caratteri inseriti nella stringa da sostituire all'entità perché è introdotto per convenzione dai due segni &# e chiuso da "punto e virgola". Ad esempio, se un programma rappresenta la legatura "ct" con i caratteri "c" e "t" preceduti dal carattere con valore esadecimale 102, la dichiarazione di entità è la seguente:
<!ENTITY ctlig "fct">
Notare che i riferimenti ai caratteri perdono significato se trasferiti in altri ambienti hardware e software, pertanto vanno usati solo in determinate situazioni.
Il meccanismo ora introdotto è destinato a casi in cui si deve introdurre eccezionalmente un carattere che non fa parte del set in uso; non può essere usato se si devono codificare ampi brani in greco e in russo all'interno di un testo inglese. In situazioni del genere si ricorre ad altri metodi, introdotti in altre sezioni di queste Guidelines (capitolo 4, "Characters and Characters Sets").
Un tipo speciale di entità chiamato parameter entities può essere usato nelle dichiarazioni. Le entità parametriche differiscono dalle altre (chiamate tecnicamente general entities) per due aspetti:
Le dichiarazioni per le entità parametriche rispettano la stessa sintassi delle altre, ma presentano il segno di percento tra la parola chiave ENTITY e il nome dell'entità. Devono essee introdotti spazi bianchi ai due lati del segno %. Una entità parametrica interna chiamata TEI.prose dichiarata come INCLUDE e un'entità esterna chiamata TEI.extensions.dtd collegata al file di sistema mystuff.dtd possono essere introdotte con le seguenti dichiarazioni11:
<!ENTITY % TEI.prose 'INCLUDE' > <!ENTITY % TEI.extensions.dtd SYSTEM 'mystuff.dtd' >
La TEI-DTD fa ampiamente uso delle entità parametriche per controllare la scelta di diversi insiemi di tag e per facilitare le modifiche alla struttura. Numerosi esempi del loro uso si trovano nel capitolo 3 "Structure of the TEI Document Type Definition".
Talvolta è conveniente codificare parti di un testo in modo che il parser SGML le gestisca in modo particolare. Può essere necessario ad esempio includere od escludere determinate sezioni di un testo di legge a seconda dello stato o del paese in cui il documento viene diffuso (coì la clausola "responsabilità limitata a 50.000 $" dovrebbe essere inclusa in Delaware ma esclusa in Mariland). Manuali tecnici con istruzioni d'uso di prodotti simili possono contenere un gran numero di informazioni comuni ma differire in qualche parte; può convenire conservare tutte le informazioni comuni in un unico documento selezionando al momento della visualizzazione o della stampa solo quelle parti specifiche per il singolo prodotto. La spiegazione di come si cambia olio alla macchina contiene delle direttive generali, ma avvertimenti specifici su come rimuovere il carburatore in relazione al modello di motore in questione).
SGML mette a disposizione il costrutto marked section per trattare questi casi particolari. In generale come mostra il precedente esempio, questo metodo è più utile nella produzione di nuovi testi che nella codifica di testi esistenti. Molti utenti della TEI-DTD non avranno bisogno di utilizzare le "marked section" e possono quindi non leggere i rimanenti paragrafi. La TEI-DTD fà comunque un notevole uso delle "marked section" e questa sezione andrebbe letta con attenzione da chiunque desiderasse seguire nel dettaglio le spiegazioni del capitolo 3 "Structure of the TEI Document Type Definition".
Il trattamento particolare possibile per le marked sections può essere di vario tipo a seconda della parola chiave introdotta nella codifica:
Quando una marked section si trova nel testo è preceduta da una sequenza di caratteri (Marked-section start) che contiene una o più parole chiave della precedente lista; la sua fine è segnata da un'altra sequenza di caratteri (Marked-section close). La seconda ed ultima riga del seguente esempio costituiscono l'apertura e la chiusura di una marked section da ignorare:
I such cases, the bank will reimburse the customer for all losses. <![ IGNORE [ Liability is limited to $50,000. ]]>
Tra tutte le parole chiave destinate alle marked sections le più importanti per la comprensione della TEI-DTD sono INCLUDE e IGNORE; esse possono essere usate per includereo o escludere parti di un documento - o una DTD - in modo da adattarlo a situazioni diverse (ad esempio per consentire ad un utente di selezionare parti della DTD importanti per il documento oggetto della codifica).
Le parole chiave INCLUDE e IGNORE non sono da sole molto utili per adattare una DTD o un documento alle necessità dell'utente (per cambiare il testo di prima in modo da includere o escludere la frase un utente dovrebbe intervenire manualmente nel testo e cambiare la parola chiave di volta in volta. Praticamente impiegherebbe lo stesso tempo ad inserire e togliere direttamente la frase). Ma le parole chiave non devono essere introdotte letteralmente nel testo codificato, possono essere rappresentate da una entità parametrica. In un documento contenente molte frasi da includere solo nel Maryland, ad esempio, ogni frase deve essere inserita in una marked section la cui parola chiave è sostituita da una entità chiamata Maryland. L'esempio precedente diventerebbe quindi:
I such cases, the bank will reimburse the customer for all losses. <![ %Maryland; [ Liability is limited to $50,000. ]]>
Quando l'entità Maryland è definita come IGNORE il testo compreso nella marked section verrà escluso. Se la definizione viene cambiata nella seguente, le sezioni verranno incluse nel documento:
<!ENTITY % Maryland 'INCLUDE'>
Quando in una DTD vengono usate entità parametriche in questo modo per le marked sections, il file esterno con la DTD contiene di norma una dichiarazione da usare in mancanza di altre definizioni. Se l'utente la vuole sovrascrivere (per includere le sezioni) deve semplicemente aggiungere la dichiarazione appropriata nel sottoinsieme della DTD12.
Gli esempi delle dichiarazioni mostrati alla fine del capitolo precedente risulteranno ora più comprensibili. Le dichiarazioni:
<!ENTITY % TEI.prose 'INCLUDE'> <!ENTITY % TEI.extensions.dtd SYSTEM 'mystuff.dtd'>
permettono di includere nella DTD tutte le marked section importanti per testi in prosa, dal momento che queste sezioni nel file contenente la DTD sono codificate con una entità parametrica TEI.prose. Esse sovrascrivono la dichiarazione presente nella TEI.extensions.dtd (che definisce questa entità come vuota) in modo da includere il file mystuff.dtd nella DTD.
Un documento SGML contiene più parti, delle quali alcune sono state introdotte in questo capitolo mentre altre possono essere tranquillamente ignorate da coloro che intendono usare la TEI-DTD. Per completezza può comunque risultare utile la lettura del seguente riassunto che illustra come queste parti interagiscono tra loro.
Un documento SGML consiste in un prologo SGML e in un documento vero e proprio. Il prologo contiene una declaration SGML (descritta precedentemente)e una document type definition nella quale trovano posto le dichiarazioni di elementi ed entità come visto. Diversi programmi possono associare in modi diversi documento e prologo; talvolta ad esempio il prologo può essere fortemente dipendentente dal programma usato e totalmente invisibile all'utente.
La dichiarazione SGML introduce alcuni fondamentali elementi relativi al linguaggio SGML usato come l'insieme dei caratteri legalmente accettati, i codici usati con funzione delimitativa, la lunghezza degli identificativi, etc. Il suo contenuto nel caso di documenti codificati secondo la TEI-DTD è analizzato nel capitolo 39 "Formal grammar for the TEI-Interchange-Format Subset of SGML" e nel 28 "Conformance". Normalmente la dichiarazione SGML in uso è compilata dal programma e resta invisibile per l'utente.
La document type definition viene usata per convalidare il singolo documento codificato. Anch'essa come la dichiarazione può essere compilata dal programma o restare comunque nascosta all'utente, oppure richiede solamente che venga specificato il nome del tipo di documento prima dell'operazione di convalida.
Nel caso più semplice la DTD è costituita semplicemente da una definizione di base (eventualmente da una o più definizioni concorrenti di documento) posta all'inizio del singolo documento codificato. Ad esempio:
<!DOCTYPE my.dtd [ <!-- seguono tutte le dichiarazioni che costituiscono la DTD --> ... ] > <my.dtd> questo è un documento codificato secondo la my.dtd </my.dtd>
Più spesso la DTD viene memorizzata in un file separato e chiamata nel modo seguente:
<DOCTYPE tei.2 system "tei2.dtd" [ <!-- seguono tutte le dichiarazioni che costituiscono la DTD --&gr; ... ] > <tei.2> questo è un documento codificato secondo la tei.dtd </tei.2>
In questo caso il testo del della TEI-DTD non è introdotto nel documento ma il programma SGML lo prende dal file che ha come identificatore di sistema il nome scritto tra virgolette. Le parentesi quadre possono essere introdotte per completezza anche se non contengono nulla.
La parte compresa tra parentesi quadre è chiamata document type declaration subset o "DTD subset". Il suo scopo è quello di introdurre modifiche alla DTD:
<!DOCTYPE tei.2 system "tei2.dtd" [ <!ENTITY tla "Three Letter Acronym" > <!ELEMENT my.tag - - (#PCDATA) > <!-- seguono dichiarazioni legate al caso particolare o modifiche a quelle generali --&gr; ] > <tei.2> questo è un documento codificato secondo la tei.dtd modificata in modo da contenere <my.tag>tag speciali</my.tag> e riferimenti ad entità come &tla; </tei2>
In questo caso la DTD usata comprende anche il subset che ha la precedenza rispetto a quanto definito nel file chiamato con la parola chiave SYSTEM. L'ordine è importante in quanto in SGML conta solamente la prima dichiarazione di un entità. Nell'esempio precedente la dichiarazione di un'entità tla nel subset della DTD avrà la precedenza rispetto a qualsiasi dichiarazione della stessa entità contenuta nel file tei2.dtd. È consentito dichiarare due volte le stesse entità; si tratta anzi di un metodo utilizzato per introdurre modifiche ad una DTD. (Al contrario gli elementi non possono essere dichiarati più di una volta; se una dichiarazione di <my.tag> fosse presente nel file tei.dtd il parser SGML segnalerebbe la presenza di un errore). Nel capitolo 3 "Structure of the TEI Document Type Definition" si affronta il tema di come combinade le diverse TEI-DTD.
Il documento codificato contiene testo, codici o tag ed entità, non dichiarazioni. Un modo convenzionale di costruire documenti molto grandi è quello di introdurre nel subset della DTD delle entità che fanno riferimento a singole parti:
<!DOCTYPE tei.2 [ <!ENTITY cap1 system "cap1.txt" > <!ENTITY cap2 system "cap2.txt" > <!ENTITY cap3 "--non ancora composto --" > ] > <tei.2> <teiHeader> ... </teiHeader> <text> <front> ... </front> <body> &cap1; &cap2; &cap3; .... </body> </text> </tei.2>
In questo esempio la DTD contenuta nel file tei2.dtd è stata ampliata inserendo una dichiarazione di entità per ogni capitolo dell'opera. Le prime due sono entità di sistema che si riferiscono ai file in cui è memorizzato il testo dei capitoli; la terza indica semplicemente che il testo non è ancora pronto (si potrebbe usare anche un entità con un contenuto nullo). Nel singolo documento i riferimenti &cap1;, etc. verrano sostituiti dal parser con i contenuti dei file associati. I file stessi non dovranno contenere né dichiarazioni di elemento, né di entità, né di attributi, ma semplicemente testo codificato.
Diversi programmi sono disponibili per facilitare il lavoro di creare, convalidare e gestire documenti SGML. Se ne possono introdurrre in questa sede solamente alcuni. Il cuore della maggior parte dei programmi SGML è costituito dal parser, un programma a sua volta che prende una DTD e convalida un documento collegato ad essa. Il risultato delle operazioni di un parser è solo "si" (il documento è valido) o "no" (il documento non è valido). Molti parser tuttavia producono una nuova versione del documento in forma corretta e completa (in genere con tutti i tag di chiusura e le entità sostuite dal loro contenuto) o impaginato secondo i parametri voluti dall'utente. Questa versione può essere usata da altri programmi per altre operazioni, ad esempio impaginazione o gestione dei dati contenuti.
Un editor SGML è una sorta di impaginatore intelligente. Può usare le informazioni contenute nella DTD per aiutare l'utente a inserire i tag nelle varie parti del documento in corso di elaborazione. Può quindi semplificare il compito della codifica anche con l'inserimento automatico dei tag.
Un impaginatore SGML lavora con un documento codificato e ne produce una versione da stampare. Molte caratteristiche tipografiche come il tipo di carattere, le dimensioni, etc. sono legate proprio alla struttura del documento e l'impaginatore può quindi usare la codifica descrittiva. È anche possibile definire la codifica richiesta da un impaginatore per ottenere determinati effetti usando le strutture concorrenti.
Programmi di gestione database usano in genere degli indici inversi per puntare dentro i documenti. In questo modo si può cercare dentro il documento una parola come un insieme di parole. Divisioni significative dei documenti in ingresso saranno messe in stretta relazione con le divisioni specificate usando la codifica descrittiva. Il programma di gestione di archivi testuali potrà sfruttare al meglio documenti con codifica SGML. Attualmente si lavora per consentire a programmi già in uso per la gestione di database di gestire anche informazioni esplicitate dalla codifica SGML.
Sistemi ipertestuali hanno il vantaggio di
supportare collegamenti associativi all'interno di un documento o tra documenti diversi.
Per ottenere questi collegamenti è molto utile la codifica SGML: la possibilità di
identificare e collegare elementi presenti nel documento è infatti una delle
caratteristiche dello standard. Codificando esplicitamente i collegamenti piuttosto che
ricorrendo ad un software specifico si ha il vantaggio di creare ipertesti che potranno
essere gestiti a lungo. Per caricare un documento SGML in un sistema di gestione di
ipertesti serve solamente un programma che interpreti correttamente i tag SGML del tipo di
quelli illustrati nel capitolo 14 "Linking, segmentation and alignment".