XML - Extensible Markup Language

XML - Introduzione

 XML è l’acronimo di eXtensible Markup Language.
Creato al W3C (World Wide Web Consortium), è stato ufficializzato il 10 Febbario 1998 con il rilascio della XML Recommendation 1.0.
Sia XML che HTML derivano direttamente da SGML (Standard Generalized Markup Language), ma in effetti hanno due funzioni diverse: l'HTML è il linguaggio WEB per la presentazione dei dati, mentre XML è il linguaggio WEB per il loro trasporto.
XML rende piu' semplice scambiare dati tra due computer in rete.

Markup è tutto ciò che ha un significato speciale, che deve essere ben caratterizzato come per esempio un testo scritto in grassetto o un testo sottolineato.
In XML tutto ciò che è compreso tra i caratteri "<" e ">" è considerato markup, viene detto anche tag, ad esempio: <NOME> è un tag.
XML è un metalinguaggio non ha tag predefiniti ma consente di definire nuovi metalinguaggi, ed è perciò estensibile.

XML - Le specifiche

 L’attuale specifica di XML è consultabile al seguente indirizzo:
http://www.w3.org/TR/1998/REC-xml-19980210
Esiste una traduzione in italiano di questo documento al seguente indirizzo:
http://www.xml.it/ REC-xml-19980210-it.html

XML - La struttura

 I metalinguaggi di markup di tipo descrittivo offrono rispetto ad HTML sostanzialmente tre vantaggi
Il progetto prevede la definizione di un gruppo di specifiche, che raccoglie oltre a XML anche quelle per la gestione dei link (XLL) e per la rappresentazione (XSL).
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 Resource Description Framework (RDF) e Channel Description Format (CDF), due linguaggi già ampiamente diffusi sul Web.
XML nasce per riportare la realizzazione di documenti per il Web alla normale separazione struttura e rappresentazione dei dati che con il tempo, nella programmazione HTML, si erano confusi.
Si occupa infatti esclusivamente della definizione dei tag da usare e della loro strutturazione. Separando la struttura e il contenuto dalla presentazione, lo stesso sorgente, scritto una sola volta, può essere visualizzato in vari modi diversi: scritto su di un monitor come attraverso audio da un cellulare.
Questo vuol dire che un documento scritto secondo queste specifiche può essere veicolato attraverso device diversi non necessariamente presi in considerazione all'atto della sua stesura.
XML quindi, pur essendo nato propriamente per il mondo Web, ha senso anche fuori da questo, comunque e dovunque qualcuno voglia produrre un documento, a prescindere dal mezzo trasmissivo.
Un tool per leggere un documento XML consta di due parti:
Già da questa dinamica si capisce come la separazione fra struttura e rappresentazione, che come si è visto è uno degli aspetti chiave della buona costruzione di un ipertesto, sia garantita attraverso la separazione fisica dei dati che governano i due aspetti ed addirittura attraverso la separazione anche dei linguaggi.
XML infatti non dice nulla della rappresentazione che può essere gestita attraverso un altro linguaggio: XSL.
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 altro controllo relativo però alle regole generali della sintassi XML.
Proprio per via di questo doppio controllo i documenti possono essere di due tipi, Valid e Well-Formed. Valid sono quelli conformi al proprio specifico DTD, Well-Formed quelli conformi alla sintassi generale.

