quaderni di usabilità TILS: Scuola Superiore Guglielmo Reiss Romoli

appuntamenti, strumenti di lavoro, personaggi, la rassegna stampa strumenti per approfondire gli argomenti scambia le tue idee ricerche bibliografiche, commenti e suggerimenti, libro degli ospiti consulta i quaderni

vai all'indice del quaderno n° 1

Architettura ed Evoluzione del World Wide Web

L'eXtensibile Markup Language (XML): la nuova architettura

La definizione di una struttura unica per il documento HTML, l’utilizzo di un insieme di tag chiuso, l’utilizzo prevalente dei tag ai fini della presentazione, si sono rapidamente dimostrati dei limiti all’utilizzo del Web nei diversi contesti applicativi. D’altra parte, il successo dell’HTML, legato anche alla sua semplicità, rendeva non proponibile tornare alla complessità dell’SGML.

Si è scelto, quindi, di definire un nuovo linguaggio di markup, meno complesso dell’SGML, ma più potente dell’HTML: l’eXtensible Markup Language (XML), rilasciato nel febbraio del 1998. Il progetto prevede la definizione di un gruppo di specifiche, che raccolga, oltre a XML, anche quelle per la definizione dello stile di rappresentazione (XSL) e per la gestione dei link (XLL).

XML nasce per riportare la realizzazione di documenti per il Web alla normale separazione tra struttura e rappresentazione. Infatti, XML si occupa esclusivamente della definizione dei tag da usare e della loro strutturazione. Separando la struttura e il contenuto dalla presentazione, lo stesso contenuto può essere riprodotto in modi diversi: sia scritto su di un monitor, sia riprodotto sottoforma di audio. Piuttosto che di un linguaggio si tratta quindi di un metalinguaggio, ovvero di un linguaggio per la definizione di altri linguaggi o applicazioni, come successo per esempio con il Channel Description Format (CDF), già ampiamente diffuso sul Web.

