2. Struttura dei documenti SGML

2.1. Dichiarazione SGML

2.2. Document Type Definition (DTD)

2.3. Elementi della DTD

2.3.1. Attributi degli elementi

2.4. Entità

2.5. Sezioni opzionali

2.6. Esempio di DTD

2. Struttura dei documenti SGML

Un documento SGML consiste di un gruppo di elementi fondamentali, più un altro gruppo di elementi opzionali; essi sono:

• dichiarazione SGML opzionale
• DTD
• caratteristiche degli elementi che compongono i documenti
• riferimenti a files esterni (entità)

• sezioni opzionali

2.1. Dichiarazione SGML

La dichiarazione SGML permette di alterare le convenzioni di markup rispetto a quelle di base. Ad esempio, possono essere variati i caratteri delimitatori delle tags e la lunghezza di quest'ultime; la riduzione della lunghezza delle tags può rendersi necessaria per ridurre le dimensioni del documento, nel caso si abbia uno spazio insufficiente alla sua memorizzazione.

La sintassi di una dichiarazione SGML è questa:

<!SGML parti della dichiarazione >

Di solito, le dichiarazioni SGML vengono poste in files esterni al documento stesso e in quest'ultimo compare soltanto un riferimento alla dichiarazione. Questo risulta utile nel caso si abbiano molti documenti che utilizzano la stessa dichiarazione; se questa fosse inserita per intero in tutti i documenti, sarebbe necessario modificarli tutti ogni volta che si volesse cambiare questa dichiarazione. Invece, se questa non si trova nel sorgente del documento SGML ma in un apposito file, allora è sufficiente modificare soltanto quest'ultimo.

2.2. Document Type Definition (DTD)

La DTD è una descrizione formale della struttura di una particolare classe di documenti. Nella DTD sono specificati gli elementi che compongono un documento, le relazioni che intercorrono tra questi, il loro nome ed i dati che possono contenere. Ogni elemento può contenere altri elementi, oppure dati, o entrambi; nel content data model di ogni elemento è specificato che cosa questo può contenere. I content data models usano delle particolari notazioni nelle quali ogni elemento è accompagnato da un simbolo, il cui significato è questo:

• "+" una o più ricorrenze dell'elemento
• "*" zero o più ricorrenze
• "?" zero o una ricorrenza

Gli elementi possono essere raggruppati tramite parentesi tonde e separati dai seguenti simboli:

• "|" almeno uno degli elementi della lista deve comparire
• "&" entrambi gli elementi separati da questo simbolo devono comparire, in qualsiasi ordine.
• "," entrambi gli elementi separati da questo simbolo devono comparire, nell'ordine specificato

Se un elemento non è accompagnato da uno degli indicatori di ricorrenza, significa che questo può apparire una sola volta nel contesto del documento. In altre parole la sua presenza è obbligatoria ma non può essere ripetuta più di una volta.

Se, ad esempio, consideriamo la seguente definizione:

<!ELEMENT DL - - (DT*, DD?)+>

Questo significa che:

1. Se il tag <DL> compare in un documento, deve essere seguito da almeno una occorrenza di <DT> e da una di <DD>, come indicato dal segno "+" fuori della parentesi tonda.
2. Ogni volta che compare <DT>, questo può essere seguito da nessuno o al massimo da un solo <DD>
3. Il termine <DT> può comparire zero o più volte all'interno di un <DL>, come indicato dal simbolo "*" ma, in questo caso, deve comparire almeno una volta a causa del segno "+" fuori parentesi, che stabilisce che zero occorrenze delle tags in parentesi sono illegali

Esiste un tipo particolare di content data model, "ANY", che permette all'elemento di contenere, a sua volta, altri elementi della DTD; ANY viene usato senza parentesi. In SGML esistono delle parole riservate che permettono di caratterizzare alcuni content data model e sono:

• CDATA - i markup all'interno di una tag vengono ignorati, eccetto che quelli con </ che non sono seguiti da uno spazio
• RCDATA - l'elemento può contenere una qualunque sequenza di caratteri; per rappresentare caratteri che altrimenti sarebbero interpretati come markup usa una character reference utilizzando la stringa &#
• EMPTY - l'elemento deve essere vuoto e non deve avere una tag finale

Esempi di utilizzo di queste parole riservate sono i seguenti:

<!ELEMENT XMP - - CDATA>

<xmp>Questo è un esempio. Sembra contenere <tags> e <!--commenti--> ma non è così. Perfino questo </ è un carattere di testo, essendo seguito da uno spazio. </xmp>

<xmp>Altro esempio. Qui c'è un errore. CDATA non considera come testo la tag </end> perché </ non è seguito da uno spazio. </xmp>

<!ELEMENT TITLE - - RCDATA>

<title>Ancora un esempio. RCDATA permette di visualizzare una tag. Con &#60;end> si riproduce come testo la tag che nell'esempio precedente causava un errore. </title>

Nella DTD non viene specificata la semantica degli elementi contenuti. Le applicazioni SGML non apprezzano il significato di termini come <CHAPTER> o <TITLE>, ma possono verificare che i documenti rispettino le specifiche della DTD.

Tipicamente, le DTD sono usate per:

• stabilire le regole che governano la struttura dei documenti, definendo così il "documento ufficiale".
• formalizzare le convenzioni di markup, per permettere alle varie applicazioni di poter analizzare i documenti conformi a questa DTD.
• permettere agli analizzatori sintattici SGML di verificare se la struttura di un documento è conforme allo standard.
• dichiarare i tipi di dati esterni (immagini, video, audio, ecc.) che possono comparire nei documenti.

In sostanza, la DTD definisce tutti gli elementi di markup "legali" per un certo tipo di documento, stabilendo tutte le possibili opzioni di questi markup ed il contesto in cui possono comparire.

Il nome, o la locazione, della DTD che governa un certo documento conforme a SGML deve essere specificato all'inizio del documento stesso (come già accennato, la DTD può essere anche contenuta nel documento, ma questo non risulta pratico). Il nome della DTD viene specificato nel prologo del documento SGML; un esempio di prologo SGML per un documento HTML, la cui DTD è "IETF HTML 2.0 DTD", è questo:

<!DOCTYPE PUBLIC HTML "-//IETF//DTD HTML 2.0//EN">

Il riferimento alla DTD deve essere fatto con la dichiarazione SGML "DOCTYPE" la cui struttura è:

<!DOCTYPE root-tag PUBLIC public-id system-id [ ...-eventuali dichiarazioni markup aggiuntive-]>

Nell'esempio relativo ad HTML, root-tag coincide con "PUBLIC" e public-id coincide con la stringa "-//IETF//DTD HTML 2.0//EN". Dal public-id possiamo stabilire che la DTD è stata sviluppata dalla IETF e che è la versione 2.0 per HTML, scritta in inglese (EN).

In generale, le dichiarazioni degli elementi di markup hanno la forma:

<!nome-del-tipo-di-elemento caratteristiche>

2.3. Elementi della DTD

Ogni elemento nella DTD viene realizzato sulla base della sua funzione nel documento SGML. In altre parole, un elemento viene identificato col proprio identificatore generico (GI, generic identifier). Ogni elemento può a sua volta contenerne altri, come specificato nel suo content data model; come è stato già detto, il content data model per <DL> (definition list) è:

<!ELEMENT DL - - (DT*, DD?)+>

Questo viene letto da sinistra verso destra e, in questo caso si legge: l'elemento chiamato DL può contenere l'elemento DT, che può comparire zero o più volte; l'elemento DT può essere seguito dall'elemento DD e quest'ultimo può comparire zero o una volta.

