I possibili errori presenti in questo documento, dovuti alla traduzione, sono di responsabilit� del traduttore e non sono in alcun modo imputabili al W3C. Per qualsiasi commento riguardo la traduzione rivolgersi a Patrizia Andronico.
L'unica versione ufficiale di questo documento � la versione originale in inglese: http://www.w3.org/TR/2000/REC-xhtml1-20000126)

XHTML^? 1.0: Extensible HyperText Markup Language

Una riformulazione di HTML 4 in XML 1.0

W3C Recommendation 26 January 2000

Questa versione (in inglese):

http://www.w3.org/TR/2000/REC-xhtml1-20000126

(Postscript version, PDF version, ZIP archive, or Gzip'd TAR archive)

Ultima versione (in inglese):

http://www.w3.org/TR/xhtml1

Precedente versione (in inglese):

http://www.w3.org/TR/1999/PR-xhtml1-19991210

Autori:

Vedi acknowledgements.

Copyright �2000�W3C^� (MIT,�INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.

---

Riassunto

Stato di questo documento

Questo documento � stato rivisto dai Membri del W3C e da altre parti interessate ed � stato approvato dal Direttore come una Raccomandazione del W3C. E' un documento stabile e pu� essere usato come materiale di riferimento o citato da un altro documento come una normativa di riferimento. L'obiettivo del W3C nel fare le Raccomandazioni � quello di richiamare l'attenzione alle specifiche e di promuovere la loro pi� ampia diffusione. Questo aumenta la funzionalit� e l'interoperabilit� del Web.

Questo documento � stato prodotto come parte del W3C HTML Activity. Gli scopi del HTML Working Group (members only) sono discussi nel HTML Working Group charter (members only).

Un elenco delle attuali Raccomandazioni del W3C e di altri documenti tecnici � reperibile all'indirizzo http://www.w3.org/TR.

La discussione pubblica sulle caratteristiche dell'HTML si ha attraverso la mailing list [email protected] (archivio).

Per favore, riportate gli errori presenti in questo documento a [email protected].

Una lista degli errori noti di questa specifica si trovano a http://www.w3.org/2000/01/REC-xhtml1-20000126-errata (in inglese).

Contenuto

1. Cosa � XHTML?

XHTML 1.0 (questa specifica) � il primo tipo di documento della famiglia XHTML. E' una riformulazione dei tre tipi di documento HTML 4 come applicazioni di XML 1.0 [XML]. Il suo scopo � quello di essere usato come linguaggio di contenuto che sia contemporaneamente conforme a XML e che operi con gli user agent in conformit� a HTML 4, nel caso in cui vengano seguite alcune semplici linee guida. Gli sviluppatori che migrano le loro applicazioni verso XHTML 1.0 avranno i seguenti vantaggi:

• i documenti XHTML sono conformi a XML. In quanto tali sono facilmente visualizzati, editati e validati con i tool standard di XML.
• i documenti XHTML possono essere scritti per funzionare in modo uguale o migliore di quanto facessero prima con gli user agent conformi a HTML 4, cos� come nei nuovi user agent conformi a XHTML 1.0.
• i documenti XHTML possono utilizzare applicazioni (per esempio script e applet) che si basano sia sul Document Object Model di HTML sia su quello di XML [DOM]
• poich� si ha una evoluzione della famiglia XHTML, i documenti conformi a XHTML 1.0 saranno sempre pi� pronti per interagire all'interno e con diversi ambienti XHTML.

1.1 Cosa � HTML 4?

SGML � un linguaggio per descrivere linguaggi di markup, in particolare per quelli usati nello scambio di documenti elettronici, sviluppo e pubblicazione di documenti. HTML � un esempio di linguaggio definito in SGML.

SGML viene usato dalla met� degli anni '80 ed � rimasto abbastanza stabile. La maggior parte della sua stabilit� si deve al fatto che il linguaggio � ricco di caratteristiche e flessibile. La flessibilit�, comunque, ha il suo prezzo, e questo prezzo � l'alto livello di complessit� che ha inibito l'uso di questo linguaggio in diversi ambienti, incluso il World Wide Web.

L'HTML, cos� come fu concepito originariamente, era un linguaggio per lo scambio di documenti scientifici e tecnici, adatto per essere usato da persone non specializzate nel trattamento di documenti. L'HTML ha risolto il problema della complessit� dell'SGML specificando un piccolo insieme di tag strutturali e semantici adatti alla realizzazione di semplici documenti. Inoltre, per semplificare la struttura del documento, l'HTML ha aggiunto un supporto per l'ipertestualit�. In seguito sono state aggiunte le capacit� multimediali.

In pochissimo tempo l'HTML � diventato largamente popolare e rapidamente ha superato il suo scopo originale. Fin dagli inizi dell'HTML c'� stata una continua invenzione di nuovi elementi da usare all'interno dell'HTML (come uno standard) e per adattarlo ad un mercato verticale altamente specializzato. Questa pletora di nuovi elementi ha portato a problemi di compatibilit� per i documenti nelle diverse piattaforme.

Dato il rapido proliferarsi dell'eterogenit� sia del software che delle piattaforme, � chiaro che l'adeguatezza dell'HTML 'classico' per l'uso su queste piattaforme � in qualche modo limitato.

1.2 Cosa � XML?

XML � stato concepito come un mezzo per riguadagnare la potenzialit� e la flessibilit� di SGML eliminando la maggior parte della sua complessit�. Nonostante sia la forma ristretta di SGML, XML conserva gran parte della potenza e della ricchezza di SGML, mantenendo ancora tutte le caratteristiche comunemente usate da SGML.

Conservando tali caratteristiche, XML rimuove le caratteristiche pi� complesse di SGML che rendevano difficile e costosa la creazione e il disegno di software appropriato.

1.3 Perch� la necessit� di XHTML?

• Gli sviluppatori di documenti e i disegnatori di user agent sono costantemente alla scoperta di modi nuovi per esprimere le loro idee attraverso nuovi marcatori. In XML � relativamente semplice intodurre nuovi elementi o aggiungere attributi agli elementi. La famiglia XHTML � stata concepita per accogliere queste estensioni attraverso moduli XHTML e tecniche per lo sviluppo di nuovi moduli conformi ad XHTML (descritti nella futura specifica di Modularizzazione di XHTML). Questi moduli permetteranno la combinazione di insiemi di caratteristiche nuove ed esitenti durante la creazione del contenuto cos� come il disegno di nuovi user agent.
• Costantemente vengono prodotte nuove forme di accesso ad Internet. Alcune stime indicano che nell'anno 2002 il 75% dei documenti visibili su Internet saranno sviluppati da queste piattaforme alternative. La famiglia XHTML � stata concepita tenendo conto della interoperabilit� con gli user agent generali. Attraverso un nuovo user agent e un nuovo meccanismo di specifica del documento, i server, i proxies e gli user agent potranno realizzare una migliore trasformazione del contenuto. In ultimo, sar� possibile sviluppare contenuto conforme a XHTML che sia utilizzabili da tutti gli user agent conformi a XHTML.

2. Definizioni

2.1 Terminologia

Definito per l'implementazione (Implementation-defined)

Un valore o un comportamento si dice definito per l'implementazione quando viene lasciata alla stessa implementazione il compito di definire (e documentare) i requisiti corrispondenti per una costruzione corretta del documento.

Pu� (May)

Rispettando l'implementazione, la parola "may" deve essere interpretata come una caratteristica futura che non viene richiesta in queste specifiche ma che pu� essere fornita. Rispettando la Conformit� del Documento, la parola "may" significa che le caratteristiche opzionali non devono essere usate. Il termine "optional" ha la stessa definizione di "may".

Deve (Must)

In queste specifiche, la parola "must" deve essere interpretata come un requisito obbligatorio dell'implementazione o della Stretta Conformit� dei Documenti XHTML, a seconda del contesto. Il termine "shall" ha la stessa definizione di "must".

Riservato (Reserved)

Si riferisce ad una valore o ad un comportamento che non � specificato e il cui uso non � neppure ammesso dalla Conformit� dei Documenti n� deve essere supportato dagli User Agent Conformi.

Dovrebbe (Should)

Rispettando l'implementazione, la parola "should" deve essere interpretata come una raccomandazione per l'implementazione, ma non come un requisito. Rispettando i documenti, la parola "should" deve essere interpretata come una raccomandazione pratica per la programmazione dei documenti e un requisito per la Stretta Conformit� dei Documenti XHTML.

Ammesso (Supported)

Alcune strutture in queste specifiche sono opzionali. Se alcune di queste vengono supportate, il loro comportamento sar� quello indicato in queste specifiche.

Non specificato (Unspecified)

Quando un valore o un comportamento non � determinato, le specifiche non definiscono requisiti di portabilit� sull'implementazione neanche quando si deve analizzare un documento che usi tale struttura. Un documento che richiede uno specifico comportamento in questa situazione, invece di tollerare qualsiasi comportamento nell'uso di questa struttura, non sar� un Documento Strettamente Conforme a XHTML.

2.2 Termini generali

Attributo

Un attributo � un parametro ad un elemento dichiarato nella DTD. Il tipo di un attributo e il suo insieme di valori, compreso un possibile valore di default, vengono definiti nella DTD.

DTD

Una DTD, o definizione di tipo di documento, � una collezione di dichiarazioni XML che. come collezione, definisce la struttura legale, gli�elementi, e gli�attributi che sono disponibili per l'uso in un documento che soddisfa la DTD.

Documento

Un documento � un flusso di dati che, dopo essere stato combinato con altri flussi di dati a cui fa riferimento, viene strutturato in modo che porta le informazioni contenute all'interno degli�elementi organizzati come definito nella�DTD associata. Vedere I Requisiti di Conformit� dei Documenti per maggiori informazioni.

Elemento

Un elemento � una unit� strutturale di un documento dichiarato nella�DTD. Il modello del contenuto dell'elemento viene definito nella�DTD e la semantica addizionale pu� essere definita nella descrizione commentata dell'elemento.

Funzionalit�

Le funzionalit� comprendono gli�elementi, gli�attributi, e la semantica associata con questi�elementi e�attributi. Una implementazione che supporti questa funzionalit� deve fornire le strutture necessarie.

Implementazione

Una implementazione � un sistema che fornisce un insieme di�strutture e servizi che supporti queste specifiche. Vedere User Agent Conformance per maggiori informazioni.

Analisi (Parsing)

Il parsing � l'azione secondo cui un�documento viene analizzato, e l'informazione contenuta all'interno del�documento viene filtrata nel contesto degli elementi in cui l'informazione � strutturata.

Presentazione (Rendering)

Rendering � l'azione secondo cui l'informazione viene presentata all'interno di un�documento. Questa presentazione viene fatta nella forma pi� appropriata rispetto all'ambiente (esempio: uditiva, visiva, per la stampa).

User Agent

Uno user agent � una implementazione che ricerca e processa i documenti XHTML. Vedi Conformit� degli User Agent (User Agent Conformance) per maggiori informazioni.

Validazione

La validazione � un processo secondo cui i�documenti vengono verificati rispetto alla�DTD associata, assicurando che la loro struttura, l'uso degli�elementi, e l'uso degli�attributi sia consistente con le definizioni nella�DTD.

Ben-formato

Un�documento � ben formato quando la sua struttura � in accordo con le regole definite nella Sezione 2.1 della Raccomandazione XML 1.0 [XML]. Principalmente questa definizione indica che gli elementi, delimitati dai loro tag iniziale e finale, sono annidati in maniera corretta uno dentro l'altro.

3. Definizione Normativa di XHTML 1.0

3.1 Conformit� del Documento

3.1.1 Documenti Strettamente Conformi

1. Deve essere validato rispetto ad una delle tre DTD presenti in Appendice A.
2. L'elemento radice del documento deve essere .
3. L'elemento radice del documento deve indicare lo spazio dei nomi di XHTML usando l'attributo xmlns [XMLNAMES]. Lo spazio dei nomi per XHTML � definito in http://www.w3.org/1999/xhtml.

4. All'interno del documento ci deve essere una dichiarazione di DOCTYPE prima dell'elemento radice. L'identificatore pubblico incluso nella dichiarazione di DOCTYPE si deve riferire ad una delle tre DTD presenti in Appendice A usando il corrispondente Identificatore Formale Pubblico. L'identificatore di sistema pu� essere cambiato per riflettere le convenzioni del sistema locale.

Qui viene riportato un piccolo esempio di un documento XHTML.

  
    
  
  
    
Moved to vlib.org.
  

Nota che in questo esempio viene inclusa la dichiarazione di XML. Una dichiarazione XML come quella sopra non viene richiesta da tutti i documenti XML. Si raccomanda fermamente agli autori di documenti XHTML di usare le dichiarazioni XML in tutti i loro documenti. Questo tipo di dichiarazione viene richiesta quando la codifica dei caratteri del documento � un'altra rispetto a quella usata per default UTF-8 o UTF-16.

3.1.2 Uso di XHTML con altri spazi di nomi

L'esempio seguente mostra il modo in cui XHTML 1.0 pu� essere usato insieme alle Raccomandazioni MathML:

� 
��� 
� 
� 
��� 
The following is MathML markup:
��� $�����\log_{���������3�������}x���$
� 

� 
� 1568491379
� 
��� 
��� 

������� This is also available online.
��� 
� 

3.2 Conformit� degli User Agent

1. Per essere consistente con le Raccomandazioni di XML 1.0 [XML], lo user agent deve analizzare e valutare un documento XHTML come "ben formato". Se lo user agent si dice validante, allora deve validare anche i documenti rispetto alla loro DTD in accordo con [XML].
2. Quando uno user agent afferma di supportare strutture definite all'interno di queste specifiche o richieste da queste specifiche attraverso le normative di riferimento, lo deve fare in modo consistente rispetto alla definizione di stuttura.
3. Quando uno user agent processa un documento XHTML come un generico XML, dovr� riconoscere solo gli attributi di tipo ID come identificatori di frammento (per esempio l'attributo id nella maggior parte degli elementi XHTML).
4. Se uno user agent incontra un elemento che non riconosce, deve presentare il contenuto di tale elemento.
5. Se lo user agent incontra un attributo che non riconosce, deve completamente ignorare le specifiche dell'attributo (per esempio, l'attributo e i suoi valori).
6. Se lo user agent incontra un valore di attributo che non riconosce, deve usare il valore di default dell'attributo.
7. Se lo user agent incontra un riferimento ad una entit� (diversa da quelle predefinite) per la quale lo user agent non ha processato nessuna dichiarazione (pu� succedere se la dichiarazione si trova in un sottoinsieme esterno che lo user agent non ha letto), l'entit� deve essere presentata come i caratteri (iniziando con un ampersand, &, e finendo con un punto e virgola) che formano il riferimento alla entit�.
8. Quando viene presentato il contenuto, lo user agent che incontra caratteri o entit� di tipo carattere che riconosce ma che non sa come presentare, dovrebbe visualizza il documento in modo tale che l'utente si accorga chiaramente che non � stata possibile una corretta presentazione.
9. I seguenti caratteri vengono definiti in [XML] come caratteri di spazi bianchi:

• Spazio ( )
• Tabulazione ( )
• Ritorno carrello ( )
• Line feed ( )

Il processore XML normalizza diversi sistemi di codice di fine linea in un singolo carattere di line-feed che viene passato all'applicazione. In aggiunta lo user agent XHTML deve trattare come spazi bianchi anche i seguenti caratteri:

• Form feed ()
• Zero-width space (​)

Negli elementi dove l'attributo 'xml:space' ha il valore 'preserve', lo user agent deve conservare intatti tutti i caratteri di spazi bianchi (fatta eccezione per i caratteri di spazi bianchi iniziali e finali che dovrebbero essere rimossi). In altri casi uno spazio bianco viene considerato secondo le seguenti regole:

• Tutti gli spazi bianchi che circondano elementi in blocco dovrebbero essere rimossi.
• I commenti vengono rimossi interamente e non hanno conseguenza sulla manipolazione di spazi bianchi. Un carattere di spazio bianco su entrambi i lati di un commento viene trattato come due caratteri di spazio bianco.
• Gli spazi bianchi iniziale e finale dentro un elemento in blocco devono essere rimossi.
• I caratteri di line feed all'interno di elementi in blocco devono essere convertiti in uno spazio (tranne quando l'attributo di 'xml:space' viene posto a 'preserve').
• Una sequenza di caratteri di spazi bianchi deve essere ridotta ad un singolo carattere di spazio bianco (tranne quando l'attributo di 'xml:space' viene posto a 'preserve').
• Rispetto alla presentazione, lo user agent dovrebbe visualizzare il contenuto in maniera appropriata al linguaggio secondo cui � scritto il contenuto stesso. Nelle lingue in cui la base di scrittura � il carattere latino, il carattere di spazio ASCII viene usato tipicamente sia come spazio grammaticale tra le parole che come spazio tipografico bianco; nelle lingue la cui scrittura � in relazione al Nagari (esempio Sanscrito, Thai, ecc.) i limiti tra le parole possono essere codificati usando il carattere 'space' ZW, ma non verranno visualizzati come caratteri tipografici di spazi bianchi; lingue con scritture di base araba possono codificare il carattere tipografico di spazio bianco con un carattere di spazio, ma possono anche usare il carattere spazio ZW per delimitare i limiti grammaticali 'interni' (quelle che sembrano parole arabe per un lettore inglese normalmente comprendono pi� parole, per esempio 'kitAbuhum'= 'kitAbu-hum' = 'libri loro' == i loro libri); e lingue di scrittura cinese normalmente non codificano questi identificatori n� usano spazi bianchi in questo modo.

4. Differenze con HTML 4

4.1 I documenti devono essere ben formati

Sebbene la sovrapposizione sia illegale in SGML, � stata ampiamente tollerata dai browser esistenti.

4.2 Gli elementi e i nomi degli attributi devono essere in lettere minuscole

sono tag diversi.

4.3 Gli elementi non vuoti richiedono il tag di chiusura

In HTML 4.0 basato su SGML alcuni elementi potevano omettere il tag di chiusura, in modo tale che gli elementi che seguivano implicavano tale chiusura. Questa omissione non � permessa in XHTML basato su XML. Tutti gli elementi, ad eccezione di quelli dichiarati come EMPTY nella DTD devono avere un tag di chiusura.

�
CORRETTO: elementi chiusi

here is a paragraph.

here is another paragraph.

SBAGLIATO: elementi non chiusi

here is a paragraph.

here is another paragraph.

4.4 I valori degli attributi devono sempre essere compresi fra doppi apici

Tutti i valori degli attributi devono essere compresi fra doppi apici, inclusi i valori numerici.

�
CORRETTO: valori di attributo tra doppi apici

SBAGLIATO: valori di attributo senza doppi apici

4.5 Minimizzazione degli attributi

XML non supporta la minimizzazione degli attributi. I valori degli attributi accoppiati devono essere scritti completamente. I nomi degli attributi come compact e checked non possono essere presenti negli elementi se non viene specificato il loro valore.

�
CORRETTO: attributi non minimizzati

SBAGLIATO: attributi minimizzati

4.6 Elementi vuoti

Gli elementi vuoti devono avere un tag di chiusura o il tag iniziale deve terminare con />. Per esempio
o

---

. Vedere HTML Compatibility Guidelines per informazioni sul modo con cui poter assicurare la compatibilit� retroattiva con gli user agent di HTML 4.

�
CORRETTO: tag vuoto chiuso

---

SBAGLIATO: tag vuoto non chiuso

---

4.7 La manipolazione di spazi bianchi nei valori degli attributi

Nei valori degli attributi, gli user agent elimineranno gli spazi bianchi iniziali e finali dai valori degli attributi e sostituiranno la sequenza di uno o pi� spazi bianchi (compreso il salto di linea) con un singolo spazio tra le parole (un carattere di spazio ASCII per le scritture di tipo occidentale). Vedere la Sezione 3.3.3 di [XML].

4.8 Gli elementi Script e Style

In XHTML gli elementi script e style vengono dichiarati come se avessere un contenuto di tipo #PCDATA. Come risultato < e & verranno trattati come inizio del marcatore, e entit� quali < e & saranno riconosciute come entit� di riferimento dal processore XML rispettivamente come < e &. Racchiudere il contenuto dell'elemento script o style dentro una sezione marcata CDATA evita il processamento di queste entit�.

Le sezioni CDATA vengono riconosciute dal processore XML e appaiono come nodi nel Modello dell'Oggetto di Documento, vedi Section 1.3 delle Raccomandazioni DOM Livello 1 [DOM].Una alternativa � quella di usare documenti esterni per gli script e gli style.

4.9 Esclusioni dell'SGML

L'SGML d� allo scrittore di una DTD la possibilit� di impedire che specifici elementi siano annidati in altri elementi. Queste proibizioni (chiamate "esclusioni") non sono possibili in XML.

Per esempio, la DTD Stretta di HTML 4 proibisce l'annidamento di un elemento 'a' dentro un altro elemento 'a' a qualsiasi profondit�. Non � possibile dettagliare tale proibizione in XML. Anche se queste proibizioni non possono essere definite in una DTD, certi elementi non dovrebbero essere annidati. Un elenco di questi elementi e degli elementi che non dovrebbero essere annidati con loro si trova nella normativa in Appendix B.

4.10 Gli elementi con attributi 'id' e 'name'

HTML 4 definisce l'attributo name per gli elementi a, applet, form, frame, iframe, img, e map. HTML 4 introduce anche l'attributo id. Entrambi questi attributi sono disegnati per essere usati come identificatori di frammenti di informazioni.

In XML gli identificatori di frammenti sono di tipo ID, e ci pu� essere un solo attributo di tipo ID per elemento. Quindi, in XHTML 1.0 l'attributo id viene definito di tipo ID. Con l'obiettivo di assicurare che i documenti XHTML 1.0 siano documenti XML ben-formati, i documenti XHTML 1.0 DEVONO usare l'attributo id quando definiscono gli identificatori di frammento, compreso con elementi che storicamente usavano anche un attributo name. Vedere HTML Compatibility Guidelines per informazioni su come assicurare la compatibilit� retroattiva delle ancore quando si servono di documenti XHTML come media di tipo text/html.

Nota che in XHTML 1.0 l'attributo name di questi elementi � formalmente proibito e verr� rimosso nella futura versione di XHTML.

5. Compatibilit�: punti di attenzione

Sebbene non vi sia nessun obbligo per i documenti XHTML 1.0 per quanto riguarda la compatibilit� con gli user agent esistenti, in pratica questo � facile da ottenere. Le linee guide per creare la compatibilit� dei documenti si trovano in Appendix C.

5.1 Tipi di Media di Internet

Al momento della pubblicazione di questa raccomandazione, il MIME generale raccomandato per le applicazioni basate su XML � stato gi� deciso.

Comunque, i documenti XHTML che seguono le linee guida indicate in Appendix C, "Linee guida sulla compatibilit� di HTML" possono essere etichettati con il tipo di Media per Internet "text/html", in quanto sono compatibili con la maggior parte dei browser HTML. Questo documento non presenta nessuna raccomandazione sull'etichetta MIME di altri documenti XHTML.

6. Direzioni future

XHTML 1.0 fornisce le basi per una famiglia di tipi di documento che estender� e delimiter� XHTML per supportare un ampio insieme di nuovi dispositivi e applicazioni, definendo moduli e specificando un meccanismo per la combinazione di questi modelli. Questo meccanismo permetter� l'estensione e la delimitazione di XHTML 1.0 in maniera uniforme attraverso la definizione di nuovi moduli.

6.1 Modularizzare HTML

Nel momento in cui XHTML si sposter� dallo user agent del tradizionale desktop ad altre piattaforme, � chiaro che non tutti gli elementi di XHTML saranno necessari in tutte le piattaforme. Per esempio un dispositivo manuale o un telefono cellulare possono supportare solo un sottoinsieme di elementi XHTML.

Il processo di modularizzazione spezza XHTML in una serie di piccoli insiemi di elementi. Questi elementi possono essere ricombinati per raggiungere i bisogni delle diverse comunit�.

Questi moduli saranno definiti in un futuro documento del W3C.

6.2 Sottoinsiemi e estensibilit�

La modularizzazione si porta dietro molti vantaggi:

• Fornisce un meccanismo formale per il sottoinsieme di XHTML.

�
• Fornisce un meccanismo formale per l'estensione di XHTML

.
• Semplifica la trasformazione tra i tipi di documenti.

�
• Promuove il riutilizzo di moduli in nuovi tipi di documenti.

�

6.3 Profili del documento

Il profilo di un documento specifica la sintassi e la semantica di un insieme di documenti. La conformit� ad un profilo di documento fornisce la base per garantire l'interoperabilit�. Il profilo del documento specifica le caratteristiche richieste per processare i documenti di questo tipo, per esempio quale formato di immagine pu� essere usato, i livelli di scripting, il supporto degli style sheet, e cos� via.

Per i designer dei prodotti questo permette di definire il proprio profilo standard dei vari gruppi.

Per gli autori, questo permette di evitare di scrivere versioni differenti dei documenti per diversi clienti.

Per gruppi speciali come i chimici, i medici o i matematici, questo permette di costruire un profilo speciale usando elementi standard di HTML insieme ad un gruppo di elementi appositamente disegnati per le specifiche necessit�.

Appendice A. DTD

Questa appendice � normativa.

Queste DTD e gli insiemi di entit� formano una parte normativa di questa specifica. L'insieme completo dei file delle DTD insieme con la dichiarazione XML e il Catalogo Aperto SGML � incluso nel file zip di questa specifica.

A.1 Definizione del Tipo di Documento

Queste DTD si avvicinano alle DTD di HTML 4. Verosimilmente quando queste DTD verranno modularizzate, verr� adottato un modo di costruzione delle DTD che corrisponda pi� strettamente a HTML 4.0.

XHTML-1.0-Strict

XHTML-1.0-Transitional

XHTML-1.0-Frameset

A.2 Insieme delle entit�

Gli insiemi di entit� di XHTML sono gli stessi di HTML 4, ma sono stati modificati in modo da essere dichiarazioni di entit� valide in XML 1.0. Nota che l'entit� per il segno dell'Euro (€ or € or €) � stata definita come parte di caratteri speciali.

Latin-1 characters

Special characters

Symbols

Appendix B. Limitazioni degli elementi

Questa appendice � normativa.

I seguenti elementi hanno limitazioni sugli elementi che possono essere annidati (vedere la Sezione 4.9). Questa proibizione si applica a tutte le profondit� di annidamento, cio� riguarda tutti gli elementi discendenti.

a

non pu� contenere altri elementi a.

pre

non pu� contenere gli elementi img, object, big, small, sub, or sup

button

non pu� contenere gli elementi input, select, textarea, label, button, form, fieldset, iframe or isindex

label

non pu� contenere altri elementi label

form

non pu� contenere altri elementi form

Appendix C. Linee guida per la compatibilit� con HTML

Questa appendice � normativa.

Questa appendice riassume le linee guida per gli autori che desiderano che i loro documenti XHTML sia visualizzabili con gli user agent HTML esistenti.

C.1 Istruzioni per il processo

E' necessario sapere che le istruzioni di processo sono visualizzabili con alcuni user agent. Nota comunque che quando la dichiarazione XML non viene inclusa in un documento, il documento pu� usare solo il carattere di default codificato da UTF-8 or UTF-16.

C.2 Elementi vuoti

Includere uno spazio bianco prima della barra e della parentesi angolare chiusa / e > di elementi vuoti, per esempio,
,

---

e . Inoltre, usare la sintassi minimizzata per i tag degli elementi vuoti, per esempio,
, dato che la sintassi alternativa

permessa da XML d� risultati imprevisti con molti user agent esistenti.

C.3 Minimizzazione degli elementi e contenuto degli elementi vuoti

Data una istanza vuota di un elemento il cui modello di contenuto non � EMPTY (per esempio, un titolo vuoto o un paragrafo) non usare la forma mimimizzata (per esempio usa

e non

).

C.4 Style sheet e script incorporati

Usare style sheet esterni se questi usano i caratteri < or & or ]]> or --. Usare script esterni se questi usano i caratteri < or & or ]]> or --. Nota che i parser XML possono rimuovere il contenuto dei commenti. Comunque, la pratica comune di "nascondere" gli script e gli style sheet all'interno di commenti rende il documento compatibile con le vecchie versioni di browser, ma non lo rende funzionante con implementazioni basate su XML.