Un tool per leggere un documento XML consta di due parti: il "parser", che esegue il controllo semantico e gestisce gli errori, e il "processor" che visualizza il documento. Il controllo da parte del parser avviene su due livelli: valutando la conformità del documento al DTD di riferimento prima e, in caso di non conformità, eseguendo un controllo limitato alle regole generali della sintassi XML (presenza dei tag di chiusura, differenza tra maiuscolo e minuscolo, controllo dell'indentamento dei tag, …). Nei due casi, si parla di file "valid" oppure "well-formed". Questo significa che, mentre per sviluppare un documento ben formato è sufficiente scrivere il file XML, nel caso del documento valido è assolutamente necessario associarci un secondo file, appunto il DTD.

Entrambi i tipi di documento iniziano nella prima riga con la "Document Type Declaration"; un esempio potrebbe essere del tipo:

<?XML version="1.0" standalone="yes" encoding="UTF-8"?>

dove:

<?XML .... ?> è l'elemento che introduce il documento e lo dichiara come documento aderente alle specifiche XML;
"version" definisce la versione delle specifiche di riferimento;
"standalone" è l'attributo che indica se il documento è well-formed ("yes") o valid ("no"). Nel secondo caso il file sarà accompagnato da un file che definisce il DTD;
"encoding" indica il tipo di codifica. Al momento la "UTF-8" e quella di default.

Come si è visto quindi con la "Document Type Declaration" sostanzialmente si dichiara il riferimento del documento alle specifiche XML e se questo fa riferimento o meno ad un DTD specifico, ovvero se è valido o semplicemente ben formato.

Il DTD (Document Type Definition) contiene le regole che definiscono i tag usati nel documento XML, definendo, quindi, la sua struttura. Sebbene non sia obbligatorio, è quindi consigliabile usarlo. Il DTD è contenuto all'interno della "Document Type Declaration", tramite il tag <DOCTYPE>. XML prevede la possibilità di definire il DTD non solo in un file esterno, ma anche all’interno del documento stesso. Nel caso di file esterno, nel tag <DOCTYPE> vi sarà il riferimento a questo file; es.:

<?xml version="1.0"?>

<!DOCTYPE greeting SYSTEM "hello.dtd">

Nel caso in cui il DTD è inglobato nel documento, segue il tag <DOCTYPE> aprendosi con il carattere "[" e chiudendosi con il carattere "]".

<?xml version="1.0"?>

<!DOCTYPE greeting [

<!ELEMENT greeting (#PCDATA)>

]>

dove il DTD è rappresentato dalla riga

<!ELEMENT greeting (#PCDATA)>

In questo caso ELEMENT definisce "greeting" come un elemento utilizzabile come tag nel documento. Questo tag sarà utilizzabile per marcare del testo (PCDATA = Parsed Character Data).

L'elemento è il blocco base del documento XML. Gli elementi sono definiti nel DTD con una sintassi del tipo:

<!ELEMENT [nome_elemento] ([elenco_sottoelementi])>

per cui nell'esempio sopra avremo:

L’uso degli elementi nel documento XML avviene è delimitando i contenuti tra un tag di apertura e ed un tag di chiusura

<greeting>Hello, world!</greeting>

In questo caso abbiamo l'elemento " greeting " che contiene la porzione di testo " Hello, world!". Da notare che, a differenza di HTML gli elementi sono case sensitive per cui <greeting> non ha lo stesso valore di <GREETING>.

Esiste anche un tag di elemento vuoto, che viene usato nel caso di elementi che non debbano avere contenuto (es.: una definizione). Il tag di un elemento vuoto si differenziano dagli altri tag perché la barra è posta dopo il nome dell'elemento: es.:

<linea/>

E’ possibile aggiungere all'elemento informazioni addizionali tramite gli attributi permettono. Anche nell’HTML è previsto l'uso di attributi ; ad esempio nel caso di:

<IMG align=center ...>

"align" è un attributo dell'elemento IMG che ne definisce il tipo di allineamento. In linea di massima, però, l'uso degli attributi in HTML è legato alle modalità di rappresentazione dell'elemento. In XML, invece, gli attributi degli elementi sono informazioni addizionali sulla struttura del documento.

Gli attributi vengono dichiarati nell’"attribute list" (<ATTLIST>); questo contiene:

il nome dell'elemento cui gli attributi si riferiscono;
il tipo di dati;
la lista dei valori degli attributi;
il valore di default.

Ad esempio, nel caso di definizione di un elemento relativo ad un libro e volendo inserire un attributo relativo alla rilegatura, nel DTD, dopo la dichiarazione dell'elemento LIBRO, si avrà un’"attribute list" del tipo:

<!ATTLIST LIBRO RILEGATURA (duro|brossura) "duro">

in cui

ATTLIST definisce la lista di attributi;
LIBRO è il nome dell'elemento cui è riferito l'attributo;
RILEGATURA l'attributo;
"duro" e "brossura" i due valori che può assumere l'attributo, mentre "duro" è l'attributo di default.

Nel caso quindi di una edizione rilegata in brossura del "Decameron", avremo quindi nel documento un tag del genere (da notare che il valore di un attributo deve stare necessariamente tra doppi apici):

<LIBRO RILEGATURA="brossura">Decameron</LIBRO>

L'attributo deve avere poi dei valori che indicano al Parser come comportarsi durante il controllo di conformità:

#REQUIRED indica che l'attributo deve avere necessariamente un valore ogni volta che è usato l'elemento;
#IMPLIED indica che l'attributo può non avere valore;
#FIXED indica che l'attributo può non avere valore, ma se è presente, deve necessariamente essere quello di default.

Un documento XML non deve necessariamente essere composto da un solo file, ma può assemblare al suo interno più parti, chiamate entità. Queste possono contenere sia dati convalidabili, che sono i markup e tutto quanto è definito da un markup, sia dati non convalidabili, che sono quelli cui non è applicabile un markup.

Le entità permettono di creare dei riferimenti ad altri documenti (entità esterne), o anche a porzioni di testo (entità interne), a patto che ci sia una dichiarazione nel DTD. Pertanto nel caso di una dichiarazione del tipo:

<!ENTITY decameron "G.Boccaccio, Il Decamerone, Giunti, Firenze, 1987">

all’interno del documento avrò una entità interna, che quindi può essere paragonata ad una vera e propria variabile, mentre in una dichiarazione del tipo:

<!ENTITY decameron "./decam.txt">

avrò un’entità esterna, perché c’è un riferimento ad un file diverso (anche su una macchina remota).

Dato questo approccio modulare, nasce l’esigenza di gestire eventuali collisioni tra elementi aventi lo stesso nome. A tal fine sono nati i "namespace", che permettono la creazione e l'uso di tag ambigui, ovvero con lo stesso nome, ma in riferimento a significati ed ambienti diversi utilizzando costrutti con nomi non equivoci.

Ad esempio, sarà possibile utilizzare l’elemento "titolo" a seconda del contesto, sia per referenziare il titolo di un articolo, sia per il ruolo del giornalista all'interno della struttura redazionale. E' possibile, cioè, creare due tag, chiamandoli entrambi <TITOLO>, utilizzandoli poi nel documento senza correre il rischio che il Parser ed il Processor li confondano.

Il nome non equivoco si ottiene associando agli elementi delle URI tramite l’attributo "xmlns"; ad esempio, la seguente definizione:

<X xmlns:edi='http://ecommerce.org/schema'></X>

applica l'ambiente "edi", definito in "http://ecommerce.org/schema", all'elemento <X>. La dichiarazione di namespace si applica all'elemento all'interno del quale c'è la dichiarazione e a tutti gli altri elementi in esso contenuti, a meno di nuova dichiarazione di namespace. Pertanto nel caso precedente tutto quello che sarebbe indentato dentro il tag <X> farebbe parte del namespace "edi". E’ possibile utilizzare anche più namespace contemporaneamente. Ad esempio, in:

<bk:book xmlns:bk='urn:loc.gov:books' xmlns:isbn='urn:ISBN:0-395-36341-6'>

<bk:title>Cheaper by the Dozen</bk:title>

<isbn:number>1568491379</isbn:number>

</bk:book>

all’interno del contesto <bk:book> si alternano due namespace, "bk" e "isbn" ed ognuno vale fintanto che non ne è invocato un altro.