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