Dell’Extensible
Markup Language cominceremo ad analizzare nel dettaglio come si definisce un
linguaggio XML, come è fatto un DTD, e alcune applicazioni XML quali il VML e
il MathML.
Al contrario dell’HTML, l’Extensible Markup Language non è un linguaggio
univoco per la visualizzazione di documenti. Chi più chi meno, tutti coloro che
navigano in Rete conoscono, o hanno sentito parlare, dell’Html quantomeno
perché viene utilizzato per sviluppare le pagine Web. È un linguaggio ben
definito, in cui la struttura, l’aspetto e il comportamento delle varie pagine
viene specificato mescolando il testo vero e proprio della pagina a una serie di
istruzioni più o meno complesse chiamate marcatori o contrassegni. Sebbene l’Html
si sia evoluto nel tempo includendo sempre più funzioni e marcatori
utilizzabili dagli sviluppatori, la sua caratteristica fondamentale è che ogni
elemento ha una sua ben precisa connotazione. Un qualunque browser sa come
interpretare e visualizzare i marcatori standard e spesso anche una serie di
marcatori proprietari che finiscono, in molti casi, per diventare standard de
facto. Nonostante sia oggigiorno possibile definire a parte il comportamento e
la rappresentazione delle pagine tramite linguaggi più o meno evoluti, come
Java e JavaScript o utilizzando i cosiddetti fogli di stile (CSS), l’Html
resta di fatto un linguaggio chiuso, con limiti e caratteristiche ben precise.
Di qui è nata l’esigenza di dare agli sviluppatori dei documenti la
possibilità di definire nuovi elementi e di specificarne separatamente
sintassi, semantica, rappresentazione e comportamento. Ed è proprio ciò che
permette di fare l’XML che, di fatto, rappresenta una versione semplificata
dell’SGML, complesso metalinguaggio per la definizione di linguaggi
dichiarativi per la realizzazione di documenti.
Ricapitolando possiamo affermare che:
1) L’XML non è un linguaggio come l’Html, ma un
metalinguaggio che permette di definire altri linguaggi a marcatori. In modo
improprio, ma non del tutto scorretto, l’XML può anche essere considerato una
famiglia di linguaggi. In pratica, permette di definire un qualsiasi linguaggio
generico o specifico a determinati tipi di documenti. Per esempio, possiamo
definirne uno appositamente studiato per compilare schede contenenti ricette di
cucina, come riportato nel listato 1
2) L’XML non è stato pensato per sostituire l’Html,
quanto semmai per integrarlo ed estenderlo. Di fatto è possibile ridefinire
l’Html utilizzando XML stesso. Un esempio relativo al marcatore <A> è
riportato nel listato 2.
Funzioni
Ma
come funziona, com’è possibile cioè scrivere un linguaggio come quello
riportato nel listato 1 e far sì che il browser possa visualizzarlo in una
pagina?
L’XML prevede due moduli separati a riguardo. Il primo, chiamato Processore
XML, ha lo scopo di analizzare il documento, suddividerlo nelle varie componenti
(parsing), per metterle poi a disposizione di un altro modulo chiamato
Applicazione XML. È quest’ultimo che si occupa di trasformare le informazioni
così acquisite in una serie di elementi di varia natura che possono poi essere
riprodotti sullo schermo o inoltrati verso apposite periferiche, come, per
esempio, schede audio o per l’acquisizione dei dati. E questo perché, come
forse può incominciare a trasparire da quanto scritto finora, questa
architettura in realtà può essere utilizzata in maniera molto flessibile non
solo per visualizzare documenti più o meno multimediali, ma per costruire vere
e proprie applicazioni interattive guidate da profili scritti con un linguaggio
a marcatori appositamente studiato.
Aldilà dei possibili sviluppi che l’XML potrà stimolare in futuro,
analizziamo in dettaglio la sintassi del linguaggio. Prima però è necessario
introdurre alcuni termini. Il file che contiene il testo e i marcatori si chiama
Documento XML, anche se come abbiamo poco sopra descritto esso può arrivare a
diventare un programma vero e proprio. Un documento XML ha una struttura fisica
e una logica. Da un punto di vista fisico, è formato di tante componenti
chiamate entità. L’entità principale è chiamata radice. Da un punto di
vista logico sarà composto da vari tipi di marcatori, come descriveremo tra
poco.
Documenti
e marcatori
Esistono
due tipi di documenti: quelli conformi (well-formed) e quelli validi (valid).
Perché sia conforme, un documento deve rispettare una serie di regole.
Innanzitutto esso deve contenere almeno un elemento. Per esempio, un file di
testo senza alcun marcatore non può essere considerato un documento XML
conforme. Inoltre, l’elemento radice deve sempre esserci e non può mai
apparire all’interno di un altro elemento. Per esempio, la radice di un libro
potrebbe essere <BOOK></BOOK>. Per quanto riguarda gli altri
elementi, l’annidamento deve essere completo: non è cioè possibile che due
elementi si sovrappongano parzialmente come in <B>La
<I>bisbetica</B> domata</I>. La conseguenza di queste tre
semplici regole è: ogni elemento che non sia la radice deve essere contenuto in
uno e un solo altro elemento. Questo porta a poter vedere tutti gli elementi di
un documento XML rappresentabili in un albero in cui ogni elemento è figlio di
un altro, radice esclusa, e può a sua volta essere padre di uno o più
elementi. Molti Parser in effetti di un documento XML forniscono proprio la sua
struttura ad albero.
Un documento XML può essere scritto utilizzando qualunque carattere dello
standard ISO/IEC 10646, sia nella forma diretta sia codificata UTF-8 e UTF-16.
Questo standard è sostanzialmente analogo all’insieme dei caratteri Unicode,
esclusi i cosiddetti blocchi surrogati e i caratteri 0xFFFE e 0xFFFF. Il
risultato è un insieme di testo e marcatori (markup).
Esistono vari tipi di marcatori. In aggiunta ai classici marcatori iniziali e
finali, come <PROVA> e </PROVA>, esiste anche il marcatore vuoto,
quello cioè che non delimita uno o più altri elementi, per esempio <VUOTO/>.
Sono considerati marcatori anche i riferimenti a un’entità, come, per
esempio, &firma;, e quelli a un carattere, come }, i commenti, le
dichiarative del tipo di documento, i delimitatori delle sezioni CDATA e le
istruzioni di elaborazione (processing instructions, o PI). Tutto il resto è
testo.
I
commenti possono essere posizionati ovunque in un documento, fuorché
all’interno di un altro marcatore, con l’esclusione dei DTD, cioè delle
dichiarative relative al tipo di documento; ne parleremo in dettaglio nel
prossimo articolo. Come in Html esse iniziano sempre per “<!—” e
terminano con “—>“. Possono contenere qualunque testo a esclusione di
due trattini consecutivi (“—”).
Le istruzioni di processo, o elaborazione, servono a fornire all’applicazione
XML una serie d’informazioni e vengono passate direttamente al modulo in
oggetto. Esse iniziano sempre con i due caratteri “<?” seguiti senza
alcun spazio da un nome che corrisponde all’applicazione che le deve
processare, e terminano con i caratteri “?>“. Le istruzioni “<?xml”
sono riservate all’XML stesso. Questo permette, per esempio, di avere in uno
stesso documento più linguaggi XML, ognuno gestito dalla sua applicazione. Per
esempio, in un documento scritto con un linguaggio tipo Html, potremmo voler
introdurre un grafico vettoriale definito via VML. Un documento XML deve
iniziare sempre con una PI XML che lo identifica come tale, detta prologo. Per
esempio:
<?xml version=“1.0”?>
Le sezioni CDATA sono dei blocchi che permettono di considerare una stringa di
caratteri come semplice testo, anche se contiene uno o più marcatori. In
pratica è un modo per interrompere in moto temporaneo l’interpretazione del
linguaggio; se, per esempio, state scrivendo un manuale relativo a un linguaggio
XML e il documento contiene delle demo che volete mostrare così come sono senza
far interpretare anche quei marcatori, basterà che includiate i vari esempi in
blocchi CDATA e il gioco è fatto. Un blocco di questo tipo inizia sempre con
"<![CDATA [ "e termina con "] ]>". Un esempio è
riportato nel listato 3.
Fin qui per quello che riguarda i documenti conformi. Tuttavia, affinché un
documento XML sia anche valido, è necessario preventivamente definire tutta una
serie di regole che descrivano in qualche modo come vanno utilizzati i vari
marcatori e permettano al processore di convalidare il documento da un punto di
vista sintattico. In Html questo non è necessario, perché il linguaggio è ben
definito e conosciuto da qualunque browser che dichiari di essere in grado di
gestire una certa versione. In questo caso la dichiarativa del tipo di documento
è abbastanza semplice, e contiene di fatto solo la versione del linguaggio e
poche altre informazioni. È quella «strana» istruzione <!DOCTYPE> che
viene posta sempre in testa al documento (listato 4).
Ma se sviluppiamo un linguaggio per scrivere ricette come quello riportato nel
listato 1, come fa il processore a sapere che l’entità voce può apparire
all’interno di ingredienti, ma non all’interno di fase?
Grammatica
e linguaggio
Per
permettere al processore di convalidare un documento da un punto di vista
grammaticale, è necessario fornire una serie di dichiarative scritte
utilizzando appositi marcatori. Queste possono essere incluse direttamente nella
dichiarativa principale <!DOCTYPE> oppure essere memorizzate in un file a
parte con estensione .dtd, chiamato appunto Document Type Declaration File.
Quest’ultima tecnica è molto comoda quando un certo numero di documenti è
stato scritto con lo stesso linguaggio e la stessa grammatica. Abbiamo scritto
di proposito linguaggio e grammatica, perché è facile capire, a questo punto,
come due sviluppatori potrebbero definire linguaggi molto simili se non quasi
identici, in particolare se riferiti a un contesto molto specifico, inventandosi
tuttavia regole grammaticali differenti. Pensate, per esempio, a un linguaggio
per produrre etichette per audio cassette o CD musicali. Alla fine i marcatori
sarebbero più o meno gli stessi – non tutti i programmatori sono dotati di
grande fantasia – ma la struttura grammaticale potrebbe essere molto
differente.
Tutti i marcatori DTD iniziano con i caratteri “<!” seguiti da un nome
che definisce il tipo di dichiarativa, e terminano con il carattere “>“.
È inoltre possibile includere all’interno della dichiarativa un commento
semplicemente racchiudendolo fra due coppie di trattini, nel seguente modo:
<!ELEMENT VOCE (#PCDATA) — voce di una lista di ingredienti —>
Se le dichiarative sono incluse direttamente in quella principale, esse saranno
comprese fra due parentesi quadre, come nel listato 5, altrimenti faranno parte
di un file separato anch’esso con il suo prologo XML, mentre la dichiarativa
principale del documento conterrà solo il nome del file DTD (listati 6 e 7).
Ovviamente, affinché un documento di cui siano state fornite le dichiarative di
linguaggio sia valido, esso dovrà rispettare senza eccezioni le regole in esse
contenute. Inoltre, il nome del <!DOCTYPE> dovrà corrispondere al nome
del marcatore che rappresenta la radice del documento. Per esempio, se il
marcatore principale è <music>, il tipo di documento sarà identificato
dalla dichiarativa
<!DOCTYPE music . . . >
Esistono poi altre regole secondarie che non staremo qui a descrivere, anche
perché interessano solo quanti sono seriamente interessati a sviluppare un
linguaggio XML convalidabile. A queste persone suggeriamo la lettura della
versione 1.0 dello standard pubblicata dal World Wide Web Consortium (W3C)
accessibile all’indirizzo http://www.w3.org/TR/REC-xml
È comunque una lettura che consigliamo solo ai più volenterosi.
Un
altro aspetto di un documento XML riguarda la sua eventuale dipendenza da
dichiarative esterne. Abbiamo visto che un documento XML può dipendere da un
file DTD. È inoltre possibile che all’interno del documento ci siano
riferimenti ad altre dichiarative esterne. Una dichiarativa può alterare il
contenuto di un documento nel passaggio dal processore XML all’applicazione
XML. Per esempio, se in una dichiarativa si specifica che un certo parametro di
un marcatore, se omesso, ha un valore di default ben definito, il processore
passerà all’applicazione quel parametro con quel valore anche se non
esplicitamente codificato. Un altro caso è l’utilizzo di riferimenti. Se in
una dichiarativa &firma; è definito come <B>DdJ</B>, sarà
questa la stringa passata all’applicazione, non certo il riferimento.
Quest’ultimo sarà cioè risolto dal processore stesso. Se questo tipo di
dichiarative sono tutte contenute all’interno del documento, diremo che il
documento XML è indipendente, e si segnala con il parametro standalone=“yes”
nel prologo XML. Invece, se almeno una di queste dichiarative è contenuta
all’esterno del documento, per esempio in un file DTD, il parametro va
impostato a “no”. Da notare che questo parametro non è obbligatorio. L’XML
lo assume sempre “yes” a meno che non si accorga dell’esistenza di
evidenti dichiarative esterne del tipo suddetto.
Questo per quanto riguarda la conformità. Se poi il documento deve anche essere
valido, il parametro standalone va obbligatoriamente impostato a “no“ nel
caso ci siano dichiarative esterne dei seguenti tipi: attributi con valori di
default, qualora essi non vengano impostati in modo esplicito nel documento;
entità, se utilizzate; attributi normalizzabili – lo vedremo nel prossimo
articolo – elementi con un contenuto che può includere uno o più caratteri
di spaziatura.
Per il momento ci fermiamo qui. Nel prossimo numero descriveremo come è fatto
un file DTD e alcune applicazioni XML quali il VML e il MathML. Fatto questo
avrete gli elementi di base per scrivere un linguaggio XML, almeno in teoria…
Struttura
e presentazione
Un
documento, nel senso più esteso del termine, è un insieme di capitoli,
paragrafi, sezioni, note, titoli, figure e altri elementi composti in modo da
formare una serie di pagine logicamente collegate fra loro. Se il documento è
di tipo classico, le varie pagine formano una sequenza, come in un libro. Se
invece è di tipo ipertestuale, esse possono formare una struttura più o meno
complessa che può anche richiudersi su se stessa. Se infine i collegamenti e i
riferimenti sono dinamici, possiamo anche realizzare una struttura in grado di
cambiare a seconda di come si interagisce con il documento stesso; tanto più
che in un documento dinamico persino il contenuto può adattarsi a quelle che
sono le esigenze o i desideri di chi legge. Naturalmente, se il documento è
multimediale, agli elementi più classici si possono aggiungere animazioni,
suoni e in generale vere e proprie applicazioni integrate in grado di fare più
o meno qualunque cosa, come nel caso degli applet Java o degli oggetti ActiveX.
Ogni elemento poi può avere le sue caratteristiche. Lo stesso testo può essere
reso con caratteri differenti per tipo e dimensioni, le immagini possono avere
una didascalia e una cornice, i titoli possono essere centrati o allineati a un
margine, suoni e altri oggetti possono avere attributi predefiniti eventualmente
modificabili in modo dinamico. In altre parole, a parità di contenuti ogni
documento ha un suo stile, un suo modo di presentarsi.
Formattazione
fisica e logica
Quando
realizziamo un documento utilizzando una delle tante applicazioni per
l’elaborazione dei testi o per l’impaginazione, in genere specifichiamo
direttamente tutte queste caratteristiche: scegliamo il carattere per un certo
testo o un paragrafo, modifichiamo l’allineamento, evidenziamo determinate
parole in grassetto o italico, includiamo nel testo figure e grafici. È il
programma che pensa poi a memorizzare tutte queste informazioni associandole
alle varie componenti del documento. Per esempio, possiamo decidere di allineare
tutti i titoli a sinistra, oppure di utilizzare un carattere molto piccolo per
tutte le note a piè di pagina. Il programma acquisirà l’informazione e la
legherà in qualche modo all’elemento interessato.
Ma che succede se, una volta completato il documento cambiamo idea? Cosa fare
cioè se a un certo punto decidiamo che tutti i titoli vanno centrati e non più
allineati a sinistra? Fino a qualche tempo fa ci toccava modificare ogni singola
istanza di quell’elemento a mano, o quantomeno scrivere un’apposita macro.
Oggi, la maggior parte degli elaboratori di testi ci permette di assegnare a
ogni parte del nostro documento uno stile, ovvero un profilo che definisce tutti
gli attributi per un certo tipo di elemento. Per esempio, possiamo richiedere
che i titoli di secondo livello siano resi in «Verdana», grassetto, da 12
punti, con allineamento a sinistra. Nel momento in cui dovessimo decidere di
utilizzare un carattere diverso non dovremmo far altro che cambiare lo stile e
il programma penserebbe a modificare, in modo automatico, tutti i titoli
corrispondenti.
Quello che abbiamo fatto è stato di dare un nome, un significato, a ogni parte
del nostro documento, in modo da non essere costretti a specificare direttamente
le caratteristiche di ogni singola parola, paragrafo o sezione. Abbiamo cioè
definito delle categorie per gli elementi. Un elemento è quindi ora un
componente del documento che ha uno scopo, una logica che è fondamentalmente
scollegata dal modo in cui poi si decide di realizzarlo. Per esempio, la
didascalia di una figura sarà posizionata vicino alla figura corrispondente, ma
quello che importa è che essa serve a descriverla in qualche modo. Se poi sarà
messa sopra o sotto, resa in italico o in grassetto, con un carattere piccolo o
grande e se conterrà o meno una qualche numerazione, tutto ciò non cambia
l’essenza dell’elemento in questione. E così un titolo, una nota a margine,
un listato, un grafico e via dicendo.
Disegnare quindi un linguaggio strutturato per realizzare documenti nel senso più
generale del termine, vuol dire definire una serie di elementi, ognuno con
attributi ben definiti e specificarne in qualche modo la sintassi e la
semantica. Viceversa, la rappresentazione e il comportamento dei vari elementi
può essere lasciato allo sviluppatore che, attraverso strumenti appositi, può
definire queste informazioni all’interno del documento stesso o in uno o più
file esterni scritti utilizzando appositi linguaggi.
Come
abbiamo brevemente descritto, l’Html soffre di alcuni problemi di coerenza,
peggiorati spesso da un utilizzo scorretto del linguaggio. Un caso classico è
l’uso di tabelle senza cornice come metodo per realizzare pagine a più
colonne.
In Html abbiamo tre tipi di marcatori. Alcuni definiscono un certo elemento in
modo «puro», identificando di fatto solo l’elemento logico. Un esempio è
<TITLE>, il marcatore che identifica il titolo della pagina. Altri
identificano in modo univoco un certo elemento, ma permettono a chi scrive di
definire, se lo desidera, anche alcune delle caratteristiche di visualizzazione
dell’elemento stesso. Per esempio <P>, il marcatore che identifica un
generico paragrafo. Infatti, se utilizziamo il parametro ALIGN, potremo decidere
se allineare il paragrafo a destra o a sinistra, centrarlo o giustificarlo.
Infine ci sono marcatori il cui scopo è strettamente legato alla
rappresentazione del contenuto di una pagina o di parte del testo. Un classico
esempio è <FONT>, che permette di specificare il tipo di carattere da
utilizzare per visualizzare un blocco di testo.
Ricapitolando, un elemento ha quattro caratteristiche. La prima riguarda la
sintassi, ovverosia come è scritto, quali parametri ha, che valore possano
prendere e così via. Per definizione in XML un elemento è formato da tutto ciò
che è incluso fra il marcatore iniziale e il marcatore finale, contrassegni
inclusi, oppure da un contrassegno vuoto. La seconda riguarda la semantica,
ovvero che cosa significa, che cosa rappresenta, e di conseguenza quali
relazioni ha con gli altri marcatori. Per esempio, dove è corretto posizionare
quel determinato elemento in un documento e dove invece non può essere
presente. La terza riguarda la rappresentazione, ovvero come viene reso
graficamente sullo schermo o sulla carta. La quarta riguarda il comportamento.
Quest’ultima caratteristica ha senso solo per gli elementi dinamici, quelli
cioè che possono interagire con l’utente o con eventi esterni che possono
anche arrivare dalla rete. Per esempio, un pulsante può servire ad aprire
un’altra finestra con una lista di opzioni selezionabili, oppure un grafico
relativo alle azioni quotate in Borsa potrebbe venire automaticamente aggiornato
ogni cinque minuti.
Marcatori
non puri
Ma
chi gestisce queste caratteristiche? Prendiamo un caso estremo, come quello di
un marcatore puro qual è il titolo della pagina, dove il linguaggio non
fornisce altro che un contrassegno senza ulteriori indicazioni, e poniamoci
alcune domande. Può un titolo essere presente all’interno di un paragrafo?
Possono esserci due titoli nella stessa pagina? Come e dove va visualizzato il
testo corrispondente? Il titolo deve anche comparire nella barra di
trascinamento della finestra del browser o no?
Nel codice non c’è niente che aiuti il browser a prendere queste decisioni.
Il fatto è che, come abbiamo più volte sottolineato, la maggior parte dei
marcatori dell’Html ha sintassi, semantica, rappresentazione e comportamento
predefiniti. O quantomeno esiste un default per ognuna di queste caratteristiche
e per ogni singolo elemento. Il browser deve sapere come interpretare il
marcatore, come rappresentarlo, come gestirlo, anche se nella realtà quello che
succede è che ogni browser fa un po’ di testa sua, tant’è che la stessa
pagina è spesso resa in modo differente dai diversi browser.
Per ovviare a questo inconveniente, si è fatto sempre più uso di marcatori non
puri e di linguaggi di programmazione come JavaScript per specificare
direttamente nelle pagine le caratteristiche relative alla rappresentazione e al
comportamento dei vari elementi. Questa commistione delle varie caratteristiche
di un elemento in uno stesso file ha reso sostanzialmente illeggibili e molto
difficili da mantenere i sorgenti Html. L’invenzione dei parametri di stile
non ha risolto il problema.
Come descritto nel box Struttura e presentazione, un foglio di stile è un file
in cui si specifica a priori come va rappresentato un elemento caratterizzato da
un certo marcatore. Per esempio, possiamo decidere una volta per tutte il tipo
di carattere e il colore del testo da utilizzare per il titolo, forzando il
browser a usare la nostra definizione invece di quella di default. Sebbene sia i
programmi JavaScript sia i fogli di stile possano essere memorizzati in file a
parte, molti hanno preso l’abitudine di includere queste istruzioni
direttamente nelle pagine, rendendo il codice ingestibile. Ma anche là dove si
è mantenuto un minimo di disciplina, la situazione non è poi così allegra. Il
fatto è che il foglio di stile permette di definire la rappresentazione solo
dei marcatori predefiniti dall’Html, o al più di subclassarli in modo da
creare più versioni dello stesso elemento. Per esempio, possiamo definire un
paragrafo P.piccolo e un paragrafo P.grande, ma non possiamo definire nuovi
elementi chiamati <ACCORDO> oppure <NOTA>. Siamo costretti a
simularli utilizzando marcatori preesistenti, cosa non sempre possibile. Un
classico esempio sono le formule matematiche, difficili da realizzarsi con l’Html
classico, anche usando pesantemente i file CSS (Cascading Style Sheets).
XML
da anni fa parlare di sè come il linguaggio di Markup destinato a sostituire l'HTML.
Questa guida, scritta da Paolo De Lazzaro, introduce in 29 lezioni le
caratteristiche principali di XML. E' rivolta ad una fascia di utenti
apprendisti, pertanto non è eccessivamente complessa. Clikka sull'argomento al
quale sei interessato anche se ti consiglio (se sei alle prime armi) di seguire
il corso punto per punto data la correlazione tra una lezione e l'altra. Buona
fortuna.