I vari elementi della DTD formano un albero, creato dalla combinazione di tutti gli elementi ed i loro corrispondenti data models. I vari elementi possono creare strutture annidate nel documento, però queste non possono sovrapporsi e devono rimanere ognuna all'interno di quella di livello superiore. Un esempio di questo è:

<PARA>Questo è un <EM>paragrafo</PARA></EM>

In questo esempio si ha un errore in quanto la chiusura del paragrafo, </PARA>, compare prima dell'altro tag di chiusura </EM>; questo errore viene detto "annidamento improprio delle tags". La forma corretta è:

<PARA>Questo è un <EM>paragrafo</EM></PARA>

Gli elementi hanno dei nomi che indicano il componente strutturale del documento da essi rappresentato, come <SECTION>, <LIST>, <BOOK>, ecc.. Inoltre permettono di inserire, all'interno del documento, delle ancore (anchors), cioè dei riferimenti a particolari punti del testo, che permettono di passare velocemente da un punto ad un altro del documento; ad esempio, è possibile inserire un'ancora all'inizio di ogni capitolo, in modo da poter passare direttamente dall'indice, all'inizio del capitolo scelto, senza dover scorrere tutto il documento. In HTML un'ancora viene indicata così:

<A NAME="nome-ancora"> inizio del testo a cui si fa riferimento</A>

L'elemento di markup <A> contiene l'attributo NAME, il cui valore identifica il nome unico dato all'ancora di testo; l'ancora è la destinazione di un collegamento che può essere fatto da un qualsiasi altro punto all'interno dello stesso documento, oppure da un punto di un altro documento.

La sintassi di un elemento comprende la tag di inizio, contenente il nome, cioè il GI; ad esempio, la tag iniziale dell'elemento capitolo potrebbe essere <CHAPTER>. L'elemento deve terminare con la tag finale, che nel nostro esempio sarà </CHAPTER>. Di solito, le tags di inizio e di fine di un elemento compaiono in coppia; l'eccezione a questa regola si ha quando la DTD permette la minimizzazione di un particolare elemento; questo permette di usare, per l'elemento minimizzato, la sola tag di inizio. Ad esempio, la DTD di HTML 2.0 permette la minimizzazione della tag <P>; infatti risulta difficile trovare la tag </P> in un documento HTML.

La minimizzazione viene usata per accorciare, oppure omettere, le tags di alcuni elementi, anche se questa può comportare alcuni problemi:

• Non tutti gli analizzatori sintattici per SGML lavorano con la minimizzazione, in quanto questa complica l'analisi dei documenti.
• La minimizzazione rende i files SGML difficilmente comprensibili a chi li legge, perché introduce delle ambiguità nella struttura del documento.
• Risulta più difficile rilevare errori dovuti ad annidamento improprio delle tags.

Ad esempio, l'elemento "capitolo" può essere descritto dal seguente modello:

<!ELEMENT chapter - - (title?, section*)+(footer)>

Dove:

• <!ELEMENT: inizio della dichiarazione dell'elemento.
• chapter: GI dell'elemento, cioè il suo nome.
• -: indicatore tag di inizio; "-" significa che ci vuole sempre la tag iniziale; "O" permette che la tag iniziale sia omessa, dove questo non provochi ambiguità.
• -: indicatore tag di fine; ha le stesse specifiche della precedente.
• (title?, section*, ...): altri content data models; specificano quali altri elementi possono comparire all'interno di questo elemento.
• >: chiude la dichiarazione dell'elemento.

Talvolta, nel "content data model" di un certo elemento può comparire la stringa "#PCDATA"; questo significa che l'elemento può contenere un testo generico, che è poi il testo del documento che verrà rappresentato secondo le modalità specificate. Ad esempio:

<!ELEMENT caption - O (#PCDATA)>

2.3.1. Attributi degli elementi

Un attributo dà ad un elemento delle caratteristiche uniche, fornendo informazioni specifiche sul suo uso in un documento SGML. Un nome di attributo può essere usato da più elementi diversi e, in ogni caso, darà informazioni specifiche per l'elemento a cui è associato e non comuni agli altri.

Gli attributi hanno dei nomi che sono dichiarati nella DTD e sono opzionali per gli elementi a cui si riferiscono, cioè non è necessario che un elemento contenga tutti i suoi attributi. Ogni attributo ha un valore dichiarato che deve essere specificato anche nella DTD; inoltre ha un valore di default, che può essere un valore specifico, oppure può semplicemente indicare che questo attributo deve essere dichiarato ad ogni ricorrenza dell'elemento a cui si riferisce.

In generale, gli attributi indicano le caratteristiche globali e le proprietà di un certo elemento; sulla base del loro valore, uno stesso elemento può comportarsi diversamente in uno stesso documento.

In SGML la sintassi per gli attributi segue le regole seguenti:

• Gli attributi possono comparire solo nelle tags di inizio.
• I valori assegnati agli attributi devono essere tra virgolette.
• In un documento SGML, ogni attributo ha il nome seguito dal segno = e dal valore, ad esempio:

<CAR COLOR="rosso" INTERIOR="pelle">

• Gli attributi possono comparire in un qualsiasi ordine.

Un esempio di dichiarazione di attributi per l'elemento <CHAPTER>, è:

Nome Tipo Status/Default

<!ATTLIST chapter id ID #REQUIRED

num NUMBER #IMPLIED

sect (public| secret) "public">

Dove:

• <!ATTLIST: indica l'inizio di una dichiarazione di attributi.
• chapter: GI dell'elemento di cui stiamo specificando gli attributi.
• id, num, sect: nomi degli attributi; questi nomi compaiono, nel documento, nelle tags iniziali dell'elemento, a sinistra del segno "=".
• ID, NUMBER, (public | secret): indicano i tipi di dati assegnati agli attributi.
• #REQUIRED, #IMPLIED, "public": valori di default degli attributi; indicano se un attributo è richiesto, opzionale, oppure ne indicano il valore.

In questo esempio di dichiarazione viene specificato che ogni capitolo deve avere un identificatore (id) di tipo ID; ogni capitolo deve avere un numero dipendente (IMPLIED) dalla sua locazione nella sequenza dei capitoli; l'accesso ad ogni capitolo può essere libero (public), oppure no (secret) ed il valore "public" viene preso come default.

La dichiarazione completa dell'elemento chapter (capitolo) è quindi:

<!ELEMENT chapter - - (title?, section*)+(footer)>

<!ATTLIST chapter id ID #REQUIRED num NUMBER #IMPLIED

sect (public|secret) "public">

Per assicurare la leggibilità della DTD, gli attributi di un elemento vengono solitamente posti immediatamente dopo la dichiarazione dell'elemento a cui si riferiscono, in modo da mantenere tutte le informazioni vicine.

In SGML i valori dichiarati di ogni attributo usano parole riservate, che sono:

• CDATA - Tutto il markup interno al valore dell'attributo viene ignorato.
• ENTITY(IES) - Indica il nome di un'entità esterna nota al documento corrente.
• ID - Indica un identificatore unico all'interno del documento.
• IDREF(s) - Identifica un elemento, in un documento, con un ID come valore.
• NAME(s) - Indica il nome che viene assegnato ad un certo elemento, come, ad esempio, un'ancora; deve iniziare con una lettera.
• NMTOKEN(s) - Come NAME, però può non iniziare con una lettera.
• NOTATION - Indica il nome di un tipo di dati esterno, seguito da una lista, tra parentesi, contenente tutte le notazioni permesse.
• NUMBER(s) - Contiene numeri.
• NUTOKEN(s) - Inizia con un numero, ma può contenere anche lettere.

I valori dichiarati specificano il tipo di valore che un attributo può assumere e sono utili per la ricerca degli errori e per la leggibilità della DTD.

La presenza di un attributo in un elemento è regolata dalle seguenti parole riservate:

• #REQUIRED - L'attributo deve essere specificato ogni volta che si richiama l'elemento.
• #CURRENT - Per l'elemento considerato, l'attributo assume per default il valore più recentemente specificato.
• #CONREF - Quando è presente, indica che l'attributo non ha un valore specificato; se #CONREF è assente dalla dichiarazione, l'elemento assume il suo valore normale.
• #IMPLIED - Indica che un valore può essere omesso; in quest'ultimo caso, l'applicazione che richiede questo attributo deve dedurne il suo valore.
• valore (value) - Per un attributo può essere specificato un valore di default.

Un ulteriore valore di attributo è "#FIXED"; questo indica che l'attributo in questione deve avere lo stesso valore per ogni ricorrenza dell'elemento. L'attributo specificato con #FIXED, nella DTD, deve essere posto prima del valore esplicito di default, come mostrato in questo esempio:

<!ATTLIST blob area NUMBER #FIXED sq-feet>

2.4. Entità

Le entità sono gruppi di dati immagazzinati in opportuni files; ogni file contiene un gruppo di entità. Le entità vengono usate per spezzare grossi files in parti più piccole e quindi più maneggevoli. Possono essere utilizzate per incorporare gli stessi dati in documenti diversi; inoltre permettono di proteggere i dati non-SGML dagli analizzatori sintattici, consentendo di includerli in un documento attraverso un riferimento.

Le entità sono dichiarate nella DTD con un nome ed un valore; ad esempio:

<!ENTITY AEI CDATA "Associazione Elettrotecnica Italiana" >

Dove:

• <!ENTITY: inizio della dichiarazione di entità.
• %: simbolo usato per indicare un'entità parametro (non presente nell'esempio). Deve essere seguito da uno spazio.
• AEI: nome dell'entità.
• CDATA: indica il tipo di entità. Se viene omesso il tipo di entità, questa viene analizzata ad ogni sua occorrenza.
• "Associazione Elettrotecnica Italiana": testo dell'entità. Contiene il testo dell'entità; alternativamente, può essere l'identificatore per un'entità esterna.