XML: Well-Formed e Valid Document

 In XML si possono generare documenti Well-Formed oppure documenti Valid, diciamo per semplicità Ben formati e Validi; la differenza stà nella conformità dei validi ad un DTD specifico e dei ben formati alle generiche specifiche XML (presenza dei tag di chiusura a meno di empty element comunque vincolati, differenza tra maiuscolo e minuscolo e controllo dell'indentamento dei tag).
Questo significa che, mentre per sviluppare un documento ben formato è sufficiente scrivere il file XML, nel caso del documento valido è assolutamente necessario scrivere anche un secondo file, appunto il DTD.
Entrambi i tipi di documento iniziano nella prima riga con la "Document Type Declaration" che non ha tag di chiusura per cui per esempio potrebbe essere del tipo:


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

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.

XML: Il DTD
  • specifica le strutture ed i dati
  • specifica sia la sintassi che la semantica delle strutture
  • consente di validare il documento XML
  • non è obbligatorio
Il DTD (Document Type Definition) contiene le regole che definiscono i tag usati nel documento XML, ovvero in pratica definisce la struttura del documento; per questo sebbene non sia obligatorio è consigliabile, per chiarezza, usarlo sempre.
XML prevede la possibilità di definire la struttura del documento non solo in un file esterno bensì anche al suo interno, pertanto di fatto i due esempi di file XML che seguono danno lo stesso risultato:


<?xml version="1.0"?>
<!DOCTYPE greeting SYSTEM "hello.dtd">

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE greeting [
  <!ELEMENT greeting (#PCDATA)>
]>

Nel primo caso il documento fa riferimento per la struttura ad un file esterno (hello.dtd), mentre nel secondo caso il contenuto di questo è inglobato dentro il documento stesso.
In ogni caso la Document Type Definition, è contenuta all'interno della "Document Type Declaration", impostata dal tag <DOCTYPE>, e quando ne è inglobata si apre con il carattere "[" e si chiude con il carattere"]".
In ogni caso nell' esempio è:


<!ELEMENT greeting (#PCDATA)>

In questo caso ELEMENT definisce "greeting" come un elemento, che potra' essere quindi usato come tag nel documento e che contiene del testo (PCDATA=Parsed Character Data)

XML: Gli elementi

 L'elemento è il blocco base del documento XML.
Abbiamo visto come uno dei vantaggi di questo linguaggio si la possibilità di definire tag propri; questo è possibile proprio per mezzo della dichiarazione di elemento, che avviene nel DTD.
Nel documento XML l'elemento è delimitato da un tag di apertura e da un tag di chiusura o da un tag di elemento vuoto in vaso appunto di elemento vuoto.


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


<linea/>

Questi è invece un esempio di elemento vuoto, che va usato nel caso di elementi che non debbano avere contenuto ed in cui la barra, a differenza del tag di chiusura è posta dopo il nome dell'elemento.
Come si è detto gli elementi vanno definiti nel DTD con una sintassi del tipo:


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

per cui nell'esempio sopra avremo:


<!ELEMENT greeting (#PCDATA)>

Rissumendo ci sono le seguenti regole da rispettare nella creazione dei tag (diversamente da quanto succede nell'HTML:

XML: Gli attributi

 Gli attributi permettono l'aggiunta all'elemento di informazioni addizionali.
Già HTML prevedeva l'uso di attributi degli elementi, per esempio nel caso di:


<IMG align=center ...>

"align" altro non e che un attributo dell'elemento IMG.
In linea di massima però l'uso degli attributi in HTML descrive la rappresentazione dell'elemento, e come abbiamo visto, la confusione tra i due livelli, quello della struttura e quello della rappresentazione, in XML non è possibile.
In realtà infatti gli attributi degli elementi in XML sono vere e proprie informazioni addizionali ancora della struttura del documento.
Poniamo il caso di dover definire un DTD per documenti relativi ad una libreria.
Sicuramente l'elemento base è il libro, ma i libri possono essere rilegati con copertina dura oppure in brossura; a questo punto la scelta sarà tra la definizione di due elementi distinti, "libro_duro" e "libro_brossura", e la definizione di un unico elemento LIBRO con attributo RILEGATURA che potrà assumere uno tra i due valori "duro" e "Brossura". Nel caso quindi di un edizione rilegato 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>

Gli attributi vengono dichiarati nell'"attribute list" (<ATTLIST>) che contiene il nome dell'elemento cui gli attributi si riferiscono, il tipo di dati, la lista dei valori degli attributi stessi e il valore di default.
In questo caso, nel DTD, dopo la dichiarazione dell'elemento LIBRO si avrà un' "attribute list" del genere:


<!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 e "duro" quello di default.
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 ce l'ha deve necessariamente essere quello di default.

XML: Le entità

 Un documento XML non deve necessariamente essere composto da un solo file, ma può assemblare al suo interno pezzi diversi chiamati "entities", entità, le quali 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 a dati esterni, ad altri documenti, o anche a porzioni di testo , a patto che ci sia una dichiarazione nel DTD.
Le entità possono essere quindi interne od esterne a seconda di dove fisicamente si trovano i dati rispetto al documento. Pertanto nel caso di una dichiarazione del tipo:


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

all'interno del documento avro' 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).
In ogni caso il concetto chiave è che dopo la dichiarazione nel DTD l'entità è utilizzabile in tutti i documenti che a quel DTD fanno riferimento, semplicemente per mezzo del suo nome.
Molto evidente il vantaggio della costruzione di un documento per mezzo di entità; è possibile infatti così definire la struttura nel DTD, lo scheletro nel documento con la possibilità di riempirlo con contenuti presi dall'esterno. In questo modo anche il contenuto, oltre che la rappresentazione, diventando praticamente un modulo a parte, risulta maggiormente manutenibile.

XML: Namespace

 Essendo XML un linguaggio che si candida a migliorare lo stato della riusabilità delle applicazioni Web attraverso un approccio modulare, e chiaro che esiste un problema di riconoscimento e di collisione.
Il parser, così come il processor deve assolutamente essere in grado di gestire eventuali ambiguità, il cui rischi è inevitabilmente insito nell'approccio modulare.
Per questo 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.
Si pensi per esempio a documenti di una rivista in cui la parola "titolo" a seconda del contesto può referenziare il titolo di un articolo, ma anche il ruolo del giornalista all'interno della struttura aziendale.
E' possibile 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 delle URI ad elementi che fungono da ambiente per cui la seguente definizione:


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

applica l'ambiente "edi", rappresentato dal comando "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 contenuti all'interno di quello 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", mentre nel caso seguente:


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

XSL - La rappresentazione
  • è un compromesso tra CSS e DSSSL: semplicità e potenza
  • specifica lo stile di presentazione dei dati
  • è estensibile
  • consente al client la personalizzazione dei dati

Si è detto più volte della rappresentazione tra struttura e rappresentazione tipica di XML.
Una volta definito il DTD, ovvero la struttura del documento, e quindi messo il parser in condizione di effettuare un controllo sintattico, è assolutamente necessario associare al documento stesso un foglio di stile che ne descriva le regole relative alla rappresentazione.
Queste non devono essere necessariamente univoche, ma devono poter variare al variare del dispositivo di output o anche in seguito all'interazione dell'utente.
In linea di massima, non dicendo XML nulla delle regole di rappresentazione, si potrebbe usare una sintassi qualsiasi di stile; in effetti, una volta rilasciate a Febbraio le specifiche di XML, per lungo tempo si è discusso su quali potessero o dovessero essere i linguaggi candidati a rappresentare le informazioni strutturate per mezzo di XML. Le possibilità più credibili sembravano e sembrano tuttora le seguenti:

Ognuno di questi linguaggi presenta vantaggi e svantaggi; probabilmente alla fine la spunterà quello che riuscirà ad avere la maggiore penetrazione nell'immediato, cosa non facile da prevedere vista la caoticità che caratterizza in questo ultimo periodo il Web ed in particolare i nuovi linguaggi applicativi.
Per quanto riguarda CSS è una tecnologia, rilasciata dal consorzio W3C per HTML, già diffusa e quindi sperimentata e conosciuta, il che è sicuramente un vantaggio notevole. Il suo limite e che non riesce a modificare notevolmente il documento, e quindi è "filosoficamente" un po' lontano dalle intenzioni iniziali dei creatori di XML.
DSSSL sulla carta andrebbe bene: è una tecnologia ampiamente definita anche se non altrettanto diffusa. E' il linguaggi di stile di SGML e di questo eredita pregi e difetti, vale a dire la potenza e la difficoltà. Quest'ultima mal si addice ad un ambiente diffuso come quello del Web. Il consorzio W3C ha optato per implementare XML, una semplificazione per Web di SGML, considerato troppo complesso, per cui lo stesso ragionamento sembra doversi fare per DSSSL.
Infine XSL, il linguaggio proprietario del progetto XML.
Sulla carta dovrebbe raccogliere i pregi di CSS e quelli di DSSSL, ovvero unire la semplicità alla potenza. Una prima bozza di lavoro è stata rilasciata solo il 18 agosto del 1998 per cui è abbastanza presto per dare un giudizio, tanto più che nella bozza stessa si invita ad aspettare le prime specifiche ufficiali. Insomma XSL è sicuramente avvantaggiato a vincere la partita ma intanto i pochi software che permettono di visualizzare XML non lo possono utilizzare finchè non sarà definitivo. Infatti le differenze tra le proposte fatte nell'agosto del 1997, su cui si basa sostanzialmente questo documento, e la bozza dell'anno successivo sono notevoli e notevoli potrebbero essere ancora le differenze con le specifiche definitive. In linea di massima il consorzio si stà muovendo su tre livelli: sviluppare XSL, permettere nell'immediato una buona compatibilità con HTML e mantenere un rapporto stretto con DSSSL.

I componenti principali di XSL sono: 

L'associazione tra un documento XML e un foglio di stile avviene nel prologo del documento per mezzo dell'istruzione "xml:stylesheet", che ha come pseudo-attributi: href (necessario), type (necessario), title (opzionale), media (opzionale), charset (opzionale):


<?xml:stylesheet href="stile.xsl"title="Compact" type="text/xsl"?>

Nell'esempio al documento si associa un foglio di stile XSL ma la stessa sintassi può essere usata per associare altri tipi di fogli di stile.
E' possibile anche associarte al file XML un foglio di style alternativo attraverso l'istruzione "xml:alternate-stylesheet" che mantiene la stessa sintassi.

XSL - Construction Rules

 Con XSL l'output formattato è creato attraverso una operazione in due tempi: la creazione prima di una struttura ad albero in cui viene associato ad ogni elemento lo specifico stile, e l'elaborazione definitiva di questa struttura ad albero. L'associazione tra gli elementi e la loro rappresentazione nel foglio di stile, che rappresenta il primo blocco fondamentale di XSL è specificato dalle "Construction Rules". Una Construction Rule consta di due elementi logici, un Pattern che identifica l'elemento o il gruppo di elementi del sorgente per cui valgono quelle regole, ed una Action che specifica l'albero da costruire quando il processor incontra quell'elemento o uno di quegli elementi.

XSL: Construction Rules: Pattern

Il pattern identifica l'elemento del sorgente cui applicare la regola di costruzione, nel modo più semplice con il nome come valore dell'attributo type del tag <target-element>. Una Construction Rule contiene almeno un target element per cui il caso più semplice è il seguente:


<target-element type="titolo"/>

in questo esempio l'elemento "titolo" viene esclusivamente definito come destinatario della regola, a prescindere dalla sua posizione all'interno del documento, ovvero dovunque si trovi. Oltre al nome il pattern può identificare gli elementi cui applicare la regola anche in modo più complesso, ovvero a seconda del suo contesto specifico in base ai rapporti di ascendenza e discendenza con altri elementi, ad eventuali "wildcard" in questi rapporti,agli attributi, alla posizione rispetto ad elementi fratelli. I rapporti gerarchici vengono definiti per mezzo dell'elemento <element>, il quale ha gli stessi attributi dell'elemento <target-element> ma non indica l'elemento cui applicare la regola, bensì quello che rappresenta il contesto superiore dell'elemento cui applicare la regola. Pertanto a differenza dell'esempio di prima, in questo caso:


<element type="capitolo">
<target-element type="titolo"/>
</element>

la regola viene associata non più a tutti gli elementi "titolo",ma solo a quelli che hanno come ascendente "capitolo". Ovviamente questo permette la definizione di regole rappresentative diverse per lo stesso elemento in base alla sua posizione nella gerarchia struturale del documento. Nel seguente esempio l'elemento "titolo" ha un pattern diverso, e quindi una diversa rappresentazione, a seconda che si trovi indentato dentro l'elemento "capitolo" o dentro l'elemento "paragrafo"


<regola>
<element type="capitolo">
<target-element type="titolo"/>
</element>
</regola>

<regola>
<element type="paragrafo">
<target-element type="titolo"/>
</element>
</regola>

L'elemento <element> sprovvisto dell'attributi type, che normalmente definisce l'ambito di applicabilità, e l'elemento <any> sono detti wildcard. Il primo permette di associare il "target-element" alla regola qualora questo sia figlio di un elemento qualsiasi figlio a sua volta dell'elemento definito come padre, in un rapporto di terzo livello. Il secondo fa sostanzialmente la stessa cosa con la differenza che il target-element può trovarsi a qualsiasi livello di gerarchia. Ecco due esempi per questi due casi.


<element type="capitolo">
<element>
<target-element type="titolo"/>
</element>
</element>

<element type="capitolo">
<any>
<target-element type="titolo"/>
</any>
</element>

Nel primo esempio la regola è applicabile agli elementi "titolo" figli di un qualsiasi elemento figlio di "capitolo", nel secondo caso è invece applicabile agli elementi "titolo" che siano figli di un elemento che si trova ad un qualsiasi livello di gerarchia rispetto all'elemento "capitolo". E' possibile poi vincolare l'associazione del pattern all'elemento in base al valore assunto da un attributo dell'elemento stesso:


<target-element type="capitolo"><attribute name="numero"
value="primo"/></target-element>

In questo caso la regola è applicata solamente agli elementi "capitolo" il cui attributo "numero" abbia valore "primo". Nel caso il valore dell'attributo has-value sia "yes" allora la regola si applica all'elemento a condizione che l'attributo abbia un valore qualsiasi e non si abbia qualora nopn abbia nessun valore. Pertanto nel caso:


<target-element type="capitolo">
<attribute name="numero"has-value="yes"/>
</target-element>

come si è detto l'applicabilità della regola all'elemento "capitolo" dipende dalla presenza o meno di un generico valore associato al suo attributo "numero".

XSL: Construction Rules: Action

Una volta identificati i pattern associati agli elementi viene invocata la seconda parte della Costruction Rule, chiamata Action, al termine della quale viene generata la struttura del "Flow object", ovvero la struttura del documento e insieme le regole per la formattazione. La action comprende due tipi di elementi: flow objects and "XSL processing elements". I flow objects, che XSL deriva quasi direttamenta da DSSSL definiscono la formattazione, mentre i processing element sono elementi di controllo. I flow object sono molto numerosi e tra gli altri i più comuni sono:

Le caratteristiche dei flow object permettono di controllare la presentazione in quest modo:


<titolo
space-before="12pt"
space-after="36pt"
font-weight="bold"
font-size="24pt">
<children/>
</titolo>

L'esempio genererebbe un tag titolo spaziato 12 punti sopra e 36 sotto, grande 24 punti e in grassetto. Le caratteristiche dei flow object possono essere ereditate o meno dagli oggetti figli. Gli alti elementi dell'action, i processing elements servono per definire e controllare azioni relative al processo del documento, ovvero contengono informazione sul come applicare le action al pattern. Tra questi i più comuni sono:

XSL: Style Rules

 Per mezzo delle "Style Rule", definite dal tag <style-rule> è possibile attribuira ad un elemento più di una regola di formattazione. Come le construction rule, le style rule sono composte da pattern e action ma la differenza stà nel fatto che non generano un flow object e che si applicano a cascata su tutti gli elementi figli. Pertanto in un caso del genere:


<style-rule>
<target-element type="titolo"/>
<apply color="red"/>
</style-rule>

all'elemento titolo si applica sempre un colore rosso, a prescindere da dove sia, per cui poi nelle successive construction rule non è più necessario definire il colore.

XSL: Named Style, Macros e Scripts

 I Named Style sono dei gruppi di regole definiti da un nome che, richiamato come valore dell'attributo "use" durante la definizione di un action permette l'applicazione a quell'elemento delle regole contenute nel gruppo. Pertando definendo in questo modo il Named Style "gruppo":


<define-style
name="gruppo"
font-weight="bold"
font-size="18pt"
line-spacing="24pt"/>

questo può essere usato se si vuole rappresentare qualche elemento con quelle caratteristiche scrivendo semplicemente:


<paragraph use="gruppo">

Le macro, definite per mezzo del'elemento <define-macro> permettono la costruzione di flow object complessi, mentre con <define-script> è possibile associare il risultato di una funzione ed usarlo per gestire dei controlli.

XLL - I nuovi collegamenti
  • specifica i legami tra le strutture dati
  • ha 2 tipi di link:
    • monodirezionali in-line (come HTML)
    • estesi in-line o out-line
XLL è il linguaggio dedicato allo sviluppo degli hyperlink XML.
La prima bozza è dell'aprile 1997 ed in seguito sono stati anche redatti i principi generali cui il linguaggio dovrà rispondere, che si rifanno principalmente ad HTML, ad Hytime e a TEI.
Da subito è stato chiarito come, sulla base della tipologia del link unidirezionale affermatasi insieme ad HTML, l'idea fosse quella di svilluppare tutte le tipologie di link che i sistemi ipertestuali nel tempo avevano implementato.
XLink usa la sintassi XML per creare costrutti che possono essere inseriti in risorse XML per descrivere link fra oggetti o fra documenti.
In XLink i legami tra entità non hanno solo il significato di "vai ad altro documento", ma possono diversificarsi in termini di semantica: un link può indicare una figura, una citazione, un insieme di siti inerenti all'elemento da cui parte il riferimento, ed altro ancora:

Il linguaggio è diviso in due sottogruppi, XPointer e XLink:

Il panorama del Software

 La Microsoft, tra tutte le Società è quella che probabilmente sta spingendo maggiormante sull'acceleratore del progetto XML. In quest'ottica ha già ha sviluppato due parser XML che si integrano con il suo browser e una serie di controlli ActiveX dedicati al trattamento di documenti XML, tra i quali in particolare MSXML che al momento è forse l'unico software relamente utilizzabile in rete. Inoltre è stata la prima azienda a sviluppare una applicazione sulla base delle specifiche XML. Si tratta di Channel Definition Format (CDF), il linguaggio su cui si basa il sistema di push integrato in Explorer. La stessa Microsoft, insieme a Marimba, ha sottoposto al W3C un'altra applicazione XML, Open Software Description (OSD), che permette di descrivere oggetti software scambiati in rete. Anche Netscape, che inizialmente non aveva dimostrato molto interesse verso XML, sembra essere ritornata sui suoi passi. La versione 5 del browser Navigator dovrebbe contenere un processor in grado di leggere e formattare i file XML Comunque sembra abbastanza chiaro che la prospettiva dei software per la navigazione della rete punta in quella direzione, per cui non è difficile ipotizzare una piena implementazione di XML nei browser di entrambe le aziende.

In attesa del rilascio di Processor in grado di interpretare in modo nativo documenti XML (vincolato di fatto all'attesa delle specifiche stabili di XSL, il linguaggio relativo alla rappresentazioen sul quale si fonda un browser) ch vuole cominciare a realizzare documentazione con questa tecnologia l'unica soluzione consiste nell'utilizzazione di appositi browser SGML, magari integrati nei tradizionali programmi di navigazione. Attualmente sul mercato esistono sostanzialmente tre Software: Panorama, prodotto dalla SoftQuad, una delle aziende leader nel settore SGML, Multidoc PRO, della finlandese Citec e Jumbo, una applicazione Java usata per Chemical Markup Language, un'applicazione specifica di SGML. Panorama è disponibile in due versioni, una commerciale e l'altra gratuita. La versione commerciale, a sua volta, consiste di due moduli: Panorama Publisher, un browser stand-alone dotato di strumenti per la creazione di fogli di stile e reti ipertestuali tra più documenti; Panorama Viewer, un plug-in per Netscape ed Explorer che può solo visualizzare i documenti (di quest'ultimo viene distribuita una versione di prova, con alcune limitazioni funzionali, sul sito della SoftQuad). La versione gratuita è invece basata sulla release 1 del browser ed è reperibile dal sito Web della OCLC all'indirizzo. Multidoc Pro, è disponibile solo in versione commerciale, ma chi è interessato può scaricarne una versione funzionante per tre settimane presso il sito della Citec. Jumbo è disponibile in versione freeware presso il sito della "Venus".

Per quanto riguarda i parser il panorama è molto più variegato. A parte i software che permettono anche la visualizzazione, di cui si è parlato, che ovviamente prima eseguono il controllo formale, esistono in versione freeware molti parser, tra i quali vanno ricordati Sax della "Microstar Software Ltd.", XML for Java da IBM AlphaWorks, TclXML.

Infine i tool di sviluppo. Recentemente Microsoft ha rilasciato la prima release di un tool per la costruzione di file XML; si chiama "XML Notepad" ed è disponibile freeware nel sito della società Americana. Anche la "Arbortext", che da tempo produce software per SGML ha implementato un tool di sviluppo "XML Styler", ed infine anche la "Vervet Logic" commercializza un tool, "XML Pro". Entrambi questi ultimi due sono pero' disponibili freeware solo in una versione demo priva di alcune funzionalità fondamentali.

Cosa è possibile fare oggi

 Al momento non esiste alcun modo per produrre e pubblicare sul web attraverso XML senza utilizzare software creato per altre tecnologie. Questo perchè di fatto non esiste ancora un software XML degno di questo nome, ovvero un Processor che sia in grado di visualizzare un file XML secondo quanto espresso nei principi base del progetto del consorzio W3. Abbiamo visto però come il panorama del software sia tutt'altro che desolante, e come sia caratterizzato da una certa dinamicità. Purtroppo questa dinamicità si sviluppa sostanzialmente sul lato Parser, ma in fondo questo è abbastanza ovvio se si considera che la parte strutturale, che è quella che permette il controllo di validazione, è l'unica in cui sono state rilasciate specifiche stabili sulla base delle quali poter implementare del software. La situazione è quindi tale per cui chi vuole sperimentare XML, non ha difficoltà a trovare tools di sviluppo e parser, mentre sicuramente incontrerà maggiori problemi per quanto riguarda la visualizzazione del lavoro svolto. In attesa di un Processor o di un browser che supporti completamente XML è possibile sostanzialmente seguire tre strade:

Nel primo caso, essendo XML un sottogruppo di SGML, non vi sono problemi per quanto riguarda il parsing e la strutturazione del documento, ma ovviamente il discorso cambia per quanto riguarda l'aspetto della rappresentazione. In altre parole non è possibile utilizzare XSL. Nel secondo caso abbiamo diversi vantaggi, ovvero la compatibilità assoluta con tutto quanto si trova già sul web senza la perdita dei vantaggi che XML assicura e il maggiore controllo della parte relativa alla visualizzazione attraverso l'uso della tecnologia CSS, oltre che la legibbilità attraverso semplice browser; d'altra parte però, pur essendo una moldalità ottima per una fase di passaggio, è pur sempre lontana dalla filosofia di partenza del progetto XML, che prevede l'utilizzo diretto di XML sul web, perchè comunque deve sempre tener conto dei limiti di HTML. La terza possibilità è in pratica uno sviluppo della seconda: infatti richiamando all'interno di un file HTML l'ActiveX MSXML e dandogli gli estremi del file XML e del foglio di stile, si realizza on-line quello che nel secondo caso si realizzava off-line, ovvero, il controllo di validazione, e la costruzione di un file HTML frutto dell'applicazione del foglio di stile (in questo caso si puo' usare XSL che microsoft ha proposto al consorzio). Nella demo che segue viene utilizzato questo metodo per due motivi, perchè non necessita l'installazione e la conoscenza di software oltre ad Explorer e perchè permette di visualizzare i passaggi senza dover ogni volta "pregenerare" i file HTML.

Demo

 Come si è visto un Processor vero e proprio in grado di mandare direttamente in output un file XML non esiste ancora, ed è quindi necessario per il momento appoggiarsi ad altre tecnologie. In questa demo verrà utilizzato un ActiveX Microsoft che inserito in una pagina HTML la compone dinamicamente prendendo come input file XML e XSL. Per questi va comunque chiarito che la sintassi XSL utilizzata da questo ActiveX non è quella delle ultime raccomandazioni del consorzio W3C bensì quella della proposta dello scorso anno. Va premesso che l'ActiveX gira esclusivamente su Windows 95 e NT con Internet Explorer 4.0 o successive release. Nel corso della demo le sarà possibile visualizzare il risultato dei singoli passi cliccando il bottone in fondo alla pagina, ma sara' anche possibile copiare ed incollare via via le stringhe.Per renderle più visibili, d'ora in poi userò il colore rosso per le stringhe da copiare e incollare.

Vediamo allora per prima cosa come deve essere usato questo ActiveX per creare la pagina HTML che poi sarà quella effettivamente usata dal browser per visualizzare la demo. L'ActiveX non deve essere installato e va richiamato inserendo nell'HEAD del documento HTML il seguente <OBJECT>:

<OBJECT ID="XSLControl"
        CLASSID="CLSID:2BD0D2F2-52EC-11D1-8C69-0E16BC000000"
        codebase="http://www.microsoft.com/xml/xsl/msxsl.cab"
        style="display:none">
</OBJECT>

Questo comando no fa altro che richiamare ed installare automaticamente il file. La prima volta che si lancia il file che contiene l'ActiveX avviene un download che impiega circa 30 secondi. Sia il CLASSID che il codebase sono sempre quelli per cui la cosa migliore è cominciare copiando le stringhe incollandole nel proprio file HTML. A questo oggetto vanno passati due parametri, che rappresentano il file XML da processare e il foglio di stile XSL da usare per la formattazione. Entrambi questi valori sono quindi variabili al variare dei file da utilizzare. In questo daso saranno chiamati "esempio.xml" ed "esempio.xsl", così come il file HTML sarà chiamato "esempio.htm". Tutti e tre, a meno di uso copia e incolla possono perciò essere modificati. Alla fine pertanto l'oggetto sarà così definito:

<OBJECT ID="XSLControl"
        CLASSID="CLSID:2BD0D2F2-52EC-11D1-8C69-0E16BC000000"
        CODEBASE="http://www.microsoft.com/xml/xsl/msxsl.cab"
        STYLE="display:none">
  <PARAM NAME="documentURL" VALUE="esempio.xml">
  <PARAM NAME="styleURL" VALUE="esempio.xsl">
</OBJECT>

L'Activie ha una proprietà "HtmlText" che processa il file XML secondo le definizioni contenute nel file XSL e le trasforma in una stringa HTML. Per attivare questa proprietà va inserita, sempre nell'HEAD del documento la seguente istruzione:

<SCRIPT FOR=window EVENT=onload>
  var xslHTML = XSLControl.htmlText;
  document.all.item("xslTarget").innerHTML = xslHTML;
</SCRIPT>

Infine l'elemento xslTarget definito sopra come destinatario del risultato del processo va inserito nel BODY del documento:

<DIV id=xslTarget></DIV>

visualizza l'esempio


Abbiamo visto come i documenti XML siano di due tipi, ovvero ben formati e validi, la cui differenza sta nella presenza o meno di un DTD. Cominciamo a vedere i primi passi nella costruzione di un documento ben formato, ovvero di un documento che, non facendo riferimento ad un aprticolare DTD, deve semplicemente sottostare alle regole base della sintassi XML ovvero la correttezza della dichiarazione, la presenza di un elemento radice, e la correttezza dgli annidamenti per cui se un elemento inizia all'interno di un altro, all'interno di questo deve anche chiudersi. Quello che andremo via via a costruire sarà un file chiamato "esempio.xml", lo stesso file che viene preso dal documento "esempio.htm" come sorgente da processare.

Il primo passo è rappresentato dalla dichiarazione che dice al parser e al processor che quel file fa riferimento a quelle particolari specifiche e che determina il richiamo o meno di un DTD.

<?xml version="1.0" standalone="yes"?>

Al momento le specifiche 1.0 sono le uniche disponibili per cui quello è l'unico valore accettato ma in futuro, se il consorzio rilasciasse versioni successive sarebbe l'attributo "version" a determinarne la scelta. L'attributo "standalone" dichiara in questo caso che il file è "solo" e non rimanda ad alcun DTD. Altra regola rilevante per un documento ben formato è quella che vincola alla presenza di un elemento radice, che rappresenta il padre di tutti gli altri elementi e che non può contenere testo; è qualcosa di paragonabile all'elemento <HTML> di HTML. In questo caso chiamiamolo "RADICE", anche se in realtà è buon uso dare all'elemento radice un nome che sintetizzi il focus del documento.

<?xml version="1.0" standalone="yes"?>
<RADICE>

</RADICE>

A questo punto non rimane che inserire all'interno dell'elemento radice i vari elementi destinati a contenere il testo. Ipotizziamo un documento che elenchi tre libri utilizzando l'autore, il titolo una breve descrizione e il costo. In questo caso sarebbe stato meglio chiamare <ELENCO> l'elemento radice ma non fa niente. Gli elementi da inserire sono 5: innanzi tutto "libro" e dentro di lui 4 figli, "autore", "titolo", "descrizione" e "prezzo".

<?xml version="1.0" standalone="yes"?>
<RADICE>

<LIBRO>
<AUTORE></AUTORE>
<TITOLO></TITOLO>
<DESCRIZIONE></DESCRIZIONE>
<PREZZO></PREZZO>
</LIBRO>

</RADICE>

Ovviamente il blocco dell'elemento <LIBRO> e degli elementi suoi figli deve essere ripetuto una volta per ogni libro e Ogni elemento deve essere anche riempito con il testo in questo modo:

<?xml version="1.0" standalone="yes"?>
<RADICE>

<LIBRO>
<AUTORE>Giovanni Boccaccio</AUTORE>
<TITOLO>Decameron</TITOLO>
<DESCRIZIONE>10 persone in fuga dalla peste raccontano per 10 giorni una novella ciascuno</DESCRIZIONE>
<PREZZO>£ 25.000</PREZZO>
</LIBRO>

</RADICE>

Non essendo ancora stato costruito il foglio di stile relativo è ancora impossibile visualizzare il file "esempio.htm" se non nella sua struttura.

visualizza l'esempio

A questo punto bisogna assegnare una tipologia di formattazione agli elementi del file "esempio.htm", ad eccezione dell'elemento radice non viene mai visualizzato, anche se è necessario. La prima cosa da fare è inserire l'elemento radice che apre e chiude il file XSL:

<RADICE>

</RADICE>

All'interno di questo ogni elemento che si vuole visualizzare deve essere riconosciuto e associato ad una certa formattazione. Entrambe le operazioni rappresentano la regola associata a quell'elemento e devono essere contenute all'interno del tag <rule>. Iniziando dall'elemento <LIBRO> che non ha contenuto ma che potrebbe essere associato ad una linea di demarcazione possiamo scrivere:

<RADICE>

<rule>
<target-element type="LIBRO"/>
<HR>
<children/>
</HR>
</rule>

</RADICE>

Attraverso l'elemento "target-element" si dichiara quella "rule" come relativa all'elemento associato all'attributo "type", in questo caso LIBRO e poi si associano a questo i tag HTML con i quali si vuole formattare l'elemento. il tag <children/> è strettamente necessario. Con questo tipo di informazioni associate all'elemento LIBRO, per ogni ricorrenza di questo all'interno del file XML ci sarà una riga di demarcazione. Per ogni elemento va poi fatta la stessa cosa, scegliendo il tipo di formattazione che si desidera. Decidiamo di visualizzare l'autore in marrone e un po' più grande del resto del testo, il titolo e la descrizione in blu con quest'ultima più piccola ed infine il prezzo in rosso e con font "italic". Avremo un file del genere:

<RADICE>
<rule>
<target-element type="LIBRO"/>
<HR>
<children/>
</HR>
</rule>

<rule>
<target-element type="AUTORE"/>
<H3 color="brown">
<children/>
</H3>
</rule>

<rule>
<target-element type="TITOLO"/>
<H4 color="#000080">
<children/>
</H4>
</rule>

<rule>
<target-element type="DESCRIZIONE"/>
<H5 color="#000080" font-style="italic">
<children/>
</H5>
</rule>

<rule>
<target-element type="PREZZO"/>
<P color="red" font-style="italic">
<children/>
</P>
</rule>

</RADICE>

visualizza l'esempio

Vediamo ora come procedere nella costruzione di un documento valido, overo associato ad uno specifico DTD, il che vuol dire fare riferimento ad una sintassi più articolata e complessa che prende in considerazione entità, attributi e altro. Va chiarito innanzi tutto che ogni documento valido deve anche essere ben formato, ovvero deve sottostare alle regole generali del linguaggio XML viste nella prima parte della demo, a cominciare dalla dichiarazione di tipo del documento che in questo caso sarà:

<?xml version="1.0" standalone="no"?>

con standalone che assume il valore "no" perchè al documento è associato un DTD. L'associazione del DTD avviene immediatamente dopo per mezzo del nome che deve necessariamente essere quello dell'elemento radice (nel nostro caso "RADICE") e del path del file. Il tutto attraverso l'elemento DOCTYPE preceduto da "!":

<?xml version="1.0" standalone="no"?>
<!DOCTYPE RADICE system "esempio2.dtd">

In questo caso quindi si dice al processor che il documento XML va processato e verificato in base alla sintassi contenuta all'interno del file "esempio2.dtd". Per chiarezza va notato come tutti i file relativi a questa seconda parte della demo avranno nome "esempio2" seguito da un'estensione che renda immediatamente leggibile il tipo di file. Nel caso di un documento valido le regole relative alla rappresentazione, come nel caso del documento ben formato si trovano nel foglio di stile, in questo caso "esempio2.xsl" per cui tutto rimane uguale. Lo stesso si può dire del file XML che è di fatto il contenitore delle informazioni e che in questo caso si chiama "esempio2.xml" e per il file HTML che contiene l'ActiveX in grado di processare il tutto, in questo caso "esempio2.htm". L'unica variante stà nel fatto che il documento XML verra' controllato dal parser non più soltanto in base alle poche regole che fanno di un documento un documento ben formato XML, ma in base alle definizioni date nel DTD, nel nostro caso quindi in un nuovo file, "esempio2.dtd" che deve essere creato. Nel DTD deve essere definito ogni elemento che si intende utilizzare nel documento XML. Nel caso del nostro esempio quindi: RADICE, LIBRO, AUTORE, TITOLO, DESCRIZIONE e PREZZO. Bisogna anche fare caso a come si strutturano gerearchicamente i vari elementi ovvero nel nostro caso sarà proprio nel DTD che andremo a dire al processor che RADICE è l'elemento radice che contiene vari elementi LIBRO, composti a loro volta di quattro elementi, AUTORE, TITOLO, DESCRIZIONE e PREZZO. Quindi per prima cosa definiremo l'elemento RADICE:

<!ELEMENT RADICE (LIBRO+)>

Da notare che la definizione avviene all'interno dei simboli "<" ">" attraverso il tag ELEMENT. Tra parentesi l'elenco degli elementi figli, in questo caso solo uno, LIBRO, seguito da un "+" che indica che possono essere in numero variabile. Va poi definito l'elemento LIBRO:

<!ELEMENT RADICE (LIBRO+)>
<!ELEMENT LIBRO (AUTORE,TITOLO,DESCRIZIONE,PREZZO)>

tra parentesi gli elementi figli di LIBRO che vanno poi definiti come elementi destinati a contenere del testo. Questo avviene attraverso la struttura "#PCDATA":

<!ELEMENT RADICE (LIBRO+)>
<!ELEMENT LIBRO (AUTORE,TITOLO,DESCRIZIONE,PREZZO)>
<!ELEMENT AUTORE (#PCDATA)>
<!ELEMENT TITOLO (#PCDATA)>
<!ELEMENT DESCRIZIONE (#PCDATA)>
<!ELEMENT PREZZO (#PCDATA)>

Cliccando sul bottone sotto si potrà vedere come, attraverso una struttura diversa, più rigida ma più affidabile, si arriva allo stesso risultato. Questo perchè per il testo e per la sua rappresentazione sono stati usati di fatto gli stessi documenti. Modificando il testo nel file "esempio2.xml" o i criteri di formattazione nel file "esempio2.xsl", si potranno vedere i diversi effetti generati.

visualizza l'esempio


In linea di massima il DTD, che concettualmente è l'area in cui viene definita la struttura del documento, è un file esterno che come abbiamo visto viene collegato al file XML. In realtà è possibile effettuare una seconda scelta, ovvero quella di posizionare il DTD non esternamente bensì all'interno del documento XML, subito dopo la dichiarazione. In questo caso non avremo più nel documento XML una dichiarazione del tipo:

<?xml version="1.0" standalone="no"?>
<!DOCTYPE RADICE system "esempio2.dtd">

bensì del tipo:

<?xml version="1.0" standalone="no"?>
<!DOCTYPE RADICE []!>

con all'interno delle parentesi quadre tutte le dichiarazioni degli elementi fatte in precedenza nel DTD esterno, ovvero:

<?xml version="1.0" standalone="no"?>
<!DOCTYPE RADICE [
<!ELEMENT RADICE (LIBRO+)>
<!ELEMENT LIBRO (AUTORE,TITOLO,DESCRIZIONE,PREZZO)>
<!ELEMENT AUTORE (#PCDATA)>
<!ELEMENT TITOLO (#PCDATA)>
<!ELEMENT DESCRIZIONE (#PCDATA)>
<!ELEMENT PREZZO (#PCDATA)>
]!>

XML secondo Microsoft e Netscape

L’interesse che XML è riuscito a creare intorno a se’ ha spinto Netscape e Microsoft ad implementare, o prevedere di farlo a breve termine, le estensioni di tale sistema. Come sempre accade, le due software house hanno sviluppato tecnologie differenti, ognuna delle quali presentata al W3C per la definitiva standardizzazione.

Il formato CDF (Channel Definition Format) è stato progettato da Microsoft per consentire agli autori Web di personalizzare e ottimizzare il recapito di informazioni. Tale formato consente di scaricare il materiale desiderato, senza necessità di consultare grandi quantità di files per estrarne, in fondo, solo una piccola parte. Lo standard CDF è un’applicazione di XML attualmente allo studio del W3C. Poiché si basa su XML, il formato di file CDF può essere interpretato da vari parser HTML esistenti.

IE 4 è, a tutt’oggi, l’unico browser capace di gestire applicazioni XML.

Netscape, dal canto suo, ha presentato una nuova infrastruttura standard per metadati denominata RDF (Resource Description Format). Come CDF anche RDF si basa su XML ed è attualmente al vaglio del W3C per una possibile standardizzazione. RDF è parte integrante di "Aurora", futuro componente di Netscape Communicator 5, volto all’integrazione tra desktop e informazioni presenti in Rete, nonché alla fornitura automatica di dati ("push").

Netscape ha in programma di inserire ulteriori parser XML quali: Chemical Markup Language (CML) e Mathematical Markup Language (MathML).

Il futuro di XML dipende, in misura determinante, dall’integrazione che tale sistema riuscirà a stabilire con le specifiche del Document Object Model.

L’indubbio impatto positivo che XML ha nella compilazione di documenti per il Web, fa ben sperare coloro che vedono in esso il degno successore di HTML.

Links
XML W3C Raccomendation http://www.w3.org/Press/1998/XML10-REC
XML di Microsoft http://www.microsoft.com/xml/
XML.com http://www.xml.com/
XSL di W3C http://www.w3c.org/Style/XSL/
SGML Open http://www.sgmlopen.org/
XLL di W3C http://www.w3.org/TR/WD-xml-link

Glossary
W3C World Wide Web Consortium
SGML Standard Generalized Markup Language (ISO 8879:1986)
XML eXtensible Markup Language
XSL eXtensible Style Language
XLL eXtensible Linking Language
DTD Document Type Definition
PCDATA Parsed Character Data
Xlink XML Link Language
XPointer XML Pointer Language
XQL XML Query Language
DSSSL Document Style Semantic and Specification Language (ISO/IEC 10179:1996.)
CSS Cascading Style Sheets
HyTime Hypermedia/Time-based Structuring Language (ISO 10744)
RDF Resource Description Framework (applicazioni nei motori di ricerca)
CDF Channel Definition Format (applicazioni alla nascente tecnologia di tipo "push", grazie alla quale l'utente può scegliere cosa i server possono inviargli)
OFX Open Financial Exchange (applicazioni finanziarie)
EDI Electronic Data Interchange
OSD Open Software Description format (descrizione del software con XML)
CML Chemical Markup Language
MML Mathematical Markup Language (descrizione di strutture matematiche sul Web)
DOM Document Object Model

Other...

 Questa situazione, che ripercorre la storia già vissuta per HTML negli anni passati, potrebbe tuttavia cambiare nei prossimi mesi. Infatti il W3C ha avviato un progetto per proporre uno standard in questo campo, denominato Document Object Model (DOM). Esso dovrebbe fornire un insieme di specifiche indipendenti da particolari piattaforme o da particolari linguaggi di script per manipolare gli oggetti che compongono una pagina Web. Nel momento in cui scriviamo il lavoro di specificazione dello standard non è ancora terminato, ma alcuni aspetti dell'interfaccia sono già stati definiti (per informazioni il sito di riferimento è http://www.w3.org/DOM).


Il progetto Voyager
Il nome assegnato al progetto è "Voyager".
I documenti Voyager saranno identificati alle applicazioni, quindi ai browser, sia come text/html che text/xml. I browser distingueranno i documenti Voyager da quelli html puri per la presenza dell'attributo xmlns all'interno dell'elemento <html>:
<html xmlns="http://www.w3.org/Profiles/voyager-strict">
In questo modo i documenti Voyager, seguendo poche semplici linee guida, potranno venire visualizzati all'interno dei browser esistenti, al fine di garantire una graduale migrazione.


Perchè XML
Why do we need XML when everyone's browser supports HTML today? To answer this question, look at the sample HTML Code shown. HTML tags are for browsing; they're meant for interactions between humans and computers.

Sig. Alberto Bellina
via Ca' Paletta, 11
Negrar (VR)




Un BNF semplificato
<!ELEMENT rules (comment|start|end|rule|parameters)*>
<!ATTLIST rules
          outputMode (xml|none)   "none">
<!ELEMENT rule (#PCDATA|process-children)*>
<!ATTLIST rule
          query    CDATA   ".*"
          name     CDATA   #IMPLIED
          continue (true|false) "false"
          test     CDATA   #IMPLIED >
<!ELEMENT start (#PCDATA)>
<!ELEMENT end (#PCDATA)>
<!ELEMENT process-children EMPTY>
<!ELEMENT parameters EMPTY>          <!-- arbitrary number of attributes allowed on this -->
<!ELEMENT comment ANY>



Rendering HTML
When rendered, the HTML in the previous example looks like this. As you can see, HTML tags describe how something should render. They don't contain any information about what the data is, they only describe how it should look.

Sig. Alberto Bellina
via Ca' Paletta, 11
Negrar (VR) 37024

Sample XML Code
Now let's look at some sample XML Code. With XML, you can understand the meaning of the tags. More importantly, a computer can understand them as well. It's easier for a computer to understand that the tag <zipcode>34829</zipcode> is a zip code.

<address>
<name>
<title>sig</title>
<first-name>Alberto</first-name>
<last-name>Bellina</last-name>
</name>
<street>via Ca' Paletta, 11</street>
<city>Negrar</city>
<state>VR</state>
<zipcode>37024</zipcode>
...
</address>
Rendering XML
XML from the previous example might be rendered like this. Notice that even though the tags are different, they can still be rendered just like HTML.
A Second Rendering of XML
By applying a different stylesheet to the same document, an XML document can be rendered in different formats. The key is that with XML the information is in the document, while the rendering instructions are elsewhere. In other words, content and presentation are separate.
How XML Will Change the Web
XML applications provide many advantages. Let's talk about several of those now.

XML's strongest point is its ability to do data interchange. Because different organizations (or even different parts of the same organization) rarely standardize on a single set of tools, it takes a significant amount of work for two groups to communicate. XML makes it easy to send structured data across the web so that nothing gets lost in translation.
Enable Business to Business Communication
When using XML, I can receive XML-tagged data from your system, and you can receive XML-tagged data from mine. Neither of us has to know how the other's system is organized. If another partner or supplier teams up with my organization, I don't have to write code to exchange data with their system. I simply require them to follow the document rules defined in the DTD.
Enable Smart Agents
When writing an agent, one of the challenges is to make sense of incoming data. A good agent interprets information intelligently, then responds to it accordingly. If the data sent to an agent is structured with XML, it's much easier for the agent to understand exactly what the data means and how it relates to other pieces of data it may already know.
Enable Smart Searches
One major problem with today's web is that search engines can't process HTML intelligently. For example, if you search on "chip" when you're looking for someone named Chip, you might get pages on chocolate chips, computer chips, and guys named Chip. But if there were a DTD for name and address records, searching for a guy named Chip could generate much more accurate and useful search results.
Accessing XML on the Client
XML changes the way data moves across networks. XML encapsulates data inside custom tags that carry semantic information about the data. A common question is, "Once I've got some XML-tagged data, how do I view it?"
The XML Enabler
The architecture of the XML Enabler is simple. When a browser attempts to load an XML document, the XML Enabler looks at the type of browser that requested the document. The XML Enabler then selects a stylesheet written in the Extensible Stylesheet Language, or XSL, based on the browser type.

The XML Enabler retrieves the requested XML document, processes it with the appropriate stylesheet, and returns the results to the browser. This allows you to generate different views of an XML document, and each view takes advantage of as many browser features as possible.
Implementation
The XML Enabler is implemented as a Java servlet. It is built on the XML4J parser from IBM and the Lotus XSL Processor, both of which are available on IBM's alphaWorks site. All of the code is written in Java, so it's platform independent.

SAX events
The SAX API defines a number of events. You can write Java code that handles all of the events you care about. If you don’t care about a certain type of event, you don’t have to write any code at all. Just ignore the event, and the parser will discard it.

A wee listing of SAX events
We’ll list most of the SAX events here and on the next panel. All of the events on this panel are commonly used; the events on the next panel are more esoteric. They’re part of the HandlerBase class in the org.xml.sax package.

More SAX events
Here are some other SAX events:
A note about SAX interfaces
The SAX API actually defines four interfaces for handling events: EntityHandler, DTDHandler, DocumentHandler, and ErrorHandler. All of these interfaces are implemented by HandlerBase.
Most of the time, your Java code will extend the HandlerBase class. If you want to subdivide the functions of your code (maybe you’ve got a great DTDHandler class already written), you can implement the xxxHandler classes individually.

The Parsers

Kinds of parsers
There are several different ways to categorize parsers:

Validating versus non-validating parsers
As we mentioned in our first tutorial, XML documents that use a DTD and follow the rules defined in that DTD are called valid documents. XML documents that follow the basic tagging rules are called well-formed documents.

The XML specification requires all parsers to report errors when they find that a document is not well-formed. Validation, however, is a different issue. Validating parsers validate XML documents as they parse them. Non-validating parsers ignore any validation errors. In other words, if an XML document is well-formed, a non-validating parser doesn’t care if the document follows the rules specified in its DTD (if any).
Why use a non-validating parser?
Speed and efficiency. It takes a significant amount of effort for an XML parser to process a DTD and make sure that every element in an XML document follows the rules of the DTD. If you’re sure that an XML document is valid (maybe it was generated by a trusted source), there’s no point in validating it again.

Also, there may be times when all you care about is finding the XML tags in a document. Once you have the tags, you can extract the data from them and process it in some way. If that’s all you need to do, a non-validating parser is the right choice.
The Document Object Model (DOM)
The Document Object Model is an official recommendation of the World Wide Web Consortium (W3C). It defines an interface that enables programs to access and update the style, structure, and contents of XML documents. XML parsers that support the DOM implement that interface.

The first version of the specification, DOM Level 1, is available at http://www.w3.org/TR/REC-DOM-Level-1, if you enjoy reading that kind of thing.
What you get from a DOM parser
When you parse an XML document with a DOM parser, you get back a tree structure that contains all of the elements of your document. The DOM provides a variety of functions you can use to examine the contents and structure of the document.
A word about standards
Now that we’re getting into developing XML applications, we might as well mention the XML specification. Officially, XML is a trademark of MIT and a product of the World Wide Web Consortium (W3C).
The Simple API for XML (SAX)
The SAX API is an alternate way of working with the contents of XML documents. A de facto standard, it was developed by David Megginson and other members of the XML-Dev mailing list.

To see the complete SAX standard, check out www.megginson.com/SAX/. To subscribe to the XML-Dev mailing list, send a message to majordomo@ic.ac.uk containing the following: subscribe xml-dev.
What you get from a SAX parser
When you parse an XML document with a SAX parser, the parser generates events at various points in your document. It’s up to you to decide what to do with each of those events.

A SAX parser generates events at the start and end of a document, at the start and end of an element, when it finds characters inside an element, and at several other points. You write the Java code that handles each event, and you decide what to do with the information you get from the parser.
Why use SAX? Why use DOM?
We’ll talk about this in more detail later, but in general, you should use a DOM parser when:
Use a SAX parser if you only need to extract a few elements from an XML document. SAX parsers are also appropriate if you don’t have much memory to work with, or if you’re only going to use the information in the document once (as opposed to parsing the information once, then using it many times later).
XML parsers in different languages
XML parsers and libraries exist for most languages used on the Web, including Java, C++, Perl, and Python. The next panel has links to XML parsers from IBM and other vendors.

Most of the examples in this tutorial deal with IBM’s XML4J parser. All of the code we’ll discuss in this tutorial uses standard interfaces. In the final section of this tutorial, though, we’ll show you how easy it is to write code that uses another parser.
Resources - XML parsers
Java
C++
Perl
Python
Summary
The heart of any XML application is an XML parser. To process an XML document, your application will create a parser object, pass it an XML document, then process the results that come back from the parser object.

We’ve discussed the different kinds of XML parsers, and why you might want to use each one. We categorized parsers in several ways:
In our next section, we’ll talk about DOM parsers and how to use them.

The Document Object Model (DOM)

The DOM is a common interface for manipulating document structures. One of its design goals is that Java code written for one DOM-compliant parser should run on any other DOM-compliant parser without changes. (We’ll demonstrate this later.)
As we mentioned earlier, a DOM parser returns a tree structure that represents your entire document.
DOM interfaces
The DOM defines several Java interfaces. Here are the most common:
Common DOM methods
When you’re working with the DOM, there are several methods you’ll use often:

Applying XML

Introduction In order to build XML applications, you will need to do four things:
Selecting or Writing a DTD
What is a DTD? A document type definition defines what tags can go in your document, what tags can contain other tags, the number and sequence of the tags, the attributes your tags can have, and optionally, the values those attributes can have.
Generating an XML Document
Think of the DTD as a template you fill in. For each element, get the data from its location such as a database query, a full-text search, or a directory query, and then simply put it in the template.
When the template is full (all the required elements are filled in and the document is valid), you can send it to the requestor of the document.
Interpreting XML Documents
When you need to interpret an XML document, there are two APIs you can use: The Document Object Model, or DOM, and the Simple API for XML, or SAX.
The DOM is a standard of the World Wide Web Consortium that creates a tree view of your XML document. The DOM provides standard functions for manipulating the elements in your document.
Interpreting XML Documents
The SAX API notifies you when certain events happen as it parses your document. When you respond to an event, any data you don't specifically store is discarded.

SAX or DOM?
Why would you use SAX or DOM? If your document is very large, using SAX will save significant amounts of memory when compared to using DOM. This is especially true if you only need a few elements in a large document. On the other hand, the rich set of standard functions provided by the DOM isn't available when you use SAX.

Displaying XML Documents
There are several ways you can display XML documents. If your browser can display XML, you can simply send the document out to the browser. Or use an XSL stylesheet to transform the XML into something your browser can handle. An XSL stylesheet contains some number of templates that define how the elements in an XML document should be transformed.

If you want to do complicated sorting or restructuring that's beyond the realm of XSL, use DOM. In this method, you parse the XML document, then write Java code to manipulate the DOM tree in whatever way you wish. Your code has complete access to the DOM and all of its methods, so you're not bound by the limitations or design decisions of XSL.