C.5 Salto di linea all'interno dei valori dell'attributo

Evitare i salti di linea e i caratteri di spazi multipli all'interno dei valori dell'attributo. Questi sono manipolati in maniera inconsistente dagli user agent.

C.6 Isindex

Non comprendere pi� di un elemento isindex nel documento head. L'elemento isindex � sconsigliato in favore dell'elemento input.

C.7 Gli attributi�lang e�xml:lang

Usare entrambi gli attributi lang and xml:lang quando si vuole specificare il linguaggio di un elemento. Il valore dell'attributo xml:lang ha la precedenza.

C.8 Identificatori di frammenti

In XML gli URI [RFC2396] che terminano con gli identificatori di frammenti della forma "#foo" non si riferiscono a elementi con un attributo name="foo"; piuttosto si riferiscono a elementi con un attributo definito del tipo ID, per esempio l'attributo id in HTML 4. Molti client HTML esistenti non supportano l'uso degli attributi di tipo ID in questo modo, quindi devono essere sostituiti valori identici per entrambi questi attributi in modo da assicurare una compatibilit� futura e retroattiva (e.g., ...).

Inoltre, poich� l'insieme dei valori permessi per gli attributi di tipo ID � molto pi� piccolo di quelli per il tipo CDATA, il tipo dell'attributo name � stato cambiato in NMTOKEN. Questo attributo � limitato in modo tale che possa avere solo gli stessi valori del tipo ID, o come la produzione Name in XML 1.0 Sezione 2.5, produzione 5. Sfortunatamente questa limitazione non pu� essere espressa nella DTD di XHTML 1.0. A causa di questo cambiamento, si deve avere molta attenzione quando si convertono i documenti HTML esistenti. I valori di questi attributi devono essere unici all'interno del documento, validi, ed ogni riferimento a questi identificatori di frammenti (sia interni che esterni) dovrebbe essere aggiornato in modo che i valori vengano cambiati durante la conversione.

