Introduzione
IV
Si è evidenziata l’esigenza di realizzare delle applicazioni che proponessero
interfacce che diano all’utente la possibilità di effettuare query in forma
grafica, rivolgendo particolare attenzione all’usabilità del prodotto. Un'altra
criticità emersa in questa fase è rappresentata dalla rigidità dei linguaggi
usati per esprimere le interrogazioni che va a scontrarsi con l’estrema
flessibilità insita nella natura del linguaggio XML. L’utilizzo, per esempio,
del linguaggio XPath per effettuare query in forma testuale costringe
l’utente a possedere una conoscenza esatta della struttura e della semantica
del documento in cui i dati desiderati sono archiviati.
Con la tesi ci siamo proposti di affrontare queste tematiche, con l’obiettivo
di realizzare un’interfaccia grafica che consenta all’utente di esprimere
interrogazioni sui documenti XML in modo semplice ed intuitivo,
prevedendo l’opportunità di effettuare personalizzazioni che meglio si
adattano alle esigenze del fruitore del servizio ed alla natura del linguaggio
XML. Abbiamo progettato un’applicazione Web, in tecnologia JSP, che
realizza, attraverso una metafora grafica molto intuitiva, uno strumento
d’interfaccia utente facilmente usabile e personalizzabile.
La tesi è strutturata nel modo seguente:
ξ Nel primo capitolo viene presentata un’introduzione al linguaggio
XML: si analizza brevemente la sintassi del linguaggio e la
possibilità di validare i documenti prodotti. Successivamente si
descrivono le varie opportunità esistenti per l’espressione di
interrogazioni sui documenti XML.
ξ Nel secondo capitolo affrontiamo nel dettaglio i requisiti logici
dell’applicazione, descrivendo le caratteristiche che l’interfaccia da
realizzare deve possedere. Ci si è soffermati in particolare sulla
possibilità di personalizzare le interrogazioni e su alcuni esempi
significativi.
Introduzione
V
ξ Nel terzo capitolo è stato illustrato l’ambito tecnologico in cui
l’applicazione si colloca: abbiamo descritto l’architettura multi-tier
di una Web application, il design pattern (MVC) di base per lo
sviluppo del sistema, i vantaggi della tecnologia JSP e della
piattaforma J2EE rispetto ad altre piattaforme ed infine abbiamo
evidenziato le scelte implementative effettuate per ciò che concerne
il Web server e l’ambiente di sviluppo.
ξ Nel quarto capitolo abbiamo descritto l’applicazione realizzata: a
partire dall’architettura generale, abbiamo descritto il modello
statico ed il modello dinamico del sistema, ponendo l’accento sulle
funzionalità effettivamente realizzate.
Capitolo 1. Introduzione a XML
1
Capitolo 1. Introduzione a XML
Negli ultimi anni il linguaggio XML (eXtensible Markup Language)[1,19]
ha assunto crescente rilevanza nell’ambito dell’archiviazione e scambio di
dati in un contesto di rete Web. I motivi di un tale successo risiedono nella
natura stessa di questo linguaggio: l’XML, infatti, è testuale, flessibile ed
autoesplicativo e viene usato principalmente per rappresentare dati
semistrutturati, cioè informazioni organizzate in modo irregolare o
mutevole. In genere sono dati provenienti da sorgenti eterogenee e che non
possiedono una struttura fissa conosciuta a priori.
1.1 Il linguaggio
XML è stato definito dal consorzio W3C (World Wide Web
Consortium)[21], l’organismo che stabilisce gli standard per il Web. XML è
un’evoluzione rispetto ad altri linguaggi di markup (come ad esempio
HTML[22]), in quanto consente di creare elementi per progettare un markup
personalizzato. Gli standard pre-esistenti prevedono invece elementi
predefiniti e non “estendibili”. I linguaggi di markup descrivono il formato
del documento, cioè le modalità con cui deve essere interpretato il
contenuto.
1.1.1 La struttura
Un documento XML è costituito da markup e da dati di tipo carattere. I
markup conferiscono la struttura al documento; essi comprendono i tag
d’apertura, i tag di chiusura, i tag degli elementi vuoti, i riferimenti ad
entità, i riferimenti a caratteri, i delimitatori delle sezioni CDATA, i
commenti, le dichiarazioni di tipo del documento e le direttive di
elaborazione. I dati di tipo carattere sono tutto ciò che è testo e che è diverso
dai markup. Forniamo un semplice esempio di documento XML:
Capitolo 1. Introduzione a XML
2
<?xml version=”1.0” encoding=”UTF-8”>
<FORMULA1>
<TEAM nome= Ferrari colore=”rosso”>
<PILOTA>Schumacher M.</PILOTA>
<PILOTA>Barrichello</PILOTA>
<COLLAUDATORE>Massa</COLLAUDATORE>
</TEAM>
<TEAM nome=”Bar” colore=”bianco-rosso”>
<PILOTA>Sato</PILOTA>
<PILOTA>Button</PILOTA>
<COLLAUDATORE/>
</TEAM>
<TEAM nome=”Renault” colore=”giallo-blu”>
<PILOTA>Trulli</PILOTA>
<PILOTA>Alonso</PILOTA>
</TEAM>
<TEAM nome=”Williams” colore=”bianco-blu”>
<PILOTA>Schumacher R.</PILOTA>
<PILOTA>Montoya</PILOTA>
</TEAM>
</FORMULA1>
Esempio 1.1: Un possibile documento XML
I tag iniziano col simbolo “<” e terminano con “>”. Il markup in genere usa
questi tag per definire la struttura di un documento; nel caso di riferimenti
ad entità, il markup inizia invece con “%” oppure con “&” e finisce con “;”.
I dati di tipo carattere sono costituiti dal testo tra un markup e l’altro
(esempio: “Schumacher R.”).
La dichiarazione XML si trova all’inizio del documento e nell’Esempio 1.1
è rappresentata dalla riga <?xml version=”1.0” encoding=”UTF-8”>.
I markup sono composti da elementi; ogni elemento è costituito da un tag
d’inizio e un tag di fine se contiene testo; riferendoci sempre all’Esempio
1.1, <PILOTA>Trulli</PILOTA> è un elemento. Oppure è costituito da un
unico tag se è un elemento vuoto, per esempio <COLLAUDATORE/>. Il testo
tra parentesi angolari è detto nome del tag.
Il documento XML possiede sempre un elemento che racchiude tutti gli
altri, che è detto elemento radice del documento (nel nostro esempio:
<FORMULA1></FORMULA1>).
Capitolo 1. Introduzione a XML
3
Per specificare dati aggiuntivi di un certo elemento, si usano all’interno dei
tag d’apertura e in quelli vuoti delle coppie nome=valore, dette attributi.
Nell’esempio considerato sono attributi: nome=”Renault”, colore=”rosso” e così
via. Le sezioni CDATA sono frammenti di documento contenenti dati di tipo
carattere che non devono essere analizzati dal processore XML; tali dati
sono contenuti tra i seguenti caratteri “<[CDATA” e “]]>”.
Il consorzio W3C ha rilasciato molte regole per creare documenti XML
“well formed” (ben formati). Rispetto allo standard HTML, i validatori
XML sono molto più rigidi nell’applicare le regole rilasciate. Ne citeremo le
principali:
ξ La dichiarazione XML va posta sempre come prima riga del
documento XML.
ξ L’elemento radice deve includere tutti gli altri elementi.
ξ Ogni elemento deve essere costituito da un tag di apertura e uno di
chiusura, tranne gli elementi vuoti che devono prevedere la chiusura
del tag con “/>”.
ξ Gli elementi devono essere correttamente annidati: ogni elemento
che contiene altri elementi, deve includere sia il tag di apertura che
quello di chiusura degli elementi contenuti. Esempio di annidamento
corretto:
<TEAM nome=”Williams” colore=”bianco-blu”>
<PILOTA>Schumacher R.</PILOTA>
<PILOTA>Montoya</PILOTA>
</TEAM>
Esempio di annidamento non valido:
<TEAM nome=”Williams” colore=”bianco-blu”>
<PILOTA>Schumacher R.</PILOTA>
<PILOTA>Montoya
</TEAM>
</PILOTA>
ξ Nello stesso tag i nomi degli attributi devono essere univoci.
ξ I valori degli attributi devono essere racchiusi dai doppi apici.
Capitolo 1. Introduzione a XML
4
1.1.2 DTD
Abbiamo detto che una delle grandi potenzialità di XML è data
dall’opportunità di creare tag personalizzati. Se da una parte una tale
possibilità rappresenta uno strumento molto utile e potente in termini di
facilità d’uso e flessibilità, dall’altra può determinare una grande varietà di
strutture per memorizzare le stesse informazioni in un documento e quindi
rendere più difficile il recupero delle informazioni stesse. Di conseguenza,
se è vero che risulta impossibile scrivere documenti XML “bad formed”,
perché non accettati dal processore XML, sarebbe preferibile che chi si
appresta a scrivere un documento XML definisca una sintassi specifica che
renda valido il documento stesso. Vediamo un semplice esempio,
riferendoci al caso già preso in esame nell’Esempio 1.1. L’elemento
<TEAM> quanti elementi <PILOTA> può contenere? Può contenere elementi
di altro tipo? Ci sono elementi che devono essere obbligatoriamente vuoti?
O altri che non possono essere vuoti? Oltre a colore e nome è consentita la
presenza di altri attributi per l’elemento <TEAM>? Tutte queste regole
sintattiche e di struttura possono essere definite e personalizzate da chi
scrive il documento tramite una Data Type Definition (DTD)[19,24] che
permette la validazione del documento medesimo. Poiché una DTD non
agisce sul contenuto bensì solo sulla sintassi e sulla struttura del documento
XML, può essere utilizzata la stessa DTD per validare documenti diversi.
Senza entrare nel dettaglio, forniamo un semplice esempio di DTD per il
documento dell’Esempio 1.1.
<!DOCTYPE FORMULA1 [
<!ELEMENT FORMULA1 (TEAM)*>
<!ELEMENT TEAM (PILOTA*, COLLAUDATORE*)>
<!ELEMENT PILOTA (#PCDATA)>
<!ELEMENT COLLAUDATORE (#PCDATA)>
]>
Esempio 1.2: Un possibile DTD