In questo modo, ogni volta che nel documento si ha un riferimento all'entità AEI, questa viene sostituita da "Associazione Elettrotecnica Italiana". La sintassi di un riferimento ad un'entità è del tipo &nome_entità (nel nostro esempio avremo quindi &AEI). In generale, si hanno due regole empiriche per l'uso delle entità in SGML:

• Dichiarare tutti i dati esterni o non-SGML come entità.
• Usare le entità per rappresentare gli acronimi, le abbreviazioni e le sigle più usate.

Le entità possono rappresentare diversi tipi di testo, ma questi tipi devono essere definiti all'interno di entità dichiarate nella DTD. Esistono diversi tipi di testo:

• Testo letterario: questo tipo di testo viene analizzato normalmente ed include i tipi più comuni di markup.
• Testo dati: esistono tre sottotipi del testo dati:

- CDATA - non vengono riconosciuti né il markup né le entità.

- SDATA - usa caratteri specifici per l'applicazione.

- PI - il contenuto delle entità è un'istruzione specifica dell'applicazione.

• Testo esterno: queste entità sono files descritti dagli appositi identificatori PUBLIC e SYSTEM, seguiti o meno da uno dei seguenti sottotipi:

- SUBDOC: testo SGML ma con una diversa DTD.

- NDATA: l'entità è una notazione esterna.

- letterale (literal): viene analizzato allo stesso modo del documento SGML.

Esistono anche le entità parametro, che sono dichiarate nella DTD e sono usate solo come macro all'interno della DTD stessa (cioè vengono usate solo all'interno della DTD e non nel documento). Queste entità vengono indicate con il simbolo "%", rispetto al simbolo "&" usato in generale. Un esempio di entità dichiarata ed usata in una DTD è:

<!ENTITY % emphasis "italic | bold | red">

<!ELEMENT %emphasis; - - CDATA>