Notare, in fine, che XHTML 1.0 ha disapprovato l'uso dell'attributo name degli elementi a, applet, form, frame, iframe, img, e map, e sar� eliminato da XHTML nella versioni successive.

C.9 Codifica dei caratteri

Per specificare la codifica dei caratteri nel documento, usare sia la specifica dell'attributo di codifica nella dichiarazione xml (per esempio, ) sia una frase meta http-equiv (per esempio, ). Ha la precedenza il valore dell'attributo di codifica dell'istruzione di processo xml.

C.10 Attributi booleani

Alcuni user agent HTML sono capaci di interpretare gli attributi booleani quando questi appaiono nella loro forma completa (non-minimizzata), come richiesto da XML 1.0. Notare che questo problema non ha effetto sugli user agent conformi a HTML 4.0. Sono coinvolti i seguenti attributi: compact, nowrap, ismap, declare, noshade, checked, disabled, readonly, multiple, selected, noresize, defer.

C.11 Il Document Object Model e XHTML

La Raccomandazione del Livello 1 del Document Object Model [DOM] definisce le interfacce del modello dell'oggetto documento per XML e HTML 4. Il modello di oggetto del documento di HTML 4 specifica che gli elementi e i nomi degli attributi di HTML vengono restituiti in lettere maiuscole. Il modello di oggetto del documento XML specifica che gli elementi e i nomi degli attributi vengono restituiti in maiuscolo o minuscolo a seconda del caso in cui erano specificati. In XHTML 1.0, gli elementi e gli attributi sono specificarti in lettere minuscole. Questa apparente differenza pu� spiegata in due modi:

1. Le applicazioni che permettono l'accesso a documenti XHTML come tipo di media su Internet text/html via DOM possono usare il DOM di HTML e possono cos� assicurarsi che gli elementi e i nomi degli attributi vengano ritornati in lettere maiuscole da queste interfacce.
2. Le applicazioni che permettono l'accesso a documenti XHTML come tipo di media su Internet text/xml o application/xml, possono usare anche il DOM di XML. Gli elementi e gli attributi saranno ritornati in lettere minuscole. Inoltre, alcuni elementi XHTML possono o no apparire nell'albero degli oggetti in quanto sono opzionali nel modello di contenuto (per esempio l'elemento tbody all'interno di table). Questo accade perch� in HTML 4.0 alcuni elementi possono essere minimizzati in modo tale che il tag di apertura e di chiusura sia entrambi omessi (una caratteristica di SGML). Questo non � possibile in XML. Piuttosto che richiedere agli autori di documenti di inserire elementi estranei, XHTML ha posto tali elementi come opzionali. Le applicazioni si devono adattare a questo.

C.12 L'uso del carattere ampersand (&) nei valori degli attributi

Quando un valore di attributo contiene un ampersand (&), questo pu� essere espresso come un riferimento ad una entit� di tipo carattere (per esempio, "&"). Per esempio, quando l'attributo href dell'elemento a si riferisce ad uno script CGI con dei parametri, deve essere espresso come http://my.site.dom/cgi-bin/myscript.pl?class=guest&name=user invece che http://my.site.dom/cgi-bin/myscript.pl?class=guest&name=user.

