, che significa “molto evidenziato” [16]. Il testo in esso racchiuso
viene in genere visualizzato in neretto, ma è un tag che dà indicazioni sull’importanza del suo con-
tenuto, senza entrare esplicitamente nel merito della formattazione. Successivamente è stato intro-
dotto il tag (Bold = Neretto), il cui significato è evidentemente limitato rispetto al precedente.
Alcuni di questi hanno avuto origine come tag proprietari di uno dei due principali produttori di
browser (Microsoft e Netscape) e la loro diffusione nelle pagine Web è stata tale da “costringere” il
consorzio W3 ad approvarli nelle successive versioni di HTML.
Il W3C si rese conto che l’introduzione di una moltitudine di nuovi tag che rispondessero ad ogni
possibile esigenza di formattazione era irreale e incoerente con i principi di HTML. Il primo vero
strumento di formattazione per HTML è stato introdotto solo con la versione 4.0 ed è costituito dai
fogli di stile, per i quali sono stati definiti due linguaggi specifici: CSS1 e CSS2. I fogli di stile sono
separati dal codice HTML, così come gli script, e riescono ad ottenere la distinzione tra forma e
struttura del documento. I linguaggi CSS1 e CSS2 sono molto semplici e sono adattabili anche
all’XML, ma sono molto meno potenti di XSL, ideato appositamente per XML.
In conclusione, bisogna notare che finora i browser Web sono stati le principali piattaforme di svi-
luppo per il linguaggio Java. Per un’interazione migliore con Java, sarebbe opportuno un linguaggio
più sofisticato e più orientato al trattamento dei dati di HTML, limitato alla descrizione dei testi
[12].
2.3 HTML non consente visualizzazioni diverse dei documenti
È difficile scrivere del codice HTML che mostri gli stessi dati in modi differenti, a seconda delle
esigenze dell’utente [10]. È ancora più difficile realizzare delle viste personalizzate di dati diversi
dal testo, come ad esempio i risultati dell’interrogazione di una base di dati. Non è un caso che per
la creazione di siti dinamici e in grado di interagire con dati, come per esempio un catalogo che
permette ordinazioni, sia necessario l'uso di tecnologie esterne alle specifiche HTML, come le CGI,
Javascript o addirittura Java [7].
Una possibile soluzione di questi problemi è nell’HTML dinamico (DHTML). DHTML non è un
linguaggio di markup come HTML, ma semplicemente un insieme di regole che permettono di usa-
re i fogli di stile e un linguaggio di script al fine di modificare l'aspetto ed il contenuto di una pagina
Web al verificarsi di un dato evento (ad esempio il click o lo spostamento del mouse, o il trascorrere
di un periodo di tempo) [11]. DHTML, però, ha dei notevoli difetti:
? richiede degli script lunghi e complicati;
? è un sistema orientato alla creazione di effetti visivi, piuttosto che alla formattazione dei dati.
L’avvento di XML dovrebbe superare definitivamente questa ennesima estensione di HTML. Del
resto è già possibile associare ad un solo documento HTML diversi fogli di stile, per adattare un
unico contenuto a diversi tipi di presentazione, come quelle ottenute con:
? i normali browser grafici,
? i vecchi browser testuali,
? gli schermi televisivi, per i quali sono richiesti caratteri più visibili,
? i sistemi braille per non vedenti,
? i sistemi vocali per non udenti,
? ecc.
È bene ricordare che la tecnologia dei fogli di stile viene da SGML ed è implementata anche in
XML.
2.4 HTML non ha una struttura semantica
La maggior parte delle applicazioni Web trarrebbe beneficio dalla possibilità di catalogare i dati in
base al loro significato, piuttosto che in modo descrittivo, come fa HTML [10]. Ad esempio, noi
sappiamo che:
Apple
si presenterà in un certo modo in un browser, ma non sappiamo se Apple sia un frutto, l’azienda
produttrice di computer, un cognome o qualcos’altro [12].
Una possibilità per specificare la semantica di un documento è data dal tag , il quale [10]:
? è utilizzabile solo nell’intestazione del documento, quindi non si può associare a particolari dati
significativi contenuti in esso;
? è uno dei tag meno usati di HTML.
In questo modo, si perdono molte delle potenzialità dei motori di ricerca, costretti ad esaminare
tutto il testo a parità di importanza, proprio nel momento in cui la mole dei documenti in rete di-
venta tale da richiedere un meccanismo più puntuale [7]. Purtroppo però l’assenza di tag semantici
non permette questa possibilità e obbliga a ricerche che spesso restituiscono migliaia di documenti
senza dire nulla del significato del termine invocato.
HTML non ha alcun modo di specificare che cosa significhi una certa stringa o un certo dato nella
pagina Web [10]. Non solo: HTML non ha alcuno strumento di analisi di validità di un documento,
cosa di fondamentale importanza per importare ed utilizzare un documento in altre applicazioni.
Quest’esigenza, imprevedibile alla creazione del Web, è diventata di estrema necessità a causa
delle nuove applicazioni che si servono di Internet, come ad esempio il commercio elettronico [15].
Viceversa XML:
1) associa a tutti gli elementi un significato esplicito;
2) consente un controllo formale del documento, attraverso il confronto con la sua DTD;
3) permette di ottenere molteplici visualizzazioni delle informazioni grazie all’XSL.
2.5 Problemi nella conversione in HTML da altri formati
Molte organizzazioni pubblicano le stesse informazioni in diversi formati [14]. Accade di frequente,
infatti, che esistano almeno due versioni di uno stesso documento:
1) per la stampa e la lettura su carta;
2) per la presentazione su Web;
basti pensare ai numerosi giornali che offrono una loro versione elettronica su Web. Solitamente la
versione originale dei documenti viene scritta con un software specifico, ad esempio un word pro-
cessor, e la traduzione in HTML viene effettuata automaticamente da opportuni programmi [10].
Purtoppo queste conversioni non sono sempre perfette e richiedono delle correzioni da effettuare
manualmente, come è noto a chi ha provato l'opzione “salva come HTML” di Word. Ciò significa
che al cambiare del documento originario bisogna ripetere tali aggiustamenti, con conseguente di-
spendio di energia e di tempo [14]. D’altra parte queste aziende non hanno alcun interesse a produr-
re documenti direttamente in HTML, poiché la pubblicazione su Web non è la loro attività princi-
pale.
La causa di questi problemi è nella scarsa flessibilità di HTML, che offre molti meno strumenti ri-
spetto ai moderni word processor e ai programmi professionali per l’editoria, come Adobe Acrobat.
Alcuni siti evitano il problema a priori lasciando sul Web i documenti in formato Acrobat e costrin-
gendo gli utenti ad avere l'apposito lettore.
XML è la soluzione ideale per questi problemi. Esistono delle potenti applicazioni per l'editoria
elettronica basate su SGML che possono essere utilizzate senza difficoltà per XML, tra le quali ci-
tiamo FrameMaker, realizzato proprio dalla Adobe, l’azienda produttrice di Acrobat [1].
2.6 Problemi relativi ai link
2.6.1 HTML consente solo collegamenti semplici
HTML, attraverso il tag (ancora), assicura la possibilità di saltare da un punto ad un altro del
documento o dell’intero Web [7]. Questo elemento, però, utilizza solo la più semplice delle diverse
tipologie di link: il link unidirezionale. Vediamo un esempio di link HTML:
Consorzio WWW
Questo collegamento è unidirezionale, poiché sono definiti:
? l’origine, che è semplicemente il testo contenuto tra i tag di apertura e chiusura;
? la destinazione, che è il valore dell’attributo href.
Non è possibile con il solo HTML percorrere a ritroso questo link, anche se è semplicissimo farlo
utilizzando il tasto “indietro” del browser, oppure usando la funzione Javascript histo-
ry.back() [18].
Sin dagli anni settanta, invece, è stata sviluppata una complessa tipologia di collegamenti iperte-
stuali, che corrispondono a diverse relazioni semantiche [11]:
? link bidirezionali;
? link con destinazioni e origini multiple (uno a molti e molti a uno);
? link che puntano su sezioni strutturali di un documento di destinazione;
? link in grado di incorporare la destinazione nel documento sorgente;
? link definiti in un documento esterno a quello di partenza;
? link a scelta multipla
ed altro ancora. Alcune di queste possibilità sono già state realizzate grazie all’apporto di Java. Di
per sé, HTML consente solo di aprire la risorsa destinazione di un collegamento all’interno del do-
cumento di origine con la tecnica dei frame, che presenta vari problemi [5]:
? le pagine con diversi frame sono incomprensibili a bassa risoluzione;
? se la connessione a Internet è lenta, la pagina con i frame richiede un lungo tempo di carica-
mento;
? talvolta, per degli errori nella trasmissione dei dati, non tutti i frame vengono caricati e la pagina
è inutilizzabile.
XML, tramite i suoi linguaggi XLink ed XPointer, supporta pienamente tutti questi tipi di collega-
mento. XPointer, in particolare, riesce ad indirizzare qualsiasi parte di un documento, rappresentan-
do gli elementi del documento all’interno di una struttura ad albero, così come i moderni file system
fanno con le directory ed i file (vedi § 7.5).
2.6.2 I link scomparsi
Una delle esperienze più comuni tra coloro che utilizzano abitualmente il World Wide Web è
l’apparizione del messaggio :”HTTP/1.0: 404 Oggetto non trovato”, quando si cerca di accedere a
un documento attraverso un link ipertestuale o mediante il suo URL (Uniform Resource Locator)
[11]. Ciò significa semplicemente che il file corrispondente non si trova più nella posizione indicata
dal suo indirizzo, poiché è stato spostato, cancellato o rinominato.
In questo caso non si tratta di una scelta dello standard, quanto piuttosto di un “effetto collaterale”
della struttura sintattica dell’elemento in HTML [7]. Infatti l’indirizzo della risorsa di destina-
zione viene riportato esplicitamente nel documento HTML come valore dell’attributo HREF, e non
in un database o in un altro documento, generando notevoli problemi di manutenzione. In caso di
cancellazione della risorsa di destinazione o anche di semplice modifica del suo path, diventa allora
necessario modificare tutti i documenti che a quella risorsa avevano un riferimento, se si vuole evi-
tare di lasciare in circolazione testi contenenti link scomparsi. Questo problema si può arginare so-
lamente utilizzando nei documenti dei semplici identificativi contenuti fuori dal documento stesso,
in archivi che, modificati in seguito ad un cambiamento dell’indirizzo della risorsa, aggiornano im-
mediatamente tutti i collegamenti.
La schermata presentata da Explorer 5 nel caso sia selezionato un link scomparso
Per rispondere a questa esigenza, vari enti ed organizzazioni che si occupano dello sviluppo degli
standard su Internet hanno proposto una architettura ad hoc denominata Uniform Resource Name
(URN) [11]. In realtà con questa sigla viene indicata una serie di tecnologie, ancora in fase speri-
mentale, nate in ambiti diversi e caratterizzate da diversi approcci e finalità immediate.
Un URN è un identificatore che può essere associato ad ogni risorsa disponibile su Internet, e che
dovrebbe essere utilizzato in tutti i contesti che attualmente fanno uso degli URL. In generale, esso
gode delle seguenti caratteristiche:
? unicità: due risorse distinte non possono avere lo stesso URN;
? validità globale: un URN è indipendente dalla localizzazione della risorsa;
? persistenza: una volta assegnato un URN ad una risorsa esso rimarrà associato ad essa per
sempre, anche se la risorsa non sarà più disponibile; nessuna altra risorsa in futuro potrà ave-
re un URN già assegnato;
? scalabilità: ogni tipo di risorsa su Internet, presente e futura, potrà avere un URN che gode
delle caratteristiche elencate sopra.
Ciascuna risorsa individuata da un URN può essere disponibile in molteplici copie, distribuite su
diversi luoghi della rete: conseguentemente ad ogni URN possono corrispondere molteplici URL.
Attualmente le risorse dotate di URN sono poche, ma tra queste vi sono gli spazi dei nomi di cui
fanno uso alcune applicazioni XML. Un esempio di URN è il seguente:
urn:schemas-microsoft-com:xml-data
ed è l’URN che contiene lo spazio dei nomi di XML-Data. Torneremo nei §§ 4.6 e 4.7 sia sugli spa-
zi dei nomi che su XML-Data.
2.7 HTML si sta evolvendo anche troppo rapidamente
Come abbiamo visto, HTML è uno standard in continua evoluzione [14]. Finora le sue capacità so-
no state continuamente estese attraverso l’introduzione di nuovi tag. Per le organizzazioni che gesti-
scono grandi quantità di informazioni in HTML, il rilascio di nuove versioni di questo linguaggio
provoca in genere notevoli problemi di manutenzione dei documenti esistenti, non tanto perché
venga meno la compatibilità nei confronti delle versioni precedenti, quanto per la necessità di offri-
re pagine Web sempre “al passo con i tempi” e quindi in grado di sfoggiare le novità portate
dall’ultima versione di HTML.
Recentemente Microsoft e Netscape hanno aumentato l’intervallo di tempo fra i rilasci di una ver-
sione e della successiva dei loro browser, portandola da sei mesi a circa un anno. Molti webmaster
malignamente pensano che ciò sia dovuto al tempo impiegato da queste due software house per ag-
giornare i loro enormi siti, al fine di ottimizzarli per la navigazione con il rispettivo nuovo browser,
operazione che forse richiede più tempo dello sviluppo del browser stesso.
Per evitare completamente questo problema, molte grandi organizzazioni già da tempo scrivono i
propri documenti in formato SGML, effettuando automaticamente la traduzione in HTML con ap-
positi programmi. L’aggiornamento di un traduttore di questo tipo per una nuova versione di HTML
richiede un tempo enormemente inferiore rispetto alla ricostruzione di tutti i documenti di interi siti.
L’avvento di XML, che è una semplificazione di SGML, agevola enormemente coloro che vogliono
pubblicare su Web i propri documenti SGML. Molti affermati prodotti software per comporre do-
cumenti SGML supportano già l’esportazione in formato XML [5]. La possibilità di usare XML di-
rettamente su Web permette di confinare i tag presenti e futuri di HTML ai soli fogli di stile: even-
tuali aggiornamenti di HTML si ripercuoteranno solo sulla presentazione su Web del documento,
lasciando inalterata la sua versione in XML.
2.8 Conclusioni
Finora abbiamo evidenziato solamente i limiti e i difetti di HTML, notando come XML sia in grado
di superarli. Potrebbe sembrare così che XML debba sostituire completamente HTML, ma ciò non è
assolutamente necessario. HTML ha numerosi punti a suo vantaggio, i più importanti dei quali sono
[17]:
? ha una struttura molto semplice, che consente di progettare e realizzare rapidamente i documen-
ti;
? è molto veloce e quindi adatto per le applicazioni su Web;
? può essere visualizzato su qualsiasi computer, indipendentemente dall’hardware e dal sistema
operativo;
? è supportato da moltissimi programmi: persino i word processor più recenti esportano in for-
mato HTML;
? non necessita di validazione.
Per le applicazioni più semplici del Web passare all’XML potrebbe risultare addirittura uno svan-
taggio. Esistono numerosissime pagine Web che:
? non contengono dati strutturati o con un particolare significato;
? non hanno interesse a comparire nei motori di ricerca;
? non hanno bisogno di collegamenti estesi o multidirezionali.
Quasi sicuramente il linguaggio di queste pagine resterà HTML. Del resto se io ho una homepage
personale visitata al più da qualche mio amico, chi me lo fa fare a:
1) convertire il codice da HTML in XML,
2) aggiungere un foglio di stile per permettere la visualizzazione con un browser,
3) aggiungere la DTD per avere la mia homepage validata secondo la specifica del W3C?
Al termine di questo lavoro avrei lo svantaggio che i miei amici con browser vecchi non riuscireb-
bero neanche più ad accedere alla pagina.
In realtà HTML ed XML sono complementari tra loro e trattano i dati su livelli differenti [19]:
? XML è usato per strutturare e descrivere i dati;
? HTML è usato per visualizzarli sul Web.
Infatti XSL, che si occupa della rappresentazione dei dati, prevede la possibilità di utilizzare tag di
HTML. La cosa non è indispensabile, visto che si potrebbero usare anche dei tag propri di XSL,
chiamati oggetti di formattazione, ma è molto utile, poiché i tag di HTML sono molto più cono-
sciuti e semplici da usare (vedi § 5.9). Si può concludere che:
? se HTML soddisfa le proprie esigenze, non c’è alcuna necessità di passare ad XML.
? Se HTML è ritenuto insufficiente, si possono superare i suoi limiti:
1) sostituendo XML ad HTML nelle fasi di memorizzazione e descrizione dei dati;
2) riutilizzando il codice HTML relativo alla formattazione dei documenti, mediante
l’inserimento all’interno dei fogli di stile XSL.
3 STRUTTURA E SINTASSI DI XML
3.1 Il processo di codifica XML
Il seguente diagramma illustra i componenti fondamentali di un documento XML completo e come
questi interagiscano fra loro [5]:
Questo schema non è l’unico possibile, in quanto:
1) La DTD nell’XML è facoltativa. Però senza la DTD è impossibile validare il documento.
2) Il foglio di stile XSL (o CSS) è la soluzione più immediata per portare su Web documenti
XML. Comunque c’è anche la possibilità di accedere ai documenti XML per mezzo di file
HTML con l’aggiunta di script, applet Java, controlli ActiveX ecc.
È appena il caso di notare che i file XML, DTD ed XSL possono trovarsi nello stesso computer, co-
sì come in tre continenti diversi: questa è una caratteristica di tutte le tecnologie correlate ad Inter-
net.
In questo capitolo ci occuperemo esclusivamente della composizione dei documenti XML. Il capi-
tolo 4 sarà dedicato alle DTD e i capitoli 5 e 6 al linguaggio XSL.
3.2 La sintassi di XML
3.2.1 Sintassi dei tag
In XML viene definito elemento:
? tutto ciò che è racchiuso tra un tag di apertura ed un tag di chiusura:
Esempio di elemento non vuoto
Gli elementi possono essere anche nidificati l’uno dentro l’altro, ossia un elemento può conte-
nerne un altro al suo interno.
? l’elemento vuoto, che non ha contenuto ed ha una sintassi leggermente diversa:
Riassumiamo le sintassi dei due tipi di elementi per mezzo di questo schema [10]:
Ogni attributo associa ad un elemento un valore, il quale è un’informazione che non fa parte del
contenuto dell’elemento stesso. Come in HTML, gli attributi possono essere un numero qualsiasi,
eventualmente anche nessuno. Se gli attributi sono più di uno, le coppie formate da attributo e valo-
re vengono semplicemente elencate all’interno del tag di apertura o del tag di elemento vuoto:
Contenuto
3.2.2 Obblighi sintattici imposti da XML
Apparentemente la sintassi di XML è la stessa di HTML. Ci sono, invece, alcune differenze di fon-
damentale importanza.
1) In un elemento non vuoto il tag di chiusura deve essere sempre presente.
2) Il nome del tag deve essere esattamente identico nei tag di apertura e chiusura. XML distingue
fra maiuscole e minuscole e pertanto:
Nome ? NOME ? nome ? NoMe
3) Dato che è obbligatorio il tag di chiusura, gli elementi devono essere nidificati correttamente
l’uno nell’altro. Se all’interno di un elemento c’è il tag di apertura di un altro elemento, deve per
forza trovarvisi anche il tag di chiusura. Una nidificazione corretta è la seguente:
Contenuto
mentre è sbagliata:
Contenuto NO!
4) I valori degli attributi devono essere obbligatoriamente racchiusi tra virgolette o apici.
5) Deve essere presente un solo elemento di livello più esterno. Tale elemento costituisce la radice
del documento XML e tutti gli altri elementi devono essere contenuti in esso. La radice ha lo
stesso significato dell’elemento di HTML, ma il suo tag può avere un nome qualun-
que.
3.3 Documenti validi e ben formati
HTML definisce un insieme di elementi, ciascuno con un proprio significato ed un proprio effetto
sulla visualizzazione del documento. XML non detta regole di questo tipo, ma lascia due possibilità:
1) Fare riferimento ad una DTD interna o esterna. In questo caso il documento XML può contenere
solo elementi e attributi esplicitamente indicati nella DTD e strutturati secondo quanto stabilito
nella DTD stessa. Se il documento rispetta tutte le regole della DTD è chiamato valido.
2) Non utilizzare la DTD. In questo modo la scelta di attributi ed elementi è libera e gli unici vin-
coli sono il rispetto delle regole sintattiche appena elencate. Un documento che è privo di DTD
e non contiene errori di sintassi è detto ben formato [1] o anche ben formattato o accettabile.
Come in tutti i linguaggi, anche in XML esistono delle parole riservate che non possono essere uti-
lizzate liberamente come nomi di elementi, attributi o per markup di altro tipo [5]. Secondo la speci-
fica XML del W3C, sono parole riservate le stringhe:
XML, xml, Xml, xML, …
e tutte le altre possibili combinazioni con lettere maiuscole e minuscole [6]. Nessun nome può ini-
ziare con una di queste stringhe, o essere uguale ad una di esse [1].
Per il resto la scelta dei nomi è molto flessibile, in quanto:
? i nomi possono iniziare con una qualsiasi lettera maiuscola o minuscola;
? possono contenere una qualsiasi sequenza di lettere maiuscole, minuscole e cifre. Sono ammessi
anche i caratteri: “.”, “-“ e “_”;
? il carattere “:” è ammesso, ma può essere utilizzato solo per dichiarare l’appartenenza ad uno
spazio dei nomi (vedi § 4.6).
Ricordiamo che un documento scritto con un linguaggio di markup è composto dal testo e dal
markup.
Mentre il markup segue delle regole sintattiche precise, il testo deve poter contenere qualsiasi ca-
rattere. In XML, però, alcuni caratteri non dovrebbero essere inseriti direttamente nel testo, poiché
possono confondersi con il markup. Essi sono:
< > & ' "
XML consente di sostituire questi caratteri con entità predefinite. Vedremo in seguito come è pos-
sibile far riferimento a tali entità e quindi utilizzare anche questi caratteri nel testo.
3.4 Prologo
I documenti XML possono cominciare con un prologo, il quale è composto da:
? una dichiarazione XML,
? una dichiarazione di tipo di documento
entrambe facoltative.
3.4.1 Dichiarazione XML
La dichiarazione XML è composta da 3 parti:
1) Numero della versione. Una dichiarazione XML che contiene solo il numero della versione è
detta minima.La sua sintassi è:
Per il momento l’unica versione di XML è la 1.0, dunque l’unico valore possibile per il numero
di versione è “1.0”. Si noti inoltre che la stringa “xml” deve essere scritta in lettere minuscole.
2) Dichiarazione della codifica. Descrive quale codifica dei caratteri viene utilizzata. La sintassi è
la seguente:
Alcune possibili codifiche sono rappresentate dalle seguenti stringhe [6]:
? UTF-8: Unicode ad 8 bit (è la codifica normalmente utilizzata);
? UTF-16: Unicode a 16 bit (è una codifica comprendente 65.536 caratteri non supportata da
tutti i sistemi operativi);
? EUC-JP: caratteri giapponesi.
3) Dichiarazione di documento indipendente. Consente di specificare se debba essere recuperata
o meno la parte esterna della DTD per analizzare correttamente la validità del documento [1].
La sintassi è:
dove:
? standalone='yes': il documento è indipendente e non vanno considerate eventuali
DTD o parti di DTD esterne ad esso;
? standalone='no': il documento dipende dalla parte esterna della DTD.
Se non vi sono DTD o parti di DTD esterne al documento, questa dichiarazione non ha senso
[6]. Se è presente un riferimento ad una DTD esterna, il valore “no” è assunto come default.
3.4.2 Dichiarazione di tipo di documento
La dichiarazione di tipo di documento, se presente, stabilisce la conformità del documento ad una
certa DTD. Le possibili sintassi sono due:
1) DTD interna al documento:
supponendo che RADICE sia il nome dell’elemento radice del documento. Ciò significa che
nell’associazione alla DTD, il documento XML viene identificato per mezzo del nome del suo
elemento radice. Tra le parentesi quadre va scritta per esteso la DTD del documento. Tratteremo
la composizione delle DTD nel prossimo capitolo.
2) DTD in un file esterno al documento [19]:
“documento.dtd” è il file dove si trova la DTD del documento. La parola chiave SYSTEM
indica che il nome del file è un identificatore di sistema. Ovviamente tale nome può essere an-
che un indirizzo Internet [1]:
Infine c’è la possibilità che la DTD abbia un identificatore pubblico, che consente al software di
utilizzare una propria copia della DTD oppure di reperire questa su determinati server veloci di
sua conoscenza. In questo caso è utilizzata la parola chiave PUBLIC:
L’indirizzo Internet compare ugulamente e viene utilizzato nel caso il software non riesca ad
interpretare l’identificatore pubblico.
Un documento XML può anche avere la sua DTD, che è unica per definizione, divisa in un sottoin-
sieme interno ed un sottoinsieme esterno [19]. In questo caso la sintassi è:
Se ci sono conflitti tra i due sottoinsiemi, viene data priorità al sottoinsieme interno della DTD,
ignorando eventuali dichiarazioni esterne in contrasto con quelle all’interno del documento. In que-
sto modo chi scrive un documento XML ha la possibilità di modificare una DTD esterna, senza che
debba riscriverla completamente.
3.5 Entità predefinite
Il linguaggio XML prevede cinque entità predefinite, che possono sostituire i cinque caratteri che
non andrebbero utilizzati all’interno del testo di un documento (<,>,&,',") [1]. Esse sono:
ENTITÀ
CARATTERE
&
&
<
<
>
>
'
‘
"
“
Vediamo un esempio:
Come inserire del codice HTML in un documento XML
<HTML> <HEAD> <TITLE>Titolo</TITLE>
</HEAD> <BODY>Contenuto</BODY></HTML>
Per rendersi conto della sostituzione delle entità predefinite con i corrispondenti caratteri, ecco co-
me Explorer 5 mostra questo documento XML:
Si noti la distinzione tra il markup, che è colorato, ed il testo del documento, mostrato in nero. Tutti
i tag del codice HTML sono in nero, dunque sono considerati come semplice testo e non analizzati
come elementi di XML.
La sostituzione dei caratteri <,>,&,' e " con le entità predefinite non è obbligatoria, ma diventa ne-
cessaria nel caso siano possibili confusioni tra markup e testo, come nell’esempio precedente. È una
buona norma usare comunque le entità predefinite, poiché il comportamento dei vari programmi
alla presenza dei caratteri <,>,&,' e " nel testo può essere imprevedibile.
La sintassi delle entità predefinite:
&nome;
dove “nome” è il nome dell’entità, viene utilizzata in XML per i riferimenti alle entità generali. Le
entità, ad eccezione delle cinque entità predefinite, devono essere dichiarate nella DTD, quindi ver-
ranno discusse nel prossimo capitolo.
3.6 Riferimenti ai caratteri
I documenti XML sono costituiti esclusivamente da caratteri con codice ASCII dal 32 al 127. Per
inserire in un documento XML caratteri con codice ASCII superiore al 127, esistono due possibili-
tà:
1) dichiarare questi caratteri come entità nella DTD;
2) utilizzare il riferimento numerico al carattere. È l’unica scelta possibile per un documento senza
DTD.
Il riferimento numerico ha la seguente sintassi:
&#Codice;
dove Codice è il numero di codice del carattere secondo la codifica utilizzata. È possibile anche
scrivere questo numero in esadecimale, utilizzando la sintassi:
odice_hex;
Vediamo un piccolo esempio:
In XML si può far riferimento a caratteri speciali
utlizzando le ENTITÀ oppure i RIFERIMENTI NUMERICI.
e come viene visualizzato da Explorer 5:
In XML si può far riferimento a caratteri speciali utilizzando
le ENTITÀ oppure i RIFERIMENTI NUMERICI.
L’elenco completo dei codici dei caratteri nella codifica UTF-8 si può trovare in [5] o in qualsiasi
manuale di HTML.
3.7 Istruzioni di elaborazione
Le istruzioni di elaborazione, dette anche PI (Processing Instructions) forniscono indicazioni al
programma che elabora il documento XML [19]. Queste istruzioni sono normalmente posizionate
nel prologo, ma possono comparire in un punto qualsiasi del documento. La sintassi è questa:
dove “Istruzione ” dipende dal software che utilizza il file XML. Ad esempio, l’istruzione di
elaborazione:
indica che il documento XML deve essere visualizzato per mezzo del foglio di stile XSL nel file
“documento.xsl”. Il W3C ha standardizzato le istruzioni di elaborazione per l’associazione dei
fogli di stile ai documenti XML con una raccomandazione del giugno 1999 [20].
Un altro esempio di istruzione di elaborazione è [19]:
che fornisce indicazioni al browser sulla riproduzione dei filmati in formato AVI.
Formalmente, anche la dichiarazione XML è un’istruzione di elaborazione, visto che segue la stessa
sintassi delle PI:
3.8 Commenti
I commenti in XML sono aperti dalla sequenza di caratteri “”
[1]. Possono contenere qualsiasi stringa, ad eccezione della coppia di caratteri “--”. Esempio:
All’interno dei commenti possono essere utilizzati direttamente i cinque caratteri <,>,&,' e ", senza
bisogno di ricorrere alle entità predefinite, dato che gli elaboratori XML non analizzano il conte-
nuto dei commenti alla ricerca di markup:
Per lo stesso motivo non è possibile inserire i caratteri con codice ASCII maggiore di 127, neanche
utilizzando i riferimenti numerici o le entità. Infatti, nell’esempio precedente abbiamo sostituito il
carattere “è” con la stringa “e’”.
3.9 Conversione di un documento HTML in un documento XML
ben formato
Consideriamo un breve documento HTML, che contiene l’elenco dei docenti di un dipartimento di
informatica, con delle sommarie informazioni su ciascuno di essi:
Università di QualchePosto - Docenti del dipartimento di
Informatica
Università degli studi di
QualchePosto
Dipartimento di Informatica
Elenco dei docenti
Gianni Brahms
: Professore Ordinario
Gruppo di ricerca: Intelligenza Artificiale
Curriculum vitae: Nato nel 1936 e laureato nel 1961. Dal 1974 è
titolare della cattedra di Intelligenza Artificiale. Dirige il Dipartimento dal
1996.
Elenco pubblicazioni:
- Uso delle variabili semantiche nella logica fuzzy (1986)
- Regole di produzione ed EBNF (1988)
- Utilizzo della logica fuzzy in problemi di scheduling della CPU (1991)
- Tecniche di I.A. per i motori di ricerca (1997)
Ermanno Grieg
: Professore Associato
Gruppo di ricerca: Reti Neurali
Curriculum vitae: Nato nel 1949 e laureato nel 1973. Dal 1978 è
titolare della cattedra di Algoritmi per il controllo dei segnali.
Elenco pubblicazioni:
- L'importanza dell'apprendimento nei percettroni multistrato (1980)
- Reti neurali autoorganizzantisi: un approccio statistico (1986)
- Simulazioni al Matlab di reti neurali non lineari (1991)
Federico Mendelzon
:
Gruppo di ricerca: Visione delle macchine
Curriculum vitae: Nato nel 1971 e laureato nel 1998. Collabora con il prof.
Brahms nel corso di Intelligenza artificiale.
Elenco pubblicazioni:
- Progetto di un software in grado di riconoscere i tombini (1999)
Riccardo Strauss
:
Gruppo di ricerca: Basi di Dati
Curriculum vitae: Nato nel 1968 e laureato nel 1996. Collabora con il prof.
Verdi nel corso di Basi di dati.
Elenco pubblicazioni:
- Modello Reticolare nei database orientati agli oggetti (1997)
Giuseppe Verdi
: Professore Associato
Gruppo di ricerca: Basi di Dati
Curriculum vitae: Nato nel 1945 e laureato nel 1970. Nel 1984 ha ottenuto la
cattedra di Basi di dati.
Elenco pubblicazioni:
- Utilizzo di Oracle per l'amministrazione di piccole aziende (1991)
- Come convertire un database gerarchico in un database relazionale (1994)
- XML e le basi di dati su Internet (1998)
Sebastiano Bach
: Professore Associato
Gruppo di ricerca: Ricerca Operativa
Curriculum vitae: Nato nel 1941 e laureato nel 1970. Dal 1986 è il
titolare della cattedra di Ricerca operativa.
Elenco pubblicazioni:
- L'euristica per problemi di previsioni di mercato (1993)
- Un problema di sfrido a 3 dimensioni (1995)
- Una proposta per la composizione automatizzata degli orari ferroviari (1998)
La trasformazione del documento da HTML ad XML ben formato si può ricondurre fondamental-
mente a quattro operazioni:
1) Rendere il documento HTML conforme alle restrizioni sintattiche di XML già elencate in detta-
glio nel §3.2.2. I documenti di questo tipo appartengono, oltre che all’HTML, ad un particolare
linguaggio, chiamato XHTML (eXtensible HyperText Markup Language), la cui versione 1.0 è
stata definita da una specifica del W3C nell’agosto 1999 [21]. XHTML 1.0 è semplicemente
una riformulazione di HTML 4.0 come un’applicazione di XML (oltre che di SGML).
La trasformazione di un documento HTML in uno XHTML (e quindi XML) è effettuata auto-
maticamente da alcuni software, tra cui il browser Amaya del W3C [22]. Vediamo un esempio
di questa conversione. Il codice HTML:
Curriculum vitae: Nato nel 1968 e laureato nel 1996. Collabora con il
prof. Verdi nel corso di Basi di dati.
Elenco pubblicazioni:
- Modello Reticolare nei database orientati agli oggetti (1997)
in cui gli elementi e
non hanno il tag di chiusura e l’elemento
non segue la
sintassi di XML per gli elementi vuoti, diventa:
Curriculum vitae: Nato nel 1968 e laureato nel 1996. Collabora con il
prof. Verdi nel corso di Basi di dati.
Elenco pubblicazioni:
- Modello Reticolare nei database orientati agli oggetti (1997)
Si noti che l’XHTML impone l’uso delle lettere minuscole per tutti i tag di HTML, rispettando
la case-sensitivity di XML.
2) Dopo il primo passo abbiamo un documento XML sintatticamente corretto, ma semanticamente
molto povero, come il documento HTML di partenza (vedi § 2.4). È a questo punto che deve
avvenire la trasformazione fondamentale: la sostituzione degli elementi di HTML, orientati alla
presentazione del documento su Web, con degli elementi di XML in grado di descrivere la se-
mantica e la struttura del documento.
Occorre inoltre sopprimere:
? alcuni elementi ed attributi di formattazione privi di qualsiasi semantica,
? alcune parti del testo ripetute di frequente.
Queste parti del documento non vengono eliminate definitivamente, poiché sono utili alla pre-
sentazione e alla formattazione del documento stesso, ma saranno inserite successivamente nel
foglio di stile XSL utilizzato per la presentazione su Web.
Purtroppo non esistono regole precise per estrarre il contenuto significativo da un documento
HTML ed assegnare ad esso i tag XML, quindi sarà compito di chi si occupa della conversione
seguire i criteri ritenuti opportuni. Nel nostro semplice esempio, proponiamo i seguenti cam-
biamenti (ovviamente non sono i soli possibili):
HTML
XML
?
soppresso
?
?
soppresso
<body>…</body>
?
<DOCENTI>…</DOCENTI>
<font color="#0000ff">
?
soppresso
<h1>, <h2>, <h3>
?
soppressi
<font color="#ff00ff">
?
soppresso
<font color="#ff0000">
?
<PERSONA>
<p><b>nome</b>
?
<NOME>nome</NOME>
:titolo_accademico</p>
?
<TITOLO>titolo_accademico</TITOLO>
Gruppo di ricerca: <i>…</i>
?
<GRUPPO>…</GRUPPO>
<p>Curriculum vitae: …</p>
?
<CURRICULUM>…</CURRICULUM>
<p>Elenco pubblicazioni:</p>
?
soppresso
<ul>…</ul>
?
<PUBBLICAZIONI>…</PUBBLICAZIONI>
<li>…</li>
?
<PUBBLICAZIONE>…</PUBBLICAZIONE>
<hr/>
?
</PERSONA>
3) Sostituire i riferimenti ai caratteri speciali di HTML (à, è ecc.) con i rife-
rimenti numerici di XML. Si noti che i riferimenti di HTML sono utilizzabili anche in XML, ma
vanno definiti nella DTD. Per un documento senza DTD è possibile solo usare i riferimenti nu-
merici descritti nel § 3.6. Nel nostro documento occorre una sola sostituzione:
HTML
XML
è
?
è
4) Sostituire eventuali occorrenze dei cinque caratteri <,>,&,' e " nel testo con le rispettive entità
predefinite. Come abbiamo già detto, quest’operazione non è indispensabile, ma è consigliata,
specie se si pensa che il documento possa essere utilizzato da vari programmi. Anche in questo
caso c’è una sola sostituzione da fare:
HTML
XML
‘
?
'
Al termine di queste trasformazioni abbiamo il seguente documento XML ben formato:
<?xml version="1.0" encoding="UTF-8" ?>
<DOCENTI>
<PERSONA>
<NOME>Gianni Brahms</NOME>
<GRUPPO>Intelligenza Artificiale</GRUPPO>
<TITOLO>Professore Ordinario</TITOLO>
<PUBBLICAZIONI>
<PUBBLICAZIONE>Uso delle variabili semantiche nella logica fuzzy
(1986)</PUBBLICAZIONE>
<PUBBLICAZIONE>Regole di produzione ed EBNF (1988)</PUBBLICAZIONE>
<PUBBLICAZIONE>Utilizzo della logica fuzzy in problemi di scheduling
della CPU (1991)</PUBBLICAZIONE>
<PUBBLICAZIONE>Tecniche di I.A. per i motori di ricerca (1997)
</PUBBLICAZIONE>
</PUBBLICAZIONI>
<CURRICULUM>Nato nel 1936 e laureato nel 1961. Dal 1974 è titolare
della cattedra di Intelligenza Artificiale. Dirige il Dipartimento dal
1996.</CURRICULUM>
</PERSONA>
<PERSONA>
<NOME>Ermanno Grieg</NOME>
<GRUPPO>Reti Neurali</GRUPPO>
<TITOLO>Professore Associato</TITOLO>
<PUBBLICAZIONI>
<PUBBLICAZIONE>L'importanza dell'apprendimento nei
percettroni multistrato (1980)</PUBBLICAZIONE>
<PUBBLICAZIONE>Reti neurali autoorganizzantisi: un approccio
statistico (1986)</PUBBLICAZIONE>
<PUBBLICAZIONE>Simulazioni al Matlab di reti neurali non lineari
(1991)</PUBBLICAZIONE>
</PUBBLICAZIONI>
<CURRICULUM>Nato nel 1949 e laureato nel 1973. Dal 1978 è
titolare della cattedra di Algoritmi per il controllo dei
segnali.</CURRICULUM>
</PERSONA>
<PERSONA>
<NOME>Federico Mendelzon</NOME>
<GRUPPO>Visione delle macchine</GRUPPO>
<PUBBLICAZIONI>
<PUBBLICAZIONE>Progetto di un software in grado di riconoscere i
tombini (1999)</PUBBLICAZIONE>
</PUBBLICAZIONI>
<CURRICULUM>Nato nel 1971 e laureato nel 1998. Collabora con il prof.
Brahms nel corso di Intelligenza artificiale.</CURRICULUM>
</PERSONA>
<PERSONA>
<NOME>Riccardo Strauss</NOME>
<GRUPPO>Basi di Dati</GRUPPO>
<PUBBLICAZIONI>
<PUBBLICAZIONE>Modello Reticolare nei database orientati agli
oggetti (1997)</PUBBLICAZIONE>
</PUBBLICAZIONI>
<CURRICULUM>Nato nel 1968 e laureato nel 1996. Collabora con il prof.
Verdi nel corso di Basi di dati.</CURRICULUM>
</PERSONA>
<PERSONA>
<NOME>Giuseppe Verdi</NOME>
<GRUPPO>Basi di Dati</GRUPPO>
<TITOLO>Professore Associato</TITOLO>
<PUBBLICAZIONI>
<PUBBLICAZIONE>Utilizzo di Oracle per l'amministrazione di
piccole aziende (1991)</PUBBLICAZIONE>
<PUBBLICAZIONE>Come convertire un database gerarchico in un database
relazionale (1994)</PUBBLICAZIONE>
<PUBBLICAZIONE>XML e le basi di dati su Internet (1998)
</PUBBLICAZIONE>
</PUBBLICAZIONI>
<CURRICULUM>Nato nel 1945 e laureato nel 1970. Nel 1984 ha ottenuto la
cattedra di Basi di dati.</CURRICULUM>
</PERSONA>
<PERSONA>
<NOME>Sebastiano Bach</NOME>
<GRUPPO>Ricerca Operativa</GRUPPO>
<TITOLO>Professore Associato</TITOLO>
<PUBBLICAZIONI>
<PUBBLICAZIONE>L'euristica per problemi di previsioni di
mercato (1993)</PUBBLICAZIONE>
<PUBBLICAZIONE>Un problema di sfrido a 3 dimensioni
(1995)</PUBBLICAZIONE>
<PUBBLICAZIONE>Una proposta per la composizione automatizzata degli
orari ferroviari (1998)</PUBBLICAZIONE>
</PUBBLICAZIONI>
<CURRICULUM>Nato nel 1941 e laureato nel 1970. Dal 1986 è il titolare
della cattedra di Ricerca operativa.</CURRICULUM>
</PERSONA>
</DOCENTI>
Questo documento ha una precisa struttura ad albero, che si può già intuire dalle diverse indentature
dei vari elementi nel listato. Mostriamo più in dettaglio questa struttura, servendoci della rappre-
sentazione grafica fornita dal programma XML Notepad della Microsoft:
Per motivi di spazio sono stati completamente espansi solo i rami relativi a tre dei sei elementi
PERSONA. Vediamo, infine, la struttura ad albero utilizzando un grafo “tradizionale”:
In questo caso, per motivi di spazio, abbiamo espanso solamente il ramo relativo al secondo ele-
mento PERSONA (Ermanno Grieg).
4 DOCUMENT TYPE DEFINITION (DTD)
4.1 Dichiarazione degli elementi
La DTD di un documento definisce gli elementi, gli attributi e le entità consentiti al suo interno.
Inoltre essa esprime come questi debbano essere combinati, affinché il documento sia valido [1].
La sintassi per la dichiarazione di un elemento NOME in un documento XML è:
<!ELEMENT NOME CONTENUTO>
dove CONTENUTO può avere i seguenti valori:
Valore di CONTENUTO
Contenuto consentito
EMPTY
Nessuno. L’elemento dev’essere vuoto e seguire la sintassi per
gli elementi vuoti.
ANY
Qualsiasi. L’elemento può contenere qualunque combinazione
di sottoelementi e testo.
(FIGLIO)
L’elemento può contenere solo un sottoelemento di nome
FIGLIO. Il nome del sottoelemento deve essere racchiuso fra
parentesi tonde.
(#PCDATA)
L’elemento può contenere solo una stringa di testo di qualsiasi
lunghezza o, eventualmente, essere vuoto. Anche in questo ca-
so sono obbligatorie le parentesi.
Il contenuto di un elemento può essere specificato con precisione utilizzando degli operatori che
consentono di combinare le possibilità appena elencate [19]. Per chiarire l’uso di questi operatori,
supponiamo che A e B siano sottoelementi. Si ha:
Operatore
Valore di
CONTENUTO
Contenuto consentito
|
(A|B)
(#PCDATA|A)
L’elemento deve contenere uno solo tra A e B, senza ripeti-
zioni.
L’elemento può contenere una stringa di testo oppure un
solo sottoelemento A.
,
(A,B)
L’elemento deve contenere prima A e poi B, per una sola
volta e nell’ordine specificato.
?
(A?)
L’elemento può contenere A o essere vuoto. Non sono
ammesse ripetizioni di A.
*
(A*)
L’elemento può contenere un numero qualsiasi di occorren-
ze di A o essere vuoto.
+
(A+)
L’elemento deve contenere A, che può essere ripetuto per
un numero qualsiasi di volte.
È formalmente possibile usare gli operatori ?, * e + anche con la parola chiave #PCDATA, anche se
non hanno alcun effetto su essa.
Gli operatori possono essere combinati in vari modi, utilizzando anche parentesi multiple. È im-
portante che la parola chiave #PCDATA, se utilizzata, sia posta all’inizio di CONTENUTO [5].
4.1.1 Esempi di dichiarazione degli elementi
Esempio 1. Per evidenziare meglio la collocazione della DTD all’interno di un documento XML,
analizziamo il seguente documento XML valido, che realizza l’esempio di e-mail del §1.1 [19]:
<?xml version="1.0"?>
<!DOCTYPE EMAIL [
<!ELEMENT EMAIL (A,DA,CC,TITOLO,TESTO)>
<!ELEMENT A (#PCDATA)>
<!ELEMENT DA (#PCDATA)>
<!ELEMENT CC (#PCDATA)>
<!ELEMENT TITOLO (#PCDATA)>
<!ELEMENT TESTO (#PCDATA)>
]>
<EMAIL>
<A>Alessandro</A>
<DA>Luca</DA>
<CC>Ezio</CC>
<TITOLO>Prova</TITOLO>
<TESTO>
Questo è un esempio di e-mail, che serve a
mostrare le differenze fra i linguaggi di markup.
</TESTO>
</EMAIL>
Abbiamo diviso il documento in definizione (DTD) e istanza, seguendo la terminologia delle basi
di dati [3]. In XML il documento coincide con l’istanza, mentre la definizione, se presente, è sepa-
rata dalla struttura ad albero del documento, essendo racchiusa all’interno del prologo (vedi
§ 3.4.2).
Affinché il documento sia valido, l’istanza deve seguire le regole dettate dalla definizione. Nel no-
stro esempio, l’elemento radice del documento è EMAIL, che contiene nell’ordine i cinque sottoe-
lementi A, DA, CC, TITOLO e TESTO. Questi a loro volta contengono solo testo.
La DTD presentata è estremamente rigida: i cinque sottoelementi devono comparire tutti, essere
nell’ordine stabilito e contenere testo. Una possibile variazione della DTD più conforme alla realtà
si può ottenere introducendo alcuni operatori nella dichiarazione della radice [19]:
<!ELEMENT EMAIL (A+,DA,CC*,TITOLO?,TESTO?)>
in questo modo:
? l’elemento A è obbligatorio e può essere ripetuto più di una volta;
? l’elemento CC può o non comparire, o essere presente una o più volte;
? gli elementi TITOLO e TESTO sono facoltativi, ma se presenti non possono essere ripetuti;
? l’ordine degli elementi rimane fissato: se ci sono più elementi A, DA deve trovarsi dopo l’ultimo
di questi e così via.
Esempio 2.
<!ELEMENT paragrafo (#PCDATA|grassetto|corsivo)*>
L’elemento paragrafo può contenere stringhe di testo e degli elementi grassetto e corsi-
vo, in qualsiasi numero ed in qualsiasi ordine [1]. Eventualmente l’elemento può anche essere
vuoto. Per evitare questa possibilità basta sostituire l’operatore + all’operatore *.
Come abbiamo detto, #PCDATA, se presente, deve trovarsi all’inizio della stringa che definisce il
contenuto dell’elemento. Ciò significa che la dichiarazione:
<!ELEMENT paragrafo (grassetto|corsivo|#PCDATA)*> NO!
sarebbe scorretta, mentre risulta corretta quella precedente.
Esempio 3. È possibile utilizzare più coppie di parentesi. Esse assumono lo stesso valore che hanno
nelle espressioni matematiche:
<!ELEMENT FAQ (INTRODUZIONE,(DOMANDA,RISPOSTA)+,COPYRIGHT?)>
L’elemento FAQ deve contenere:
1) un elemento INTRODUZIONE obbligatorio;
2) una o più coppie di elementi DOMANDA e RISPOSTA. Tali coppie sono ordinate: al termine
dell’elemento RISPOSTA dovrà trovarsi il successivo elemento DOMANDA (se esiste).
3) Un elemento COPYRIGHT facoltativo e non ripetibile.
Esempio 4. Chiudiamo con una dichiarazione di elemento vuoto:
<!ELEMENT VUOTO EMPTY>
Per inserire un elemento opzionale non si può usare la dichiarazione:
<!ELEMENT prova (EMPTY|paragrafo)> NO!
poiché EMPTY viene interpretato in questo caso come il nome di un sottoelemento di prova, non
come parola chiave. Dunque l’elemento così definito deve contenere un elemento EMPTY o un ele-
mento paragrafo e non può essere vuoto. Ovviamente la dichiarazione giusta è:
<!ELEMENT prova (paragrafo?)>
4.2 Dichiarazione degli attributi
Oltre a definirne il contenuto, la DTD consente di associare attributi a ciascun elemento [19]. Gli
attributi forniscono informazioni aggiuntive relative ad un elemento o al suo contenuto. A differen-
za degli elementi, gli attributi possono contenere solo testo, e non markup, al loro interno [1]. Per-
tanto non esistono “sottoattributi”, né in XML, né in SGML (e quindi in HTML).
Nel linguaggio XML, gli attributi vengono dichiarati nella DTD utilizzando la seguente sintassi
[19]:
<!ATTLIST ELEMENTO NOME TIPO IMPOSTAZIONE>
dove:
? ELEMENTO è l’elemento al quale viene applicato l’attributo. Si possono trovare attributi con lo
stesso nome, ma associati ad elementi diversi.
? NOME è il nome dell’attributo;
? TIPO è il tipo di attributo;
? IMPOSTAZIONE è l’impostazione predefinita dell’attributo.
Elenchiamo in questa tabella i possibili valori di TIPO:
Valore di TIPO
Valore consentito per l’attributo
CDATA
Stringa di testo di qualsiasi lunghezza, eventualmente anche vuota.
NMTOKEN
Stringa composta da lettere, numeri e caratteri “.”, “-“, “:” e “_” di
qualsiasi lunghezza, ma non vuota.
NMTOKENS
Consente l’utilizzo di più valori di tipo NMTOKEN separati da spazi.
(valore1|valore2|…)
Deve essere uno dei valori specificati nella lista.
ENTITY
Riferimento ad un’entità esterna (vedi § 4.4).
ENTITIES
Riferimenti a diverse entità esterne separati da spazi.
ID
Identificatore univoco (vedi § 4.2.1).
IDREF
Riferimento ad un identificatore univoco.
IDREFS
Riferimenti a diversi identificatori univoci.
NOTATION
Riferimento ad un’annotazione dichiarata in un altro punto della DTD
(vedi § 4.4).
Il campo IMPOSTAZIONE può assumere i seguenti valori:
Valore di IMPOSTAZIONE
Significato
#REQUIRED
L’attributo è richiesto.
#IMPLIED
L’attributo è opzionale.
#FIXED “valore_fissato”
L’attributo deve avere il valore valore_fissato. Questo può
essere specificato nel documento, oppure sottinteso.
L’assegnazione di un valore diverso provoca un errore.
“default”
Se l’attributo non viene specificato, gli viene assegnato il
valore default.
Sono ammesse dichiarazioni di attributi multipli per un singolo elemento [1]. Ad esempio, un ele-
mento PERSONA potrebbe avere la seguente dichiarazione:
<!ATTLIST PERSONA EMAIL CDATA #IMPLIED
TELEFONO CDATA #REQUIRED
FAX CDATA #IMPLIED>
che risulta sicuramente più compatta rispetto a tre dichiarazioni singole.
L’ordine degli attributi non è importante. Infatti, l’elemento:
<PERSONA TELEFONO="071/84315" FAX="071/2810841"
EMAIL="mrossi@unian.it">…</PERSONA>
è compatibile con la dichiarazione precedente.
Vediamo un esempio riguardante gli attributi predefiniti:
<!ATTLIST MAGLIETTA TAGLIA (SMALL|MEDIUM|LARGE) "MEDIUM">
In questo caso i valori che può assumere l’attributo TAGLIA sono solo i tre elencati. Il valore pre-
definito è "MEDIUM". Se nel documento abbiamo:
? <MAGLIETTA TAGLIA="LARGE">…</MAGLIETTA>
il valore dell’attributo TAGLIA è posto uguale a “LARGE”;
? <MAGLIETTA>…</MAGLIETTA>
anche se non compare, l’attributo TAGLIA è comunque associato all’elemento MAGLIETTA
ed il suo valore è quello predefinito, cioè “MEDIUM”. In questo caso Explorer 5 mostra il se-
guente output:
<MAGLIETTA TAGLIA="MEDIUM">…</MAGLIETTA>
? Se si tenta di inserire un valore non previsto nell’elenco, si ottiene un errore:
<MAGLIETTA TAGLIA="XL">…</MAGLIETTA> NO!
Infatti “XL” non compare nell’elenco dei possibili valori di TAGLIA.
4.2.1 Riferimenti incrociati
All’interno di un documento XML è possibile effettuare riferimenti incrociati per mezzo degli attri-
buti di tipo ID e IDREF. Nel documento, l’attributo di tipo ID è in grado di dare un identificatore
unico ad un certo elemento, pertanto i valori che esso può assumere sono soggetti alle stesse limita-
zioni dei nomi di elementi e di attributi, descritte nel § 3.3. Ad esempio, supponiamo di dichiarare il
seguente attributo per un elemento SEZIONE:
<!ATTLIST SEZIONE argomento ID #IMPLIED>
e supponiamo che vi siano più istanze dell’elemento SEZIONE nel documento, in tal caso sarà pos-
sibile riferirsi ad uno di questi utilizzando il suo identificatore univoco. Esso è rappresentato dal
valore del suo attributo argomento di tipo ID e deve essere unico all’interno del documento.
Naturalmente un elemento non può avere più di un attributo di tipo ID.
L’impostazione #IMPLIED indica che non tutti gli elementi SEZIONE necessitano di un attributo
di tipo ID. Se avessimo voluto associare ad ogni elemento SEZIONE un identificatore univoco,
avremmo dovuto utilizzare l’impostazione #REQUIRED.
L’assegnazione dell’identificatore all’elemento avviene in questo modo:
<SEZIONE argomento="Caratteristiche_di_XML">…</SEZIONE>
Lo spazio è uno dei caratteri non ammessi per i nomi degli identificatori in XML. Dunque
l’assegnazione:
<SEZIONE argomento="Caratteristiche di XML">…</SEZIONE> NO!
è scorretta.
I riferimenti agli identificatori univoci avvengono per mezzo degli attributi di tipo IDREF. Vedia-
mo la dichiarazione di un attributo di questo tipo, assegnato ad un apposito elemento vuoto
RIFERIMENTO:
<!ATTLIST RIFERIMENTO A IDREF #REQUIRED>
Il riferimento all’interno del documento è dato da:
<RIFERIMENTO A="Caratteristiche_di_XML"/>
Chiaramente, se il valore dell’attributo A di tipo IDREF non è uguale ad alcun identificatore univo-
co, si ottiene un errore.
I riferimenti a ciascuno degli identificatori univoci del documento possono essere un numero qual-
siasi. È compito del foglio di stile gestire i vari riferimenti, utilizzando presumibilmente dei colle-
gamenti ipertestuali.
4.3 Entità
4.3.1 Entità interne
Le entità sono parti del documento XML che fungono da “contenitori”. I loro contenuti possono es-
sere:
? caratteri speciali;
? stringhe di testo;
? frammenti di documento, composti da testo e markup;
? documenti XML situati in file esterni;
? file di testo e binari.
È possibile inserire ciascuno di questi oggetti nel documento tramite un semplice riferimento al no-
me dell’entità che lo contiene.
Le entità vengono definite nella DTD in questo modo [19]:
<!ENTITY Nome Definizione>
e i riferimenti ad esse all’interno del documento seguono la sintassi:
&Nome;
dove Nome è il nome dell’entità.
Nel caso delle entità interne, Definizione è una parte di documento XML racchiusa tra virgo-
lette o apici, e può contenere [1]:
? testo;
? markup;
? riferimenti a caratteri (vedi § 3.6);
? riferimenti ad altre entità, comprese le entità predefinite (vedi § 3.5).
Vediamo due esempi:
? <!DOCTYPE EDITORIALE [
[…]
<!ENTITY IAT "<TITOLO>Insieme a tavola</TITOLO>">
<!ENTITY eacute "é">
<!ENTITY egrave "è">
<!ENTITY agrave "à">
]>
<EDITORIALE>
<par>Care amiche,</par>
<par>realizzare oggi una nuova rivista di cucina potrebbe
sembrare quanto meno fuori luogo.</par>
<par>Perché, allora, pubblicare &IAT;?</par>
<par>La risposta è semplice. &IAT; sarà
monotematico: ogni mese vi proporremo un ingrediente in base
al quale sviluppare una serie di piatti.</par> […]
</EDITORIALE>
Vengono definite quattro entità: eacute, egrave ed agrave, associate rispettivamente ai
caratteri “é”, “è” ed “à” come in HTML, e IAT, associata all’elemento TITOLO. Ad ogni rife-
rimento &IAT; viene inserito all’interno del documento l’intero elemento, completo del conte-
nuto:
<TITOLO>Insieme a tavola</TITOLO>
? <!DOCTYPE ESEMPIO [
[…]
<!ENTITY agrave "à">
<!ENTITY uno "Questa entità usa &due;, comprese le
"predefinite"!">
<!ENTITY due "<enfatizzato>altre entità</enfatizzato>">
]>
[…]
<ESEMPIO>&uno;</ESEMPIO>
Il risultato di questo esempio, visualizzato per mezzo di un opportuno foglio di stile, è un fram-
mento di documento XML, composto di testo e markup:
<ESEMPIO>Questa entità usa
<enfatizzato>altre entità</enfatizzato>
, comprese le "predefinite"!</ESEMPIO>
si può notare che:
1) l’elemento ESEMPIO nel documento fa riferimento all’entità uno;
2) l’entità uno fa riferimento alle entità due, agrave e all’entità predefinita quot;
3) l’entità due fa riferimento all’entità agrave.
Qualsiasi elemento eventualmente contenuto in un’entità dev’essere completo. In caso contrario il
documento non è ben formato. Non è possibile iniziare un elemento in un’entità e finirlo in un’altra:
<!DOCTYPE ESEMPIO [
[…]
<!ENTITY inizio "<TITOLO>Questo esempio "> NO!
<!ENTITY fine "risulta sbagliato.</TITOLO>">
]>
<ESEMPIO>&inizio;&fine;</ESEMPIO>
Lo stesso vale per gli altri tipi di markup: istruzioni di elaborazione, commenti, ecc.
Naturalmente il documento è valido solo se risulta conforme alla sua DTD una volta sostituiti i
contenuti delle entità interne ai riferimenti.
4.3.2 Entità esterne
Il linguaggio XML consente di utilizzare file esterni in formato XML o in altri formati per mezzo
delle entità esterne. La sintassi della dichiarazione di un’entità esterna è analoga a quella della di-
chiarazione di una DTD esterna (vedi § 3.4.2). Vediamo un esempio [19]:
<!ENTITY dipartimento SYSTEM "dipartimentobf.xml">
se il file esterno ha un identificatore pubblico, la descrizione dell’entità è composta dalla parola
chiave PUBLIC, dall’identificatore pubblico e da un identificatore di sistema da utilizzare nel caso
l’identificatore pubblico non sia riconosciuto [6]:
<!ENTITY open-hatch
PUBLIC "-//Textuality//TEXT Standard open-hatch boilerplate//EN"
"http://www.textuality.com/boilerplate/OpenHatch.xml">
Se l’entità esterna è un file XML, o un file di testo che può far parte del documento XML senza
causare errori, essa è detta analizzata e viene riferita con la stessa sintassi delle entità interne
(&Nome;). Le entità esterne analizzate consentono di raggruppare vari file in un unico documento
XML, come in questo esempio:
<!DOCTYPE TESTO [
<!ELEMENT TESTO (CAPITOLO)+>
<!ELEMENT CAPITOLO (#PCDATA)>
<!ENTITY CAP1 SYSTEM "Capitolo1.xml">
<!ENTITY CAP2 SYSTEM "Capitolo2.xml">
<!ENTITY CAP3 SYSTEM "Capitolo3.xml">
]>
<TESTO>&CAP1; &CAP2; &CAP3;</TESTO>
All’interno del documento vengono sostituiti i tre riferimenti con i contenuti dei file corrispondenti.
Mostriamo la visualizzazione di Explorer 5:
<!DOCTYPE TESTO (View Source for full doctype...)>
<TESTO>
<CAPITOLO>Iniziamo con il capitolo 1.</CAPITOLO>
<CAPITOLO>Proseguiamo con il capitolo 2.</CAPITOLO>
<CAPITOLO>Terminiamo il testo con il capitolo 3.</CAPITOLO>
</TESTO>
Per usare le entità (escluse quelle predefinite) dev’essere presente la DTD, che serve a definirle.
Pertanto, affinché il documento sia valido, le entità esterne analizzate devono:
? essere file privi di una loro DTD, poiché non è ammessa più di una dichiarazione di tipo di do-
cumento (DOCTYPE);
? rispettare la DTD del documento che le richiama.
A questo tipo di entità si contrappongono le entità esterne non analizzate. Queste ultime servono ad
inserire all’interno di un documento XML immagini, suoni, filmati o altri oggetti multimediali [1].
Si può far riferimento a queste entità per mezzo degli attributi di tipo ENTITY o ENTITIES, in-
sieme ad una dichiarazione di annotazione, come vedremo nel § 4.4.
4.3.3 Entità parametro
Le entità interne ed esterne vengono chiamate entità generali, poiché esse sono definite nella DTD
e richiamate all’interno del documento. Oltre a queste esistono anche le entità parametro, che ven-
gono definite e richiamate all’interno della DTD.
La sintassi della dichiarazione di un’entità parametro è la seguente:
<!ENTITY % Nome Definizione>
e il riferimento ad essa avviene in questo modo:
%Nome;
All’interno della dichiarazione il simbolo “%” e il nome dell’entità vanno separati da uno spazio,
mentre nel riferimento essi devono essere uniti. Il significato di Definizione è identico a quello
delle entità generali.
L’entità parametro non può essere una stringa qualsiasi, ma deve contenere almeno una dichiarazio-
ne completa di un elemento o di un attributo, ecc. Vediamo un esempio:
<!DOCTYPE TESTO [
<!ENTITY % parte1 SYSTEM “dichiarazioni1.ent”>
<!ENTITY % parte2 SYSTEM “dichiarazioni2.ent”>
%parte1; %parte2;
]>
[…]
Le entità parametro esterne, presenti in quest’esempio, permettono di avere parti della DTD in di-
versi file esterni. Si supera così il limite della DOCTYPE, che consente di dichiarare un unico file
come sottoinsieme esterno della DTD (vedi § 3.4.2).
4.4 Annotazioni
L’annotazione è un nome che la DTD assegna ad un certo tipo di file binari. Nella sua dichiarazione
c’è un’indicazione per l’elaboratore XML su come operare con tali file [19]. Le dichiarazioni delle
varie annotazioni si trovano nella DTD e seguono la sintassi:
<!NOTATION Annotazione Descrizione>
Per incorporare in un documento XML un’entità esterna non analizzata, occorre associarla ad
un’annotazione, utilizzando la parola chiave NDATA come in questo esempio:
<!ENTITY sfondo SYSTEM "palloncini.jpg" NDATA IMMAGINI>
IMMAGINI è il nome dell’annotazione, che deve essere a sua volta dichiarata nella DTD. Una
possibile dichiarazione di annotazione per l’esempio precedente è:
<!NOTATION IMMAGINI SYSTEM "Iexplore.exe">
la quale indica al software che sta elaborando il documento XML di utilizzare il programma
“Iexplore.exe” (Internet Explorer) per gestire i file di tipo IMMAGINI.
Una volta dichiarate, sia le entità esterne che le annotazioni possono comparire nel documento
XML come valori di particolari attributi. Ad esempio, possiamo associare ad un elemento
ESEMPIO l’entità esterna non analizzata sfondo in questo modo:
<!ATTLIST ESEMPIO FILE ENTITY #REQUIRED>
[…]
<ESEMPIO FILE="sfondo">…</ESEMPIO>
Questo non significa che il documento XML avrà come sfondo il file associato all’entità esterna
sfondo. Le annotazioni, infatti, si limitano a fornire informazioni all’elaboratore del documento,
che ha il compito di stabilire come l’entità esterna debba essere effettivamente utilizzata, in base:
? alle caratteristiche del sistema di calcolo;
? alla disponibilità del programma indicato nell’annotazione;
? alle indicazioni del foglio di stile.
4.5 Creazione della DTD per un documento XML ben formato
Nel § 3.9 abbiamo visto un esempio di conversione di un documento HTML in un documento XML
ben formato. Occupiamoci ora di scrivere una DTD compatibile con tale documento, al fine di ren-
derlo valido. Analizzando il codice del documento, si nota che esso rispetta questo schema:
? L’elemento radice è DOCENTI. Esso contiene sei elementi PERSONA.
? Ciascun elemento PERSONA contiene, nell’ordine:
1) un elemento NOME;
2) un elemento TITOLO facoltativo;
3) un elemento GRUPPO;
4) un elemento PUBBLICAZIONI;
5) un elemento CURRICULUM.
Questi elementi contengono esclusivamente testo, ad eccezione di PUBBLICAZIONI.
? L’elemento PUBBLICAZIONI contiene uno o più elementi PUBBLICAZIONE, che a loro
volta hanno stringhe di testo come contenuto.
Infine è opportuno definire un’entità per il carattere “è”, che viene utilizzato più volte all’interno del
documento. Per comodità chiameremo egrave questa entità, come in HTML.
La DTD che esplicita queste regole è la seguente:
<!ELEMENT DOCENTI (PERSONA*)>
<!ELEMENT PERSONA (NOME,GRUPPO,TITOLO?,PUBBLICAZIONI,CURRICULUM)>
<!ELEMENT NOME (#PCDATA)>
<!ELEMENT GRUPPO (#PCDATA)>
<!ELEMENT TITOLO (#PCDATA)>
<!ELEMENT PUBBLICAZIONI (PUBBLICAZIONE+)>
<!ELEMENT PUBBLICAZIONE (#PCDATA)>
<!ELEMENT CURRICULUM (#PCDATA)>
<!ENTITY egrave "è" >
Supponiamo di scrivere questa DTD in un file chiamato “dipartimento.dtd”. Per associarla al
documento, occorre aggiungere questa riga al prologo:
<!DOCTYPE DOCENTI SYSTEM "dipartimento.dtd">
inoltre nel documento XML occorre sostituire i riferimenti al carattere “è” (è) con i riferi-
menti all’entità egrave (è). Abbiamo così ottenuto un documento XML valido.
Il documento resta valido se effettuiamo modifiche conformi alla DTD. Ad esempio, possiamo ag-
giungere un nuovo elemento PERSONA all’interno dell’elemento DOCENTI:
<PERSONA>
<NOME>Antonio Vivaldi</NOME>
<GRUPPO>Sistemi operativi</GRUPPO>
<PUBBLICAZIONI>
<PUBBLICAZIONE>Confronto tra Linux e Windows NT(1998)
</PUBBLICAZIONE>
</PUBBLICAZIONI>
<CURRICULUM>Nato nel 1972 e laureato nel 1998. Collabora con
il Prof. Grieg nel corso di Algoritmi per il controllo dei
segnali.</CURRICULUM>
</PERSONA>
ma l'elemento deve contenere quanto precisato nella DTD. Se, ad esempio il Dott. Vivaldi apparte-
nesse a due gruppi di ricerca:
<PERSONA>
<NOME>Antonio Vivaldi</NOME>
<GRUPPO>Sistemi operativi</GRUPPO> NO!
<GRUPPO>Reti Neurali</GRUPPO>
[...]
</PERSONA>
il documento non sarebbe più valido. Occorrerebbe la seguente modifica alla DTD, che consente di
avere più di un elemento GRUPPO all'interno di PERSONA:
<!ELEMENT PERSONA (NOME,GRUPPO+,TITOLO?,PUBBLICAZIONI,CURRICULUM)>
È chiaro che elencare tutti gli elementi e gli attributi e analizzarne il contenuto, al fine di scrivere
una DTD compatibile, può diventare un lavoro lungo e difficile per documenti di grandi dimensioni.
Una buona idea è quella di partire da DTD molto “larghe”, per poi renderle più ristrette ed aderenti
al documento. Per il nostro esempio, è giusta anche la definizione:
<!ELEMENT PERSONA (NOME|GRUPPO|TITOLO|PUBBLICAZIONI|CURRICULUM)*>
secondo cui PERSONA può contenere un numero qualsiasi (eventualmente nessuno) di elementi
NOME, GRUPPO, ecc. in un qualsiasi ordine. La semantica di questa definizione è molto povera, pe-
rò è un buon punto di partenza per evitare errori ed ottenere in seguito una DTD più aderente al do-
cumento.
4.6 Spazi dei nomi
Il linguaggio XML consente di assegnare nomi personalizzati ad elementi, attributi, entità, ecc. col
vantaggio di una grande flessibiltà, ma con il rischio di generare confusione, utilizzando in diversi
documenti di una stessa organizzazione elementi con lo stesso nome e significati diversi.
La soluzione a questo problema è offerta dagli spazi dei nomi XML, che sono “raccolte” di nomi
identificate univocamente da un URI (Uniform Resorce Identifier). In XML un URI può essere:
? un URL (Uniform Resource Locator), che è un usuale “indirizzo Internet” ;
? un URN (Uniform Resource Name), che è un particolare identificatore associato a ciascuna ri-
sorsa in Internet, già discusso nel § 2.6.2.
La dichiarazione standard per uno spazio dei nomi segue la sintassi [23]:
<ELEMENTO xmlns=”URI”>…</ELEMENTO>
In questo caso tutti gli elementi e gli attributi di ELEMENTO devono appartenere allo spazio dei
nomi identificato da URI. Se ELEMENTO è la radice del documento, tutto il documento apparterrà
allo spazio dei nomi specificato. L’attributo xmlns è una parola chiave di XML e può essere usato
solo per dichiarare gli spazi dei nomi.
Vediamo un esempio [24]:
<Schema xmlns="urn:schemas-microsoft-com:xml-data">
<ElementType name="rate" content="textOnly"/>
[…]
</Schema>
In questo caso l’elemento Schema e tutti gli elementi ed attributi al suo interno appartengono allo
spazio dei nomi urn:schemas-microsoft-com:xml-data, relativo a XML-Data,
un’applicazione XML che tratteremo nel prossimo paragrafo.
Se il software che elabora il documento XML è in grado di:
? riconoscere gli spazi dei nomi dichiarati nel documento stesso;
? verificare l’effettiva appartenenza di elementi ed attributi agli spazi dei nomi dichiarati;
allora la DTD diventa superflua, poiché le regole che il documento XML deve seguire sono già de-
finite negli spazi dei nomi.
Gli spazi dei nomi possono essere dichiarati anche per mezzo di una dichiarazione esplicita, la cui
sintassi è [23]:
<ELEMENTO xmlns:prefisso=”URI”>…</ELEMENTO>
In questo modo vengono dichiarati appartenenti allo spazio dei nomi identificato da URI solo gli
elementi e gli attributi interni ad ELEMENTO il cui nome inizia con la stringa “prefisso:”, che
funge da identificatore dello spazio dei nomi. Questo tipo di dichiarazione è particolarmente utile se
si desidera far riferimento a più spazi dei nomi nello stesso documento.
Vediamo un esempio in cui viene considerato HTML come spazio dei nomi di XML:
<esempio xmlns:HTML="http://www.w3.org/TR/REC-html40">
<titolo>HTML all’interno di XML</titolo>
<logo>
<HTML:A href="javascript:alert('HTML come spazio dei nomi di XML')">
<HTML:IMG src="palloncini.gif" height="50" width="200" />
</HTML:A>
</logo>
</esempio>
Solo gli elementi il cui nome è preceduto dalla stringa “HTML:” appartengono allo spazio dei nomi
HTML. Utilizzare i tag di HTML in un documento XML può rivelarsi utile per incorporare nel do-
cumento elementi di formattazione di HTML, che il foglio di stile potrà lasciare inalterati o affinare
ulteriormente. Chiaramente questo è possibile solo se il software supporta anche il linguaggio
HTML. Nel nostro esempio HTML è usato per gestire un file grafico ed un brevissimo script, in
maniera sicuramente più pratica rispetto all’utilizzo delle entità esterne (si noti che non serve la
DTD). È importante che il codice HTML inserito rispetti i vincoli sintattici di XML descritti nel
§ 3.2.2.
4.7 Un’alternativa alla DTD: lo schema XML-Data
4.7.1 Difetti della DTD
La DTD rappresenta la struttura del documento XML e descrive le regole osservate dai dati conte-
nuti in esso [19]. Tuttavia essa presenta alcuni difetti:
1) la sua sintassi deriva da SGML ed è piuttosto complicata;
2) non prevede tipi di dati diversi dalle stringhe, come dati numerici, booleani, ecc.;
3) non si adatta all’interscambio con i formati di dati più recenti, poiché quando fu ideato SGML
tali formati non esistevano;
4) ammette come unico strumento di semplificazione le entità paramentro, poco flessibili e difficili
da gestire.
Per questo motivo alcune importanti organizzazioni, tra le quali Microsoft, Data Channel e Univer-
sità di Edimburgo, hanno ideato XML-Data, un’applicazione di XML che ha le stesse funzioni di
base della DTD, ma supera i suoi limiti.
4.7.2 Uso dello schema
In XML-Data, la DTD viene sostituita dallo schema, che è a sua volta un documento XML ben
formato, con la seguente struttura [24]:
<?xml version=”1.0” ?>
<Schema xmlns="urn:schemas-microsoft-com:xml-data">
[Dichiarazioni di elementi e attributi]
</Schema>
Supponiamo che questo schema sia il contenuto del file “schema.xml”. Per associare un docu-
mento XML ad esso si usa la seguente dichiarazione [23]:
<PROVA xmlns="x-schema:schema.xml">...</PROVA>
In questo modo l’elemento PROVA e tutto il suo contenuto devono rispettare lo schema del file
“schema.xml”. Non è indispensabile che l’elemento PROVA sia la radice del documento, visto
che si utilizza una dichiarazione di appartenza ad uno spazio di nomi, che può trovarsi in qualsiasi
parte del documento. Inoltre, utilizzando una dichiarazione esplicita come questa:
<PROVA sch:xmlns="x-schema:schema2.xml">...</PROVA>
sono solo gli elementi:
? figli di PROVA;
? il cui nome contiene il prefisso “sch:”
a dover rispettare lo schema del file “schema2.xml”. È evidente che un documento XML può far
riferimento ad un numero qualsiasi di schemi, ciascuno dei quali stabilirà le regole per una certa
parte del documento stesso.
4.7.3 Dichiarazione degli elementi
Gli elementi vengono dichiarati nello schema con la sintassi:
<ElementType name=”NOME” content=”contenuto”>…</ElementType>
dove:
? NOME è il nome dell’elemento dichiarato;
? contenuto può assumere i seguenti valori:
? “empty” se l’elemento è vuoto,
? “textOnly” se l’elemento deve contenere solo testo,
? “eltOnly” se l’elemento deve contenere solo sottoelementi,
? “mixed” se l’elemento può contenere sia testo che sottoelementi.
Se contenuto vale “eltOnly” o “mixed”, NOME deve avere degli elementi figli, i quali ven-
gono specificati come contenuto di ElementType utilizzando la sintassi:
<element type=”nome_figlio”/>
dove nome_figlio è il nome di un elemento dichiarato altrove nello schema, che diventa figlio
dell’elemento NOME. Oltre all’attributo type possono comparire i seguenti attributi opzionali:
? minOccurs, che indica il numero minimo di elementi nome_figlio all’interno di NOME;
? maxOccurs, che indica il numero massimo di elementi nome_figlio all’interno di NOME.
Entrambi possono assumere come valore un qualsiasi numero intero, oppure il simbolo “*”, che ha
il significato di “numero qualsiasi”. Se questi attributi non sono specificati assumono entrambi il
valore di default “1”.
Questa trattazione non esaurisce le possibili dichiarazioni di elementi previste da XML-Data, per le
quali si rimanda a [19], ma è sufficiente a realizzare lo schema per il documento XML ben formato
del § 3.9:
<?xml version="1.0"?>
<Schema xmlns="urn:schemas-microsoft-com:xml-data">
<ElementType name="DOCENTI" content="eltOnly">
<element type="PERSONA" maxOccurs="*"/>
</ElementType>
<ElementType name="PERSONA" content="eltOnly">
<element type="NOME"/>
<element type="GRUPPO"/>
<element type="TITOLO" minOccurs="0"/>
<element type="PUBBLICAZIONI"/>
<element type="CURRICULUM"/>
</ElementType>
<ElementType name="NOME" content="textOnly"/>
<ElementType name="TITOLO" content="textOnly"/>
<ElementType name="GRUPPO" content="textOnly"/>
<ElementType name="CURRICULUM" content="textOnly"/>
<ElementType name="PUBBLICAZIONI" content="eltOnly">
<element type="PUBBLICAZIONE" maxOccurs="*"/>
</ElementType>
<ElementType name="PUBBLICAZIONE" content="textOnly"/>
</Schema>
Questo schema sostituisce totalmente la DTD del § 4.5, ad eccezione della dichiarazione dell’entità
per il carattere “è”, in quanto XML-Data non supporta le entità.
Se lo schema viene salvato nel file “schema_dipartimento.xml”, l’unica modifica necessa-
ria al documento è la sostituzione del tag di apertura dell’elemento radice <DOCENTI> con:
<DOCENTI xmlns="x-schema:schema_dipartimento.xml">
Pur essendo conforme allo schema, il documento non risulta valido, poiché secondo le specifiche di
XML 1.0, un documento è valido solo se rispetta una DTD.
4.7.4 Dichiarazione degli attributi
La dichiarazione degli attributi è analoga a quella degli elementi. Segue la sintassi:
<AttributeType name=”ATTRIBUTO”/>
dove ATTRIBUTO è il nome dell’attributo. Diversamente dalla DTD, gli attributi vengono dichia-
rati indipendentemente dagli elementi. L’assegnazione di un attributo ad un elemento avviene in
questo modo:
<ElementType name=”NOME” content=”contenuto”>
<attribute type=”ATTRIBUTO”/>
[Eventuali riferimenti ad altri attributi ed elementi]
</ElementType>
Così abbiamo assegnato ATTRIBUTO all’elemento NOME.
Sia AttributeType che attribute possono avere i seguenti attributi:
? default, che è il valore assegnato all’attributo se questo non compare nel documento;
? required, che vale “yes” se l’attributo è obbligatorio.
Vediamo attraverso alcuni esempi la differenza fra le due possibili collocazioni di questi attributi.
Se abbiamo:
<AttributeType name=”EMAIL” required=”yes”/>
L’attributo EMAIL è obbligatorio per tutti gli elementi del documento che lo prevedono. Viceversa,
se required compare in attribute, anziché in AttributeType:
<ElementType name=”PERSONA” content=”textOnly”>
<attribute type=”EMAIL” required=”yes”/>
</ElementType>
l’attributo EMAIL è obbligatorio solo per l’elemento PERSONA.
Altre caratteristiche degli attributi possono essere definite utilizzando lo spazio dei nomi datatypes,
che tratteremo nel capitolo 6, insieme a XML-Data.
4.8 Conclusioni
Per descrivere la struttura di un documento XML è meglio utilizzare la DTD o lo schema di XML-
Data? La risposta non è scontata. Gli schemi sono più potenti e flessibili delle DTD, ma non sono
ancora uno standard approvato dal W3C, a differenza delle DTD, che sono parte integrante della
specifica di XML 1.0. D’altra parte, XML-Data è un’applicazione ideata dalla Microsoft e suppor-
tata dal suo browser Explorer 5, quindi la sua diffusione potrebbe spingere il W3C verso una rapida
approvazione, come è già accaduto in passato con le estensioni di HTML.
Pertanto, se si prevede di utilizzare software della Microsoft o di altre aziende in grado di supporta-
re XML-Data, è sicuramente preferibile ricorrere agli schemi, mentre in caso contrario è meglio af-
fidarsi alle “tradizionali” DTD, riconosciute da tutti i software in grado di elaborare XML.
5 EXTENSIBLE STYLESHEET LANGUAGE (XSL)
5.1 Associazione di tag HTML agli elementi XML
XSL è un’applicazione XML che può essere usata per manipolare, ordinare e filtrare i dati di un do-
cumento XML [25]. I risultati di queste trasformazioni possono essere:
1) documenti HTML visualizzabili da un browser;
2) nuovi documenti XML.
Affinché un documento XML abbia una visualizzazione analoga a quella di HTML, XSL consente
di utilizzare tutti i tag di HTML 4.0, seguendo però anche per essi le restrizioni sintattiche di XML
esposte nel § 3.2.2.
Vediamo un semplicissimo esempio di foglio di stile XSL [19]:
<?xml version="1.0" ?>
<xsl:template xmlns:xsl="http://www.w3.org/TR/WD-xsl">
<H1><xsl:value-of select="DOCENTI/PERSONA/NOME"/></H1>
<H2><xsl:value-of select="DOCENTI/PERSONA/TITOLO"/></H2>
</xsl:template>
in esso compaiono due elementi XSL [36]:
1) xsl:template, che definisce un modello per l’output di una parte del documento;
2) xsl:value-of, che inserisce il valore della parte di documento selezionata dall’attributo
select nell’output sottoforma di testo.
Nel tag di apertura di xsl:template viene dichiarato lo spazio dei nomi di XSL. È indispensa-
bile la dichiarazione esplicita, poiché nei documenti XSL si assume HTML come spazio dei nomi
predefinito. Questa scelta permette di inserire i tag di HTML senza alcun prefisso, così come ab-
biamo fatto con <H1> ed <H2>.
All’interno dell’elemento H1 di HTML viene inserito il valore definito dal pattern di selezione
DOCENTI/PERSONA/NOME. Analogamente, in <H2> viene inserito il valore identificato dal pat-
tern DOCENTI/PERSONA/TITOLO. Il significato dei pattern è identico a quello dei percorsi
(path) nelle directory di un disco: basta considerare l’albero costituito dal documento XML al posto
dell’albero delle directory. Pertanto DOCENTI/PERSONA è il sottoelemento PERSONA
dell’elemento DOCENTI.
In sostanza, il foglio di stile effettua le seguenti associazioni fra elementi XML individuati dai pro-
pri pattern e tag di HTML:
Il contenuto dell’elemento…
viene assegnato al tag…
DOCENTI/PERSONA/NOME
?
H1
DOCENTI/PERSONA/TITOLO
?
H2
Se nell’albero esistono elementi con lo stesso nome e lo stesso percorso, viene selezionato il primo
in ordine di apparizione nel documento. È il caso del nostro esempio illustrato nel § 3.9, in cui
l’elemento DOCENTI ha sei sottoelementi PERSONA. Il pattern DOCENTI/PERSONA seleziona il
primo elemento PERSONA, cioè quello relativo al prof. Gianni Brahms, dal quale vengono estratti i
valori dei due sottoelementi NOME e TITOLO.
Salvando il nostro foglio di stile con il nome di “dipartimento.xsl” e aggiungendo al docu-
mento XML del § 3.9, preferibilmente dopo il prologo e prima dell’elemento radice, l’istruzione di
elaborazione:
<?xml-stylesheet type="text/xsl" href="dipartimento.xsl"?>
si ottiene il seguente output:
che è lo stesso di questo documento HTML:
<H1>Gianni Brahms</H1>
<H2>Professore Ordinario</H2>
Un foglio di stile XSL può essere usato da un numero qualsiasi di documenti, per questo motivo al
suo interno non si trovano riferimenti ai file XML che esso deve trasformare.
5.2 Visualizzazione di più elementi con lo stesso nome
Per assegnare un tag HTML a tutti gli elementi XML corrispondenti ad un determinato pattern, oc-
corre utilizzare l’elemento xsl:for-each [19]. Anche esso è dotato di un attributo select, il
cui valore deve essere uguale al pattern ripetuto, che nel nostro caso è DOCENTI/PERSONA. A tal
proposito applichiamo quest’altro foglio di stile al nostro documento:
<?xml version="1.0" ?>
<xsl:template xmlns:xsl="http://www.w3.org/TR/WD-xsl">
<xsl:for-each select="DOCENTI/PERSONA">
<B><FONT SIZE="5">
<xsl:value-of select="NOME"/>
</FONT><FONT SIZE="4">
(<xsl:value-of select="GRUPPO"/>)
</FONT></B><P></P>
</xsl:for-each>
</xsl:template>
L’output che si ottiene è:
Gianni Brahms (Intelligenza Artificiale)
Ermanno Grieg (Reti Neurali)
Federico Mendelzon (Visione delle macchine)
Riccardo Strauss (Basi di Dati)
Giuseppe Verdi (Basi di Dati)
Sebastiano Bach (Ricerca Operativa)
Il valore dell’attributo select del primo elemento xsl:value-of è semplicemente “NOME”,
anziché l’intero pattern. Questo perché xsl:for-each ha spostato il contesto di applicazione
degli elementi XSL dalla radice (DOCENTI) agli elementi PERSONA, ciascuno dei quali ha NOME
come figlio. Scrivere “DOCENTI/PERSONA/NOME” al posto di “NOME” avrebbe fatto scomparire
tutti i nomi dei docenti, poiché il foglio di stile sarebbe andato a cercare gli elementi DOCENTI/
PERSONA/DOCENTI/PERSONA/NOME, che non esistono. Pertanto, ogni volta che si utilizza un
elemento XSL, occorre prestare attenzione al contesto di applicazione.
Si noti, infine, che le parentesi che racchiudono i valori di GRUPPO sono scritte esplicitamente nel
foglio di stile.
5.3 Visualizzazione dei valori degli attributi
Se vogliamo visualizzare il valore di un attributo associato ad un elemento, dobbiamo utilizzare
l’operatore “@” all’interno del pattern, in questo modo [25]:
<xsl:value-of select=”PATTERN/@ATTRIBUTO”/>
dove PATTERN è il percorso associato all’elemento ed ATTRIBUTO è il nome dell’attributo.
Consideriamo, ad esempio, questo breve documento XML:
<?xml version="1.0" ?>
<?xml-stylesheet type="text/xsl" href="studenti.xsl"?>
<STUDENTI>
<STUDENTE Matricola="200768">Verdi Fabio</STUDENTE>
<STUDENTE Matricola="937653">Rossi Luca</STUDENTE>
<STUDENTE Matricola="485745">Neri Anna</STUDENTE>
</STUDENTI>
Il foglio di stile per visualizzare sia i nomi che le matricole degli studenti è il seguente:
<?xml version="1.0" ?>
<xsl:template xmlns:xsl="http://www.w3.org/TR/WD-xsl">
<xsl:for-each select="STUDENTI/STUDENTE">
<DIV>Studente: <B><xsl:value-of/></B></DIV>
Matricola: <B><xsl:value-of select="@Matricola"/></B>
<P></P>
</xsl:for-each>
</xsl:template>
da cui si ottiene il seguente output:
Studente: Verdi Fabio
Matricola: 200768
Studente: Rossi Luca
Matricola: 937653
Studente: Neri Anna
Matricola: 485745
Si noti come l’elemento xsl:for-each sposti il contesto dalla radice ai tre elementi
STUDENTE, che contengono le informazioni da visualizzare. In questo caso il pattern da inserire
negli elementi xsl:value-of è nullo e pertanto:
? nell’elemento xsl:value-of relativo a STUDENTE bisogna eliminare l’attributo select;
? nell’elemento xsl:value-of relativo all’attributo Matricola, il pattern è semplicemente
“@Matricola”, che individua l’attributo Matricola dell’elemento corrispondente al conte-
sto corrente.
5.4 Fogli di stile contenenti più modelli
Il linguaggio XSL può definire diversi modelli di rappresentazione da applicare indipendentemente
alle diverse sezioni del documento XML [19]. In questo caso, ciascun modello è contenuto
all’interno di un elemento xsl:template e l’elemento radice del documento XSL diventa
xsl:stylesheet, nel quale viene dichiarato lo spazio dei nomi XSL.
La parte del documento alla quale applicare il modello definito all’interno di xsl:template è
identificata da un pattern di uguaglianza, che è il valore dell’attributo match [26].
Il modello da applicare a tutto documento deve avere come pattern di uguaglianza il simbolo “/”,
che rappresenta l’intero documento ed ha come “figlio” l’elemento radice del documento. Ciò signi-
fica che, se DOCENTI è la radice del documento, i due pattern “/DOCENTI” e “DOCENTI” sono
equivalenti.
Gli altri modelli vengono richiamati attraverso l’elemento xsl:apply-templates, ma vengo-
no applicati solo se viene trovato il loro pattern di uguaglianza a partire dal contesto corrente.
L’elemento xsl:apply-templates può trovarsi all’interno di qualsiasi modello.
Questo meccanismo è più difficile da descrivere che da applicare. Vediamo quindi un foglio di stile
con più modelli per il documento del § 3.9:
<?xml version="1.0" ?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/TR/WD-xsl">
<xsl:template match="/">
<xsl:apply-templates/>
</xsl:template>
<xsl:template match="DOCENTI">
<xsl:for-each select="PERSONA">
<TABLE BORDER="2"><TR><TD></TD><TD><B>
<xsl:value-of select="NOME"/>
<SMALL><I><xsl:value-of select="TITOLO"/>
</I></SMALL></B></TD></TR>
<xsl:apply-templates/></TABLE><P></P>
</xsl:for-each>
</xsl:template>
<xsl:template match="GRUPPO">
<TR><TD>Gruppo di ricerca:</TD>
<TD><xsl:value-of/></TD></TR>
</xsl:template>
<xsl:template match="CURRICULUM">
<TR><TD>Curriculum vitae:</TD>
<TD><xsl:value-of/></TD></TR>
</xsl:template>
<xsl:template match="PUBBLICAZIONI">
<TR><TD>Pubblicazioni:</TD>
<TD><xsl:for-each select="PUBBLICAZIONE">
<DIV><xsl:value-of/></DIV>
</xsl:for-each></TD></TR>
</xsl:template>
</xsl:stylesheet>
I modelli presenti in questo documento sono cinque:
? il primo è applicato all’intero documento e si limita a richiamare gli altri modelli;
? il secondo è applicato all’elemento radice DOCENTI e si occupa di:
? visualizzare il contenuto degli elementi NOME e TITOLO,
? richiamare gli altri modelli;
? gli altri tre modelli visualizzano il contenuto, rispettivamente, degli elementi GRUPPO,
CURRICULUM e PUBBLICAZIONI.
L’output che si ottiene è il seguente:
Si noti che il contenuto dell’elemento CURRICULUM viene visualizzato dopo quello dell’elemento
PUBBLICAZIONI, nonostante l’ordine dei modelli nel foglio di stile. Questo perché l’elemento
xsl:apply-templates segue l’ordine del documento XML quando confronta i nomi dei pat-
tern incontrati con il valore del suo attributo match. Nel documento, infatti, compaiono prima
l’elemento PUBBLICAZIONI e poi l’elemento CURRICULUM (vedi § 3.9).
Comunque è possibile scegliere quale modello applicare aggiungendo l’attributo select, già visto
per xsl:for-each, all’elemento xsl:apply-templates. Per far comparire il curriculum
prima delle pubblicazioni, basta sostituire questi tre elementi:
<xsl:apply-templates select="GRUPPO"/>
<xsl:apply-templates select="CURRICULUM"/>
<xsl:apply-templates select="PUBBLICAZIONI"/>
all’unico xsl:apply-templates del modello associato a DOCENTI.
5.5 Visualizzazione dei nomi di elementi ed attributi. Carattere
jolly
XSL ci consente di visualizzare qualsiasi parte del documento XML, utilizzando un linguaggio di
script ed il modello ad oggetti DOM (Document Object Model) [47]. Il DOM è un’interfaccia indi-
pendente da piattaforme e linguaggi che permette a programmi e script di accedere dinamicamente
ai documenti HTML ed XML ed aggiornarne il contenuto, la struttura e lo stile. Non entriamo nei
dettagli di questo modello, ma ci limitiamo ad introdurre la proprietà nodeName, che restituisce il
nome dell’elemento o dell’attributo corrispondente al contesto corrente. È chiamata così perché il
DOM considera elementi, attributi, entità, commenti, ecc. come nodi dell’albero associato al docu-
mento XML.
Per supportare gli script, la Microsoft ha introdotto due elementi aggiuntivi ad XSL [36]. Essi sono
[19]:
? xsl:script: contiene gli script che verranno richiamati all’interno del foglio di stile.
? xsl:eval: valuta lo script al suo interno.
Fatte queste premesse, consideriamo il seguente foglio di stile, da abbinare al documento del § 3.9:
<?xml version="1.0" ?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/TR/WD-xsl">
<xsl:template match="/">
<TABLE BORDER="3"><xsl:apply-templates/></TABLE>
</xsl:template>
<xsl:template match="*">
<TR><TH><xsl:eval>nodeName;</xsl:eval></TH></TR>
<xsl:for-each select="PERSONA">
<TR><TD><xsl:value-of select="*"/>
<SMALL><I>
<xsl:value-of select="TITOLO"/>
</I></SMALL></TD></TR>
</xsl:for-each>
</xsl:template>
</xsl:stylesheet>
Il titolo della tabella, contenuto all’interno del tag <TH> di HTML, è posto uguale al nome
dell’elemento radice, identificato con il carattere jolly “*”, anziché con il suo nome. Torneremo sul
carattere jolly e sugli operatori consentiti all’interno dei pattern nel § 6.3. L’output che si ottiene è:
Il carattere jolly “*” rappresenta il primo sottoelemento disponibile, qualsiasi nome abbia. Chiara-
mente, il primo sottoelemento di “/”, che rappresenta l’intero documento XML, è proprio
l’elemento radice DOCENTI. Inoltre abbiamo usato il carattere jolly anche al posto di NOME, che è
il primo sottoelemento di PERSONA.
N.B. In Explorer 5, lo stesso risultato di:
<xsl:eval>nodeName;</xsl:eval>
si può ottenere con l’elemento [19]:
<xsl:node-name/>
Tuttavia, anche questo elemento è un’aggiunta della Microsoft e non compare nella bozza di lavoro
del W3C [26]. Stranamente, tale elemento non viene citato nemmeno nella guida di XSL della Mi-
crosoft, sebbene utilizzato in alcuni esempi all’interno di questa [36].
5.6 Costruzione di un foglio di stile
Pur avendo esaminato solo una parte degli elementi di XSL, abbiamo già gli strumenti necessari per
introdurre i dati di un documento XML in una “pagina Web”. Possiamo così concludere il lavoro
sul documento XML introdotto nel § 3.9, fornendo ad esso un foglio di stile XSL che lo visualizzi
in maniera simile al documento HTML dal quale lo avevamo convertito.
È importante reinserire nel foglio di stile tutti quelle parti del documento HTML che avevamo sop-
presso nella conversione all’XML. In questo modo viene realizzata una delle caratteristiche più im-
portanti di XML, cioè la separazione fra:
? i dati del documento, descritti formalmente dalla DTD e dalla struttura ad albero imposta da
XML;
? la presentazione del documento, costituita da un foglio di stile XSL formato da elementi che
stabiliscono le relazioni con il documento XML e tag di HTML. Nel foglio di stile devono com-
parire anche quelle parti di testo che rendono più leggibili i dati, ma che non fanno parte di essi.
Ecco un foglio di stile per il “nostro” documento XML che si avvicina al documento HTML dal
quale eravamo partiti:
<?xml version="1.0" ?>
<HTML xmlns:xsl="http://www.w3.org/TR/WD-xsl">
<HEAD><TITLE>
Università di QualchePosto - Docenti del dipartimento di Informatica
Università degli studi di QualchePosto
Dipartimento di Informatica
Elenco dei docenti
:
Gruppo di ricerca:
Curriculum vitae:
Elenco pubblicazioni:
La visualizzazione che si ottiene è la seguente:
Per migliorare la presentazione della pagina, abbiamo aggiunto ad alcuni tag di HTML l’attributo
STYLE, che ci consente di assegnare ai singoli tag gli attributi di formattazione di CSS (vedi
§ 2.1.2). Questa tecnica è detta CSS in linea ed è uno dei metodi forniti da HTML 4.0 per imple-
mentare i fogli di stile CSS [27]. È possibile utilizzarla all’interno di un documento XSL, poiché in
esso si può inserire tutto ciò che può trovarsi in un documento HTML, come fogli di stile CSS, ap-
plet Java, script vari, ecc.
In generale, la stesura di un foglio di stile XSL si può riassumere in questi punti:
1) associazione delle parti del documento XML che si vuole visualizzare a semplici tag di HTML
(, , , ecc.), attraverso gli elementi XSL;
2) aggiunta di testo che spieghi il significato dei dati (titoli, commenti, ecc.);
3) affinamento della visualizzazione ottenuta per mezzo dei tag di HTML dedicati alla formatta-
zione (
,