[successivo] [precedente] [inizio] [fine] [indice generale] [indice ridotto] [violazione licenza] [translators] [docinfo] [indice analitico] [volume] [parte]

Capitolo 299.   XML: introduzione

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.

È bene chiarire che XML nasce come sottoinsieme di SGML, ma nel tempo si evolve e si allontana da SGML. In particolare, la prima caratteristica che comincia il distacco tra i due è l'introduzione dei domini applicativi (namespace), che rende difficile l'abbinamento di un DTD a un documento XML che ne fa uso.

299.1   Differenze significative tra SGML e XML

In questa sezione vengono affrontate solo le caratteristiche salienti di XML che lo distinguono sostanzialmente dall'SGML, ovvero il suo predecessore.

299.1.1   Codifica

La novità più importante di XML è l'utilizzo predefinito dell'insieme di caratteri 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 viene mostrata in seguito.

299.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 <!>.

299.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 >.

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 299.1 si vede un confronto tra la dichiarazione SGML e quella XML. Si vede chiaramente che in XML mancano le regole di minimizzazione.

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;

• possono contenere i due punti (:), ma questa possibilità è comunque riservata a situazioni particolari (serve a definire un prefisso che rappresenta un contesto);

• 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.

299.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

299.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.

299.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.

299.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, assieme alla codifica utilizzata:

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

299.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.

• 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;

  • 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' >

299.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:

• contiene un elemento principale unico, all'interno del quale vanno collocati tutti gli altri (si parla comunemente dell'elemento root, ovvero della radice);

• 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.

299.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; 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[Invio]

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

299.5   Domini applicativi: «namespace»

Con il termine dominio applicativo si vuole qui fare riferimento a quello che è noto come namespace a proposito di XML. Si definisce un dominio applicativo associando elementi, ma eventualmente anche attributi, a qualcosa che viene identificato tramite un indirizzo URI (sia URL, sia URN). Questa associazione ha lo scopo di evitare ambiguità, quando per qualche ragione si utilizzerebbero elementi o attributi con lo stesso nome, ma con significati differenti.

Dal momento che non è possibile utilizzare nomi di elementi e di attributi che contengano direttamente un URI, si associa questo URI attraverso un attributo particolare:

      1 <?xml version="1.0"?>
      2 <html xmlns="http://www.w3.org/1999/xhtml">
      3   <head>...</head>
      4   <body>
      5     <h1>Bla bla bla</h1>
      6     ...
      7     <math xmlns="http://www.w3.org/1998/Math/MathML">
      8       <mi>x</mi><mo>+</mo><mn>3</mn>
      9     </math>
     10   </body>
     11 </html>

Questo esempio mostra l'utilizzo di MathML all'interno di un documento XHTML (le righe dalla settima alla nona). Si può osservare che l'elemento html, alla riga numero due dell'esempio, che contiene l'attributo xmlns, a cui è associata la stringa http://www.w3.org/1999/xhtml. Questa dichiarazione specifica che all'elemento html e a tutti i suoi discendenti si associa il dominio applicativo <http://www.w3.org/1999/xhtml>. Questo indirizzo (<http://www.w3.org/1999/xhtml>) è solo un punto di riferimento univoco; se si vuole, lo si può anche visitare (figura 299.13), ma ha soltanto lo scopo di dichiarare che gli elementi a cui è associato si riferiscono a XHTML; inoltre, non è nemmeno necessario che esista veramente.

Continuando a leggere l'esempio mostrato, alla settima riga appare l'elemento math, che, come dichiarato dall'attributo xmlns appartiene al dominio applicativo <http://www.w3.org/1998/Math/MathML/>; in pratica, dichiara che l'elemento in questione e ciò che contiene riguarda MathML.

Quanto visto in questo esempio, rappresenta un uso «predefinito» del dominio applicativo. Infatti, esiste anche la possibilità di associare gli elementi (e gli attributi) a un dominio applicativo, specificando un prefisso:

      1 <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
      2   <xsl:template name="/">
      3     ...
      4   </xsl:template>
      5 </xsl:stylesheet>