C.13 Cascading Style Sheets (CSS) e XHTML

Le Raccomandazioni di livello 2 dei Cascading Style Sheet [CSS2] definiscono le propriet� di stile che vengono applicate all'albero di analisi di un documento HTML o XML. Le differenze nell'analisi produrranno risultati visivi o auditivi diversi a seconda del selector usato. La traccia seguente ridurr� questo effetto per i documenti che sono serviti senza modifiche in entrambi i tipi di media:

1. Gli style sheet CSS per XHTML dovrebbero usare i nomi degli elementi e degli attributi in lettere minuscole.
2. Nelle tabelle, l'elemento tbody verr� dedotto dall'analizzatore dello user agent HTML, ma non dall'analizzatore dello user agent XML. Quindi si dovrebbe sempre aggiungere esplicitamente l'elemento tbody se si vuole riferirsi a un selector CSS.
3. Dentro lo spazio dei nomi XHTML gli user agent si aspettano di riconoscere l'attributo "id" come un attributo di tipo ID. Quindi gli style sheet dovrebbero essere capaci di continuare usando la sintassi abbreviata del selector "#" anche se lo user agent non legge la DTD.
4. Dentro lo spazio dei nomi XHTML, gli user agent si aspettano di riconoscere l'attributo "class". Quindi gli style sheet dovrebbero essere capaci di continuare usando la sintassi abbreviata del selector ".".
5. I CSS definiscono diverse regole di conformit� per i documenti HTML e XML; tenere in considerazione che le regole HTML si applicano ai documenti XHTML distribuiti come HTML e le regole XML si applicano ai documenti XHTML distribuiti come XML.

