[successivo] [precedente] [inizio] [fine] [indice generale] [violazione GPL] [translators] [docinfo] [indice analitico] [volume] [parte]
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. |
L'SGML è già stato introdotto nel capitolo 249; in questo vengono affrontate solo le caratteristiche salienti di XML che lo distinguono sostanzialmente dal suo predecessore.
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.
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 <!>.
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 267.1 si vede un confronto tra la dichiarazione SGML e quella XML. Si vede chiaramente che in XML mancano le regole di minimizzazione.
|
Tabella 265.2. 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:
devono iniziare con una lettera alfabetica, oppure con un trattino basso (_, ovvero #x5F), e possono contenere anche cifre numeriche, il punto, il trattino basso e il trattino normale (#x2D);
non possono contenere spazi;
potrebbero eventualmente contenere i due punti (:), ma questa possibilità viene riservata per situazioni particolari;
non possono iniziare con la sigla xml, o con qualunque altra variazione delle lettere minuscole e maiuscole, dal momento che questi potrebbero avere in seguito dei significati speciali.
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 &, <, >, ' e ".
Si può osservare questo particolare nella dichiarazione SGML di XML:
...
SYNTAX
...
ENTITIES
"amp" 38
"lt" 60
"gt" 62
"quot" 34
"apos" 39
...
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.
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.
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, assieme alla codifica utilizzata:
<?xml version="1.0" encoding="UTF-8"?>
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.
I nomi di elementi e degli attributi che iniziano per xml, con qualsiasi altra variante delle lettere maiuscole e minuscole, sono riservati.
Gli elementi che ne possono avere bisogno, devono poter disporre di un attributo denominato xml:space, a cui possano essere assegnate le parole chiave default o preserve. Il suo scopo è quello di definire il comportamento nei confronti degli spazi (di tutti i caratteri assimilabili a questo concetto). Assegnando la parola chiave default si intende lasciare che gli spazi vengano gestiti come al solito, eliminando quelli superflui; con la parola chiave preserve si vuole richiedere di mantenere gli spazi come sono. La dichiarazione di questo attributo può avvenire nel DTD come nell'esempio seguente:
<!ATTLIST esempio xml:space (default|preserve) 'preserve'>
In particolare, un elemento che per sua natura deve rispettare le spaziature originali, potrebbe essere definito nel modo seguente, dove si vede il caso dell'elemento pre di XHTML:
<!ELEMENT pre %pre.content;> <!ATTLIST pre %attrs; xml:space (preserve) #FIXED 'preserve' >
Gli elementi che ne possono avere bisogno, devono poter disporre di un attributo denominato xml:lang, a cui poter assegnare un codice identificativo del linguaggio contenuto. Si prevede l'uso di diversi tipi di codice:
un codice di linguaggio composto da due lettere, secondo lo standard ISO 639 (sezione 543);
un codice di linguaggio registrato dall'autorità IANA (Internet assigned numbers authority), a cui va aggiunto comunque il prefisso i-, oppure I-;
un codice stabilito dall'utente o concordato tra le parti, a cui va aggiunto il prefisso x-, oppure X-.
La dichiarazione di questo attributo può avvenire nel DTD come nell'esempio seguente:
<!ATTLIST esempio xml:lang NMTOKEN #IMPLIED >
Eventualmente si può anche specificare un linguaggio predefinito, come si vede nell'esempio seguente:
<!ATTLIST testo xml:lang NMTOKEN 'it' >
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:
contiene un elemento principale unico, all'interno del quale vanno collocati tutti gli altri (si parla comunemente dell'elemento root);
tutti i marcatori degli elementi devono essere indicati in modo corretto, attraverso degli annidamenti ordinati;
tutti gli elementi devono essere delimitati correttamente, senza saltare dei marcatori, inoltre gli elementi vuoti vanno chiusi oppure vanno indicati con il marcatore speciale già mostrato;
devono essere rispettate le regole stabilite per i nomi degli elementi;
i valori associati agli attributi vanno delimitati sempre attraverso apici doppi oppure apici singoli;
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.
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 250. 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 si 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
W3C, Extensible Markup Language (XML) 1.0
James Clark, Comparison of SGML and XML
XML Frequently Asked Questions
Norman Walsh, A Technical Introduction to XML
daniele @ swlibero.orgDovrebbe essere possibile fare riferimento a questa pagina anche con il nome xml_cenni.html
[successivo] [precedente] [inizio] [fine] [indice generale] [violazione GPL] [translators] [docinfo] [indice analitico]