Best View 1024 X 768

 

 

 

 

 

Home Page

 

W W W . J N E T W O R L D . C O M

 

Home > Tech > XML

 

Linguaggi

 

 

 

 

 

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

Come funziona 

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

Documenti e marcatori

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 &#125;, 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

Commenti e istruzioni

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

Grammatica e linguaggio

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

Dichiarative esterne

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

Struttura e presentazione

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

Formattazione fisica e logica

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

I limiti dell’Html

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

Marcatori non puri

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: 64895872 - E-mail: jnet@iol.it

Best view: 1024 x 768 / all right reserved © 2000/2001 The Last Day in the Web 

   

 

 

On Top