Appendix D. Ringraziamenti

Questa appendice � informativa.

Queste specifiche sono state scritte con la partecipazione dei membri del gruppo di lavoro HTML del W3C:

Steven Pemberton, CWI (HTML Working Group Chair)

Murray Altheim, Sun Microsystems

Daniel Austin, AskJeeves (CNET: The Computer Network through July 1999)

Frank Boumphrey, HTML Writers Guild

John Burger, Mitre

Andrew W. Donoho, IBM

Sam Dooley, IBM

Klaus Hofrichter, GMD

Philipp Hoschka, W3C

Masayasu Ishikawa, W3C

Warner ten Kate, Philips Electronics

Peter King, Phone.com

Paula Klante, JetForm

Shin'ichi Matsui, Panasonic (W3C visiting engineer through September 1999)

Shane McCarron, Applied Testing and Technology (The Open Group through August 1999)

Ann Navarro, HTML Writers Guild

Zach Nies, Quark

Dave Raggett, W3C/HP (W3C lead for HTML)

Patrick Schmitz, Microsoft

Sebastian Schnitzenbaumer, Stack Overflow

Peter Stark, Phone.com

Chris Wilson, Microsoft

Ted Wugofski, Gateway 2000

Dan Zigmond, WebTV Networks

Appendix E. Riferimenti