In questo caso si può osservare, alla riga numero uno, che l'elemento xsl:stylesheet contiene l'attributo xmlns:xsl, a cui è associato un URI. Ciò significa che, nell'ambito del controllo dell'elemento xsl:stylesheet, elementi e attributi il cui nome inizia con il prefisso xsl: appartengono al dominio applicativo <http://www.w3.org/1999/XSL/Transform>; per la precisione, anche lo stesso elemento xsl:stylesheet appartiene a questo dominio applicativo, proprio perché anche il suo nome inizia con il prefisso xsl:.

      1 <?xml version="1.0" encoding="utf-8"?>
      2 <xsl:stylesheet version="1.0"
      3         xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
      4         xmlns:fo="http://www.w3.org/1999/XSL/Format">
      5 
      6 <xsl:output method="xml" indent="yes"/>
      7 ...
      8 <xsl:template match="studio">
      9 <fo:root>
     10     <fo:layout-master-set>
     11         ...
     12     </fo:layout-master-set>
     13     <fo:page-sequence master-reference="cover">
     14         ...
     15     </fo:page-sequence>
     16     ...
     17 </fo:root>
     18 </xsl:template>
     19 ...
     20 </xsl:stylesheet>

Questo nuovo esempio mostra l'uso di due domini applicativi, associati rispettivamente ai prefissi xsl: e fo: (le righe tre e quattro). La dichiarazione dei domini applicativi avviene nell'elemento principale, ovvero xsl:stylesheet (che appartiene al dominio applicativo associato al prefisso xsl:), in modo che possa essere valida per tutto il documento, salva la possibilità di modificarla all'interno di elementi ben precisi.

Oltre ai modi mostrati in questi esempi, esistono altre combinazioni; per esempio è possibile affiancare un dominio applicativo predefinito a domini specificati attraverso l'uso di prefissi. Tuttavia si preferisce evitare di creare troppa confusione su un concetto che invece dovrebbe essere semplice, per consentire la comprensione di altri concetti legati a XML. Eventualmente si possono consultare i documenti annotati nella bibliografia al termine del capitolo, per una visione più precisa e dettagliata a proposito dei domini applicativi (ovvero namespace).

La presenza dei domini applicativi rende difficile l'abbinamento di un DTD a un documento XML, perché i prefissi devono essere previsti esattamente nel DTD, come parte dei nomi degli elementi e degli attributi, mentre la definizione di un dominio applicativo consentirebbe l'utilizzo di un prefisso libero, deciso nel momento in cui si usa l'attributo xmlns:x.

299.6   Riferimenti

• W3C, Extensible Markup Language (XML) 1.0

  <http://www.w3.org/TR/REC-xml/>

• James Clark, Comparison of SGML and XML

  <http://www.w3.org/TR/NOTE-sgml-xml-971215.html>

• Peter Flynn, The XML FAQ

  <http://www.ucc.ie/xml/>

• Norman Walsh, A Technical Introduction to XML

  <http://nwalsh.com/docs/articles/xml/>

• W3C, Namespaces in XML

  <http://www.w3.org/TR/REC-xml-names/>

• James Clark, XML namespaces

  <http://www.jclark.com/xml/xmlns.htm>

• O'Reilly, xml.com

  <http://www.xml.com>

• Cover Pages

  <http://xml.coverpages.org/xml.html>

Appunti di informatica libera 2006.01.01 --- Copyright © 2000-2006 Daniele Giacomini -- <daniele (ad) swlibero·org>, <daniele·giacomini (ad) poste·it>

Dovrebbe essere possibile fare riferimento a questa pagina anche con il nome xml_introduzione.htm

[successivo] [precedente] [inizio] [fine] [indice generale] [indice ridotto] [violazione licenza] [translators] [docinfo] [indice analitico]