Introduzione a XML
di Gianluca Torta
Dopo diversi anni in cui il Web è stato dominato quasi esclusivamente da
HTML (e sue estensioni proprietarie), si è recentemente posta all'attenzione
della comunità internet una nuova tecnologia: XML (eXtensible Markup
Language).
Essa non è sostitutiva di HTML (anche se per alcuni aspetti possono
sovrapporsi), riflette invece nuove necessità nate dall'evoluzione del Web da
una collezione statica di contenuti da leggere (o guardare, ascoltare, ...) ad
una piattaforma applicativa.
Non che fino ad XML lo sviluppatore non avesse alcuno strumento per creare
applicazioni Web dinamiche: basta pensare, per esempio, sul lato server
ai CGI, a PHP, ai Java Servlet, ad ASP; e, sul lato client, all'embedded
scripting, alle applet Java o a DHTML.
Quello che mancava, essenzialmente, era un formato standard di
interscambio di informazioni applicative; l'effettivo scambio di tali
informazioni tra browser e server avveniva in uno dei seguenti modi: o tramite
codice HTML (quindi per mezzo di <FORM> che mescolano la
definizione dei dati con il modo in cui devono essere visualizzati), o usando
qualche protocollo applicativo proprietario definito tra la applet ed
il servlet. Lo standard XML tenta di colmare questa lacuna che è un ostacolo
fondamentale allo sviluppo delle applicazioni Web.
Voglio sottolineare subito, comunque, che le applicazioni di XML vanno già
ora ben al di là del Web anche se, trattandosi di un formato di interscambio,
esso presuppone per lo più l'esistenza di diverse applicazioni comunicanti su
una rete.
Un esempio abbastanza significativo è la probabile affermazione di XML nel
campo dell'EDI (Electronic Data Interchange), al posto di formati come ASC X12
e EDIFACT, nell'interscambio di documenti elettronici tra aziende ed altri
enti (si veda per esempio ebXML).
Un'altra applicazione promettente è l'uso di XML per la persistenza
di oggetti run-time, concetto ben noto noto ai programmatori di
linguaggi OO o di componenti distribuiti. In sostanza, si tratta di "ibernare"
lo stato di un oggetto (per esempio una classe Java) su disco, in modo da
riprendere l'esecuzione successivamente dallo stesso stato in cui era stata
interrotta.
L'ubiquità di XML come futura lingua franca si può facilmente vedere
dalla varietà di domini in cui già esistono o sono in fase di realizzazione
specifiche di interscambio che si fondano su di esso: oltre al già citato
settore dell'e-business, esistono applicazioni XML per lo scambio di
informazioni di tipo matematico, grafico, di multimedia e di statistica (solo
per citarne alcune).
Anche il mondo dei DBMS (e del data-access in generale), naturalmente, si è
accorto di XML e i principali prodotti commerciali e non, insieme a database
sperimentali per ora accademici, tentano di supportare XML in modo più
o meno profondo.
In questo articolo introduttivo, cercherò di spiegare un po' le origini e
in cosa consiste XML, e di descrivere e organizzare brevemente alcune delle
tante tecnologie e standard collegati ad esso (in continuo incremento) per
fare un po' di chiarezza sulle principali buzzword che ci compaiono
continuamente davanti quando leggiamo a proposito di XML. Infine, per i
programmatori, accennerò a quali sono correntemente i modelli più diffusi per
scrivere applicazioni che manipolano XML.
In eventuali futuri articoli, potrò approfondire uno qualunque degli
argomenti abbozzati qui, oppure affrontare altri aspetti quali:
- implementazione di soluzioni con XML
- specifici tool legati a una piattaforma o a un sistema operativo, o
funzionalità XML presenti nei server http e nei browser
- applicazioni specifiche di XML (come quelle citate sopra, tra cui i
Database)
Ma questo lo deciderete voi lettori.
Indice
XML (versione 1.0) deriva come HTML dalla specifica di SGML (Standard
Generalized Markup Language) ed è gestito dal WWW
Consortium.
Dunque è un altro "markup language", ovvero i documenti XML sono costituiti
essenzialmente da tag che possono avere attributi e contenere ricorsivamente
altri tag, dando luogo a una struttura gerarchica ad albero. Per esempio:
<?XML version="1.0" ?>
<tag1>
<tag2 att2="x"/>
<tag2 att2="y"/>
</tag1>
Ci sono alcune semplici regole affinché un file come quello dell'esempio
sia considerato ben formato (well-formed XML); per esempio:
- deve esserci una sola "radice" (root), ovvero il file deve contenere un
solo albero
- i nomi di tag e attributi sono case-sensitive.
- ogni tag "aperto" (
<tag1>) deve essere
"chiuso"(</tag1>) e non è ammesso avere strutture che
si intersecano (al contrario di HTML), ovvero non è ammesso:
<tag1><tag2></tag1></tag2>
Sono regole alquanto semplici; dove sta dunque la potenza di XML, così
spesso sbandierata con più o meno cognizione di causa dai suoi
sostenitori?
Le principali differenze tra XML e HTML sono due, e sono in relazione l'una
all'altra:
- mentre in HTML i tag sono predefiniti dal W3C, in XML ogni utente o
gruppo di utenti può definire i suoi tag preferiti. Un insieme di tag
definiti per un dominio specifico e' detto vocabolario XML.
Un esempio che potrà risultare familiare è XHTML, ovvero la ridefinizione
(ed estensione) di HTML basata sulla sintassi XML.
- mentre lo scopo di HTML è descrivere l'apparenza grafica (layout) di una
pagina in modo indipendente dal sistema operativo su cui verrà
visualizzata, lo scopo di XML è quello di strutturare delle informazioni
secondo la logica richiesta dall'applicazione. Come caso particolare,
certo, si può così definire il layout del contenuto (vedi XHTML), ma l'uso
principale è quello di descrivere relazioni più profonde tra le
informazioni. L'applicazione di uno Stylesheet XSL (eXtensible Stylesheet
Language) potrà poi occuparsi della visualizzazione grafica della pagina,
magari trasformandola "al volo" in (X)HTML.
Detto questo, XML definito come l'abbiamo ora, può anche avere un grande
potenziale, ma difficilmente può essere usato in modo convincente per
risolvere problemi reali.
Per fortuna, insieme ad esso sono stati definiti tutta una serie di
standard "ausiliari", e le aziende più importanti nel campo del software hanno
implementato una parte più o meno consistente di essi, più eventuali
estensioni ed altri strumenti di sviluppo.
Un concetto molto importante è per esempio la nozione di validità di
un documento XML, dato che il concetto di documento well-defined è
troppo generico e "debole". Abbiamo visto che in realtà le applicazioni fanno
uso di vocabolari XML di pertinenza al loro dominio; abbiamo bisogno
perciò di uno strumento per la definizione formale e la validazione dei
documenti elaborati dall'applicazione rispetto al vocabolario usato.
La validità ha dunque a che fare con quali elementi e attributi il
documento può usare, la compatibilità dei valori degli attributi con un tipo
predefinito, e la struttura logica del documento stesso. Diverse proposte,
nate in tempi diversi, coesistono per la definizione di validità, come vedremo
nel prossimo paragrafo (DTD, XDR, XSD).
In pratica, per mezzo di queste tecnologie, è possibile validare un
documento XML allo stesso livello (e in alcuni casi anche superiore) di quello
applicato da un normale browser di fronte a un documento HTML. Ma ricordiamoci
che sia i tag che la struttura di un documento XML non sono predefiniti da
W3C, di qui la necessità di DTD, XDR o XSD.
Un'altra specifica fondamentale riguarda la possibilità di "trasformare" un
documento XML attraverso uno stylesheet, un po' come avviene coi documenti
HTML e i CSS. Vedremo che XSL è in effetti molto più potente di CSS,
riflettendo la necessità legata a XML di trasformazioni più complesse.
Una delle prime domande che può venire in mente a uno sviluppatore, a
questo punto, può essere: se voglio scrivere una applicazione XML, dovrò
reinventare la "ruota", ossia un parser, un validatore, ecc. ecc.? Niente
paura, anche di questo si è preso cura il W3C (con il suo DOM) e esiste almeno
un altro modello (con relative implementazioni) che, di fatto, è altrettanto
standard (SAX).
Dunque, qualunque (o quasi) sia la vostra piattaforma di sviluppo, non
preoccupatevi: qualche compagnia o la Open Source Community hanno già
preparato dei tool che vi solleveranno da tutti i dettagli che non riguardano
direttamente la vostra applicazione.
Il concetto di namespace in XML è molto simile a quello usato in linguaggi
di programmazione tipo Java e C++: permette di evitare collisioni tra i nomi
di elementi e attributi tramite l'uso di nomi qualificati, consistenti
in un prefisso che indica il namespace cui l'elemento appartiene seguito da un
nome locale a tale namespace. Per esempio <ns1:tag1>
e <ns2:tag1> sono due elementi distinti, pur avendo lo
stesso nome locale tag1 .
I namespace sono in realtà identificati da URI (Uniform Resource
Identificator) e associati a particolari prefissi nel file XML stesso, tramite
l'uso dell'attributo xmlns:
<root xmlns:ns1="http://www.acme.org/ns1">
<ns1:tag1 ns1:att1="value1"/>
</root>
Una cosa importante riguardo gli XML namespace (e che li distingue da
quelli Java e C++) è che non implicano, di per sé, l'esistenza di alcun file o
risorsa contenente la dichiarazione degli elementi e attributi che essi
contengono. L'URI usato come valore dell'attributo xmlns in genere non
si risolve in alcuna risorsa effettivamente esistente su qualche server.
Esso serve semplicemente a identificare univocamente il namespace, in modo
che la applicazioni possano interpretare correttamente i tag riferentisi a
quel namespace.
Questa interpretazione, però potrebbe essere specificata da un
documento in linguaggio naturale o semplicemente da una serie di accordi presi
tra due o più partner. Solo se si è "fortunati" vi sarà un DTD (o XDR, o XSD)
che specifica formalmente gli elementi e attributi e le loro relazioni, ma
esso non si troverà, in generale, navigando all'URI che identifica il
namespace.
Come abbiamo menzionato sopra, la definizione di documento XML
well-formed è troppo debole per le esigenze di applicazioni XML
specifiche. Occorre potere definire la struttura dei documenti XML "corretti"
per una certa applicazione o dominio, inclusi i nomi dei tag e degli
attributi, le strutture permesse, i tipi degli attributi ecc. Tale definizione
costituisce un vocabolario XML.
Il primo tentativo in questo senso è la specifica DTD (Document Type
Definition), rilasciata da W3C insieme a XML 1.0. Un esempio di DTD è il
seguente:
<!ELEMENT Y (X)>
<!ELEMENT X (#PCDATA)>
<!ATTLIST X z CDATA #REQUIRED>
che definisce una struttura con radice Y, e un sottoelemento X con
attributo z obbligatorio. Il seguente documento XML è una delle tante
istanze valide secondo questo DTD:
<Y><X z="valore1">testoX</X>
</Y>
Lo standard DTD ha alcuni limiti, che lo stanno rendendo progressivamente
obsoleto per la validazione XML: prima di tutto, usa una sintassi diversa da
XML stesso, richiedendo dunque speciali tool per la creazione di schemi. Un
altro problema è l'assenza di tipi per gli attributi: in DTD, tutti gli
attributi sono semplicemente stringhe.
Molte proposte sono state inviate a W3C dall'industria ed altri enti per
superare i limiti di DTD: XDR (XML Data Reduced), DCD, DDML, XML-Data e
altre.
Partendo da esse, W3C ha recentemente elaborato e poi promosso a "Candidate
Recommendation" lo standard XML Schema (XSD). Esso è destinato molto
probabilmente a sostituire non solo DTD, ma anche i vari formati più o meno
proprietari come XDR.
Un XSD equivalente al DTD di sopra è il seguente:
<xsd:schema
xmlns:xsd="http://www.w3.org/2000/08/XMLSchema">
<xsd:element name="Y " type="Ytype "/>
<xsd:complexType name="Ytype">
<xsd:element name="X" type="Xtype"/>
</xsd:complexType>
<xsd:complexType name="Xtype">
<xsd:attribute name="z"
type="xsd:string"/>
</xsd:complexType>
</xsd:schema>
Come si vede, esso è un documento XML perfettamente well-formed.
Inoltre abbiamo specificato il tipo dell'attributo z come stringa;
avremmo potuto specificare uno qualunque degli altri tipi base definiti da
XSD.
Si noti anche l'uso di un namespace (dichiarato con l'attributo
xmlns:xsd). In realtà XSD, così come altri standard che vedremo
più sotto, è a sua volta un vocabolario XML contenuto in un namespace.
Abbiamo accennato a questo punto alla sintassi dei documenti XML e degli
schemi che ne specificano la struttura per particolari applicazioni.
Uno strumento necessario per processare tali documenti (sia tramite XSL/T
che tramite APIs, entrambi descritti nei paragrafi sotto) è un meccanismo per
selezionare specifici elementi o "regioni" all'interno di un documento.
Supponiamo che una mia applicazione di grafica sia interessata solo ai tag
<SHAPE> e al loro contenuto in un file XML di informazioni
grafiche. O supponiamo ancora che una applicazione di contabilità sia
interessata solo ai tag <ORDER> che hanno un attributo
amount con valore maggiore di 1.000.000. XPath fornisce un
meccanismo di selezione di regioni di un documento XML che permette di
eseguire le operazioni richieste dai nostri esempi, e naturalmente altre molto
più complesse.
Per dare un'idea della sintassi di XPath, le selezioni menzionate negli
esempi di sopra sarebbero espresse con i seguenti XPath:
//SHAPE
//ORDER[@amount > 1.000.000]
La utilità (o meglio necessità direi) di un meccanismo come XPath dovrebbe
diventare più evidente leggendo i paragrafi su XSL/T, XLink e la sezione sui
modelli di sviluppo di applicazioni XML più sotto.
Come per HTML esistono i CSS (Cascading StyleSheet) che permettono di
specificare il rendering dei TAG indipendentemente dal documento, anche XML ha
il suo Stylesheet Language chiamato XSL.
Nel caso di XML, anzi, esso è forse ancora più importante perché, come
abbiamo visto, un documento XML non specifica, in generale, come deve essere
visualizzato graficamente.
La specifica di XSL (attualmente in stato di Candidate
Recommendation) si divide in due parti ben distinte: quella riguardante la
definizione di un vocabolario XML per la specifica del rendering (detta
XSL/FO, eXstensible Stylesheet Language/Formatting Objects); quella
riguardante la definizione di un vocabolario XML per la trasformazione
di un documento XML in un diverso documento XML o di qualunque altro formato
(detta XSL/T, eXstensible Stylesheet Language/Transformation).
Mentre della prima ci sono ancora pochissime implementazioni e
applicazioni, molti parser XML commerciali e non supportano la XSL/T per la
sua straordinaria potenza. Con XSL/T è possibile ristrutturare completamente
il vostro documento, eliminandone alcune regioni, aggiungendone altre,
riformattandone altre, il tutto con la possibilità di calcolare dinamicamente
valori per elementi e attributi applicando funzioni XPath o, in alcune
estensioni proprietarie, anche embedded-scripting.
XML necessita, come HTML, di una sintassi per definire link da un
file XML a risorse interne o esterne al documento. In HTML, come è noto, gli
hyperlink sono espressi con tag <a> (o
<img>) contenenti un URI (Uniform Resource Identifier)
alla risorsa desiderata. Per XML, il W3C ha recentemente promosso a
Proposed Recommendation la definizione di XLink, il cui scopo è appunto
mimare ed estendere le funzionalità dei link HTML ai documenti XML.
XLink è assai più sofisticato degli hyperlink HTML: permette ad esempio di
specificare due risorse, quella di partenza e quella di arrivo del link,
anziché solo quella di arrivo come HTML. Questo permette, per esempio di
"aggiungere" un hyperlink su una pagina HTML esistente a cui abbiamo solo
accesso read-only.
L'attraversamento del link, inoltre, può essere controllato esplicitamente,
decidendo se dovrà aprire una nuova pagina o mostrare la risorsa nella pagina
corrente (magari aggiungendosi al contenuto del documento anzichè
rimpiazzandolo, come avviene in HTML per le immagini), e inoltre se
l'attraversamento del link richiede un'azione esplicita (come
mouse-click) oppure viene fatto automaticamente al momento del load del
documento.
Cosa succede se un link in un documento XML (o, se per questo, in un altro
tipo di risorsa, come un documento HTML) vuole "puntare" a una risorsa XML?
Naturalmente deve usare un URI, come accennato sopra, ma qual è la sintassi di
un URI quando si riferisce a un (frammento di) documento XML?
La risposta è XPointer, specifica del W3C strettamente legata a XLink ma
distinta da essa.
Così come in HTML possiamo riferirci a specifici tag del documento corrente
o di un altro documento con una sintassi tipo:
<a href="#section1">
oppure:
<a href="http://www.mysite.org/mydoc.html#section1">
in XML useremo un XLink in cui la sorgente o la destinazione specificano un
Xpointer. Gli XPointer sono molto potenti e si basano sulla sintassi XPath
(con ulteriori estensioni) per selezionare regioni qualunque all'interno di un
documento XML. Per esempio possiamo selezionare con un solo XPointer tutte le
occorrenze della parola "Diff" nel documento. Usando tale XPointer come
sorgente in un XLink la cui destinazione è la Home Page di Diff, possiamo
ottenere che tutte le occorrenze della parola "Diff" diventino hyperlink al
sito, specificando un unico XLink!
Non sono ancora molte le implementazioni di XLink, anche nei prodotti
commerciali più "evoluti". La recente promozione da Candidate a
Proposed Recommendation, però dovrebbe stimolarne una maggiore adozione
nel vicinissimo futuro.
Si parla sempre più, recentemente di Servizi Web. Essi costituiscono
un argomento molto vasto (e per lo più ancora non ben definito) e
meriterebbero un articolo a parte (che potrò cercare di scrivere se
l'argomento vi interessa), ma qui vorrei soltanto spiegare in breve che cosa
sono e in che relazione stanno con gli standard SOAP, WSDL, DISCO e UDDI.
Un Servizio Web è sostanzialmente un sito che può essere interrogato da
applicazioni tramite messaggi ben definiti e fornisce la risposta sotto forma
di uno o più messaggi. In parole povere, un sito Web senza interfaccia utente,
ma con un'interfaccia ben definita per le applicazioni che lo vogliono
interrogare! Il termine "Servizio Web" viene probabilmente dal fatto che la
comunicazione tra i client e il servizio avviene tramite il protocollo http
che è una sorta di "sinonimo" di Web, e che quindi si suppone che tali
clienti siano in ultima analisi browser o server Web "tradizionali".
Molti di voi avranno notato delle analogie con sistemi di componenti
distribuiti, quali JavaBeans, CORBA, DCOM solo per citarne alcuni.
Effettivamente, io credo che il concetto sia esattamente lo stesso, ma questa
volta la piattaforma, invece di essere Java o Windows o un'altra piattaforma
specifica, diventa il Web stesso, poiché (quasi) tutti i server e i client
operanti su Web sono capaci di comunicare per mezzo di http.
La interoperabilità di un simile sistema sarebbe molto maggiore di quella
degli altri menzionati, perché per fortuna il Web ha finora resistito a
frammentarsi in una serie di sotto-Web proprietari cui non piace comunicare
fra loro.
Manca però ancora un pezzo a questo puzzle: http è un ottimo
candidato per il trasporto dei messaggi, data la sua ubiquità e soprattutto la
benevolenza che i firewall generalmente mostrano nei suoi confronti (la
porta 80 non è quasi mai chiusa, neanche dall'amministratore di rete piu'
paranoico).
Occorre però anche una specifica di livello applicativo del formato dei
messaggi scambiati tra Web Service e clienti. Tale specifica è SOAP (Simple
Object Access Protocol).
SOAP, e a questo punto non dovremmo più meravigliarci, non è che un altro
vocabolario XML, dove il dominio in questo caso è l'interrogazione
remota di Servizi Web.
Un documento SOAP inviato dal client conterrà un messaggio-richiesta
per il Servizio Web (che può essere pensato, a tutti gli effetti, come
l'invocazione di un Oggetto Remoto); il documento SOAP restituito dal Servizio
Web conterrà un messaggio-risposta (analogo al Valore di Ritorno di una
invocazione remota).
Non è scopo di questo articolo addentrarsi nella specifica struttura dei
messaggi SOAP, né in dettagli di implementazione di un modulo di un Web Server
per il supporto di SOAP. È chiaro fin d'ora, però, che l'effettiva
"esecuzione" della richiesta contenuta nel messaggio SOAP potrà essere
effettuata da qualunque specifica implementazione (JavaBean, CORBA, DCOM, ma
persino, in teoria, un CGI). Tutto ciò è però mascherato al client dal
Servizio Web, la cui responsabilità è di "mappare" la richiesta SOAP su
un'invocazione a qualche modulo eseguibile, e il conseguante risultato in una
risposta SOAP.
Infine, un client di questa interessante "piattaforma WEB" avrà bisogno di
sapere dove e quali Servizi sono disponibili in quel momento sulla rete. Per
esempio, il mio sito Web (un buon sito grafico tradizionale) ha bisogno di
visualizzare le quote di azioni, e intende richiedere quest'informazione a un
Servizio Web, uno che sia in quel momento attivo e magari che fornisca
l'informazione al prezzo migliore.
Alcune specifiche per questo tipo di interrogazioni sono già presenti,
anche se non mi risulta che alcuna di esse sia già stata "benedetta" da
W3C:
- WSDL (Web Services Description Language) per descrivere il "contratto"
di un singolo Web Service, ovvero la sua interfaccia (si noti che diversi
Web Service possono trovarsi sullo stesso sito, ad esempio uno per le
quote delle azioni e uno per le previsioni del tempo); una sorta di
Reflexion applicata ai Servizi Web
- DISCO (Discovery of Web Services) per interrogare un particolare server
su quali Web Services ("contratti") fornisce
- UDDI (Universal Description, Discovery, and Integration) per la
creazione di "directory" di Web Services dove i "fornitori" possano
pubblicare l'esistenza dei loro servizi, e i "clienti" consultare la
directory per trovare l'URL dei servizi cui sono interessati (una buona
analogia sono le Pagine Gialle oppure, il servizio DNS di internet)
A questo punto abbiamo un'idea di cosa sia un documento XML
well-formed, di come si possano descrivere "famiglie" di documenti XML
per particolari applicazioni (tramite Schemi) ed anche di come si possano
trasformare documenti XML in altri documenti XML o altri formati (tramite
XSL/T).
La domanda spontanea per uno sviluppatore è: come posso scrivere
applicazioni che "parlino" XML e si avvantaggino delle altre specifiche
correlate, come appunto Schemi, XPath, XSL/T ecc.?
Il W3C propone una API (Document Object Model o DOM, level 2) basata su un
"Object Model". Questo significa che il documento XML può essere visto
dall'applicazione come una gerarchia di oggetti, e processato per mezzo di
metodi e proprietà degli oggetti di tale gerarchia. Data la struttura
gerarchica ad albero dei documenti XML, questa rappresentazione interna
all'applicazione sembra quantomeno naturale.
Che cosa sia in realtà la "gerarchia di oggetti " dipende dalla piattaforma
e/o linguaggio che state usando: istanze di classi Java o C++, oggetti COM
ecc. Ciò che esse però devono avere in comune per supportare il DOM del W3C è
che gli oggetti di cui sono costituite devono esporre determinate
interfacce, ovvero metodi e proprietà pubbliche. Così, dovrò potere
invocare il metodo createElement() dell'interfaccia
Document su una qualunque delle implementazioni menzionate (Java,
C++, ecc.) e la interfaccia Document dovrà essere derivata dalla
interfaccia Node.
Una volta che il documento XML è "caricato" in memoria in questa gerarchia
di oggetti, l'applicazione può effettuare visite, ricerche, modifiche,
inserimenti, cancellazioni. Molte implementazioni di DOM permettono anche di
validare il documento con uno Schema (al momento del caricamento) e di
applicare trasformazioni XSL/T oppure selezionare nodi dell'albero usando
XPath.
Il DOM, pur essendo molto utile e ampiamente disponibile, ha un grande
limite: il file XML deve essere completamente caricato in memoria, prima che
vi si possa effettuare qualunque operazione (vi è in realtà un'operazione di
caricamento asincrono, ma essa semplicamente permette di iniziare a lavorare
con alcuni nodi prima che il documento sia caricato completamente). Questo è
in molti casi indesidsiderabile, per ragioni di efficienza, e in alcuni casi,
in cui il file XML è troppo grande per le risorse disponibili, può addirittura
impedire all'applicazione di manipolarlo.
Esistono altri approcci alla programmazione di applicazioni XML, come SAX
2.0 (Simple API for XML) che cercano di ovviare a questo inconveniente
proponendo modelli ad eventi: invece di caricare il documento e poi navigare
nel DOM costruito dal parser, l'applicazione può registrare delle callback
function con il Parser SAX, che verranno invocate quando specifici eventi
si verificano. Un tipico evento durante il parsing di un documento XML è la
lettura di uno specifico tag da parte del parser. In questo modo,
l'applicazione è invocata solo quando il parser sta processando dati che la
interessano, e non c'è necessità che l'intero documento sia completamente
contenuto in memoria.
Uno dei principali problemi di questo modello ad eventi (push) è la
difficoltà di mantenere uno stato globale per l'applicazione: essa è
frammentata in tanti event-handler (o callback function) che
operano in modo asincrono (o meglio, data driven) l'uno dall'altro. È
necessario studiare attentamente delle strutture dati globali in cui lo stato
del parsing è rappresentato, e dove ciascun event-handler legge e
scrive le informazioni di sua pertinenza.
Modelli più flessibili di DOM2 e SAX, e che supportano anche tecniche
pull (controllo da parte dell'applicazione, pur non caricando l'intero
file in memoria) sono disponibili in piattaforme avanzate come Java e il
recente C#/.NET, ma al momento non mi risulta ne esista qualcuno standard.
Come si è potuto vedere da questa breve panoramica su XML, esso costituisce
una tecnologia di grandissimo interesse specialmente per i prossimi sviluppi
del Web. Tuttavia, l'applicazione di XML non è limitata alla comunicazione
client-server o server-server in ambiente Web, ma costituisce un attraente
formato standard per l'interscambio di informazioni tra applicazioni
qualunque.
A mio avviso, XML non è affatto una tecnologia rivoluzionaria o
impensabile prima d'ora, che attendeva l'intuizione di un qualche genio per
essere inventata; semplicemente, si sono da poco create delle condizioni di
quantità e qualità nelle interconnessioni dei sistemi informativi
(specialmente, ma non solo, grazie a internet) che rendono necessaria
la definizione di un linguaggio comune per lo scambio di dati e di messaggi a
un livello applicativo, ovvero più alto dei protocolli di "vecchia" data come
HTTP, FTP, ecc..
XML si profila come un candidato molto promettente per soddisfare questa
nuova e fortissima necessità.
W3.org per ulteriori dettagli su quasi tutte le tecnologie discusse
The XML Industry Portal
XML from the inside out
utile FAQ sugli XML namespaces
per la specifica XDR
per una discussione su XLink e XPointer
A gentle Introduction to XSL FO
per SOAP 1.1
per UDDI
per SAX 2.0
Organization for the Advancement of Structured Information Standards
Creating a Single Global Electronic Market
| 
