' Rapid-Q by William Yu (c)1999-2000                                             .
' ================================================================================
' Upload_il_tuo_script_su_Rapidq.it

' Manuale_XHTML

 
Per definire cos'è XHTML possiamo iniziare con una semplice espressione:
HTML + XML = XHTML
Esaminiamo i termini dell'operazione.
HTML
Se siete su questo sito sapete di cosa parliamo. HTML è un linguaggio di marcatura per presentare i
contenuti di una pagina web. La sua semplicità è la base dell'esplosione di Internet. L'ultima
raccomandazione rilasciata dal W3C è la 4.01 (dicembre 1999).
XML
XML è una sorta di "super-linguaggio" che consente la creazione di nuovi linguaggi di marcatura.
Potente, flessibile e rigoroso è alla base di tutte le nuove specifiche tecnologiche rilasciate dal W3C
e adottate ormai come standard dall'industria informatica. I principali obiettivi di XML, dichiarati
nella prima_specifica_ufficiale(ottobre 1998), sono pochi ed espliciti: utilizzo del linguaggio su
Internet, facilità di creazione dei documenti, supporto di più applicazioni, chiarezza e
comprensibilità . Nella visione di Tim Berners Lee è destinato ad essere il fondamento di un web
finalmente universale.
XHTML
XHTML è la riformulazione di HTML come applicazione XML. Ciò significa essenzialmente una cosa: un
documento XHTML deve essere valido e ben formato. Torneremo in seguito su questi concetti. Per ora è
importante chiarire il punto di vista del W3C su XHTML.
Piuttosto che sfornare una nuova versione del linguaggio, un HTML 5.0, gli uomini del Consortium hanno
compiuto un'opera di ridefinizione. Niente nuovi tag, attributi o metodi. Questi rimangono
essenzialmente quelli di HTML 4.0. In pratica: il vocabolario rimane uguale, ma cambiano le regole
sintattiche. Se si comprende questo fatto, sarà chiaro come XHTML risponda a due esigenze fondamentali:
   1. portare HTML nella famiglia XML con i benefici che ciò comporta in termini di estensibilità e
      rigore sintattico
   2. mantenere la compatibilità con i software che supportano HTML 4.0
Visto così, XHTML è un ponte tra passato e futuro. E' un modo per imparare a pensare in XML partendo da
un linguaggio che conosciamo, senza dover rinunciare, dunque, alle conoscenze già acquisite.
***** Versioni di XHTML *****
Le versioni di XHTML attualmente disponibili e pubblicate come raccomandazioni dal W3C sono tre.
**** XHTML 1.0 ****
Pubblicata il 26 gennaio 2000 e seguita da una versione rivista dell'ottobre 2001. Consiste, come detto,
nella riscrittura in XML di HTML 4.0 e si basa sulle tre DTD già definite per questo linguaggio:
    * DTD Strict
    * DTD Transitional
    * DTD Frameset
**** XHTML Basic ****
E' una versione_"ridotta" del linguaggio. Specificamente pensata per dispositivi mobili (PDA,
cellulari), contiene solo gli elementi che si adattano a questi dispositivi (esclude, ad esempio, i
frames che non hanno ovviamente senso in tale contesto). E' destinata a sostituire WML come linguaggio
di base per le applicazioni WAP.
**** XHTML 1.1 ****
Basata sulla DTD Strict della versione 1.0, rappresenta la prima formulazione pratica del concetto di
modularità . In questa visione, gli elementi fondamentali (in pratica l'insieme di tag che definiscono la
struttura di un documento) sono raggruppati in una serie di moduli indipendenti, che possono essere
implementati o esclusi secondo le necessità . Secondo il W3C è la base della futura estensione di XHTML
con altri set di linguaggi o moduli, anche personalizzati.
***** Riferimenti *****
La_guida_HTML_di_HTML.it
Il_corso_su_XML_di_HTML.It
XHTML_sul_W3C:_news,_specifiche,_definizioni_e_discussioni
Traduzione_italiana_della_specifica_XHTML_1.0_(di_Patrizia_Andronico)

 
Quando si propone una nuova tecnologia è fatale sollevare dubbi e obiezioni. Consideriamo il quadro
d'insieme degli attuali linguaggi web.
Milioni di pagine sono scritte in HTML. Una gran parte di esse non è valida rispetto alle
raccomandazioni del W3C, ma funziona. L'adozione di un nuovo linguaggio (XHTML) non è obbligatoria nè
forzata: tutti i browser in commercio sono in grado di interpretare HTML 4. XHTML non introduce nuove
features rispetto al suo predecessore. "Perchè allora imparare un nuovo linguaggio?". "Perchè dovrei
riscrivere tutto il mio sito?". Sono domande scontate, ma legittime. Ecco alcune possibili risposte ed
un semplice elenco dei vantaggi di XHTML.
***** Codice pulito e ben strutturato *****
Il passaggio ad XHTML può essere visto come un ritorno alle origini. HTML è nato come linguaggio per
definire la struttura di un documento. Non ha nulla a che vedere con la presentazione. Eppure, è stato
stiracchiato da tutte le parti, costretto a svolgere compiti per cui non è stato creato. Il caso delle
tabelle è quello macroscopico. Sono nate per la presentazione di dati tabulari. Sono state impiegate
come l'unico mezzo per costruire il layout della pagina.
E ancora: quando si sentì la necessità di gestire la tipografia dei documenti, venne introdotto il tag
<font> con i relativi attributi. La conseguenza è quella di pagine cariche di elementi inutili, più
pesanti, difficili da modificare.
La responsabilità principale per questo uso improprio di HTML non ricade sugli sviluppatori. Nel 1996
(le date sono importanti!) il W3C ha rilasciato la versione definitiva di CSS1. Era questa la tecnologia
destinata a definire la presentazione dei documenti. L'idea era chiara: HTML per la struttura, CSS per
lo stile e il layout. Eppure, per avere browser che supportano decentemente questi standard si è dovuto
attendere il 2000-2001. Quattro anni, tre generazioni di browser, milioni di siti costruiti tentando di
risolvere incompatibilità e bug.
Con XHTML, almeno nella sua versione Strict, si torna ad un linguaggio che definisce solo la struttura.
Semplicemente, se inserite elementi non supportati (font, larghezza per le celle di tabelle o margini
per il body, per citare solo alcuni esempi) il documento non è valido. Quindi: la formattazione si fa
con i CSS. Mai più tag <font>, mai più gif di un pixel. Tra poco, forse, niente più tabelle per il
layout. Risultato: codice più pulito, più logico, più gestibile.
Esempio: due pagine realizzate secondo le due impostazioni, diciamo "old_style" e "new_style".
Attenzione al codice riportato in fondo. Nel secondo caso tutta la formattazione è definita in un CSS e
si vede! Peso delle due pagine: "old style" 3 kb, "new style" 1 kb.
***** Portabilità *****
Portabilità è la capacità /possibilità di un documento di essere visualizzato e implementato
efficacemente su diversi sistemi: PC, PDA, cellulari WAP/GPRS, WebTV. Ora, se pensate alle limitazioni
in termini di memoria, ampiezza dello schermo e usabilità di un terminale mobile, capirete perchè è
importante un linguaggio essenziale, centrato sulla struttura del documento, privo di orpelli inutili.
Ciò che ha senso è avere un titolo della pagina, un'intestazione, un paragrafo, una lista per scandire
gli argomenti.
Sulla portabilità poggia l'enfasi con cui aziende del calibro di Nokia, Motorola, Ericsson o Siemens
guardano ad XHTML. Dopo l'accettazione da parte del Wap Forum si può affermare con certezza che la
piattaforma WAP 2 e tutta l'evoluzione dei servizi mobili sarà fondata sull'integrazione tra XHTML e
CSS, con il supporto delle necessarie tecnologie sul lato server.
Nelle immagini, tratte da un documento di Nokia, è chiarissimo lo schema di distribuzione delle
informazioni fondato su questa interazione. In breve:
    * nella pagina XHTML incorporiamo diversi CSS per ciascun supporto
    * il browser viene identificato
    * su un PC vedremo il layout standard
    * su un cellulare visualizziamo un layout "ridotto" e adatto alle caratteristiche del mezzo
    * ciò che non cambia sono i contenuti