Questa appendice � informativa.

[CSS2]

"Cascading Style Sheets, level 2 (CSS2) Specification", B. Bos, H. W. Lie, C. Lilley, I. Jacobs, 12 May 1998.

Ultima versione disponibile a: http://www.w3.org/TR/REC-CSS2

[DOM]

"Document Object Model (DOM) Level 1 Specification", Lauren Wood et al., 1 October 1998.

Ultima versione disponibile a: http://www.w3.org/TR/REC-DOM-Level-1

[HTML]

"HTML 4.01 Specification", D. Raggett, A. Le Hors, I. Jacobs, 24 December 1999.

Ultima versione disponibile a: http://www.w3.org/TR/html401

[POSIX.1]

"ISO/IEC 9945-1:1990 Information Technology - Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API) [C Language]", Institute of Electrical and Electronics Engineers, Inc, 1990.

[RFC2046]

"RFC2046: Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", N. Freed and N. Borenstein, November 1996.

Disponibile all'indirizzo: http://www.ietf.org/rfc/rfc2046.txt. Note that this RFC obsoletes RFC1521, RFC1522, and RFC1590.

[RFC2119]

"RFC2119: Key words for use in RFCs to Indicate Requirement Levels", S. Bradner, March 1997.

Disponibile all'indirizzo: http://www.ietf.org/rfc/rfc2119.txt

[RFC2376]

"RFC2376: XML Media Types", E. Whitehead, M. Murata, July 1998.

Disponibile all'indirizzo: http://www.ietf.org/rfc/rfc2376.txt

[RFC2396]

"RFC2396: Uniform Resource Identifiers (URI): Generic Syntax", T. Berners-Lee, R. Fielding, L. Masinter, August 1998.

Questo documento aggiorna gli RFC1738 e RFC1808.

Disponibile all'indirizzo: http://www.ietf.org/rfc/rfc2396.txt

[XML]

"Extensible Markup Language (XML) 1.0 Specification", T. Bray, J. Paoli, C. M. Sperberg-McQueen, 10 February 1998.

Ultima versione disponibile a: http://www.w3.org/TR/REC-xml

[XMLNAMES]

"Namespaces in XML", T. Bray, D. Hollander, A. Layman, 14 January 1999.

Lo spazio dei nomi XML fornisce un metodo semplice per qualificare i nomi usati nei documenti XML associandoli con lo spazio dei nomi identificati da una URI.

Ultima versione disponibile a: http://www.w3.org/TR/REC-xml-names

---

indice