<?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 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)
<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)>
<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ò assumenre 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.
<!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.
<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.
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.
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".
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:
<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, pewr cui poi nelle successive construction rule non è più necessario definire il colore.
<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.
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.
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.
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>
|
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> 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"?> <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"?> <LIBRO> </RADICE> Non essendo ancora stato costruito il foglio di stile relativo è ancora impossibile visualizzare il file "esempio.htm" se non nella sua struttura. |
| 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> </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> <rule> <rule> <rule> </RADICE> |
<?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.
<?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)>
]!>
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.
| 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 |