[inizio] [indice generale] [precedente] [successivo] [indice analitico] [contributi]


144. XML: cenni

XML è un linguaggio derivato dall'SGML, da intendersi come un sottoinsieme compatibile con questo; in particolare, il nome rappresenta l'acronimo di eXtensible Markup Language. Il motivo per il quale è stata introdotta questa variante dell'SGML è dovuto all'esigenza di trovare un compromesso tra l'SGML originale e l'HTML, che è solo un'applicazione di SGML troppo limitata per la documentazione multimediale. In pratica, l'intento è stato ed è quello di semplificare leggermente l'SGML rendendo disponibili molte qualità dell'SGML che un'applicazione rigida come l'HTML non è in grado di offrire.

In generale, un documento XML è un'applicazione di XML; nello stesso modo, l'HTML (come linguaggio) è un'applicazione SGML.

È importante non illudersi: XML resta un sistema abbastanza complesso, anche se non quanto l'SGML tradizionale. Infatti, un documento realizzato in XML richiede la definizione di un DTD, esattamente come avveniva prima.

144.1 Differenze significative tra SGML e XML

L'SGML è già stato introdotto nel capitolo  131; in questo vengono affrontate solo le caratteristiche salienti di XML che lo distinguono sostanzialmente dal suo predecessore.

144.1.1 Codifica

La novità più importante di XML è l'utilizzo predefinito della codifica universale, prevalentemente attraverso la forma UTF-8 e UTF-16. Questo fatto ha delle implicazioni importanti, in quanto i riferimenti a macro del tipo `&n;' e `&xn;' si fanno ai punti di codifica dello standard ISO 10646 (nel primo caso il numero è espresso in decimale, mentre nel secondo si tratta di un numero esadecimale.

XML non esclude a priori l'utilizzo di altri tipi di codifica; tuttavia, se non è possibile usare le codifiche UTF-n, per evitare ambiguità potrebbe essere conveniente limitarsi all'uso dell'ASCII tradizionale, dal momento che è perfettamente compatibile con la forma UTF-8. Eventualmente è possibile anche specificare il tipo di codifica attraverso un'istruzione apposita, che verrà mostrata in seguito.

144.1.2 Commenti

I commenti si indicano in linea di massima come in SGML, attraverso la forma:

<-- <commento> -->

Come nell'SGML si deve evitare l'uso di due trattini in sequenza, `--', ma in XML non è ammissibile il commento nullo nella forma `<!>'.

144.1.3 Marcatori ed elementi vuoti

In XML, gli elementi devono essere aperti e chiusi correttamente attraverso i marcatori relativi; in pratica non è possibile più lasciare all'analizzatore XML il compito di determinare da solo la cosa in base al contesto. Questa limitazione è importante per facilitare il compito dei programmi che devono interpretare un documento XML e comunque si riflette positivamente nella struttura del sorgente del documento stesso.

Gli elementi vuoti vanno indicati regolarmente con il marcatore di chiusura, oppure con un solo marcatore speciale, che ha la forma seguente:

<<nome-elemento>/>

In pratica, alla fine del marcatore appare una barra obliqua prima del simbolo `>'.

Di fatto, per problemi di compatibilità, si lascia uno spazio prima della barra finale. Per esempio: `<hr />'.

L'assenza della possibilità di definire dei marcatori di apertura o di chiusura opzionali, fa sì che si semplifichi la dichiarazione di questi nel DTD:

<ELEMENT <nome-elemento> <modello-del-contenuto> >

Nella figura 144.1 si vede un confronto tra la dichiarazione SGML e quella XML. Si vede chiaramente che in XML mancano le regole di minimizzazione.

SGML:
<!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