Si deve fare attenzione a mettere uno spazio dopo il simbolo "%" nella dichiarazione di entità, per non incorrere in un errore.

2.5. Sezioni opzionali

Le sezioni opzionali sono usate per escludere opzionalmente parti del documento SGML. Riferendosi all'esempio, citato in precedenza, del manuale in ambiente DOS e/o MacIntosh, per istruire l'applicazione SGML a creare la versione DOS del manuale, escludendo così tutti i riferimenti alla versione MacIntosh, potremmo fare così:

Per il sistema operativo <![ INCLUDE [ <EM>DOS</EM> ] ]>

<![ IGNORE [ <EM>MacIntosh</EM> ] ]> si ha che ...

Al contrario, per realizzare la versione MacIntosh, basta scambiare tra loro le parole INCLUDE ed IGNORE.

Il modo migliore per realizzare questa operazione, è quello di dichiarare nella DTD un'entità per ognuna delle condizioni:

<!ENTITY DOS CDATA "INCLUDE" >

<!ENTITY MacIntosh CDATA "IGNORE" >

In questo modo il nostro esempio diventa:

Per il sistema operativo <![ &DOS [ <EM>DOS</EM> ] ]>

<![ &MacIntosh [ <EM>MacIntosh</EM> ] ]> si ha che ...

A questo punto, per passare da una versione all'altra del documento basta scambiare le parole INCLUDE ed IGNORE nella sola DTD e non in tutto il documento. Le sezioni opzionali possono essere anche usate per evitare l'analisi sintattica di parti del documento non conformi allo standard SGML. La sintassi della dichiarazione di una sezione opzionale è:

<![ parola-chiave [ ... testo opzionale ... ] ]>

Dove le parole chiave possono essere:

• IGNORE - escludi questo testo.
• INCLUDE - considera il testo come parte integrante del documento.
• CDATA - non riconoscere tags o entità.
• RCDATA - non riconoscere le entità.
• TEMP - identifica la sezione come temporanea e non ha effetto sull'analisi sintattica.

Infine, le sezioni opzionali permettono una certa libertà per quanto riguarda il loro annidamento con gli altri elementi del documento; ad esempio è permesso scrivere:

<PARA>Questo paragrafo <![ IGNORE [ <B>contiene</B></PARA>

<PARA>elementi annidati in modo incrociato ma ] ]> è corretto.</PARA>

2.6. Esempio di DTD

Nella DTD seguente viene definito l'elemento "book":

<!DOCTYPE book

<!ENTITY % chunks "para | list | figure">

<!NOTATION gif SYSTEM "xv">

<!ELEMENT book - - (frontmatter, body)+(link)>

<!ELEMENT frontmatter - - (title, author, copyright?)>

<!ELEMENT (title, author, copyright) - - (#PCDATA)>

<!ELEMENT body - - (chapter*)>

<!ELEMENT chapter - - (title, section*)>

<!ELEMENT section - - (title, (%chunks;)*)>

<!ELEMENT para - - (#PCDATA | emph)*>

<!ATTLIST (chapter, section, para) id ID #IMPLIED>

<!ELEMENT list - - (item*)>

<!ATTLIST list type (unord | ord | plain) "plain" id ID #IMPLIED>

<!ELEMENT item - - (para*)>

<!ELEMENT emph - - (#PCDATA)>

<!ATTLIST emph type CDATA #IMPLIED>

<!ELEMENT figure - O (caption)>

<!ATTLIST figure type NOTATION (gif) #REQUIRED>

<!ELEMENT caption - O (#PCDATA)>

<!ELEMENT link - O EMPTY>

<!ATTLIST link rid IDREF #REQUIRED type CDATA #REQUIRED>

>

La DTD forma una struttura ad albero che mostra le relazioni tra capitoli, sezioni, paragrafi e tra intestazione e capitoli, come mostrato nella figura seguente.

Ultimo aggiornamento: 21-Mar-1996

Telematic lab's home page