E' solo uno degli scenari possibili. Se al quadro si aggiungono le enormi potenzialità del linguaggio
XSL, si comprende come l'epoca delle tante versioni di uno stesso sito sia davvero al termine.
***** Estensibilità *****
Dal momento che XHTML è XML diventa estensibile. Significa che sarà facilissimo incorporare in un
documento parti scritte in uno dei tanti linguaggi della famiglia XML.
Esempio. Dovete inserire in una pagina delle formule matematiche complesse. Basterà dichiarare il
namespace relativo al linguaggio MathML e inserire nella pagina i tag specifici di quest'ultimo (il
codice è tratto dal sito del W3C).
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>A Math Example</title>
</head>
<body>
<p>The following is MathML markup:</p>
<math xmlns="http://www.w3.org/1998/Math/MathML">
<apply> <log/>
<logbase>
<cn> 3 </cn>
</logbase>
<ci> x </ci>
</apply>
</math>
</body>
</html>
I frutti di questo approccio, che è il più semplice dei tanti possibili, sono ancora lontani dalla
maturità . L'implementazione da parte dei browser è infatti carente, ma non mancano esempi funzionanti e
di grande potenza. Parleremo in un'altra lezione di FML (Form Markup Language), un linguaggio che
estende in maniera impressionante l'uso dei classici form di HTML.
***** Accessibilità *****
Una altro punto fondamentale. I documenti scritti in XHTML e validati sono naturalmente più accessibili.
Da una parte la validazione richiede l'uso obbligatorio di funzionalità come il testo alternativo per le
immagini. Dall'altra, una pagina che evita elementi non standard, ben definita nella struttura è di gran
lunga meglio gestibile da browser alternativi come quelli vocali o testuali. Per questi aspetti è
obbligatoria la lettura delle linee guida per l'accessibilità del contenuto Web rilasciate dal W3C e
tradotte_anche_in_italiano.
***** Riferimenti *****
XHTML_linguaggio_del_futuro: l'articolo espone la visione su XHTML di Nokia e delle principali aziende
del settore mobile.
The_fear_of_X: Molly Holzschlag è una delle personalità più influenti del web design americano. In
questo articolo (tradotto sul numero di Novembre 2001 di PC Professionale) espone la sua visione su
XHTML e sui vantaggi di questo linguaggio. Da leggere altri_suoi_articoli sull'argomento.
Entriamo nel vivo della conoscenza di XHTML esponendo le sue regole di base. Sono quelle che rendono un
documento strettamente conforme (punto_3.1.1 della specifica) e che ne definiscono i requisiti minimi
essenziali. In pratica: se non si rispettano questi semplici punti il documento non può essere definito
XHTML.
***** 1. Validazione *****
Un documento deve essere convalidato rispetto ad una delle tre DTD XHTML del W3C. Vedremo nella prossima
lezione come si effettua la convalida. Per ora è sufficiente chiarire che essa controlla essenzialmente
due cose: che il documento sia valido e ben formato. Sono due concetti fondamentali derivati da XML e su
cui vale la pena soffermarsi.
**** Documenti ben formati ****
XHTML, ricordiamolo, è fondato su XML. Da questo eredita il concetto di documento ben formato. Ciò
significa che esso deve rispettare le regole della sintassi XML: presenza di un elemento radice,
corretto annidamento degli elementi, chiusura obbligatoria dei tag vuoti, etc. Affronteremo nei dettagli
questi aspetti nelle lezioni successive.
**** Documenti validi ****
Un documento è valido se usa correttamente un linguaggio, vale a dire se usa nel modo giusto solo
elementi specifici e consentiti. Ma dove vengono stabilite queste regole? Per XHTML (e per XML in
genere, anche se in questo ambito si sta sviluppando l'uso degli schemi) le regole sono definite nelle
DTD (Document Type Definition). Una DTD identifica gli elementi (tag) consentiti, cosa essi significano,
come devono essere trattati (ad esempio, stabilisce quali sono gli attributi possibili per ciascun
elemento). In un documento XHTML la DTD deve essere obbligatoriamente specificata all'inizio. Per ora
passiamo alla seconda regola di conformità .
***** 2. Elemento radice *****
Ogni documento XML deve contenere un elemento radice. Si tratta dell'elemento che contiene al suo
interno tutti gli altri:
<rubrica>
     <contatto>
        <nome>Marco</nome>
        <cognome>Rossi</cognome>
     </contatto>
</rubrica>
Nell'esempio l'elemento radice è <rubrica>. In un documento XHTML l'elemento radice deve essere <html>.
***** 3. Namespace XHTML *****
L'elemento radice <html> deve contenere la dichiarazione di un namespace XML (spazio_dei_nomi) tramite
l'attributo xmlns. Il namespace usato deve essere "http://www.w3.org/1999/xhtml".
***** 4. Dichiarazione DOCTYPE *****
In un documento XHTML l'elemento radice deve essere preceduto da un elemento <!DOCTYPE>. All'interno di
questo elemento è necessario specificare la DTD di riferimento e il suo URI.
Ora che conosciamo un pò meglio XHTML possiamo finalmente creare la nostra prima pagina.
Ecco come si presenta il codice di una semplice pagina XHTML basata sulla DTD Strict (figura 1):
[Figura 1 - La mia prima pagina XHTML]
Nell'immagine abbiamo evidenziato con colori diversi le quattro sezioni essenziali di un documento
XHTML:
    * in rosso: il prologo
    * in verde: l'elemento radice (<html>)
    * in viola: la testata (<head>)
    * in giallo: il corpo del documento
Le analizzeremo nelle prossime lezioni, definendo nei dettagli la funzione di ciascuna e le differenze
con HTML. Per ora iniziamo con un pò di pratica.
Il listato_1 contiene il codice della nostra prima pagina. Copiatelo e incollatelo, anche in un editor
di testo. Salvate, nominando il documento "test.html", visualizzate nel vostro browser preferito.
A questo punto, dopo aver tanto insistito sul concetto di documento valido e ben formato, è opportuno
imparare a fare la convalida. All'url http://validator.w3.org è possibile effettuare la validazione di
qualunque documento presente in rete: basta inserire l'URI della pagina e cliccare su "Validate this
page". Dal momento che la pagina appena creata è localizzata sulla nostra macchina dobbiamo usare un
altro metodo.
Il W3C dà la possibilità di validare i documenti tramite l'upload del file sui suoi server. Usate quindi
l'url http://validator.w3.org/file-upload.html. Cercate il file da validare sul vostro PC e inviate la
richiesta. Se il documento è valido riceverete, questo messaggio (figura 2):
[Figura 2 - Il nostro documento è valido.]
Bene. La prova è andata a buon fine, la pagina rispetta le regole. Possiamo ora passare all'analisi
delle quattro sezioni del documento. Cominciamo dal prologo.
***** Riferimenti *****
Un_validatore_alternativo: potete validare i documenti anche su htmlhelp.com. Il sito fornisce
utilissime notizie e suggerimenti su possibili problemi nella convalida.
[Figura 1 - Prologo di un documento XHTML]
La figura 1 mostra il prologo di un documento XHTML. Esso risulta composto da due parti: la dichiarazione
XML e la definizione del DOCTYPE.
***** Dichiarazione XML *****
La nostra pagina inizia con una riga di codice: <?xml version="1.0"?>. La sua funzione è semplice: rendere
esplicito il fatto che il documento è XML. Non è obbligatoria, ma è il suo uso è consigliato dal W3C per
tutti i documenti XML. Quando viene usata non deve essere preceduta da altre istruzioni.
All'interno della dichiarazione è possibile usare tre attributi. L'unico obbligatorio è version (il solo
valore possibile è "1.0", in quanto non esistono altre versioni del linguaggio). Un altro attributo,
opzionale, ma spesso usato è encoding. Serve a specificare la codifica del linguaggio:
<?xml version="1.0" encoding="UTF-8"?>.
L'ultimo attributo possibile è standalone. Se il valore è "yes" vuol dire che il documento non fa
riferimento ad entità esterne.
Se il vostro obiettivo è la massima compatibilità potete omettere la dichiarazione XML. Molti browser hanno
mostrato problemi così come alcuni editor (Dreamweaver). Se avete la necessità di specificare una codifica
per i caratteri potete sempre usare un meta tag:
<meta http-equiv="Content-Type" content="text/html;charset=UTF-8" />
***** Definizione del DOCTYPE *****
La dichiarazione del DOCTYPE (obbligatoria!) è composta da due sezioni:
   1. Un FPI (Identificatore Formale Pubblico) riferito ad una delle tre DTD XHTML (in rosso)
   2. L'URI della DTD (in verde)
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
Essa, dunque, ha lo scopo di stabilire a quale delle tre DTD XHTML intendiamo conformarci e di dire al
browser dove essa è collocata. Nel nostro esempio la DTD di riferimento è quella Strict, collocata sul sito
del W3C. Il DOCTYPE, inoltre, non ha alcun effetto sulla presentazione della pagina. Serve solo al
validatore per stabilire le regole della convalida.
Notate anche la parola chiave PUBLIC. Significa che la DTD è pubblica, creata dal W3C. In effetti, in XML, è
anche possibile definire DTD "private", specifiche per la nostra applicazione. In tal caso si usa la parola
chiave SYSTEM.
Un'ultima notazione. Su molti siti (tra cui quello del W3C) vengono forniti schemi di dichiarazione DOCTYPE
per le tre DTD che presentano URI relativi:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"DTD/xhtml1-strict.dtd">
Quest'uso comporta talvolta problemi in fase di validazione, pertanto è preferibile usare sempre URI
assoluti. Riportiamo per comodità le tre dichiarazioni per ciascuna DTD. Potete usarle nelle vostre pagine
con un semplice copia e incolla.
**** DTD Strict ****
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
**** DTD Transitional ****
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
**** DTD Frameset ****
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">
L'argomento DTD merita comunque un approfondimento. E' ciò di cui parleremo nella prossima lezione.
***** Riferimenti *****
Come_vivere_meglio_con_XHTML: recente articolo apparso su A list apart con trucchi e suggerimenti su un uso
appropriato del DOCTYPE.
Giunti a questo punto dovrebbe essere ormai chiara la funzione di una DTD: descrivere in un linguaggio
comprensibile da una macchina la sintassi e la grammatica di un linguaggio XML. Il tutto allo scopo di
verificare la validità di un documento che a quella DTD fa riferimento.
Le DTD XHTML 1.0 sono contenute in tre documenti che potete anche scaricare sul vostro computer, sia per
imparare come sono fatte sia per usarle direttamente nel vostro sito. In questo modo dovrete modificare
l'URI nella dichiarazione DOCTYPE:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.miodominio.it/DTD/xhtml1-strict.dtd">
Nell'esempio si suppone che la DTD sia localizzata nella cartella DTD di un server miodominio.it. Se ciò
può sembrare una bizzarria ora non lo sarà forse tra qualche anno quando milioni di browser tenteranno
di convalidare documenti XHTML contro le DTD del W3C. E' evidente che il pericolo è quello di
rallentamenti e strozzature.
L'aspetto su cui ora vogliamo soffermarci è il contenuto di una DTD. Il codice è quanto di più criptico
si possa immaginare, ma non mancano manuali che spiegano bene come interpretarle. Facciamo un esempio.
Ecco come viene definito nella DTD Strict l'uso dell'elemento <img>:
<!ELEMENT img EMPTY>
<!ATTLIST img
%attrs;
src %URI; #REQUIRED
alt %Text; #REQUIRED
longdesc %URI; #IMPLIED
height %Length; #IMPLIED
width %Length; #IMPLIED
usemap %URI; #IMPLIED
ismap (ismap) #IMPLIED
>
Traduzione in italiano:
L'elemento immagine è vuoto (EMPTY). Puo assumere tutti gli attributi fondamentali (%attrs;): sono
quelli comuni alla maggior parte degli elementi (id, class, style, title). Altri attributi possibili
sono: src, alt, longdesc, width, height, usemap, ismap. Src e alt sono obbligatori (#REQUIRED). Gli
altri opzionali (#IMPLIED).
Conoscere il contenuto di una DTD è dunque importante. Se non inserite, per esempio, l'attributo alt per
un'immagine e validate la pagina vi verrà segnalato l'errore e potrete correggerlo. Ma se si conoscono
le regole in partenza è certamente meglio, si eviterà di procedere per prova e correzione d'errore.
Per fortuna non è necessario imparare una DTD. Esistono per lo scopo ottime reference, elenchi di tutti
i tag, degli attributi e degli eventi consentiti che spiegano in dettaglio il loro uso. Nella sezione
riferimenti in fondo alla pagina segnaliamo un paio di reference online, ma le trovate anche nei
migliori manuali su XHTML o HTML.
Il riferimento ad HTML non deve stupire. Le tre DTD XHTML 1.0 sono infatti basate sulle corrispondenti
DTD elaborate per HTML 4.0. Vedremo ora quali sono le principali caratteristiche di ciascuna.
***** DTD Strict *****
E' la DTD più rigida, centrata esclusivamente sulla struttura del documento. Elimina diversi elementi ed
esclude tutti gli attributi che definiscono la presentazione. Per questo scopo vanno usati i CSS. Segue
un elenco degli elementi non supportati:
<applet>, <basefont>, <center>, <dir>, <font>, <frame>, <frameset>, <iframe>, <isindex>, <menu>,
<noframes>, <s>, <strike>, <u>
Oltre agli elementi non consentiti particolare attenzione va posta ad attributi molto usati nella comune
pratica del web design. Elenchiamo alcuni casi e rimandiamo ad una buona reference per i dettagli:
    * sono esclusi tutti gli attributi del tag <body> tranne quelli comuni (vedi_sopra)
    * non si può usare align per l'allineamento del testo in paragrafi e altri elementi
    * non è supportato l'attributo target per i link e i form
    * per una tabella (<table>) non si possono specificare il bordo, il colore di sfondo (bgcolor) o
      l'allineamento (align)
    * le celle di tabella (<td>) non supportano il colore di sfondo, la larghezza (width), l'altezza
      (height). Supportano invece l'allineamnto del testo (align)
***** DTD Transitional *****
Basata sull'omologa DTD di HTML 4.0 è attualmente quella più usata. La spiegazione è semplice. Nelle
intenzioni del W3C essa deve essere una sorta di passaggio verso una ridefinizione più rigida del
linguaggio. In effetti è utile quando si voglia passare ad XHTML mantenendo il massimo grado di
compatibilità con i vecchi browser. Supporta tutti gli elementi e gli attributi di presentazione di HTML
4.0, anche quelli ritenuti sconsigliati. Se dovete e volete ancora usare le tabelle per il layout o fare
uso del tag <font> è la DTD che fa per voi.
***** DTD Frameset *****
E' identica alla Transitional, ma va usata quando si utilizzano i frame. L'unica differenza è in pratica
la sostituzione del tag <body> con <frameset> nella pagina principale.
***** Riferimenti *****
XHTML_Reference_di_W3Schools: W3Schools è una specie di HTML.it americano. Tante guide e tutorial su
vari aspetti del web design con un linguaggio semplice ed efficace. La reference XHTML è un capolavoro
di chiarezza e facilità d'uso.
XHTML_Reference_di_zvon.org: ottimo sito che spazia da HTML ai linguaggi emergenti. La reference XHTML è
completa ma poco chiara.
Riprendiamo l'analisi delle quattro sezioni della nostra pagina XHTML. E consideramo l'elemento radice:
[Figura 1: Dichiarazione dell'elemento radice]
Come abbiamo visto, l'elemento radice di un documento XHTML deve essere <html>, che deve a sua volta
contenere tutti gli altri elementi. Niente di nuovo direte, tutte le pagine HTML iniziano più o meno
così:
<html>
<head>
<title>Lezione 7 - L'elemento radice</title>
</head>
<body bgcolor="#FFFFFF" text="#000000">
......... Contenuto della pagina ..............
</body>
</html>
Ma le differenze ci sono e qui potete capire davvero cosa significa il rigore di XML.
***** <HTML> è obbligatorio *****
Perchè prima non lo era? Incredibilmente la risposta è: no! <html> era considerato di default. Piccola
prova:
<head>
<title>Lezione 7 - L'elemento radice</title>
</head>
<body bgcolor="#FFFFFF" text="#000000">
<h1>Questo è HTML!</h1>
</body>
Copiate e incollate queste poche righe in Blocco Note; salvate come "prova.html". Aprite in un browser.
La scritta "Questo è HTML!" comparirà bella ed evidente. Ma cosa volete farci, i nostri browser sono
fatti così. Sanno perdonare molto, forse troppo. Si calcola che l'80% della potenzialità del parser HTML
di un browser venga usata per risolvere gli errori di scrittura presenti nelle pagine. E' evidente che
sottoponendo questa pagina a validazione non sarete nemmeno presi in considerazione. Semplicemente
questo non è un documento XHTML. Se un giorno i browser (come è auspicabile) effettueranno la verifica
la nostra paginetta di test verrà sdegnosamente rifiutata perchè non corretta. Ma affronteremo
l'argomento browser in una prossima lezione. Ora ribadiamo: <html> è obbligatorio.
***** Il namespace *****
L'elemento <html> può assumere questi attributi:
dir      Determina la direzione del testo
lang     Specifica il linguaggio di base dell'elemento quando è interpretato come HTML
xml:lang Specifica il linguaggio di base dell'elemento quando è interpretato come XML
xmlns    Specifica il namespace predefinito per XHTML
L'unico attributo obbligatorio è xmlns. Il W3C, come visto, specifica anche il valore obbligatorio di
tale attributo: "http://www.w3.org/1999/xhtml" (vedi figura_1).
La necessità di un namespace (spazio di nomi) dipende dalla derivazione da XML. Linguaggio estensibile
per definizione. E' possibile, infatti, estendere il set di tag di XHTML con elementi di altri
linguaggi, anche creati personalmente. Specificare uno o più namespace evita la possibilità di conflitti
tra i tag. Chiariamo anche qui con un esempio.
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//OVERFLOW//DTD XHTML-FML 1.0//EN"
"http://www.mozquito.org/dtd/xhtml-fml1.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:x="http://www.mozquito.org/xhtml-fml">
<head>
<title>Untitled</title>
</head>
<body>
<x:form>
</x:form>
</body>
</html>
Il codice riporta l'implementazione di FML (Form Markup Language) in un documento XHTML. FML, su cui
torneremo, è un linguaggio che ridefinisce e potenzia l'uso dei form. Come si può notare all'interno
dell'elemento <html> sono stati definiti due namespace: in rosso è evidenziato quello standard di XHTML,
in blue quello di FML.
La differenza tra i due, a parte l'URI, sta nel prefisso. Il primo non ne ha. Il secondo ha come
prefisso "x". Significa che i tag non preceduti da prefisso sono quelli standard di XHTML e come tali
verranno intepretati. Ora date uno sguardo al codice. Nel corpo della pagina è stato inserito un form.
Ma il tag è preceduto da x! Vuol dire che esso appartiene al namespace FML e come tale deve essere
trattato dal browser. Senza specificare il prefisso avremmo avuto un classico form XHTML.
L'argomento namespace è attualmente uno dei più dibattuti nella comunità XML e dunque vi rimandiamo ad
uno dei tanti siti sull'argomento o ad un manuale aggiornato per chiarificazioni e approfondimenti.
***** Riferimenti *****
Nozione_e_uso_dei_namespace: dal corso XML di HTML.it una buona introduzione all'argomento.
Form_Markup_Language: articoli e reference su questa interessante estensione di XHTML
Presente sin dalle prime specifiche di HTML, la testata (<head>...</head>) è ovviamente supportata in
tutte le DTD XHTML:
[Figura 1: testata tipica di un documento XHTML]
La funzione principale della sezione <head> è quella di contenere informazioni che non vengono
direttamente visualizzate nella pagina, ma che sono comunque di grande rilievo. Ecco l'elenco degli
elementi che possono apparire nella testata:
<base>     Usato per definire l'URL di base della pagina. Utilissimo per la risoluzione dei link
           relativi.
<isindex>  Sconsigliato. E' un modo per creare elementi simili alle caselle di testo.
<link>     Contiene informazioni su documenti esterni collegati. Usato soprattutto per i CSS.
<meta>     Specifica informazioni di vario tipo sul documento.
<noscript> Usato per visualizzazioni alternative nei browser che non supportano gli script.
<object>   Racchiude un oggetto.
<script>   Contiene script di programmazione .
<style>    Definisce le regole di formattazione per il documento corrente
<title>    Specifica il titolo del documento che compare nella barra del titolo del browser
Di questi elementi l'unico richiesto nelle DTD XHTML 1.0 è title. In realtà se esso viene omesso, il
validatore del W3C non segnala errori. Rimane il fatto che dare un titolo ad una pagina è una buona
norma da seguire sempre ed è anche utilissimo per i motori di ricerca, che sempre più considerano questo
elemento piuttosto che le classiche keywords definite nei meta tag.
Tutti gli elementi della testata sono comunque ben noti a chi ha dimestichezza con HTML e nel passaggio
ad XHTML non hanno subito variazioni (a parte, come vedremo, il tag script). Vi rimandiamo pertanto ai
riferimenti per approfondimenti o per un semplice ripasso.
***** Riferimenti *****
I_meta_tag: dalla guida di HTML.it una panoramica sull'uso di questi fondamentali elementi.
Collegare_fogli_di_stile: la guida ai CSS di HTML.it spiega il più classico uso del tag <link>.
Stili_incorporati: dalla stessa guida consigli utili su come formattare un documento con l'elemento
<style>.
Il corpo del documento è la sezione in cui si sviluppa il contenuto. E' racchiusa, come in HTML, tra i
tag <body>...</body>. Gli elementi che possono comparire all'interno del corpo sono in genere suddivisi
in due categorie: elementi blocco ed elementi inline.
***** Elementi blocco *****
Gli elementi blocco sono quelli che definiscono la struttura del documento. Possono contenere altri
elementi blocco, elementi inline o testo. Quando sono inseriti danno origine ad una nuova riga nel
flusso del documento. Chiariamo: se si inseriscono in una pagina queste due righe di codice:
<h1>Titolo</h1>
<p>Paragrafo</p>
il testo "Paragrafo" si troverà su una nuova riga, in quanto abbiamo inserito un nuovo elemento blocco
(<p>).
Abbiamo riportato inallegatol'elenco di tutti gli elementi blocco XHTML, specificando per ciascuno il
supporto nelle tre DTD.
**** Gerarchie e annidamento degli elementi blocco ****
Nella strutturazione del documento è fondamentale rispettare alcune semplici regole relative alla
gerarchia e all'annidamento degli elementi blocco. Il primo elemento della gerarchia dovrebbe essere
<div>, che definisce in pratica una sezione del documento. Al suo interno trovano posto gli altri
elementi. La cosa importante è che bisogna evitare annidamenti errati, che i browser fanno passare senza
problemi, ma che il validatore segnala impietosamente in quanto violano le regole delle DTD. Esempio:
<p><div>Qui inserisco il mio testo</div></p>
Se inserite questa breve riga di codice in un documento visualizzerete regolarmente il testo. Niente
problemi allora? Non proprio. In realtà il documento non è valido, in quanto l'elemento<p> non può
contenere altri elementi blocco. Il giusto annidamento è questo:
<div><p>Qui inserisco il mio testo</p></div>
Avete imparato allora una cosa importante: non fidatevi dei browser per verificare se il documento che
scrivete funziona. Molto spesso ciò che funziona non è valido e in XHTML la correttezza formale è
obbligatoria.
La consultazione di un buon riferimento XHTML o la consultazione diretta della DTD potrà chiarirvi ogni
dubbio sul corretto annidamento degli elementi. Nella nostra lista abbiamo specificato le regole di
contenuto di base per i principali elementi blocco.
***** Elementi inline *****
Gli elementi inline si distingono da quelli di tipo blocco per due motivi: quando sono inseriti non
danno origine a una nuova riga e possono contenere solo dati (essenzialmente testo) o altri elementi
inline. Chiariamo anche qui con un esempio:
<p>Questo tasto è<b>grassetto</b></p>
La parte delimitata dai tag <b>...</b> non sarà posta su una nuova riga. Anche per gli elementi inline
va posta molta attenzione all'annidamento. Esempi come questo:
<b><p>Testo in grassetto</p></b>
sono tollerati dai browser, ma non reggono al giudizio della validazione in quanto un elemento inline
non può contenerne uno di tipo blocco. Evitiamoli!
Anche per gli elementi inline forniamo in allegato una lista_commentata.
***** Attributi di body *****
Gli attributi per il testo, i link, il colore di sfondo e i margini dell'elemento <body> sono
espressamente vietati solo nella DTD Strict, ma erano già considerati sconsigliati in HTML 4.0. Non
vanno pertanto usati e devono essere sostituiti dai CSS. Li ricordiamo:
    * alink
    * background
    * bgcolor
    * link
    * text
    * vlink
Nella prima lezione abbiamo evidenziato come XHTML sia essenzialmente una ridefinizione di HTML e
l'excursus tra le varie sezioni di una pagina ha confermato questa affermazione. Al di là delle
differenze tra le tre DTD, non abbiamo incontrato nuovi tag o elementi inusuali. Anche quelle che
possono sembrare novità assolute, come la dichiarazione del DOCTYPE, erano in realtà già previste nelle
precedenti versioni di HTML.
Le novità sostanziali riguardano piuttosto la sintassi, il modo in cui tag, attributi e valori vengono
usati. Le esamineremo ora una per una, proponendo sempre il confronto con HTML. Attenzione: l'uso di
queste convenzioni è normativo. XHTML è un'applicazione XML e alla sintassi di questo deve conformarsi.
Non rispettare queste regole significa non avere documenti validi e ben formati. La cosa che le accomuna
è che queste regole pongono fine ad una serie di procedure che HTML consentiva e che ora sono invece
vincolate ad usi ben definiti.
**** 1.Gli elementi devono essere correttamente annidati ****
HTML                  XHTML
<b><i>un test</b></i> <b><i>un test</i></b>
Il primo esempio non è corretto in XHTML. Il tag <i> si sovrappone a <b>. La seconda colonna mostra
invece un corretto annidamento degli elementi. La prima pratica è consentita in HTML. Certo, il browser
dovrà interpretare qualcosa che è ambiguo, ma alla fine ci restituirà un testo in grassetto-corsivo (ciò
che volevamo). In XHTML non possono sorgere ambiguità , tutto segue una regola.
**** 2. I nomi di elementi e attributi devono essere in minuscolo ****
XML è un linguaggio case sensitive. Significa che <table> e <TABLE> sono cose diverse. In XHTML è
consentito solo l'uso delle minuscole per i nomi di elementi e attributi. Anche qui regole più
vincolanti.
HTML                                     XHTML
<TABLE><TR><TD>un test</TD></TR></TABLE> <table><tr><td>un test</td></tr></table>
**** 3. Gli elementi non vuoti devono essere chiusi ****
HTML     XHTML
<p>Test1 <p>Test1</p>
<p>Test2 <p>Test2</p>
In HTML la pratica esposta a sinistra è tollerata, in XHTML non lo è. Ogni elemento non vuoto (sono
quelli che contengono testo o altri elementi) deve avere dopo il tag di apertura quello di chiusura.
**** 4. I valori degli attributi devon essere posti tra virgolette ****
Anche questa pratica è tollerata in HTML. E, soprattutto, è causata da molti editor che la "dimenticano"
con molta disinvoltura.
HTML               XHTML
<img src=test.gif> <img src="test.gif">
**** 5. Ogni attributo deve avere un valore ****
Alcuni attributi di HTML non hanno un valore (si dice che sono standalone). E' il caso dell'attributo
selectedusato per identificare l'opzione di un menu a tendina selezionata all'apertura del documento. In
XHTML anche questi attributi devono essere valorizzati.
HTML                           XHTML
<option selected>test</option> <option selected="selected">test</option>
Il problema si pone anche nei form. Se ad esso non si assegna un'azione avremo questa situazione:
<form action=""></form>
Si può risolvere assegnando un valore fittizio:
<form action="action"></form>
**** 6. Gli elementi vuoti devono terminare con /> ****
In XML tutti i tag devono essere chiusi. Ma cosa fare con gli elementi vuoti? Si tratta di quelli che
non possono contenere nulla al loro interno ma semplicemente ricevere attributi: <meta>, <br>, <hr>,
<img> sono i più comuni. In XHTML tali elementi vengono chiusi terminando la dichiarazione con />.
HTML                 XHTML
<br>                 <br/>
<img src="test.gif"> <img src="test.gif"/>
**** 7. Uso di id e name ****
Per identificare un elemento si deve usare l'attributo id e non name. Apparantemente la cosa non fa una
grinza. In questo modo si ha una perfetta conformità con XML dove id è l'attributo standard per
l'identificazione dei frammenti. In realtà qui il cambiamento con HTML è notevole, perchè per elementi
come <img> o <a> l'attributo di identificazione è proprio name. Il passaggio a id non pone problemi nei
browser più recenti, ma con altri (Netscape 4, per esempio) non funziona. In questo caso e se la
compatibilità all'indietro è assolutamente necessaria, la stessa specifica XHTML 1.0 suggerisce di usare
entrambi gli attributi, anche se ciò è contro le regole:
HTML           XHTML
               <a id="test">
<a name="test> Per compatibilità :
               <a id="test" name="test">
Nelle specifche successive (cosa che è accaduta con XHTML 1.1) l'attributo name è stato abolito
completamente.
 
Uno degli argomenti più spinosi relativi a XHTML è la gestione dei linguaggi di programmazione,
tradizionalmente incorporati nel documento con il tag <script>. Procediamo con ordine.
***** Uso di <script> *****
In HTML il tag <script> serve a incorporare nel documento codice di programmazione. Il linguaggio più
comunemente usato è Javascript. Il tag è supportato anche in XHTML e va ugualmente inserito nella
sezione <head>....</head>. L'elemento <script> supporta i seguenti attributi:
charset   Specifica la codifica dei caratteri
defer     Dice al browser che lo script non genera documenti
langauage Specifica il linguaggio di scripting. E' obbligatorio quando l'attributo src non è
          specificato.
src       Contiene l'URL di uno script contenuto in un file esterno
type      Obbligatorio. Indica il tipo MIME dello script: es "text/javascript"
xml:space Usato per mantenere la spaziatura del codice
Dunque, uno script può essere direttamente incorporato nella pagina oppure inserito in un file esterno e
richiamato:
Script incorporato
<script type="text/javascript" language="javascript">
<!--
document.open()
document.writeln("Questo è XHTML!")
document.close()
//-->
</script>
 
Script collegato
<script type="text/javascript" src="mioscript.js">

</script>
***** Caratteri pericolosi *****
Fin qui niente di nuovo. Il problema sorge quando nello script si utilizzano caratteri "pericolosi"
(sensitive characters nella definizione XHTML). Si tratta di caratteri che possono ingenerare confusione
e fraintendimenti perchè il processore XML li interpreta in un modo, nel linguaggio di scripting hanno
tutt'altro significato. In Javascript >significa "maggiore di"; in XML indica la chiusura di un tag. Che
fare? Il W3C suggerisce due vie, ma entrambe presentano punti deboli.
**** Usare le sezioni CDATA ****
Nella specifica si suggerisce di racchiudere gli script all'interno di una sezione CDATA. Esse vengono
usate in documenti XML per racchiudere blocchi di testo contenenti caratteri che potrebebro essere
interpretati come elementi di marcatura.
Una sezione CDATA inizia con la stringa <![CDATA[ e termina con ]]>. Ecco come lo script visto in
precedenza apparirebbe:
<script type="text/javascript" language="javascript">
<![CDATA[
document.open()
document.writeln("Questo è XHTML!")
document.close()
]]>
</script>
Il punto debole di questo approccio è che i nostri browser non gestiscono affatto bene le sezioni CDATA.
**** Usare script esterni ****
Si potrebbe ovviare scrivendo gli script in un file esterno e collegandolo al documento. Tutto bene. Ma
se bisogna modificare lo script, magari con ASP o comunque con variazioni lato server? Non è possibile
farlo.
E allora? In effetti, se la situazione è quella appena prospettata, non rimane che usare il vecchio
metodo. Avremo un documento non conforme al 100% in attesa che XHTML sia in grado di incorporare i
linguaggi di scripting diversamente.
In XHTML vengono ereditate da HTML alcune regole che proibiscono l'annidamento di determinati elementi.
Si tratta a volte di casi limite, ma sono comunque regole che è importante conoscere. Vediamole:
   1. un elemento <a> non può contenere altri elementi <a>
   2. l'elemento <pre> non può contenere gli elementi <img>, <object>, <big>, <small>, <sub>, <sup>
   3. l'elemento <button> non può contenere <input>, <select>, <textarea>, <label>, <button>, <form>,
      <fieldset>, <iframe>, <isindex>
   4. l'elemento <label> non può contenere un altro elemento <label>
   5. l'elemento <form> non può contenere l'elemento <form>
La specifica XHTML 1.0 contiene nell'appendice C una serie di linee guida per mantenere la compatibilità 
con i browser esistenti. Riguardano aspetti molto importanti e sono da tenere sempre presenti quando la
retrocompatibilità è per voi fondamentale. Elenchiamo quelle principali, dal momento che ad alcune di
esse si è già fatto cenno.
**** 1. Elementi vuoti ****
Quando si usano elementi vuoti è opportuno, chiudendoli, lasciare uno spazio prima della slash. Usando
la sintassi standard (<br/>) si hanno problemi con certi browser. Dunque usate sempre questa forma: <br
/>, <img... />, <hr />
**** 2. Contenuto degli elementi vuoti ****
Capita frequentemente di lasciare vuoti elementi che richiedono un contenuto. Spesso, ad esempio, si
usano paragrafi vuoti per creare spazio nel documento. In tal caso è preferibile usare la forma completa
di chiusura e non quella minimizzata. Useremo quindi <p></p> e non <p />.
**** 3. Codifica dei caratteri ****
Se si usa la codifica dei caratteri usare sempre tale dichiarazione sia nella dichiarazione XML sia in
un meta tag:
<?xml version="1.0" encoding="UTF-8"?>
<meta http-equiv="Content-type" content='text/html; charset="UTF-8"' />
**** 4. Uso del carattere & ****
Se si fa uso della e commerciale (&) in valori di attributi è preferibile esprimerlo con un
riferimento ad una entità di carattere: "&amp;". Se, ad esempio, abbiamo un link di qusto tipo:
<a href="http://www.miodominio.it/indice.asp?nome=marco&cognome=rossi">
si scriverà :
<a href="http://www.miodominio.it/indice.asp?nome=marco&amp;cognome=rossi">
**** 5. CSS ****
Quando si collegano CCS esterni è opportuno che questi utilizzino le minuscole.
Bene. A questo punto possediamo tutti gli strumenti concettuali per iniziare a lavorare con XHTML. E'
giunto il momento di affrontare questioni più pratiche. Inizieremo dall'analisi della validazione.
Nella quinta lezione abbiamo effettuato una semplice prova di validazione della nostra prima pagina
XHTML, imparando che esistono due opzioni, a seconda che il documento sia online oppure offiline. Oltre
al validatore_del_W3C abbiamo anche segnalato quello alternativo del sito htmlhelp.com.
La prima validazione era, diciamo così, "pilotata", dal momento che era effettuata su un documento
sicuramente valido. Entriamo ora nei dettagli, partendo dall'analisi delle opzioni che il validatore
offre per svolgere il suo lavoro.
Nella figura_1 abbiamo riportato la schermata della pagina iniziale (l'esempio fa riferimento alla
procedura con upload del file). Come si può osservare, la prima casella è destinata al file da
convalidare: se non ricordate il path preciso, potete ovviamente usare la funzione "Sfoglia" per cercare
nelle cartelle del vostro computer.
La seconda casella (Document type) serve a specificare un DOCTYPE e una DTD. L'opzione di default è
"specified inline" . Significa che il DOCTYPE è dichiarato nel documento e che la convalida avverrà in
base a quello. Scorrendo la lista troverete tutti i possibili modelli, da HTML 2.0 fino a XHTML 1.0
STRICT.
Prima di effettuare la convalida si può scegliere cosa verrà mostrato nella pagina dei risultati. Non
selezionando nessuna casella verrà visualizzato solo il rapporto che certifica la correttezza o gli
errori presenti nella pagina. Le quattro checkbox consentono di aggiungere i seguenti elementi:
    * il codice sorgente - Show source input
    * un sommario del documento basato sui tag <h1>..<h6> - Show outline of this document
    * il codice elaborato dal parser - Show parse tree
    * gli attributi di questo codice - Exclude attributes from the parse tree
Se il documento non è valido si possono avere varie possibilità . Per esempio, non inserendo un DOCTYPE e
il namespace XHTML nell'elemento radice, verrà riportato un "fatal error": significa che il documento
non è stato praticamente preso in considerazione in quanto "ingiudicabile". In altri casi il validatore
segnala con precisione la riga e la colonna dove ha riscontrato gli errori ed offre la possibilità di
avere ulteriori spiegazioni o suggerimenti. Un piccolo consiglio: il validatore non gradisce l'assenza
di una dichiarazione che specifichi la codifica dei caratteri. In tali casi, pur constatando che il
documento è ben formato, non lo riterrà valido. Pertanto usate sempre un meta tag con una dichiarazione
di codifica. Quella più comune è sicuramente:
<meta http-equiv="content-type" content="text/html; charset=iso-8859-1" />
Se il documento è valido potrete inserire nelle pagine poche righe di codice che incorporano in essa la
gif (figura 2) che certifica la validità e puntano al validatore:
[Figura 2 - Logo del W3C XHTML 1.0]
***** Validare con Opera *****
Il piccolo grande browser Opera (versione 5 e 6) offre una bellissima caratteristica per tutti gli
sviluppatori. Mentre siete connessi alla rete e visualizzate un qualunque documento (anche presente solo
sul vostro computer) premete CTRL+ALT+V. Si aprirà una nuova finestra che vi porta dritti al validatore
del W3C con i risultati relativi al file che stavate visualizzando. Comodo ed efficace.
La questione del supporto di XHTML da parte dei browser è delle più interessanti. Nel corso delle
precedenti lezioni abbiamo più volte accennato all'argomento. Qui raccoglieremo le idee e fisseremo i
punti chiave del problema.
***** Compatibilità con il passato *****
XHTML 1.0 è un linguaggio che garantisce la compatibilità con il passato. Basta salvare il documento con
estensione .html e il gioco è fatto. Tutti i browser saranno in grado di rendere il documento,
soprattutto se si rispettano alcune semplici regole. Ne ricordiamo due che risolvono problemi con
Netscape 4 e con Explorer 4 e 4.5 per Mac:
   1. lasciare uno spazio prima della slash nei tag vuoti: <br /> e non <br/>
   2. omettere la dichiarazione XML
***** Compatibilità con il futuro *****
Uno dei concetti su cui tante volte si è insistito è quello di documento valido e ben formato.
Nell'ultima lezione abbiamo imparato tutto sulla validazione. Tenetelo in mente e fatela sempre. Perchè
fin quando ci saranno questi browser è l'unico modo che avete per assicurarvi che i vostri documenti
rispettino gli standard. I browser attuali non hanno infatti un meccanismo di controllo della
correttezza formale di un documento. Chiariamo subito.
Nel listato_2 abbiamo riportato lo stesso codice della prima_pagina_XHTML, ma con una piccola modifica:
abbiamo eliminato il tag di chiusura del paragrafo. Copiate il codice, incollate e salvate come
"test2.html". Aprite nel vostro browser. Nessuna differenza rispetto al primo esempio. Ora procediamo
alla validazione. Il validatore vi avvertirà che avete omesso il tag di chiusura: il documento non è
valido.
Cosa impariamo da questo? Che i browser di oggi hanno le maglie molto larghe, lasciano passare tutto,
per loro le DTD non esistono. Visto che per anni ha regnato l'anarchia del codice i loro parser HTML
sono abituati a tutto. Come stupirci? Pensate se fossero stati rigidi censori del nostro codice! Non
riusciremmo a vedere che una percentuale irrisoria di pagine (solo quelle scritte in modo corretto).
Ma facciamo un passo avanti e cerchiamo di capire come potrebbe essere il futuro. Non abbiamo bisogno di
costruire ipotesi. Possiamo provarlo sin da ora.
XHTML è XML, ricordate? Bene. I browser recenti (quelli di quinta e sesta generazione) sono tutti in
grado di gestire, più o meno bene, il formato XML. Ognuno di essi ha un parser XML, un processore che
analizza il documento. I parser XML sono di due tipi:
    * processori non validanti: verificano soltanto che il documento sia ben formato
    * processori validanti: oltre alla correttezza formale devono verificare che il documento sia
      conforme alla DTD di riferimento
Quelli implementati nei principali browser sono parser del tipo non validante.
Ora prendete i due documenti (la prima pagina e la sua versione modificata). Rinominateli, assegnando
questa volta l'estensione XML (trovate una copia dei file "test.xml" e "test2.xml" nel file_zip con i
materiali del tutorial).

I browser hanno comportamenti diversi nel modo di visualizzare l'output del primo documento (quello
corretto), ma tutti fanno la stessa cosa con quello che non è ben formato: interrompono la
visualizzazione e segnalano l'errore. Non è una bizzarria. E' quanto viene esplicitamente richiesto
nella specifica XML: quando incontra un errore un processore deve interrompere l'elaborazione del
documento.
Abbiamo riportato per comodità l'output dei due file prodotto dai seguenti browser (le immagini sono
accompagnate da note di commento):
    * Explorer_6_Windows
    * Netscape_6_Windows
    * Opera_6_Windows
    * Mozilla_Windows
Concludendo: i browser attuali tollerano, ma in futuro? Quando e se ci saranno browser XHTML una pagina
con errori non verrà caricata. Torna il discorso di fondo: ciò che oggi è facoltativo domani sarà 
necessario, perchè non prepararci per tempo al futuro?
In questa lezione vedremo con quali strumenti è possibile creare documenti XHTML. Valuteremo due diverse
situazioni: creare pagine ex novo e convertire vecchi documenti.
***** Editor *****
Scrivere in XHTML richiede, una grande attenzione al codice. Per certi versi, il passaggio ad un
linguaggio così rigido nelle sue regole è anche la vendetta degli editor testuali su quelli visuali.
Chiariamoci subito: chi scrive è stato per anni sostenitore ed utilizzatore soddisfatto di editor
WYSIWYG. Ma scrivere XHTML con questi tools è addirittura controproducente. Lavorando in modalità solo
visuale la speranza di avere un documento valido è praticamente nulla. Correggere tutto porta via troppo
tempo. Meglio scrivere con un buon editor testuale, magari fornito di funzionalità avanzate come
l'autocompletamento del codice. La speranza, che è quasi certezza stando alle dichiarazioni delle
software house, è che gli eredi delle attuali versioni di Dreamweaver o GoLive offriranno un supporto
maggiore verso gli standard.
A proposito di Dreamweaver, abbiamo inserito nei riferimenti a fondo pagina un ottimo tutorial curato da
Jeffrey Zeldman che offre una serie di utili suggerimenti per settare efficacemente il software di
Macromedia in vista di un suo utilizzo (sempre imperfetto) come editor XHTML.
Passiamo ora in rassegna quelli che appaiono oggi i tool più efficaci. Abbiamo limitato la scelta a
quelli che ci paiono i migliori editor per il mondo Windows e Mac, di cui abbiamo preso in esame solo il
supporto di XHTML.
**** Macromedia Home Site 5.0 (Windows) ****
Home Site 5 è un programma eccellente sotto vari aspetti e il supporto di XHTML è certamente notevole.
Se si crea un nuovo documento con il wizard iniziale e si sceglie XHTML come formato, il programma
adotta automaticemente l'opzione "Set Document as XHTML", inserendo il DOCTYPE scelto dall'utente,
configurando nel modo giusto i tag di chiusura e usando solo le lettere minuscole. Stupisce
negativamente che non venga inserito l'attributo xmlns nel tag <html> di apertura: si tratta come
sappiamo di una delle quattro regole di base di XHTML.
Dopo che si è scritto il codice, Home Site ci viene incontro con un'utile funzione di validazione, ma
purtroppo solo per la DTD Strict. Essa è comunque molto precisa nella segnalazione degli errori.
Home Site fornisce anche potenti funzionalità come l'autocompletamento e il cosiddetto "tag insight".
Usando quest'ultimo, mentre si opera all'interno di un tag, viene automaticamente visualizzato un
piccolo box con tutti i possibili attributi, rendendo così la scrittura molto più rapida. Purtroppo il
"tag insight" non è di tipo intelligente, nel senso che non si adegua alla DTD preselta. E' una
funzionalità davvero utilissima di cui è invece dotato uno dei programmi di cui parleremo più avanti.
Le piccole pecche cui si è accennato sono comunque compensate dalla presenza nel programma di una
versione Macromedia di HTML Tidy, un potente convertitore che se ben settato riesce a trasformare in
XHTML e rendere valido qualunque documento. Ne parleremo più avanti.
**** Altova XML Spy 4.0 ****
XML Spy è un altro grande prodotto, ma le sue caratteristiche sono molto diverse da quelle Home Site.
Mentre il software di Macromedia è infatti esplicitamente rivolto al web design, il programma della
austriaca Altova è tutto centrato su XML. Con esso potrete praticamente produrre qualunque documento
legato a XML: fogli di stile XSL, schemi, DTD complesse, file WML, SVG o RDF. Essendo XHTML parte
integrante di questa grande famiglia non poteva mancare un supporto per questo linguaggio.
La natura di editor XML è evidente per chi viene dal mondo del web design. In XML Spy (la cui
interfaccia non è delle più intuitive) si lavora a livelli di astrazione notevoli, non c'è praticamente
spazio per ausilii visivi o per wizard di qualunque tipo, anche se il programma consente una preview
interna sfruttando la presenza di Internet Explorer. Carente risulta anche l'aiuto in linea.
Nonostante ciò, è dotato di alcune caratteristiche davvero straordinarie. Il controllo sulla validità e
sulla correttezza formale è incredibilmente preciso ed efficace, al punto da rendere praticamente
inutile la validazione del W3C. Questo perchè tratta i documenti come XML e quindi effettua un confronto
severo rispetto alle DTD (di cui una copia è presente anche in locale). Inoltre, la sua funzionalità di
tag insight è intelligente. Se, ad esempio, si sceglie la DTD Strict, nel piccolo box compariranno solo
gli attributi consentiti in quella DTD. Si passa alla Transitional? Ecco che il software si adegua
fornendo gli attributi corrispondenti.
Concludendo. Un programma eccellente, ma che risulterà forse un pò ostico a chi è abituato a pensare ad
una pagina web principamente in termini visuali.
Una recensione_ampia del programma (centrata però su XML) è stata pubblicata sul numero di dicembre 2001
di PC Professionale ed è disponibile sul sito della rivista.
**** BB Edit 6.5 (Mac) ****
Se lavorate in ambiente Mac, la scelta è quasi obbligata: BB Edit di Bare Bones Software. La versione
6.5 è disponibile anche per il nuovo MacOs X ed offre un supporto validissimo per XHTML.
Anche qui, come in Home Site, quando si crea un nuovo documento si può contare su una sorta di wizard
iniziale che consente di settare gli elementi di base del documento. Rispetto ad Home Site le opzioni
sono però molto più numerose: è possibile scegliere il DOCTYPE, impostare la codifica dei caratteri, il
titolo, inserire o meno la dichiarazione XML. BB Edit, inoltre, inserisce correttamente il namespace
XHTML. Al termine della procedura abbiamo un documento XHTML di base valido e completo.
Al posto del tag insight, in BB Edit troviamo un eccellente tag maker, anch'esso sensibile al contesto e
alla DTD prescelta. Il tag maker è attivabile in vari modi, ma purtroppo non automaticamente. Una pecca
tutto sommato piccola, se ci si abitua alle scorciatoie di tastiera e se si valuta il set di
funzionalità di questo programma che è certamente il miglior editor di file testuali del mondo Mac e non
solo.
***** Convertitori *****
Se si ha la necessità di convertire molte pagine HTML in XHTML si hanno due possibilità . Affrontare
un'estenuante operazione di riscrittura manuale (magari con uso massiccio di "Trova e sostituisci") o
usare HTML Tidy.
Si tratta di una straordinaria utility creata da Dave Raggett pubblicata sotto licenza Open Source e
disponibile per un numero incredibile di piattaforme. Cosa fa? Semplice: dato un file di configurazione
in cui sono contenute le regole di trasformazione, il programma ripulisce le vecchie pagine e le adegua
allo standard XHTML. Il numero delle opzioni selezionabili è notevole, alcune riguardano aspetti (come
la codifica dei caratteri e delle entità ) certamente criptici per i non esperti. In questo e nel fatto
di essere utilizzabile solo da linea di comando sta la sua maggiore difficoltà d'uso. Una volta che si
siano imparate le regole, comunque, si rivela uno strumento efficace e insostituibile. Per chi volesse
contare sulla potenza di HTML Tidy ma sfruttando un'interfaccia amichevole rimane la possibilità di
usare il tool integrato in Home Site 5.0 di cui si è parlato.
***** Riferimenti *****
Dreamweaver_e_XHTML: come usare il popolare software di Macromedia per scrivere XHTML valido (o quasi).
Home_Site_5.0: presentazione del prodotto e supporto sul sito di Macromedia.
XML_Spy_4.0: la home page di uno dei migliori editor XML.
BB_Edit: il sito di Bare Bones Software.
HTML_Tidy: regole, impostazioni, tutorial e download di questo utilissimo e potente strumento di
conversione.
Con XHTML 1.0 il World Wide Web Consortium aveva voluto esplicitamente creare un linguaggio di
transizione: passare ad XML ma mantenendo il più possibile la compatibilità con il passato. La scelta di
basare le tre DTD su quelle di HTML 4.0 ne è la prova più evidente. XHTML 1.1 è invece tutto proietatto
verso il futuro. Nelle intenzioni del Consortium esso sarà la base per futuri linguaggi web estensibili
e facilmente adattabili ad un ampio numero di dispositivi.
La definizione di questa specifica è strettamente legata ad un'altra raccomandazione, quella relativa
alla modularizzazione_di_XHTML. Se XHTML 1.0 era consistito nella riscrittura di HTML come applicazione
XML, questo nuovo approccio punta invece a frammentare il linguaggio in tanti moduli indipendenti. E' un
argomento complesso e un suo approfondimento va oltre gli scopi di questa guida. In questa lezione
daremo pertanto solo riferimenti essenziali.
***** Linguaggio più "stretto" *****
In XHTML 1.1 il W3C ha portato al termine la sua redifinizione di un linguaggio di markup orientato solo
alla struttura. E' basato infatti sulla DTD Strict di XHTML 1.0: tutti gli elementi e gli attributi di
presentazione sono definitivamente esclusi. La dichiarazione DOCTYPE può dunque fare riferimento solo ad
una DTD e non a tre:
<!DOCTYPE
html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
Rimangono invariate le altre regole di base relative all'elemento radice <html> e alla dichiarazione del
namespace con l'attributo xmlns.
***** Moduli *****
La DTD XHTML 1.1 è diversa dalle precedenti. Non contiene una lista di elementi e attributi con le
regole che ne definiscono l'uso. E' invece costituita da diverse dichiarazioni che includono altrettanti
moduli. Le specifiche sui moduli XHTML fanno parte di un'altra raccomandazione, quella sulla
modularizzazione_di_XHTML.
Senza scendere nei dettagli, diciamo che ciascun modulo definisce un insieme di elementi e attributi per
una determinata classe di oggetti. Ecco perchè si è detto che XHTML 1.1 smonta il linguaggio. Esiste, ad
esempio, un modulo "structure" che serve a definire la struttura di base di un documento e che contiene:
body, head, html, title. E ancora, troviamo un modulo per il testo, uno per i form, uno per le liste e
così via. Potete farvi un'idea precisa sui moduli e sul loro contenuto consultando la specifica_XHTML
1.1.
Nella DTD XHTML 1.1 un modulo viene caricato con questa dichiarazione (l'esempio fa riferimento
all'inclusione del modulo form):
<!-- Forms Module ..... -->
<!ENTITY % xhtml-form.module "INCLUDE" >
<![%xhtml-form.module;[
<!ENTITY % xhtml-form.mod
PUBLIC "-//W3C//ELEMENTS XHTML Forms 1.0//EN"
"http://www.w3.org/TR/xhtml-modularization/DTD/xhtml-form-1.mod" >
%xhtml-form.mod;]]>
L'approccio modulare è stato ben descritto da Molly Holzschlag in uno dei suoi articoli_su_XHTML. Esso
viene paragonato all'uso di certi portatili in cui le varie periferiche possono essere inserite e tolte
a seconda delle necessità . Ho bisogno del floppy? Collego il floppy. Mi serve il CD-Rom ma non il DVD?
Facile, attacco il primo e stacco il secondo. Non mi serve nessuno dei tre? Non importa: il mio
portatile continuerà a funzionare.
Ecco perchè dei moduli inclusi nella DTD alcuni sono richiesti e altri opzionali. Quelli richiesti sono
indispensabili perchè senza di essi non si potrebbe nemmeno parlare di un documento. E' come se al
portatile di prima togliessimo, invece del floppy, la RAM: si potrebbe chiamare ancora PC?
***** Altre differenze *****
Nella specifica XHTML 1.1 vengono anche indicate le differenze con la DTD Strict di XTML 1.0. Esse sono:
    * l'attributo lang è sostituito da xml:lang
    * per gli elementi img e map l'attributo name è sostituito da id
    * è stata inserita la collezione di oggetti ruby
***** Riferimenti *****
Specifica_XHTML_1.1: è la raccomandazione definitiva datata 31 maggio 2001.
Come_creare_moduli_XHTML: dal sito del W3C. Articolo-tutorial complesso ma essenziale.
Introduzione_alla_modularizzazione: sempre dal sito del W3C, breve e coinciso articolo sui moduli.
Specifica_"Modularizzazione_di_XHTML": complessa, ricchissima, fondamentale. La seconda parte spiega in
maniera completa come implementare nuovi moduli ed estendere le DTD.
Il mercato della cosiddetta Internet Mobile è certamente uno dei più promettenti. L'avvento e
l'affermazione di tecnologie come GPRS e UMTS sono un'occasione importante non solo per le aziende
tradizionali del settore, ma anche per i fornitori di contenuti. Certo, le previsioni che volevano per
il 2002 una percentuale del 75% del traffico Internet diffuso su dispositivi mobili si sono rivelate
premature, ma ciò non ha diminuito l'interesse per un settore che deve ancora dare il meglio di sè.
La piattaforma finora usata per la diffusione di contenuti su cellulari e altri dispositivi mobili è
stata WAP 1.x, che usava come linguaggio una delle prime applicazioni XML, WML (Wireless Markup
Language). L'uso di WML è probabilmente uno dei motivi del mancato decollo del WAP. Difficoltà e alti
costi di implementazione, la necessità per gli sviluppatori di dover imparare un linguaggio nuovo,
l'adattamento dei server web sono stati tutti fattori di ostacolo.
Le principali aziende del settore, riunite nel Wapforum, hanno iniziato così un'opera di ripensamento e
ridefinizione della piattaforma. Uno dei cardini di questa operazione è l'adattamento agli standard di
Internet. Il motivo è facile da comprendere: si tratta di linguaggi facili, diffusi, che non richiedono
drastiche operazioni di ricostruzione e adattamento e che sono più potenti e flessibili di WML.
Quest'ultimo sarà ovviamente supportato dai prossimi browser mobili, ma il linguaggio elettivo della
piattaforma WAP 2.0 è XHTML.
Ma quale XHTML? I dispositivi mobili (cellulari, ma anche PDA e palmari di vario genere) sono limitati.
Poca memoria, schermi piccoli, navigazione oggettivamente poco agevole. C'è bisogno dunque di un
linguaggio che implementi solo gli elementi adatti a questi dispositivi. Questo linguaggio si chiama
XHTML Basic. E' basato sull'approccio modulare visto nella lezione precedente, ma invece di estendere,
snellisce e riduce all'essenziale il linguaggio. Come? Includendo solo pochi moduli (la specifica_XHTML
Basic definisce quali sono quelli supportati).
Tra gli elementi non supportati troviamo i frames, gli script di programmazione, l'uso di stili
incorporati con <style>, diversi elementi di testo, oltre a vari attributi di presentazione. E ancora:
sono supportati solo i moduli di base dei form, è consentito l'uso delle tabelle ma non nidificate.
Fondamentale è la possibilità di definire la presentazione dei documenti con CSS esterni collegati.
Le regole_di_base sono identiche a quelle di XHTML 1.0. La dichiarazione DOCTYPE per questa specifica,
che fa riferimento alla DTD XHTML Basic è la seguente:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
***** Riferimenti *****
La sezione riferimenti è questa volta più corposa del solito, ma una visita ai siti proposti vi darà un
quadro completo su XHTML Basic e sull'evoluzione dei servizi WAP. Cominciamo con le risorse di HTML.it:
Il_corso_di_WML: per conoscere il linguaggio di base di WAP 1.x
Programmare_WML: corso di base di WML scipt
Wapitalia: portale informativo sul mondo WAP
Punto di riferimento fondamentale, anche per XHTML Basic è il sito del W3C:
Specifica: è la raccomandazione ufficiale. Contiene tutto quello che c'è da sapere, compreso il driver
della DTD e i riferimenti ai moduli implementati.
Traduzione_italiana_della_specifica: ottima e provvidenziale, opera di Patrizia Andronico.
Tra i punti di riferimento obbligati su WAP e XHTML Basic va annoverato Forum Nokia, la sezione per gli
sviluppatori del sito della casa finlandese. Per accedere ai contenuti bisogna registrarsi
(gratuitamente). Vi consigliamo di farlo. La qualità e quantità di documentazione su XHTML è di livello
assoluto:
Il_sito_del_Forum_Nokia: pagina iniziale del portale.
La_sezione_browsing/wap: è il posto dove cercare notizie e documenti su XHTML.
Linee_guida_XHTML: documento ricchissimo su come realizzare documenti in XHTML Basic. Questioni di
usabilità , design, compatibilità e differenze con WML: fondamentale!
Nokia_Mobile_Internet_Toolkit: se siete seriamente interesasti allo sviluppo di applicazioni WAP non
potete non avere questo strumento. Consente la realizzazione, l'implementazione e il test di
applicazioni mobili basate su WML e XHTML. Scaricabili a parte sono i simulatori dei più diffusi
terminali Nokia.
XHTML_Basic_in_azione: presentazione animata in Flash del Nokia Mobile Browser, ovvero il browser che ci
farà navigare nelle pagine scritte in XHTML Basic.
Mozquito è una delle aziende più impegnate nella ridefinizione dei linguaggi Web basati su XML e
partecipa attivamente ai lavori del W3C. Tra le sue realizzazioni ci occupiamo qui di FML (Form Markup
Language). E' un linguaggio che estende XHTML e che ridefinisce l'uso e le potenzialità dei classici
form HTML. Stando alla documentazione ufficiale dell'azienda, FML dovrebbe:
    * ottimizzare e potenziare l'interazione tra l'utente e il server
    * ottenere con un solo linguaggio di markup risultati raggiungibili solo con uso complesso di
      Javascript o plug-in esterni
    * creare facilmente documenti distribuibili su varie piattaforme
Concretamente significa, ad esempio, creare velocemente slide-show, quiz, applicazioni di e-commerce,
sondaggi, motori di ricerca. Per apprezzare le possibilità di questo linguaggio potete visualizzare
alcuni esempi o il_tutorial presente sul sito di Mozquito: tutta l'applicazione è realizzata in una sola
pagina, senza uso di frame (un'altra delle potenti caratteristiche del linguaggio).
L'implementazione di FML è un classico esempio funzionante di modularizzazione. Riprendiamo l'esempio
già visto in un'altra lezione:
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//OVERFLOW//DTD XHTML-FML 1.0//EN"
"http://www.mozquito.org/dtd/xhtml-fml1.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:x="http://www.mozquito.org/xhtml-fml">
<head>
<title>Untitled</title>
</head>
<body>
<x:form>
</x:form>
</body>
</html>
Apparentemente è un normale documento XHTML, ma le differenze ci sono:
   1. La DTD (in verde) non è quella pubblica del W3C ma una versione "modificata" che implementa le
      caratteristiche di FML
   2. Vengono dichiarati due namespace: quello standard di XHTML (in rosso), quello per FML (in blue)
Questo è ciò che vediamo nel documento. In realtà , il cuore di tutto risiede nella DTD. Essa risulta
come un mix della DTD XHTML 1.1 per certi moduli e della DTD FML per altri. Come si ottiene questo
risultato? Escludendo i moduli riguardanti form, applet oppure oggetti e sostituendoli con quelli di
FML. Il codice di esempio riporta la dichiarazione di esclusione dei moduli di XHTML:
<!ENTITY % xhtml-applet.module "IGNORE" >
<!ENTITY % xhtml-script.module "IGNORE" >
<!ENTITY % xhtml-object.module "IGNORE" >
<!ENTITY % xhtml-form.module "IGNORE" >
<!ENTITY % xhtml-model.module "IGNORE" >

Subito dopo, scorrendo la DTD, troviamo la dichiarazione dei moduli FML che sostituiscono i form:
<!-- This section declares parameter entities used to provide
namespace-qualified names for all FML element types.
-->
<!-- module: fml-form-1.mod -->
<!ENTITY % FML.form.qname "%FML.pfx;form" >
<!ENTITY % FML.button.qname "%FML.pfx;button" >
<!ENTITY % FML.textinput.qname "%FML.pfx;textinput" >
-------------------------------------
Non entriamo in dettagli estremamente complessi: il meccanismo dovrebbe essere chiaro.
Realizzare documenti in XHTML-FML non è difficile. Per provare basta scaricare dal sito la demo di
Mozquito_Factory. Si tratta di un editor che implementa i form FML. I file prodotti dall'applicazione
hanno come estensione XHTML e sono di dimensione davvero ridotte se si pensa a quali caratteristiche
implementano. Ma con un ottimo meccanismo di codifica possono essere immediatamente convertite in HTML.
Avrete le stesse funzionalità , ma con codice Javascript e purtroppo con dimensioni maggiori: da 12kb si
può passare a 71kb! Cosa fare? Aspettare che ci siano browser in grado di leggere direttamente le pagine
XHTML-FML, trasformare in HTML ma con gli svantaggi visti oppure appoggiarsi al Matrix Server della
stessa Mozquito che effettua le trasformazioni sul server mantenendo dimensioni accettabili.
Uno dei motivi per scaricare la demo di Mozquito Factory è anche la presenza di molti esempi
funzionanti, che potranno rendere la giusta idea di questa eccellente estensione di XHTML.
***** Riferimenti *****
Specifiche_e_articoli_su_FML: dal sito di Mozquito.
 
***** Cosa realizzeremo *****
Obiettivo del tutorial è la realizzazione di un blog. Per i pochi che non lo sanno: blog è
l'abbreviazione di weblog. E' una sorta di cronaca digitale personale con una serie di post su vari
argomenti disposti in ordine cronologico. Il fenomeno è esploso da un paio di anni ed ha dato vita a
sperimentazioni interessantissime: sui contenuti, sul design, sulla creazione di sistemi di gestione dei
contenuti (CMS).
Per fare un blog serve essenzialmente una cosa: avere qualcosa da dire. Tecnicamente, ci si può
appoggiare a servizi dedicati (Blogger, Manila, LiveJournal, Pitas) o fare tutto da sè. Se questa è la
vostra soluzione, sappiate che per una gestione facile è fondamentale avere a disposizione uno spazio
web con supporto di tecnologie server-side. Tutto va bene: Windows + ASP, come Apache con PHP e MySQL.
***** Come funziona un blog *****
Il funzionamento di un blog è semplicissimo. Sono essenzialmente basati su una sola pagina principale
che ospita i post quotidiani, ma possono contenere una serie di link accessori interni (biografia,
contatti, archivi e cose del genere) o esterni (siti interessanti, segnalazioni, etc). Una visita a
bloggando.com (directory dei blog italiani) o a blogger.com potrà darvi un'idea su stili e tendenze.
La fase cruciale è quella dell'aggiornamento e dell'inserimento dei nuovi post. Il metodo deve essere
semplice e deve consentire possibilmente la conservazione dei contenuti in database o sistemi simili.
Ecco perchè è importante avere a disposizione tecnologie server-side. Per il nostro blog non ci baseremo
su database, ma useremo il più semplice XML. E visto che si parla di linguaggi, vediamo quali sono le
tecnologie che adotteremo.
***** Quali linguaggi useremo *****
L'idea guida di questo tutorial è che i linguaggi standard del W3C danno il meglio di sè se usati per lo
scopo per cui sono stati creati. Sono come singoli musicisti che vanno messi insieme per fare
un'orchestra. Ecco, allora, la lista ragionata dei nostri "suonatori":
Linguaggio Funzione
XHTML      Lo useremo per definire la struttura delle nostre pagine.
CSS        Con i CSS imposteremo il layout e lo stile grafico/tipografico del blog.
XML        In un file XML conserveremo i post che andremo poi a incorporare nella pagina principale.
XSL        Con XSL (Extensible Stylesheet Language) trasformeremo in XHTML i contenuti del documento XML.
ASP        Grazie ad ASP, che lavorerà sul lato server, supereremo le difficoltà di implementazione di XML nei
           browser.
Il workflow dell'applicazione può essere così schematizzato:
[http://www.html.it/xhtml/lez20_fig1.gif]
Con ASP carichiamo il documento XML e il foglio di stile XSL che lo trasformerà . Il risultato della
trasformazione, che avviene sul server, sarà un documento XHTML con un CSS collegato che ne definisce lo
stile. Questo documento sarà la pagina principale del blog.
***** Come procederemo *****
Le lezioni del tutorial affronteranno, nell'ordine, questi punti:
   1. creazione dei prototipi grafici
   2. creazione della struttura di base in XHTML
   3. definizione dello stile e del layout con i CSS
   4. gestione dei post con XML
   5. trasformazioni con XSL
   6. gestione del sito con ASP
   7. aggiornamento del blog
***** Quali strumenti ci servono *****
Potrebbe bastare un editor di testo. Sia perchè scrivendo si ha un controllo perfetto sul codice, sia
perchè forniremo di ogni documento il codice sorgente (basta un copia e incolla). Comunque, se lavorate
in Windows, vi suggerisco il terzetto Macromedia Home Site + XML Spy + Top Style Pro 2.10. Per testare
tutto è opportuno installare e settare correttamente il Personal Web Server o Internet Information
Server.
***** Materiali *****
Abbiamo riunito in un file zip tutti i file completati e commentati della nostra applicazione. Potete
scaricarli per seguire meglio le lezioni o testare subito il blog. Scompattando il file verrà creata
automaticamente una cartella "blog".
Scarica_il_file_blog.zip.
***** Riferimenti *****
Tra i riferimenti sono compresi ovviamente i siti citati nella lezione. Aggiungo i link di altri blog
dedicati al web design e accomunati da alcune specifiche tecniche per noi importanti: scrittura in
XHTML, validità , rispetto degli standard, utilizzo dei CSS. Tra essi (perdonatemi) il link del mio blog.
Questo tutorial non è altro che la spiegazione di come è stato realizzato, anche se cambiano alcune
funzioni avanzate e la grafica che è stata per l'occasione notevolmente semplificata:
4_banalitaten: il mio blog.
Zeldman.com: più di un blog: un riferimento assoluto.
Waferbaby: stile essenziale, contenuti originali. Un concentrato di intelligenza.
Hivelogic: pulito, ottima tipografia, è il blog di Dan Benjamin.
Un passo preliminare e importante in un progetto web è la realizzazione di un prototipo grafico. Esso è
utile per evidenziare la struttura e gli elementi stilistici di base che saranno poi tradotti in codice
XHTML (per la struttura) o CSS (per lo stile).
***** La struttura *****
Iniziamo con la struttura. Ecco l'immagine_del_prototipo_strutturale realizzato con Fireworks.
La pagina principale del nostro blog (X-blog) è costituita da sei sezioni:
   1. Sezione principale:è quella che contiene tutte le altre e che definisce lo spazio della pagina
      destinato al blog
   2. Testata:qui inseriremo il logo
   3. Menu:barra di navigazione orizzontale con link alle sezioni interne del sito
   4. Contenuto:è una sorta di box che definisce la sezione centrale, a sua volta distinta in due
      sottosezioni
   5. Navigazione:contiene link esterni suddivisi in categorie
   6. Post:qui verranno inseriti i post di X-blog
Al momento di tradurre in XHTML questa struttura non faremo uso di tabelle. Ogni elemento deve fare il
suo lavoro. Quando vorremo mostrare la classifica della serie A, useremo una tabella. Qui si tratta di
definire sezioni, blocchi di contenuto generici e in XHTML l'elemento da usare è <div>.
***** Lo stile *****
A questo punto possiamo dare un pò di vita alla nuda collezione di box annidati vista in precedenza. E'
il momento creativo. Qui imposteremo colori, margini, font, spaziature. Ed anche questa volta è
opportuno, prima di mettere mano al nostro editor CSS preferito, preparare il terreno con un buon
prototipo grafico.
Da questa_immagine potete farvi un'idea abbastanza precisa di come apparirà X-blog. Analizziamo alcuni
dettagli:
    * il font principale è Verdana, ma nel CSS vanno definiti caretteri alternativi
    * la sezione menuha uno sfondo giallo con testo rosso
    * lo sfondo della sezione navigazionerichiama quello della testata
    * l'intestazione delle categorie va differenziata dai link: la prima sarà definita con un tag <h1>,
      i secondi con un <p>
    * nella sezione postabbiamo questa struttura: titolo del post (<h1>), data (<h2>), testo (<p>)
***** Codice *****
Ora si può finalmente tradurre l'idea in codice. Ovviamente definiremo la struttura in XHTML, lo stile
in un CSS.
Nel listato_3 abbiamo riportato il codice del documento "blog.html", la pagina principale. Notate
innanzituto il rispetto delle regole di base XHTML (DOCTYPE, namespace, chiusura degli elementi, uso
delle minuscole). Osservate poi la pulizia e l'essenzialità . La DTD usata è quella Strict. Il listato_4
contiene invece una versione commentata dello stesso documento: vi aiuterà a chiarire ogni aspetto
relativo alla struttura. Attenzione però: il codice di questo documento vi serva da punto di
riferimento, non consideratelo come un punto d'arrivo. Nella nostra applicazione esso sarà generato
automaticamente grazie alla magia di XSL. Certo, il gioco potrebbe anche finire qui. Ma pensate al
momento in cui dovrete inserire nuovi post. Vi sembra comodo dover intervenire ogni volta sul documento
XHTML? Il nostro obbiettivo è separare i contenuti dalla presentazione. Quindi, ancora un pò di
pazienza, ci arriveremo.
Nel foglio di stile "mainstyle.css" definiamo invece le regole di formattazione. Anche di questo file
forniamo, nel listato_5, una versione commentata. Il CSS è piuttosto semplice.
Dopo le regole generiche per il tag <body>, contiene sei id(contraddistinti dal simbolo #), uno per
ciascuna sezione:
    * sezprinc
    * testata
    * menu
    * contenuto
    * navigazione
    * post
Di ognuno sono definite le regole di formattazione (larghezza, margini, bordi, colori, font, etc) e
ognuno viene associato ad un <div> nel file XHTML tramite l'attributo id:
<div id="sezprinc">, <div id="menu">, etc.
Inoltre, sono stati creati dei selettori contestuali. Visto che intendiamo usare il tag <p> o <h1> in
diverse sezioni e visto che devono avere una formattazione diversa si usa questa particolare forma di
selettore. Con #navigazione h1 stabilisco come deve apparire l'elemento <h1> all'interno della sezione
navigazione, con #post h1come appare nella sezione post.
Ricordiamo che tutti i documenti sono contenuti nell'allegato file_dei_materiali. Volendo testare il
tutto, scompattate lo zip e aprite nel browser il documento "blog.html".
***** E le tabelle? *****
Ritorniamo ad un punto appena accennato. Il layout di X-blog è fatto senza tabelle. E' una tecnica
ancora non completamente matura, ma che comincia a dare buoni frutti proprio nel settore dei siti
personali e dei blog. La non perfetta implementazione dei browser costringe ancora a usare vari
trucchetti per superare alcune incompatibilità . Nei browser recenti (quinta e sesta generazione di
Explorer, Netscape e Opera, più Mozilla) non avrete problemi. Rimangono i browser datati. Per questi il
supporto di questo tipo di layout è carente. Ma un blog è un sito personale e se non si sperimenta qui
non vedo dove. Le tecniche per l'implementazione di layout senza tabelle sono molte. La sezione
riferimenti contiene un elenco di ottimi siti dedicati all'argomento. Nella prossima lezione ci
limiteremo a spiegare il metodo usato per X-blog.
***** Riferimenti *****
La sezione riferimenti di questa lezione intende darvi un quadro dell'implementazione di layout senza
tabelle, basati solo sui CSS:
Introduzione_al_layout_con_i_CSS: introduzione? E' un articolo completo, ben scritto, ricco di esempi,
il migliore sull'argomento. Eric Costello sul sito di Apple.
CSS_layout_tecniques: il sito personale dello stesso Costello
CSS_Edge: esperimenti con i CSS di Eric Meyer
Box_Lesson: raccolta incomparabile di trucchi, tecniche e layout pronti per l'uso.
In questa lezione analizzeremo alcuni dettagli relativi al foglio di stile "mainstyle.css". In
particolare spiegheremo in che modo sia stato realizzato il layout senza fare uso di tabelle.
***** Centrare *****
Abbiamo visto nella_precedente_lezione che gli elementi fondamentali del CSS sono i sei #idche
definiscono le proprietà di formattazione delle corrispondenti sezioni (identificate con il tag <div>
nel documento XHTML). La prima cosa da evidenziare è il metodo usato per centrare il box principale
(#sezprinc).
In HTML avremmo inserito una tabella centrandola con l'attributo align:
<table align="center">
Nei CSS non è possibile usare un attributo simile se non per il testo (proprietà text-align). L'ostacolo
può essere superato con un uso accorto della proprietà margin. L'id #sezprinc è così definito:
#sezprinc {
background: #FFFFFF;
-------------------
margin : 20px auto;
text-align : left;
width : 574px;
}
Per centrare si procede in questo modo:
   1. Si assegna al box una larghezza esplicita (width: 574px;)
   2. Si assegna ai margini sinistro e destro il valore auto. In questo modo essi avranno una larghezza
      identica.
Nel nostro caso il valore della proprietà margin va così interpretato: il margine superiore è di 20
pixel, quello degli altri lati sarà calcolato automaticamente (auto). Questo è importante, perchè ci
consente un design fluido e ci fa essere certi che cambiando risoluzione il box sarà sempre centrato.
Alla risoluzione di 800x600 (figura_1), ad esempio, i margini sinistro e destro saranno di 113 pixel
(800-574=226/2=113). A 1024x768 di 225 pixel (figura_2).
Però...C'è un piccolo problema nell'uso di questo metodo: Explorer 5 per Windows non interpreta bene la
tecnica. Ma il modo per ingannarlo c'è. Il browser di casa Microsoft non gestisce secondo gli standard
nemmeno l'attributo text-align. Infatti, applica l'allineamento anche ai box e non solo al testo che
contengono. Allora, visto che #sezprincè contenuto nell'elemento body basta aggiungere tra gli attributi
di quest'ultimo l'istruzione "text-align: center;". Ecco il codice del nostro CSS, dove lo stile
dell'elemento body occupa infatti il primo posto:
body {
background : #FFFFFF;
-------------------
text-align : center;
}
Tutto bene? Un attimo. Explorer 5 in questo modo centrerà correttamente il box, ma sorge un problema. Se
definiamo l'attributo "text-align:center;" per l'elemento body succede che in tutti i box sottostanti il
testo sarà centrato. Rimediare è ancora facile. Basta specificare nelle proprietà di
#sezprincl'attributo "text-align:left;", cosa che, come potete osservare sopra, abbiamo fatto
puntualmente.
***** Testata *****
L'id #testatanon presenta particolari problemi. In questo caso abbiamo settato esplicitamente l'altezza
(height: 75px;), ma non la larghezza: essa sarà pertanto identica a quella del box parente (#sezprinc).
***** Menu *****
Poche osservazioni anche sull'id #menu. Abbiamo voluto che fosse meno ampio della testata. La sua
larghezza è infatti di 512px. Con i margini abbiamo quindi impostato la sua posizione rispetto agli
altri box:
margin : 0px 26px 1px;
Ricordiamo qui che l'ordine in cui vanno letti i valori di margin è il seguente: TOP, RIGHT, BOTTOM,
LEFT. In pratica, bisogna seguire, a partire dall'alto un senso orario. Nel nostrio caso, la sezione
menusarà praticamente unita alla testata(top = 0px), avrà un margine di 26px a destra e di un solo pixel
in basso. E a sinistra? Bene, nei CSS esistono delle semplici regole per evitare la replica dei valori.
Quando manca il valore per il lato sinistro (dovrebbe essere il quarto), esso sarà uguale a quello del
lato destro (il secondo). Quindi, il margine sinistro è di 26px.
***** Contenuto *****
Il box #contenutoè una sorta di scatola vuota che serve semplicemente a delimitare la sezione centrale e
a stabilirne le misure di base. La larghezza e i margini sono identici a quelli della sezione #menu. La
sua utilità consiste anche nel facilitare la gestione dei due box che contiene.
***** Navigazione *****
A parte i bordi, il colore di fondo e il padding, il menu di navigazione a sinistra ha due proprietà 
importanti che influenzano il layout generale della pagina.
La prima è la dichiarazione float: left; . Per capire la proprietà float dovete pensare al modo usato in
HTML per far scorrere il testo attorno ad un'immagine. Se si usa l'attributo <img align="left">
l'immagine rimane a sinistra e il testo scorre intorno alla sua destra (figura_3). Allo stesso modo,
definendo per l'id #navigazionefloat: left; facciamo in modo che esso rimanga a sinistra e che gli altri
elementi adiacenti vengano spostati alla sua destra, ma non su una riga diversa, cosa che avviene per il
box #post. Ecco cosa accade se eliminiamo l'istruzione (figura_4).
La seconda proprietà importante è la larghezza, che è uguale a 140px. Rimane la questione dell'altezza.
Vi renderete conto che se non si specifica nessun valore, essa sarà basata sul contenuto. Se volete
un'altezza fissa, usate height come per la testata.
***** Post *****
Siamo alla fine. L'id #postha una larghezza di 350px ed è posizionato alla destra di #navigazione. Ma
dove va posizionato precisamente? Qui entra in gioco il margine sinistro. Esso ha come valore 142px
(margin : 0px 0px 0px 142px;), calcolati a partire dall'elemento parente (l'id #contenuto). Non è
casuale. Se avessimo settato una distanza minore esso si sarebbe sovrapposto a #navigazione. Infatti, i
142px non sono altro che uguali alla larghezza di #navigazione+ 2 pixel. L'immagine potrà chiarirvi
questi particolari che possono sembrare un pò astrusi.
Bene. Il consiglio a questo punto è quello di sbizzarrirvi. Giocate un pò con il foglio di stile.
Cambiate colori, margini, bordi, font. Capirete che la creatività si esprime proprio nei CSS, mentre il
documento XHTML rimane intatto nella sua struttura.
Ora però dobbiamo riempire X-blog con i nostri post. E' il momento di pensare ai contenuti.
Nelle lezioni precedenti abbiamo evidenziato soprattutto una delle caratteristiche di XML: il suo
rigore. Correttezza formale e validità rispondono all'esigenza di avere un markup finalmente pulito e
controllato. Ora, affronteremo un'altra importante dimensione di questo linguaggio.
***** Gestione dei contenuti con XML *****
XML è una sorta di lingua franca. Non ha nulla dei linguaggi proprietari. Un documento XML è
semplicemente un file di testo e come tale leggibile su qualunque macchina. Si capisce, dunque, come si
riveli uno strumento potentissimo in applicazioni centrate sullo scambio di informazioni e sulla
distribuzione di contenuti su vari supporti. Inoltre, grazie alla possibilità di creare tag
personalizzati, i documenti sono autoesplicativi. Ogni tag mi dice esattamente la funzione che svolge e
il tipo di dati che definisce. La lettura di un buon manuale o del corso_XML_di_HTML.it potrà chiarire
questo e altri aspetti. Ora passiamo alla pratica e torniamo al nostro blog.
I dati che intendiamo conservare in XML sono i post che quotidianamente arricchiscono la nostra cronaca
digitale. Il motivo fondamentale per cui operiamo questa scelta è semplice: vogliamo tenere i contenuti
separati dal resto. In questo modo, le operazioni di aggiornamento e archiviazione dei post saranno
estremamente semplificate e volendo potremmo facilmente distribuirli su sistemi alternativi.
La struttura tipo di un post per X-blog è molto semplice. Ciascuno di essi avrà :
   1. un titolo
   2. la data di invio
   3. un testo
   4. eventuali link nel testo
Nel file "blog.html" (listato_3) abbiamo visto come questo schema si traduce in una struttura:
Sezione dei post
<div id="post">
<h2>08/03/2002</h2>
<h1>Titolo 1</h1>
<p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy
nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat.....</p>
Nel listato_6, invece, abbiamo riportato il codice del documento base di X-blog. Copiate, incollate e
salvate come "news.xml". Aprendo il file con Internet Explorer apprezzerete al meglio la struttura ad
albero del documento, con i singoli nodi strutturali contenuti all'interno dell'elemento radice. Qualche
nota di commento:
   1. il documento inizia con la dichiarazione XML
   2. la seconda dichiarazione serve a incorporare un foglio di stile XSL (ne parleremo più avanti)
   3. l'elemento radice è <news> che racchiude tutti i post
   4. il tag <post> definisce un singolo aggiornamento del blog
   5. <post> ha tre elementi figlio: <titolo>, <data>, <testo>
   6. all'interno dell'elemento <testo> è possibile avere un altro nodo, <link>(per collegamenti a siti
      esterni citati nel testo)
***** Presentare XML *****
Come è evidente, il documento "news.xml" non contiene alcuna informazione su come verrà presentato. Non
è una limitazione. E' così che deve essere. Per effettuare la formattazione di un documento XML in vista
della sua presentazione si possono seguire due metodi.
Il primo non vi risulterà nuovo: si usano i CSS. Applicare un foglio di stile CSS ad un documento XML è
infatti semplicissimo. Supponiamo di voler collegare a "news.xml" il foglio di stile "news.css". Dovremo
aggiungere, subito dopo la dichiarazione XML, quest'istruzione:
<?xml version="1.0" ?>
<?xml-stylesheet type="text/css" href="news.css" ?>
Il secondo metodo è quello che andremo ad analizzare nei dettagli nelle prossime due lezioni. E' basato
su XSL (Extensible Stylesheet Language), un linguaggio ben più potente dei semplici CSS in grado di
trasformare qualunque documento XML in vari formati: testo semplice, HTML, XHTML, persino PDF.
Finalmente capirete come "blog.html" sia generato automaticamente.
XSL è certamente uno dei più importanti linguaggi standard del W3C. Esso risulta composto di tre parti,
ciascuna delle quali rientra nella specifica XSL 1.0, pubblicata nell'ottobre 2001:
   1. XSLT: è un linguaggio che consente di trasformare documenti XML in altri formati (vedi la Guida a
      XSLT di HTML.it)
   2. Xpath: definisce espressioni e metodi per accedere ai nodi di un documento XML
   3. XSL FO (Formatting object): usato per formattare in maniera precisa un oggetto trasformato
Per il nostro tutorial si farà riferimento solo a XSLT e Xpath.
***** Cosa fa un foglio XSL *****
Un foglio di stile XSLT è un documento XML valido e ben formato. Fornisce un meccanismo per trasformare
un documento XML in un altro. Dal punto di vista del web design e per la nostra applicazione la
trasformazione che ci interessa è quella da XML in XHTML.
Una trasformazione può essere così schematizzata:
[Figura 1 - Schema di una trasformazione XSL]
Dato un documento XML d'origine e un foglio XSLT ad esso associato, un processore XSL produrrà un terzo
documento. In quest'ultimo, i contenuti saranno presi dal primo documento, la struttura e le regole di
presentazione dal secondo.
***** CSS e XSL *****
La parola "stylesheet" contenuta nel nome XSL può far pensare a una parentela con i CSS. In realtà 
questi due linguaggi sono molto diversi. Ciò che va però spiegato è che essi non sono da considerare
alternativi, ma complementari. E come tali li useremo in X-blog. Vediamo comunque le principali
differenze.
Innanzitutto, XSL è di gran lunga più potente. Un foglio di stile CSS, infatti, può contenere
principalmente le regole che definiscono lo stile dei vari elementi di una pagina. Come abbiamo visto, è
anche possibile stabilire importanti caratteristiche del layout, come posizione e dimensioni, ma tutte
le regole devono poggiare su una struttura definita altrove (in genere in un documento XHTML).
XSL va molto oltre. Può generare esso stesso lo stile di presentazione, ma può anche:
    * aggiungere nuovi elementi alla struttura
    * creare nuovi contenuti
    * filtrare e ordinare dati
    * generare documenti con diversi gradi di compatibilità 
    * usare complesse espressioni condizionali
Insomma, si può intuire che si tratta di operazioni che sono tipiche più di linguaggi come ASP che di
CSS.
***** Applicare un foglio XSL *****
Affrontiamo ora una questione cruciale. L'applicazione di un foglio XSL a un documento XML è in realtà 
molto semplice. La sintassi è simile a quella vista nella lezione precedente per i CSS:
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="news.xsl"?>
La cosa complicata è il supporto dei browser. Diciamolo subito: l'unico che garantisce un supporto
ottimale è Explorer 6 . Questo grazie alla presenza del parser MSXML 3.0, che ha notevolmente migliorato
il già discreto supporto della precedente versione 2.6. Il mancato supporto dei browser fa sì che
l'applicazione di fogli XSL nel modo visto in precedenza (con elaborazione sul lato client) sia oggi
quasi impraticabile. Non mancano comunque esempi di siti interamente realizzati con XML+XSL. Se avete
Explorer 6 potrete farvi un'idea precisa visitando l'eccellente XML/XSL_Portal. Provate a visitarlo con
qualunque altro browser per apprezzare le differenze.
***** Riferimenti *****
Questa è una guida a XHTML, pertanto non è qui possibile fornire approfondimenti su XSL. I riferimenti
proposti sono ottimi punti di partenza per iniziare ad orientarsi tra le principali regole del
linguaggio.
XSL_sul_W3C: da qui potete accedere a tutte le risorse del Consortium sul linguaggio, comprese le
specifiche ufficiali.
XSL_School: dal sito W3Schools un eccellente tutorial introduttivo.
XSL_e_CSS: ottimo tutorial sulla formattazione di documenti XML con fogli di stile CSS o XSL.
XSLT.com: portale su XSL con tutorial e link a risorse sul web.
XSL_Info: altro portale ricco di risorse e informazioni sul linguaggio, compresa una sezione su parser e
tool di sviluppo.
In questa lezione vedremo quali sono le fondamentali regole di funzionamento di un foglio XSLT. Nella
prossima, dove analizzeremo il foglio definito per X-blog, scenderemo maggiormente nei dettagli:
affrontando un caso concreto: faremo una specie di anatomia di un documento XSL.
***** Struttura di base *****
Un foglio di stile XSLT è un documento XML, pertanto è sottoposto alle stesse regole sintattiche: deve
essere insomma un documento valido. La struttura minima contiene due parti:
    * il prologo
    * l'elemento radice
Nel prologo si specifica in genere solo la dichiarazione XML:
<?xml version="1.0">
Per essa valgono le stesse regole già viste per XHTML.
Subito dopo il prologo è necessario dichiarare l'elemento radice. In un documento XSL l'elemento radice
è <xsl:stylesheet>. Esso deve contenere un attributo che definisca la versione del linguaggio e almeno
una dichiarazione di namespace. Quest'ultima ha come valore: "http://www.w3.org/1999/XSL/Transform".
La struttura di base di un foglio XSLT si presenta dunque così:
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
....................................
</xsl:stylesheet>

Tra il tag di apertura e quello di chiusura dell'elemento radice vanno definite tutte le regole di
trasformazione.
***** Scegliere il metodo di output *****
Prima della definizione delle regole di trasformazione è possibile specificare il formato del documento
finale. Ciò avviene tramite la dichiarazione <xsl:output>. All'interno di tale dichiarazione si possono
specificare vari attributi. Il più importante è certamente method, con cui si può impostare il formato
di output scegliendo tra xml, html e text:
<xsl:output method="html"/>
Altri attributi consentono di definire il DOCTYPE con la relativa DTD, la dichirazione XML, la scelta
della codifica dei caratteri. Ne vedremo un esempio concreto nella nostra applicazione.
***** Regole e templates *****
Un foglio di stile XSLT vede un documento XML come un albero fatto di nodi. Torniamo al file "news.xml"
(listato_6). Nella figura 1 abbiamo evidenziato graficamente la sua struttura:
[Figura 1 - Struttura ad albero del documento "news.xml"]
<news> è l'elemento radice; <post> è un suo elemento figlio. <data>, <titolo> e <testo> sono sullo steso
livello, ma tutti sono figli di <post>. L'elemento <link> è un nodo figlio di <testo>. Esso ha anche un
attributo: href.
Un processore XSLT può trattare sette tipi di nodi presenti in un documento XML:
    * l'elemento radice
    * gli attributi e i loro valori
    * i commenti
    * gli elementi
    * i namespace
    * le istruzioni di elaborazione
    * il testo contenuto in un nodo
Ora, in un foglio XSLT è necessario specificare delle regole per trasformare i singoli nodi. Ogni regola
viene definita in un template. Quando si crea un template è come se si dicesse: caro processore XSL,
quando incontri il nodo x esegui questa trasformazione. Esempio. Supponiamo di voler trasformare
"news.xml" in XHTML e che l'elemento <testo> con il suo contenuto debba essere racchiuso in un
paragrafo. In XSL creeremo questo template:
<xsl:template match="post">
<p><xsl:value-of select="testo"/></p>
</xsl:template>
Il processore percorrerà tutto l'albero del documento. Quando incontrerà l'elemento <post>, verificherà 
che <testo> sia presente come elemento figlio, trasformerà il testo in un paragrafo.
***** Rintracciare i nodi *****
Per individuare i singoli nodi si ricorre alla sintassi Xpath. Per capire come funziona Xpath si può
fare riferimento al modo in cui si individuano file e cartelle in un file-system. Se scrivo: C:
\documenti\ritratto.jpg significa che individuo:
    * un elemento radice (C:\)
    * una cartella al suo interno
    * un file all'interno della cartella
Se volessi specificare il path per l'elemento <testo> del file news.xml scriverei così in Xpath:
<xsl:template match="news/post/testo">
La sintassi Xpath è notevolmente più complessa e se ben usata consente di individuare e trasformare ogni
aspetto di documenti XML, anche molto complessi.
***** Elementi principali *****
Elenchiamo ora alcuni dei più importanti tag XSLT specificando per ciascuno la funzione. E' solo un
breve elenco, ma potrà darvi un'idea delle potenzialità di questo linguaggio. Per approfondimenti vi
rimandiamo alla sezione "Riferimenti" della lezione_precedente, mentre per un uso concreto di alcuni di
essi, vi aspetta la prossima lezione.
xsl:apply-templates Applica le regole definite in un tamplate.
xsl:attribute       Crea un attributo per un elemento.
xsl:comment         Genera un commento nel documento finale
xsl:element         Crea un nuovo elemento
xsl:for-each        Stabilisce una struttura ciclica ripetendo un template tutte le volte che un dato
                    nodo viene incontrato.
xsl:if              Usato per impostare semplici strutture condizionali.
xsl:include         Include un foglio XSL esterno
xsl:sort            Ordina un insieme di nodi in bse ai parametri forniti.
xsl:stylesheet      Elemento radice di un documento XSL
xsl:template        Genera un template.
xsl:text            Genera nuovo testo nel documento di output
xsl:value-of        Restituisce il valore di un elemento o di un attributo.
xsl:when            Usato per espressioni condizionali complesse

Per maggiori informazioni su XSLT rimandiamo alla Guida a XSLT pubblicata su HTML.it.
In questa lezione analizzeremo e spiegheremo nei dettagli il foglio di stile "xstyle.xsl" con cui
trasfomeremo in formato XHTML il documento "news.xml".
Iniziamo subito con una semplice prova. Nel listato_7 (ma lo trovate anche nel file_dei_materiali)
riportiamo il codice del foglio XSL. Copiate, incollate nel Blocco Note e salvate come "xstyle.xsl".
Riprendete ora il file "news.xml", apritelo, se è il vostro browser, con Explorer 6. Quello che vedrete
è esattamente identico al documento "blog.html" creato nel corso della lezione_21 (a parte il testo
delle news). La differenza? Il secondo documento è frutto di una trasformazione XSL, il primo è statico.
***** Analisi di xstyle.xsl *****
**** Dichiarazioni preliminari ****
[Figura 1 - Dichiarazioni preliminari]
Per prima cosa inseriamo la dichiarazione XML con l'attributo version. Subito dopo inseriamo l'elemento
radice <xsl:stylesheet>. Anche qui specifichiamo la versione. Segue la dichiarazione dei namespace. Il
primo fa riferimento a XSL , il secondo a XHTML. Significa che nel documento i tag senza prefisso vanno
interpretati come XHTML, quelli con il prefisso come XSL.
**** Output del documento ****
[Figura 2 - Dichiarazione dell'output del documento]
Con la dichiarazione <xsl:output> specifichiamo che il documento finale dovrà essere di tipo HTML e che
il codice verrà indentato. Dal momento che vogliamo produrre un documento XHTML valido, è necessario
definire un DOCTYPE con FPI e URI della DTD (vedi lezione_5). Scegliamo la DTD Strict.
**** Template del nodo radice ****
[Figura 3 - Template del nodo radice]
Stabiliamo un template per l'elemento radice. In Xpath esso viene indicato con la slash (/). Questa
dichiarazione è in genere la prima regola da stabilire. In questo modo il processore XSL applicherà le
trasformazioni sotto specificate a partire dal primo elemento, quindi a tutto il documento.
**** La parte statica del documento ****
[Figura 4 - Parte statica del documento]
Ritorniamo alla struttura di X-blog. Come ricorderete, esso avrà una parte statica (testata, menu, barra
di navigazione laterale) e una da aggiornare (quella con i post). La parte statica la riprendiamo così
com'è dal documento "blog.html". Ora capite la potenza di XSL. Di questa parte non vi è traccia in
"news.xml", lì abbiamo solo i post. Ma con un foglio XSL noi la possiamo creare da zero. Notate anche
che abbiamo incorporato il CSS "mainstyle.css": come vedete XSL e CSS fanno cose diverse, sono
complementari.
**** Gestione dei post ****
[Figura 5 - Template della sezione post]
Finora niente di particolare, direte. Abbiamo semplicemente creato una parte della nostra pagina usando
puro XHTML. Ora viene il bello. Siamo infatti arrivati alla sezione dei post contenuti nel documento
XML. Notate innanzitutto che tutto avviene all'interno del <div> che definisce la sezione.
Con la prima dichiarazione, <xsl:for-each select="news/post">, diciamo: applica le regole definite qui
sotto ogni volta che incontri un elemento <post>. Chi ha un pò di dimestichezza con ASP capirà subito
che è un meccanismo simile a quello usato per visualizzare i dati di un database con le espressioni do
while e loop. Oppure all struttura ciclica di VB Script con For Each...Next.
Subito dopo (<xsl:sort.../>) specifichiamo che i post vanno ordinati in ordine discendente in base al
valore dell'elemento <data>, che è di tipo testo. Dunque, è consigliabile, nella gestione dei post,
usare sempre le due cifre per il giorno (01, 02, 03, etc).
A questo punto, con la dichiarazione <xsl:value-of>, inseriamo nel documento di output i valori degli
elementi <titolo> e <data>. Il primo sarà racchiuso in un tag <h1>, il secondo in un <h2>.
Con l'ultima dichiarazione stabiliamo che il contenuto dell'elemento <testo> sarà racchiuso in un
paragrafo. In questo caso applichiamo le regole di trasformazione sono state definite in un template
separato che esamineremo tra poco.
**** Chiusura del documento XHTML ****
[Figura 6 - Chiusura del documento XHTML]
In questa sezione chiudiamo il documento XHTML e il tamplate per il nodo radice definito all'inizio.
**** Gestione dei link ****
[Figura 7 - Template per la gestione dei link]
All'interno del testo dei post possiamo anche inserire dei link e abbiamo visto come ciò si definisce in
"news.xml" (listato_6). Alla fine del documento XHTML, dobbiamo creare un template per la gestione di
questo elemento. Con l'attributo match stabiliamo che le regole vanno applicate ogni volta che il
processore incontra <link>. Ma cosa deve fare? Un link in XHTML è definito dal tag <a> e dall'attributo
href che contiene l'URL del file da visualizzare. Quindi: ogni volta che incontra <link> il processore
dovrà creare un elemento <a> (<xsl:element name="a">) con un attributo href (<xsl:attribute
name="href">) prima del testo contenuto da <link>. Il valore di href è inserito con <xsl:value-of>.La
chiocciola indica che il valore è preso da un'attributo e non da un elemento (figura 8):
[Figura 8 - Trasformazione dell'elemento <link>]
Chiudono i tag di chiusura ben annidati.
 
**** Fine del documento ****
[Figura 9 - Fine del documento]
Alla fine del documento troviamo il tag di chiusura dell'elemento radice.
Fatto. Per vostra comodità abbiamo inserito una versione commentata del foglio di stile che sintetizza
le osservazioni di questa lezione (listato_8).
A questo punto, se tutti i browser funzionassero come Explorer 6, avremmo finito. Basterebbe aprire nel
browser, come nella prova fatta all'inizio, "news.xml". Ma purtroppo così non è. Dobbiamo effettuare le
trasformazione sul server. E' il momento di usare ASP.
Il ruolo di ASP nella nostra applicazione dovrebbe ormai essere chiaro. Grazie a questa tecnologia,
facciamo in modo che la trasformazione e la gestione dei documenti XML avvenga sul server. Il file ASP
da usare, come vedrete, è dei più semplici. Prima però diamo qualche indicazione sui requisiti software
per poter implementare il sistema.
***** Requisiti software *****
Se provate il sistema in locale avete bisogno di un server web con supporto ASP. In ambiente Windows, la
scelta si restringe a Personal Web Server (Windows 95 - 98 - Millennium) o IIS (Windows 2000). In
entrambi i casi dovrete settare una directory virtuale che ospiti tutti i file.
Un requisito fondamentale è la presenza sul vostro sistema di un parser XML in grado di gestire le
trasformazioni XSL. Sin dai tempi di Exlorer 4, Microsoft distribuisce un parser con le sue principali
applicazioni. La prima versione che garantisce il supporto delle specifiche XSL del W3C è però la 3.0.
Essa va installata in modalità REPLACE. In pratica, deve rimpiazzare le precedenti versioni del parser e
diventare quella di default del sistema. Per ottenere questo risultato avete due sistemi a disposizione:
   1. installare Internet Explorer 6
   2. scaricare e installare dal sito Microsoft il pacchetto MSXML 3.0 SP2 (clicca_qui per andare alla
      pagina di download)
Al momento della pubblicazione dovrete ovviamente verificare che il vostro server abbia queste
caratteristiche.
***** Il file "default.asp" *****
Il listato_9 riporta il codice commentato del file "default.asp". Come vedete è molto semplice. Carica
in memoria il documento XML, il documento XSL e restituisce il risultato della trasformazione. Vi
consiglio di imparare queste poche righe di codice. Sono il metodo più semplice per caricare un
documento XML sul lato server.
Ora, supponendo che abbiate una directory virtuale "blog", potete aprire il documento usando l'URL:
http://nome_del_server/blog/default.asp, oppure
http://127.0.0.1/blog/default.asp
Siamo alla fine del nostro percorso. Abbiamo creato il blog, ora bisogna imparare a gestirlo. Il fatto
di aver tenuto separati i contenuti dagli elementi strutturali e di presentazione ci renderà la vita
molto facile.
La più comune operazione è l'inserimento di nuovi post. Il metodo più semplice è quello di aggiungere
manualmente i post in una copia locale del file "news.xml" e di inviare la copia aggiornata sul server
con ftp o sistemi simili. Non manca la possibilità di creare un'interfaccia di amministrazione via web,
come si fa con i database. Sarà magari l'argomento di un prossimo articolo.
Se avete intenzione di cambiare gli aspetti tipografici e del layout dovrete invece intervenire sul file
"mainstyle.css", senza toccare altro.
Un'ultima possibilità è che vogliate intervenire sulla struttura del documento, magari per inserire
nuovi elementi nel menu di navigazione o per cambiare quelli esistenti. Visto che la pagina principale
di X-blog è generata da un foglio XSLT, dovrete modificare il documento "xstyle.xsl".
In questa sezione della guida forniamo utili riferimenti su XML e XHTML. E' un universo in continua
evoluzione, che cambierà sicuramente il modo di lavorare di chi opera sul Web. La nostra speranza è
quella di aver stimolato la vostra curiosità .
***** XHTML *****
XHTML_sul_W3C: sito di riferimento per novità , specifiche, aggiornamenti.
XHTML_Guru: contiene introduzioni alle varie versioni del linguaggio, una sezione di link e libri, una
piccola raccolta di FAQ.
XHTML_School: un buon tutorial introduttivo e un'eccellente reference sul sito di W3Schools
Startkabel: mini-portale con link ad articoli e risorse
XHTML.org: pagina con news e riferimenti su XHTML, comprese mailing-list e newsgroup sull'argomento.
Ottimi articoli su XHTML si trovano anche nei più importanti siti di web-design e nei siti su XML
riportati qui sotto.
***** XML *****
XML_sul_W3C: la voce del Consortium
XML_Directory: raccolta di link e risorse
XML_School: tutorial ed esempi da W3Schools
XML.com: il sito su XML legato alla casa editrice O'Reilly&Associates. Una garanzia di eccellenza.
XML_Pitstop: sito ricchissimo sotto ogni aspetto. Incomparabile la raccolta di modelli di fogli XSLT.
XML/XSL_Portal: non solo è interamente costruito in XML e XSL, ma fornisce una serie incredibile di
trucchi e risorse.
Perfect_XML: ottimo e ricco. La cosa migliore è la raccolta di capitoli di esempio tratti dai migliori
manuali sui linguaggi legati a XML.
riferimenti sono ai libri ritenuti più validi dall'autore di questa guida.
***** In italiano *****
Tra i libri in italiano o tradotti in italiano su XHTML solo uno è davvero eccellente:
Molly E. Holzschlag, XML, HTML, XHTML Magic, Addison Wesley, 2002

Un ottima sezione su XHTML si trova anche nel manualone di Steven Holzner su XML:
Steven Holzner, XML Tutto & Oltre, Apogeo, 2001
***** In inglese *****
Steven Holzner, XHTML Black Book, Coriolis Group, 2000
AA.VV, Beginning XHTML, Wrox Press, 2000
Chuck Musciano & Bill Kennedy, HTML & XHTML : The Definitive Guide, O'Really, 2000
Michael Morrison & Dick Oliver, Sams Teach Yourself HTML and XHTML in 24 Hours, Sams, 2001
Altri volumi li potete trovare nella sezione libri di HTML.it.
 
 
 
 
 
 
 
 
 
 
 
 


 



' ===============================================================================
'                      2003 Holyguard.net - 2007_Abruzzoweb