XML:
<!ELEMENT titolo	(#PCDATA) >

Figura 144.1: Scomposizione delle varie parti della dichiarazione di un elemento SGML e XML.

In XML, i nomi che si attribuiscono agli elementi e agli attributi sono sensibili alla differenza tra lettere maiuscole e minuscole; per esempio, l'elemento `testo' è diverso dall'elemento `Testo' e da tutte le altre varianti possibili. Per la precisione, i nomi devono sottostare alle regole seguenti:

144.1.4 Entità predefinite

Alcune entità standard essenziali sono predefinite e teoricamente non è necessario specificarle nel DTD. Si tratta di `amp', `lt', `gt', `apos' e `quot'. Le macro relative sono `&amp;', `&lt;', `&gt;', `&apos;' e `&quot;'.

Si può osservare questo particolare nella dichiarazione SGML di XML:

    ...
    SYNTAX
        ...
        ENTITIES
            "amp"  38
            "lt"   60
            "gt"   62
            "quot" 34
            "apos" 39
    ...

144.1.5 Entità parametriche

In XML, le entità parametriche possono essere utilizzate solo all'interno del DTD. Da ciò consegue logicamente che le sezioni marcate con le quali si può includere o escludere del testo in base al contenuto di un'entità parametrica, possono esistere solo nel DTD.

<!ENTITY % bozza 'INCLUDE' >
<!ENTITY % finale 'IGNORE' >

<![%bozza;[
<!ELEMENT libro (commento*, titolo, corpo)>
]]>
<![%finale;[
<!ELEMENT libro (titolo, corpo)>
]]>

L'esempio mostra un pezzo di un DTD ipotetico, in cui vengono dichiarate due entità parametriche, `bozza' e `finale'. In questo caso, la macro `%bozza;' si traduce nella parola `INCLUDE', mentre la macro `%finale;' si traduce nella parola `IGNORE'. In questo modo, viene dichiarato l'elemento `libro' nella prima modalità: quella che ammette la presenza dell'elemento `commento'.

144.1.6 Altre sezioni marcate

XML ammette l'uso di un'altra sezione marcata soltanto, la sezione `CDATA' per delimitare del testo letterale.

<![CDATA[Il marcatore <ciao> serve per...]]>

L'esempio mostra in che modo sia possibile utilizzare letteralmente i simboli `<' e `>' in una sezione `CDATA'.

144.1.7 Istruzioni di elaborazione

Le istruzioni di elaborazione sono una novità in XML. Servono in qualche modo per passare delle informazioni alle applicazioni. Si distinguono per avere la forma seguente:

<?<istruzione-di-elaborazione> >

Il testo che compone l'istruzione dipende dall'applicazione a cui è diretto. È importante tenere presente che tutto ciò che inizia con la stringa `xml', assieme a tutte le sue variazioni di lettere maiuscole e minuscole, è riservato.

In generale, in base al significato che può avere l'istruzione di elaborazione, queste possono trovarsi in qualunque parte del sorgente XML.

Normalmente si inizia sempre un sorgente XML con un'istruzione di elaborazione che dichiara la versione di XML a cui si fa riferimento e la codifica utilizzata:

<?xml version="1.0" encoding="UTF-8"?>

144.2 Convenzioni dell'XML

Nella descrizione delle differenze tra XML e SGML sono già state presentate alcune convenzioni di XML che non sono esprimibili nella dichiarazione SGML relativa. In pratica, si tratta di regole che vanno tenute in considerazione quando si scrive un DTD per un documento XML. Vale la pena di raccogliere le convenzioni più importanti.

144.3 Correttezza formale e validità

Possono esistere due livelli di approccio all'XML da parte dei programmi che lo utilizzano: il primo si limita a leggere il documento senza sapere nulla della sua struttura stabilita nel DTD; il secondo invece richiede la conoscenza di questa struttura. Nel primo caso è sufficiente che il documento XML sia stato scritto correttamente dal punto di vista formale, in senso generale; in questo modo si parla di well formed document. Nel secondo caso è importante che il documento, oltre che essere corretto dal punto di vista formale, sia anche valido in base alla definizione stabilita nel DTD.

Il documento XML corretto dal punto di vista formale, ha le caratteristiche seguenti:

Il documento XML valido, oltre a essere corretto formalmente, deve anche essere conforme al DTD. Come nell'SGML normale, il DTD può essere indicato attraverso un riferimento, oppure può essere incorporato all'inizio del documento.

144.4 Verifica della validità con SP

Il pacchetto SP di James Clark può essere utilizzato anche per convalidare un documento XML, a partire dal suo DTD. Il procedimento è analogo a quanto già mostrato nel capitolo 132. Tuttavia, è necessario procurarsi la dichiarazione XML, che si può trovare nell'archivio dei sorgenti di SP stesso: `pubtext/xml.dcl'.

Supponendo di disporre del file `xml.dcl' nella directory corrente, si può realizzare un catalogo molto semplice come quello seguente:

SGMLDECL "xml.dcl"

Naturalmente, nel catalogo si possono aggiungere anche altre cose, in base alla necessità o meno di indicare il DTD e le entità generali. Per verificare il funzionamento della cosa, si può provare a eseguire la convalida dell'esempio seguente, che include il DTD nel preambolo e non ha bisogno di entità generali:

<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE esempio [
    <!ELEMENT esempio (#PCDATA)>
]>
<esempio>Ciao a tutti!</esempio>

Si può osservare che si tratta di un documento elementare, in cui esiste solo l'elemento principale, denominato `esempio'.

Per la convalida, si può usare l'eseguibile `nsgmls' nel modo seguente:

nsgmls -c catalogo.xml -s esempio.xml

Qui si sottintende che il file del catalogo sia `catalogo.xml' e che il sorgente XML sia contenuto nel file `esempio.xml'. Se oltre alla convalida di vuole avere il risultato pre-elaborato, si toglie l'opzione `-s', ottenendo quanto segue:

?xml version="1.0" encoding="ISO-8859-1" 
(esempio
-Ciao a tutti!
)esempio
C

144.5 Riferimenti

---------------------------

Appunti Linux 2000.04.12 --- Copyright © 1997-2000 Daniele Giacomini --  daniele @ pluto.linux.it


[inizio] [indice generale] [precedente] [successivo] [indice analitico] [contributi]