[an error occurred while processing this directive]
diff logo Informatica e sistemi alternativi
su questo sito sul Web
    Home   Chi siamo    Contattaci    Scrivi per diff    Proponi un argomento 23/09/17
    Cos'è diff    Come accedere    F.A.Q.    Promuovi    Dicono di diff    Amici di diff    
AmigaOS
Linux
FreeBSD
BeOS
OpenSource
Java
Database
Informatica
Hardware
E-Commerce
Narrativa

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






Cos'è XML?

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.

Standard legati a XML

Namespace

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.

Schemi: DTD, XDR, XSD

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.

XPath

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.

XSL/T e XSL/FO

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.

XLink e XPointer

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.

Servizi Web: SOAP, WSDL, DISCO e UDDI

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)

Modelli di sviluppo di applicazioni XML

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.

Conclusioni

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

Alcuni Riferimenti

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

OPENSOURCE
INFORMATICA


Dott. Gianluca Torta
Laureato con il massimo dei voti in Scienze dell'Informazione presso l'Università degli Studi di Torino con una tesi di ricerca sui formati di interscambio di documenti ed informazioni.
Appassionato di informatica e IT, ha alle spalle anni di consulenza presso aziende del gruppo FIAT e IBM, ha svolto attività di ricerca presso lo CSELT a Torino dove ha approfondito gli studi sui Workflow.
Dopo alcuni anni trascorsi a Redmond presso la Microsoft dove ha partecipato allo sviluppo di BizTalk, è tornato in Italia come ricercatore presso l'Università di Torino dove si occupa di sistemi di diagnostica automatica per l'industria aerospaziale.

Puoi contattare l'autore scrivendo a:
torta@diff.org


Altri articoli dello stesso autore:
Introduzione ai Workflow
PostgreSQL: portando l'e-business a un nuovo livello (traduzione)
Introduzione all'XML


 


La tua opinione su quest'articolo ci sarà utile per la scelta dei contenuti dei prossimi articoli, per cortesia lasciaci un tuo parere su quello che hai letto:
nome:
email:
eta:
Professione
Commento:
Gradimento:
Utile Interessante Continuate con quest'argomento

© 1999,2000,2001,2002 NonSoLoSoft di Ferruccio Zamuner (Italia)- tutti i diritti sono riservati