Linguaggio Estensibile di Marcatura (XML) 1.1

1.1 Origine e Obiettivi

La presente specifica, insieme con gli standard ad essa associati (Unicode [Unicode] e ISO/IEC 10646 [ISO/IEC 10646] per i caratteri, Internet RFC 3066 [IETF RFC 3066] per i tag di identificazione della lingua, ISO 639 [ISO 639] per i codici dei nomi di lingua, e ISO 3166 [ISO 3166] per i codici dei nomi dei Paesi), fornisce tutte le informazioni necessarie alla comprensione di XML Versione 1.0 e alla costruzione di programmi per computer atti a elaborarlo.

Questa versione della specifica XML può essere distribuita gratuitamente, fintanto che tutto il testo e le note legali rimangono intatti.

1.2 Terminologia

La terminologia usata per descrivere i documenti XML viene definita nel corpo di questa specifica. Le parole chiave DEVE, non deve, Richiesto/obbligatorio, dovrà, non dovrà, dovrebbe, non dovrebbe, Raccomandato, ha facoltà/potrebbe, e facoltativo, quando Enfatizzate, sono da interpretarsi come descritto in [IETF RFC 2119]. In aggiunta, i termini definiti nel seguente elenco sono usati nella costruzione di quelle definizioni e nella descrizione delle azioni di un processore XML:

errore

[Definizione: Una violazione delle regole di questa specifica; le conseguenze sono indefinite. A meno che non sia diversamente specificato, la mancata osservazione di una prescrizione della presente specifica indicata da una delle parole chiave deve, Richiesto, non deve, dovrà e non dovrà è un errore. Il software conforme  ha facoltà di rilevare e riportare un errore e ha facoltà di prendere le contromisure per esso.]

errore fatale

[Definizione: Un errore che un processore XML deve rilevare e riportare all'applicazione. Dopo aver incontrato un errore fatale, il processore ha facoltà di continuare l'elaborazione dei dati per cercare ulteriori errori e ha facoltà di riportare tali errori all'applicazione. Nell'ottica di supportare la correzione degli errori, il processore ha facoltà di rendere disponibili i dati non elaborati dal documento (con dati carattere e marcatura frammisti) all'applicazione. Una volta che viene rilevato un errore fatale, comunque, il processore non deve continuare la normale elaborazione (ovvero, esso non deve continuare a passare all'applicazione nel modo consueto dati carattere e informazioni riguardo alla struttura logica del documento).]

a facoltà dell'utente

[Definizione: Il software conforme ha facoltà oppure deve (in dipendenza del verbo modale nella proposizione) comportarsi come descritto; se lo fa, esso deve fornire agli utenti i mezzi per abilitare o disabilitare il comportamento descritto.]

vincolo di validità

[Definizione: Un regola che si applica a tutti i documenti XML validi. Le violazioni dei vincoli di validità sono errori; essi devono, a facoltà dell'utente, essere segnalati dai processori che convalidano XML.]

vincolo di buona-formazione

[Definizione: Una regola che si applica a tutti i documenti XML ben-formati. Le violazioni dei vincoli di buona-formazione sono errori fatali.]

corrispondenza

[Definizione: (Di stringhe o nomi:) Due stringhe o nomi che vengono comparati devono essere identici. Caratteri con rappresentazioni multiple in ISO/IEC 10646 (ad es. caratteri sia con la forma pre-composta che con quella base+diacritica) corrispondono solo se hanno la stessa rappresentazione in entrambe le stringhe. Non viene attuata nessuna modifica dei caratteri maiuscoli e minuscoli. (Di stringhe e regole nella grammatica:) Una stringa corrisponde a un costrutto grammaticale se appartiene alla lingua generata da quel costrutto. (Di contenuto e modelli di contenuto:) Un elemento corrisponde alla sua dichiarazione quando è conforme al modo descritto nel vincolo [VV: Elemento Valido].]

per compatibilità

[Definizione: Marca una proposizione che descrive una caratteristica di XML inclusa solamente per assicurare che XML stesso rimanga compatibile con SGML.]

per interoperabilità

[Definizione: Marca una proposizione che descrive una raccomandazione non vincolante inclusa per incrementare le possibilità che i documenti XML possano essere elaborati dalla base esistente di processori SGML che precedono la WebSGML Adaptations Annex a ISO 8879.]

1.3 Motivazione ed elenco delle modifiche per XML 1.1

2.1 Documenti XML Ben-Formati

[Definizione: Un oggetto testuale è un documento XML ben-formato se:]

1. Preso per intero, corrisponde alla produzione etichettata come documento.
2. Aderisce ai vincoli di buona-formazione forniti in questa specifica.
3. Ciascuna delle entità parsed alla quale si fa riferimento direttamente o indirettamente all'interno del documento è ben-formata.

Documento

Aderire alla produzione del documento implica che:

1. Contiene uno o più elementi.
2. [Definizione: Esiste esattamente un unico elemento, chiamato la radice {root}, o elemento del documento, del quale non compare nessuna parte nel contenuto di qualsiasi altro elemento.] Per tutti gli altri elementi, se il tag-di-inizio è contenuto in un altro elemento, il tag-di-fine è contenuto nello stesso elemento. Detto più semplicemente, gli elementi, delimitati da tag-di-inizio e -di-fine, vengono nidificati in maniera appropriata all'interno di ciascun altro.

[Definizione: Come conseguenza di ciò, per ciascun elemento C non-radice nel documento, esiste un altro elemento P nel documento tale che C è il contenuto di P, ma non è presente nel contenuto di qualsiasi altro elemento che è presente nel contenuto di P. Ci si riferisce a P come il genitore {parent} di C, e a C come un figlio {child} di P.]

2.2 Caratteri

[Definizione: Un'entità parsed contiene testo, un sequenza di caratteri, che possono rappresentare marcatura o dati carattere.] [Definizione: Un carattere è un'unità atomica di testo come specificato da ISO/IEC 10646:2000 [ISO/IEC 10646]. Caratteri ammessi sono tabulazioni, ritorni a capo, avanzamenti di riga, e i caratteri ammessi da Unicode e ISO/IEC 10646. Le versioni di questi standard citati in A.1 Riferimenti Normativi erano attuali al momento in cui questo documento è stato preparato. Nuovi caratteri potrebbero essere stati aggiunti a questi standard da emendamenti o nuove edizioni. Di conseguenza, i processori XML devono accettare ogni carattere compreso negli intervalli specificati per Char. ]

Intervalli di Carattere

Il meccanismo per la codifica dei punti di codice in modelli binari potrebbe variare da entità a entità. Tutti i processori XML devono accettare le codifiche UTF-8 e UTF-16 di Unicode 3.1 [Unicode3]; i meccanismi per segnalare quale fra i due sia in uso, o per far entrare in gioco altre codifiche, vengono discusse più avanti, in 4.3.3 Codifica di Carattere nelle Entità.

[#x7F-#x84], [#x86-#x9F], [#xFDD0-#xFDDF],
[#x1FFFE-#x1FFFF], [#x2FFFE-#x2FFFF], [#x3FFFE-#x3FFFF],
[#x4FFFE-#x4FFFF], [#x5FFFE-#x5FFFF], [#x6FFFE-#x6FFFF],
[#x7FFFE-#x7FFFF], [#x8FFFE-#x8FFFF], [#x9FFFE-#x9FFFF],
[#xAFFFE-#xAFFFF], [#xBFFFE-#xBFFFF], [#xCFFFE-#xCFFFF],
[#xDFFFE-#xDFFFF], [#xEFFFE-#xEFFFF], [#xFFFFE-#xFFFFF],
[#x10FFFE-#x10FFFF].

2.3 Costrutti Sintattici Comuni

S (spazio bianco) consiste in uno o più caratteri di spaziatura (#x20), ritorni a capo, avanzamenti di riga, o tabulazioni.

Spazio Bianco

[Definizione: Un Name è un token [N.d.T.: lemma] che inizia con una lettera o con uno dei pochi caratteri di punteggiatura, e prosegue con lettere, cifre, trattini, sottolineature, due punti o punti, conosciuti nell'insieme come caratteri di nome.] I nomi iniziano con la stringa "xml", o con qualsiasi stringa che corrisponda a (('X'|'x') ('M'|'m') ('L'|'l')), sono riservati alla standardizzazione in questa o in future versioni di questa specifica.

Un Nmtoken (token di nome) è una qualsiasi combinazione di caratteri di nome.

Il primo carattere di un Name deve essere un NameStartChar, e qualsiasi altro carattere deve essere NameChars; questo meccanismo viene usato per prevenire che i nomi inizino con cifre europee (ASCII) o con caratteri combinanti di base. Sono consentiti quasi tutti i caratteri nei nomi, eccetto quelli che sono o potrebbero ragionevolmente essere usati come delimitatori. L'intenzione è quella di essere includenti piuttosto che escludenti, cosicché i sistemi di scrittura non ancora codificato in Unicode possano essere utilizzati nei nomi XML. Vedi I Suggerimenti per i nomi XML per suggerimenti sulla creazione dei nomi.

Gli autori di documenti sono incoraggiati a usare nomi che siano parole o combinazioni di parole significative nei linguaggi naturali, e di evitare caratteri simbolici o di spaziatura nei nomi. Notare che DUE PUNTI {COLON}, TRATTINO {HYPHEN-MINUS}, PUNTO {FULL STOP}, TRATTINO BASSO {LOW LINE} (sottolineatura), e PUNTO MEDIO {MIDDLE DOT} sono esplicitamente permessi.

I simboli ASCII e i segni di punteggiatura, accanto a un buon gruppo di caratteri simbolo Unicode, sono esclusi dai nomi perché essi sono più utili come delimitatori in contesti dove i nomi XML sono usati al di fuori dei documenti XML; fornire questo gruppo dà a quei contesti garanzie forti su cosa non può far parte di un nome XML. Il carattere #x037E, PUNTO INTERROGATIVO GRECO {GREEK QUESTION MARK}, è escluso perché quando viene normalizzato diventa un punto e virgola, cosa che potrebbe modificare il significato dei riferimenti di entità.

Name e Token

Il dato letterale è qualsiasi stringa virgolettata non contenente le virgolette usate come un delimitatore per quella stringa. I letterali vengono usati per specificare il contenuto di entità interne (EntityValue), i valori degli attributi (AttValue), e gli identificatori esterni (SystemLiteral). Si noti che un SystemLiteral può essere analizzato in modo logico  senza effettuare una scansione della marcatura.

Letterali

2.4 Dati carattere e Marcatura

Il testo consiste di dati carattere e marcatura frammisti. [Definizione: La marcatura prende la forma di tag-di-inizio, tag-di-fine, tag di elemento-vuoto, riferimenti di entità, riferimenti di carattere, commenti, delimitatori di sezioni CDATA, dichiarazioni di tipo di documento, istruzioni di processo, dichiarazioni XML, dichiarazioni di testo, e qualsiasi spazio bianco che sia al livello massimo dell'entità documento (cioè, fuori del elemento di documento e non all'interno di qualsiasi altra marcatura).]

[Definizione: Tutto il testo che non è marcatura costituisce i dati carattere del documento.]

Il carattere di "e commerciale" (&) e la parentesi angolare sinistra (<) non devono apparire nella loro forma letterale, eccetto quando vengano usate come delimitatori di marcatura, o all'interno di un commento, di un'istruzione di processo, o di una sezione CDATA. Se si rendono necessari da qualche altra parte, essi devono esseri codificati in carattere escape usando sia i riferimenti numerici di carattere che rispettivamente le stringhe "&" e "<". La parentesi angolare destra (>) potrebbe essere rappresentata usando la stringa ">", e deve, per compatibilità, essere codificata in caratteri escape usando sia ">" che un riferimento di carattere quando appare nel contenuto della stringa "]]>", quando quella stringa non sta marcando la fine di una sezione CDATA.

Nel contenuto di elementi, i dati carattere sono qualsiasi stringa di caratteri che non contiene il delimitatore iniziale di qualunque marcatura e non include il delimitatore di chiusura-sezione-CDATA, "]]>". In una sezione CDATA, i dati caratteri sono qualsiasi stringa di caratteri che non include il delimitatore di chiusura-sezione-CDATA, "]]>".

Per consentire ai valori di attributo di contenere sia le virgolette singole che doppie, l'apostrofo o il carattere di virgoletta singola (') potrebbero essere rappresentati come "'", e il carattere di doppie virgolette (") come """.

Dati Carattere

2.5 Commenti

[Definizione: i commenti hanno facoltà di apparire ovunque nel documento al di fuori di altre marcature; in aggiunta, essi hanno facoltà di apparire all'interno della dichiarazione del tipo di documento nei posti permessi dalla grammatica. Essi non fanno parte dei dati carattere del documento; un processore XML ha facoltà, ma non ha necessità, di rendere possibile a un'applicazione di recuperare il testo dei commenti. Per compatibilità, la stringa "--" (doppio trattino) non deve ricorrere all'interno dei commenti.] I riferimenti a entità di parametro non devono essere riconosciuti all'interno dei commenti.

Commenti

<!-- dichiarazioni per <head> & <body> -->

<!-- B+, B, oppure B--->

2.6 Istruzioni di Processo

[Definizione: Le istruzioni di processo (le PI) permettono ai documenti di contenere istruzioni per le applicazioni.]

Istruzioni di Processo

Le PI non fanno parte dei dati carattere del documento, ma devono essere convogliate verso l'applicazione. La PI inizia con una destinazione (PITarget) usata per identificare l'applicazione alla quale è diretta l'istruzione. I nomi di destinazione "XML", "xml", e così via sono riservati per la standardizzazione in questa o in future versioni della presente specifica. Il meccanismo della Notazione XML potrebbe essere usato per la dichiarazione formale delle destinazioni delle PI. I riferimenti di entità parametro non devono essere riconosciuti all'interno delle istruzioni di processo.

2.7 Sezioni CDATA

[Definizione: Le sezioni CDATA hanno facoltà di ricorrere ovunque possono ricorrere i dati carattere; sono usate per codificare blocchi di testo contenenti caratteri che altrimenti sarebbero stati riconosciuti come di marcatura. Le sezioni CDATA iniziano con la stringa "<![CDATA[" e finiscono con la stringa "]]>":]

Sezioni CDATA

All'interno di una sezione CDATA, solo la stringa CDEnd è riconosciuta come marcatura, cosicché le parentesi angolari sinistre e le "e commerciali" potrebbero ricorrere nella loro forma letterale; esse non hanno bisogno (e non possono) essere codificate in caratteri escape usando "<" e "&". Le sezioni CDATA non possono essere nidificate.

Un esempio di sezione CDATA, nella quale "<greeting>" e "</greeting>" vengono riconosciuti come dati carattere, e non come marcatura:

<![CDATA[<greeting>Salve, mondo!</greeting>]]> 

2.8 Prologo e Dichiarazione del Tipo di Documento

[Definizione: i documenti XML dovrebbero iniziare con una dichiarazione XML che specifichi la versione di XML che viene usata.] Per esempio, quello che segue è un documento XML completo, ben-formato, ma non valido:

<?xml version="1.0"?>
<greeting>Salve, mondo!</greeting> 

e così anche questo:

<greeting>Salve, mondo!</greeting>

La funzione della marcatura in un documento XML è di descrivere la sua allocazione e struttura logica e associare le coppie nome-valore con le sue strutture logiche. XML fornisce un meccanismo, la dichiarazione del tipo di documento, per definire vincoli sulla struttura logica e supportare l'uso di unità di allocazione predefinite. [Definizione: Un documento XML è valido se ha una dichiarazione di tipo di documento associata e se il documento rispetta i vincoli in esso espressi.]

La dichiarazione del tipo di documento deve apparire precedentemente al primo elemento nel documento.

Prologo

[Definizione: La dichiarazione di tipo di documento XML contiene o punta a dichiarazioni di marcatura che forniscono una grammatica per una classe di documenti. Questa grammatica è conosciuta come definizione del tipo di documento, o DTD. La dichiarazione del tipo di documento può puntare a un sotto-insieme esterno (un tipo speciale di entità esterna) contenente dichiarazioni di marcatura, o può contenere dichiarazioni di marcatura direttamente in un sotto-insieme interno, oppure entrambe le cose. La DTD per un documento consiste di entrambi i sotto-insieme presi insieme.]

[Definizione: Una dichiarazione di marcatura è una dichiarazione del tipo di elemento, una dichiarazione dell'elenco-attributo, una dichiarazione di entità, o una dichiarazione di notazione.] Queste dichiarazioni potrebbero essere contenute per intero o in parte all'interno di entità di parametro, come descritto nei sottostanti vincoli di buona-formazione e validità. Per ulteriori informazioni, si veda 4 Strutture Fisiche.

Definizione del Tipo di Documento

Si noti che è possibile costruire un documento ben-formato contenente un doctypedecl che non punti né a un sotto-insieme esterno né contenga un sotto-insieme interno.

Le dichiarazioni di marcatura potrebbero essere costruite in tutto o in parte da testo in sostituzione di entità di parametro. Le produzioni successive in questa specifica per non-terminali individuali (elementdecl, AttlistDecl, e così via) descrivono le dichiarazioni dopo che tutte le entità di parametro sono state incluse.

I riferimenti di entità di parametro vengono riconosciute ovunque nella DTD (sotto-insiemi interni ed esterni ed entità di parametro), eccetto nei letterali, istruzioni di processo, commenti, e i contenuti di sezioni condizionali ignorate (vedi 3.4 Sezioni Condizionali). Essi vengono inoltre riconosciuti in letterali di valore d'entità. L'uso di entità di parametro nel sotto-insieme interno è ristretto nel modo descritto sotto.

Come un sotto-insieme interno, il sotto-insieme esterno e ogni entità parametro esterna referenziata in un DeclSep deve consistere in una serie di dichiarazioni di marcatura complete dei tipi permessi dal simbolo non-terminale markupdecl, intervallati con spazio bianco o riferimenti di entità-parametro. Comunque, porzioni dei contenuti del sotto-insieme esterno o di queste entità parametro esterne potrebbero in modo condizionale essere ignorate usando il costrutto di sezione condizionale; ciò non è permesso nel sotto-insieme interno, ma è permesso nelle entità parametro esterne referenziate nel sotto-insieme interno.

Sotto-insieme Esterno

Anche il sotto-insieme esterno e le entità parametro esterne differiscono dal sotto-insieme interno, nel fatto che in loro, i riferimenti a entità-parametro sono permessi all'interno delle dichiarazioni di marcatura, non solo fra le dichiarazioni di marcatura.

Un esempio di un documento XML con una dichiarazione di tipo di documento:

<?xml version="1.0"?>
<!DOCTYPE greeting SYSTEM "hello.dtd">
<greeting>Salve, mondo!</greeting> 

L'identificatore di sistema "hello.dtd" fornisce l'indirizzo (un riferimento URI) di una DTD per il documento.

Le dichiarazioni possono anche essere fornite localmente, come in questo esempio:

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE greeting [
  <!ELEMENT greeting (#PCDATA)>
]>
<greeting>Salve, mondo!</greeting>

Se vengono usati sia i sotto-insiemi interni che esterni, il sotto-insieme interno deve essere considerato ricorrente prima del sotto-insieme esterno. Questo ha l'effetto di dare la precedenza alle dichiarazioni di entità e di elenco-attributo nel sotto-insieme interno rispetto a quelle nel sotto-insieme esterno.

XML 1.1 processors SHOULD accept XML 1.0 documents as well. If a document is well-formed or valid XML 1.0, and provided it does not contain any control characters in the range [#x7F-#x9F] other than as character escapes, it may be made well-formed or valid XML 1.1 respectively simply by changing the version number.

2.9 Dichiarazione di Documento Autonomo

Le dichiarazioni di marcatura possono influire sul contenuto del documento, quando passate da un processore XML a un'applicazione; esempi sono i valori predefiniti di attributo e le dichiarazioni di entità. La dichiarazione di documento autonomo {standalone}, che ha facoltà di comparire come un componente della dichiarazione XML, segnala se esistono o no tali dichiarazioni che compaiono esterne all'entità documento o nelle entità parametro. [Definizione: Una dichiarazione esterna di marcatura viene definita come una dichiarazione di marcatura che ricorre in un sotto-insieme esterno o in un'entità parametro (esterna o interna, quest'ultima viene inclusa perché i processori non-validanti non sono tenuti a leggerle).]

Dichiarazione di Documento Autonomo

In una dichiarazione di documento autonomo, il valore "yes" indica che non esistono dichiarazioni esterne di marcatura che riguardano l'informazione passata dal processore XML all'applicazione. Il valore "no" indica che esistono o potrebbero esistere tali dichiarazioni esterne di marcatura. Si noti che la dichiarazione di documento autonomo denota solo la presenza di dichiarazioni esterne; la presenza, in un documento, di riferimenti a entità esterne, quando queste entità sono dichiarate internamente, non modifica il suo status di autonomia.

Se non esistono dichiarazioni esterne di marcatura, la dichiarazione di documento autonomo non ha significato. Se esistono dichiarazioni esterne di marcatura ma non esiste una dichiarazione di documento autonomo, viene presunto il valore "no".

Ogni documento XML per il quale valga standalone="no" può essere convertito in modo algoritmico in un documento autonomo, cosa che potrebbe essere desiderabile per alcune applicazioni di trasporto di rete.

Un esempio di dichiarazione XML con una dichiarazione di documento autonomo:

<?xml version="1.1" standalone='yes'?>

2.10 Gestione dello Spazio Bianco

Un processore XML deve sempre passare tutti i caratteri di un documento che non sono marcatura verso l'applicazione. Un processore XML validante inoltre deve informare l'applicazione di quali di questi caratteri costituisce lo spazio bianco che compare nel contenuto dell'elemento.

Uno speciale attributo di nome xml:space potrebbe essere allegato a un elemento per segnalare l'intenzione che in quell'elemento, lo spazio bianco dovrebbe essere preservato dalle applicazioni. Nei documenti validi, questo attributo, come ogni altro, deve essere dichiarato se viene usato. Quando dichiarato, deve essere fornito come un tipo enumerato i valori del quale sono uno o entrambi quelli di "default" e "preserve". Per esempio:

<!ATTLIST poem  xml:space (default|preserve) 'preserve'>

<!ATTLIST pre xml:space (preserve) #FIXED 'preserve'>

Il valore "default" segnala che le modalità predefinite per elaborare lo spazio bianco da parte delle applicazioni sono accettabili per questo elemento; il valore "preserve" indica che la volontà che le applicazioni preservino tutto lo spazio bianco. Questo intento dichiarato si considera da doversi applicare a tutti gli elementi all'interno del contenuto dell'elemento dove viene specificato, a meno che sovrascritto con un'altra istanza dell'attributo xml:space. Questa specifica non dà altro significato a qualsiasi valore di xml:space diverso da "default" e "preserve". È un errore se vengono specificati altri valori; il processore XML ha facoltà di riportare l'errore oppure ha facoltà di recuperarlo ignorando la specificazione dell'attributo o riportando il valore (erroneo) all'applicazione. Le applicazioni hanno facoltà di ignorare o rigettare valori erronei.

L'elemento radice di ciascun documento viene considerato come non abbia segnalato alcuna intenzione riguardo alla gestione dello spazio bianco da parte dell'applicazione, a meno che fornisca un valore per questo attributo o l'attributo sia dichiarato con un valore predefinito.

2.11 Gestione del Fine-Riga

Le entità parsed di XML spesso sono conservate in file di computer i quali, per convenienza di manipolazione, sono organizzate in linee. Queste linee tipicamente sono separate da una qualche combinazione dei caratteri RITORNO A CAPO {CARRIAGE RETURN} (#xD) e AVANZAMENTO DI RIGA {LINE FEED} (#xA).

Per semplificare i compiti delle applicazioni, il processore XML deve comportarsi come se avesse normalizzato tutte le interruzioni di riga in entità esterne parsed (inclusa l'entità documento) in ingresso, prima del parsing, traducendo tutti quelli che seguono, in un singolo carattere #xA:

1. la sequenza di due caratteri #xD #xA
2. la sequenza di due caratteri #xD #x85
3. il carattere singolo #x85
4. il carattere singolo #x2028
5. ogni carattere #xD che non sia seguito immediatamente da #xA o #x85.

I caratteri #x85 e #x2028 non possono essere riconosciuti e tradotti in modocannot be reliably recognized and translated until an entity's encoding declaration (if present) has been read. Therefore, it is a fatal error to use them within the XML declaration or text declaration.

2.12 Identificazione della Lingua

Nell'elaborare il documento, spesso è utile identificare il linguaggio naturale o formale nel quale è scritto il contenuto. Uno speciale attributo di nome xml:lang potrebbe essere inserito nei documenti per specificare la lingua usata nei contenuti e nei valori di attributo di ogni elemento nel documento XML. Nei documenti validi, questo attributo, come ogni altro, deve essere dichiarato se viene usato. I valori dell'attributo sono gli identificatori di lingua come definiti da [IETF RFC 3066], Etichette per l'Identificazione delle Lingue, o sue successive; in aggiunta, potrebbe specificarsi la stringa vuota.

(Le produzioni da 33 a 38 sono state rimosse.)

Per esempio:

<p xml:lang="en">The quick brown fox jumps over the lazy dog.</p>
<p xml:lang="en-GB">What colour is it?</p>
<p xml:lang="en-US">What color is it?</p>
<sp who="Faust" desc='leise' xml:lang="de">
<l>Habe nun, ach! Philosophie,</l>
<l>Juristerei, und Medizin</l>
<l>und leider auch Theologie</l>
<l>durchaus studiert mit hei&#xDF;em Bem&#xFC;h'n.</l>
</sp>

La lingua specificata con xml:lang si applica all'elemento dove sia specificato (inclusi i valori dei suoi attributi) e a tutti gli elementi del suo contenuto, a meno che non venga annullato da un'altra istanza di xml:lang. In particolare, il valore vuoto di xml:lang viene usato su un elemento B per sovrascrivere una specificazione di xml:lang nell'elemento A che lo racchiude, senza specificare un'altra lingua. All'interno di B, si considera che non c'è disponibile un'informazione sulla lingua, proprio come se xml:lang non fosse stato specificato su B o su ciascuno dei suoi avi. Le applicazioni determinano quale fra i valori di attributo di un elemento e quali parti del suo contenuto di caratteri, se presenti, vengano trattati come valori dipendenti dalla lingua descritta da xml:lang.

Una semplice dichiarazione per xml:lang potrebbe prendere la forma

xml:lang CDATA #IMPLIED

<!ATTLIST poem   xml:lang CDATA 'fr'>
<!ATTLIST gloss  xml:lang CDATA 'en'>
<!ATTLIST note   xml:lang CDATA 'en'>

2.13 Controllo della Normalizzazione

Tutte le entità parsed di XML (incluse le entità documento) dovrebbero essere completamente normalizzate in base alla definizione di B Definizioni per la Normalizzazione del Carattere con il supplemento delle seguenti definizioni di costrutti rilevanti per XML:

1. Il testo sostitutivo di tutte le entità parsed

2. Tutto il testo che corrisponda, nel contesto, a uno delle seguenti produzioni:

   1. CData

   2. CharData

   3. content

   4. Name

   5. Nmtoken

In ogni caso, un documento è ancora ben-formato per quanto non sia completamente normalizzato. I processori XML dovrebbero fornire all'utente la facoltà di verificare che il documento che è stato elaborato sia in una forma completamente normalizzata, e riportare all'applicazione se esso lo sia o non. La possibilità di non verificare dovrebbe essere scelta solo quando il testo in ingresso è certificato, come definito da B Definizioni per la Normalizzazione del Carattere.

La verifica della completa normalizzazione deve essere portata a termine come se per prima cosa verificando che l'entità sia in forma inclusa-normalizzata come definito da B Definizioni per la Normalizzazione del Carattere e dopo verificando che nessuno dei costrutti rilevati sopra elencati cominci (dopo che i riferimenti di carattere siano stati esansi) con un carattere componente come definito da B Definizioni per la Normalizzazione del Carattere. I processori non-validanti devono ignorare possibili denormalizzazioni che sarebbero state causate dall'inclusione di entità esterne che essi non leggono.

Se, mentre si verifica la completa normalizzazione, un processore incontra caratteri per i quali non può determinare le proprietà di normalizzazione (ovvero, i cartteri introdotti in una versione di Unicode [Unicode] successiva a quella utilizzata nell'implementazione del processore), allora il processore potrebbe, a facoltà dell'utente, ignorare ogni possibile denormalizzazione causata da questi caratteri. La facoltà di ignorare queste denormalizzazioni non dovrebbe essere offerta dalle applicazioni quando l'affidabilità o la sicurezza siano critiche.

I processori XML non devono trasformare i dati in ingresso che devono essere in forma completamente normalizzata. Le applicazioni che creano dati in uscita XML 1.1 da un ingresso sia XML 1.1 che XML 1.0 dovrebbero assicurare che i dati in uscita siano completamente normalizzati; non è necessario che le forme di elaborazione interna siano completamente normalizzate.

Lo scopo di questa sezione è di incoraggiare fortemente i processori XML ad assicurare che i creatori di documenti XML li abbiano normalizzati in maniera appropriata, cosicché le applicazioni XML possano effettuare delle prove, come le comparazioni di identità delle stringhe, senza preoccuparsi delle possibili differenti "ortografie" delle stringhe che Unicode permette.

Quando le entità sono in una codifica non-Unicode, se il processore li transcodifica in Unicode, dovrebbe usare una transcodificatore che opera la normalizzazione.

3.1 Tag-di-Inizio, Tag-di-Fine, e Tag di Elemento-Vuoto

[Definizione: L'inizio di ogni elemento XML non-vuoto è marcato da un tag-di-inizio.]

Tag-di-inizio

Il Name nei tag-di-inizio e -di-fine fornisce il tipo dell'elemento. [Definizione: Ci si riferisce alle coppie Name-AttValue come le aspecificazioni d'attributo dell'elemento], [Definizione: in ogni coppia, con il Name ci si riferisce al nome dell'attributo] e [Definizione: con il contenuto di AttValue (il testo fra i delimitatori ' o ") al valore dell'attributo.] Si noti che l'ordine delle specificazioni d'attributo in un tag-di-inizio o in un tag di elemento-vuoto non è significativo.

Un esempio di tag-di-inizio:

<termdef id="dt-dog" term="dog">

</termdef>

[Definizione: Un elemento con nessun contenuto si dice essere vuoto.] La rappresentazione di un elemento vuoto è sia un tag-di-inizio immediatamente seguito da un tag-di-fine, che da un tag di elemento-vuoto. [Definizione: Un tag di elemento-vuoto prende una forma speciale:]

Tag per Elementi Vuoti

I tag di elemento-vuoto hanno facoltà di essere usati per qualsiasi elemento che non abbia contenuto, sia se è o non è dichiarato, usando la parola chiave EMPTY. Per  interoperabilità, il tag di elemento-vuoto dovrebbe essere usato, e dovrebbe solo essere usato, per elementi che sono dichiarati EMPTY.

Esempi di elementi vuoti:

<IMG align="left"
src="http://www.w3.org/Icons/WWW/w3c_home" />
<br></br>
<br/>

3.2 Dichiarazioni del Tipo di Elemento

La struttura di elemento di un documento XML potrebbe, per scopi di convalida, essere vincolata usando dichiarazioni del tipo di elemento e elenco-attributo. Una dichiarazione del tipo di elemento vincola il contenuto dell'elemento.

Le dichiarazioni del tipo di elemento spesso vincolano quali tipi di elemento possano comparire come figli dell'elemento. A facoltà dell'utente, un processore XML potrebbe sottomettere un avvertimento quando una dichiarazione menzioni un tipo di elemento per il quale non sia stata fornita alcuna dichiarazione, ma questo non è un errore.

[Definizione: Una dichiarazione del tipo di elemento prende la forma:]

Dichiarazione del Tipo di Elemento

dove il Name fornisce il tipo di elemento da dichiararsi.

Esempi di dichiarazioni del tipo di elemento:

<!ELEMENT br EMPTY>
<!ELEMENT p (#PCDATA|emph)* >
<!ELEMENT %name.para; %content.para; >
<!ELEMENT container ANY>

<!ELEMENT spec (front, body, back?)>
<!ELEMENT div1 (head, (p | list | note)*, div2*)>
<!ELEMENT dictionary-body (%div.mix; | %dict.mix;)*>

<!ELEMENT p (#PCDATA|a|ul|b|i|em)*>
<!ELEMENT p (#PCDATA | %font; | %phrase; | %special; | %form;)* >
<!ELEMENT b (#PCDATA)>

3.3 Dichiarazioni di Elenco-Attributo

Gli attributi vengono usati per associare le coppie nome-valore con gli elementi. Le specificazioni di attributo non devono comparire al di fuori dei tag-di-inizio e dei tag di elemento-vuoto; così, le produzioni usate per riconoscerli compaiono in 3.1 Tag-di-Inizio, Tag-di-Fine, e Tag di Elemento-Vuoto. Le dichiarazioni di elenco-attributo hanno facoltà di essere usate:

• Per definire l'insieme degli attributi pertinenti a un dato tipo di elemento.
• Per stabilire i vincoli di tipo per questi attributi.
• Per fornire valori predefiniti per gli attributi.

[Definizione: Dichiarazioni di elenco-attributo specificano il nome, il tipo di dato, e il valore predefinito (se esiste) di ciascun attributo associato con un dato tipo di elemento:]

Dichiarazione di elenco-attributo

Il Name nella regola AttlistDecl è il tipo di un elemento. A facoltà dell'utnete, un processore XML potrebbe sottomettere un avvertimento se gli attributi sono dichiarati per un tipo di elemento esso stesso non dichiarato, ma questo non è un errore. Il Name nella regola AttDef è il nome dell'attributo.

Quando viene fornito più di un AttlistDecl per un dato tipo di elemento, i contenuti di tutti quelli forniti vengono uniti. Quando viene fornita più di una definizione per lo stesso attributo di un dato tipo di elemento, la prima dichiarazione è vincolante e le altre vengono ignorate. Per interoperabilità, chi scrive le DTD ha facoltà di scegliere di fornire al massimo una sola dichiarazione di elenco-attributo per un dato tipo di elemento, al massimo una sola definizione di attributo per un dato nome di attributo in una dichiarazione di elenco-attributo, e almento una singola definizione di attributo in ogni dichiarazione di elenco-attributo. Per interoperabilità, un processore XML potrebbe a facoltà dell'utente sottomettere un avvertimento quando viene fornita più di una dichiarazione di elenco-attributo per un dato tipo di elemento, oppure quando viene fornita più di una definizione di attributo per un dato attributo, ma questo non è un errore.

<!ATTLIST termdef
id      ID      #REQUIRED
name    CDATA   #IMPLIED>
<!ATTLIST list
type    (bullets|ordered|glossary)  "ordered">
<!ATTLIST form
method  CDATA   #FIXED "POST">

<!ENTITY d "&#xD;">
<!ENTITY a "&#xA;">
<!ENTITY da "&#xD;&#xA;">

a="

xyz"

x y z

#x20 #x20 x y z

a="&d;&d;A&a; &a;B&da;"

A #x20 B

#x20 #x20 A #x20 #x20 #x20 B #x20 #x20

a=
"

A

B
"

#xD #xD A #xA #xA B #xD #xA

#xD #xD A #xA #xA B #xD #xA

3.4 Sezioni Condizionali

[Definizione: Le sezioni condizionali sono porzioni del sotto-insieme esterno della dichiarazione del tipo di documento o di entità di parametro esterne che sono incluse nella, o escluse dalla, struttura logica della DTD in base alla parola chiave che le governa.]

Sezione Condizionale

<!ENTITY % draft 'INCLUDE' >
<!ENTITY % final 'IGNORE' >
<![%draft;[
<!ELEMENT book (comments*, title, body, supplements?)>
]]>
<![%final;[
<!ELEMENT book (title, body, supplements?)>
]]>

4.1 Riferimenti di Entità e di Carattere

[Definizione: Un riferimento di carattere si riferisce a uno specifico carattere nell'insieme di caratteri ISO/IEC 10646, per esempio uno non direttamente accessibile dagli strumenti di immissione disponibili.]

Riferimento di Carattere

Se il riferimento di carattere inizia con "&#x", le cifre e le lettere fino al termine segnato con ; forniscono una rappresentazione esadecimale del punto codice del carattere in ISO/IEC 10646. Se comincia solo con "&#", le cifre fino al termine segnato con ; forniscono una rappresentazione decimale del punto codice del carattere.

[Definizione: Un riferimento di entità si riferisce al contenuto di un'entità avente un nome.] [Definizione: I riferimenti a entità parsed generali usano le "e commerciale" (&) e il "punto e virgola" (;) come delimitatori.] [Definizione: I riferimenti di entità-parametro usano il segno di percentuale (%) e il "punto e virgola" (;) come delimitatori.]

Riferimento di Entità

Esempi di riferimenti di carattere e di entità:

Digita <tasto>minore-di</tasto> (&#x3C;) per salvare le opzioni.
Questo documento è stato preparato il &datadoc; ed
è classificato &livello-sicurezza;.

Esempio di un riferimento di entità-parametro:

<!-- dichiara l'entità parametro "ISOLat2"... -->
<!ENTITY % ISOLat2
         SYSTEM "http://www.xml.com/iso/isolat2-xml.entities" >
<!-- ... ora si fa riferimento ad essa. -->
%ISOLat2;

4.2 Dichiarazioni di Entità

[Definizione: Le entità sono dichiarate in questo modo:]

Dichiarazione di Entità

Il Name identifica l'entità in un riferimento di entità oppure, nel caso di un'entità non parsed, nel valore di un attributo di ENTITY o ENTITIES. Se la stessa entità viene dichiarata più di una volta, la prima dichiarazione incontrata è quella vincolante; a facoltà dell'utente, un processore XML potrebbe sottoporre un avvertimento se le entità vengono dichiarate molteplici volte.

<!ENTITY Pub-Status "Questa è un'anteprima di rilascio della specifica.">

<!ENTITY open-hatch
SYSTEM "http://www.textuality.com/boilerplate/OpenHatch.xml">
<!ENTITY open-hatch
PUBLIC "-//Textuality//TEXT Standard open-hatch boilerplate//EN"
"http://www.textuality.com/boilerplate/OpenHatch.xml">
<!ENTITY hatch-pic
SYSTEM "../grafix/OpenHatch.gif"
NDATA gif >

4.3 Entità parsed

<?xml encoding='UTF-8'?>
<?xml encoding='EUC-JP'?>

4.4 Trattamento del Processore XML di Entità e Riferimenti

La tabella sottostante riassume i contesti nei quali potrebbero comparire i riferimenti di carattere, i riferimenti di entità, e le invocazioni di entità non parsed e il comportamento obbligatorio di un processore XML in ciascun caso. Le etichette nella colonna di estrema sinistra descrivono il contesto riconoscitivo:

Riferimento nel Contenuto

come un riferimento dovunque dopo il tag-di-inizio e prima del tag-di-fine di un elemento; corrisponde al contenuto non-terminale.

Riferimento nel Valore di Attributo

come un riferimento all'interno sia del valore di un attributo in un tag-di-inizio, che un valore predefinito in una dichiarazione di attributo; corrisponde a AttValue non-terminale.

Ricorre come Valore di Attributo

come un Name, non un riferimento, che compaia sia come il valore di un attributo che è stato dichiarato come tipo ENTITY, oppure come uno dei token separati-da-spazio nel valore di un attributo che è stato dichiarato come tipo ENTITIES.

Riferimento in Valore di Entità

come un riferimento all'interno di un parametro o del valore letterale di entità di un'entità interna nella dichiarazione di entità; corrisponde a EntityValue non-terminale.

Riferimento in DTD

come un riferimento all'interno sia dei sotto-insiemi interni ed esterni della DTD, ma al di fuori di un EntityValue, AttValue, PI, Comment, SystemLiteral, PubidLiteral, oppure dei contenuti di una sezione condizionale ignorata (vedi 3.4 Sezioni Condizionali).

.

<!ENTITY % YN '"Yes"' >
<!ENTITY WhatHeSaid "He said %YN;" >

<!ENTITY EndAttr "27'" >
<element attribute='a-&EndAttr;>

4.5 Costruzione di Testo Sostitutivo di Entità

Nel discutere il trattamento delle entità, è utile distinguere due forme di valore dell'entità. [Definizione: Per un'entità interna, il valore letterale di entità è la stringa virgolettata effettivamente presente nella dichiarazione di entità, corrispondente all'EntityValue non-terminale.] [Definizione: Per un'entità esterna, il valore letterale di entità è il testo esatto contenuto dall'entità.] [Definizione: Per un'entità interna, il testo sostitutivo è il contenuto dell'entità, dopo la sostituzione dei riferimenti di carattere e dei riferimenti di entità-parametro.] [Definizione: Per un'entità esterna, il testo sostitutivo è il contenuto dell'entità, dopo la rimozione della dichiarazione di testo (lasciando ogni spazio vuoto intorno) se ne esiste uno, ma senza alcuna sostituzione di riferimenti di carattere o di riferimenti di entità-parametro.]

Il valore letterale di entità come fornito in una dichiarazione di entità interna (EntityValue) potrebbe contenere riferimenti di carattere, entità-parametro, e di entità-generale. Tali riferimenti devono essere interamente contenuti all'interno del valore letterale di entità. Il testo sostitutivo reale che viene incluso (o Incluso alla lettera) come sopra descritto deve contenere il testo sostitutivo di qualsiasi entità parametro alla quale si riferisce, e deve contenere il carattere al quale si riferisce, al posto di qualsiasi riferimento di carattere nel valore letterale di entità; comunque, i riferimenti di entità-generale devono essere lasciati così come sono, non espansi. Per esempio, date le seguenti dichiarazioni:

<!ENTITY % pub    "&#xc9;ditions Gallimard" >
<!ENTITY   rights "All rights reserved" >
<!ENTITY   book   "La Peste: Albert Camus,
&#xA9; 1947 %pub;. &rights;" >

La Peste: Albert Camus,
© 1947 Éditions Gallimard. &rights;

4.6 Entità Predefinite

[Definizione: I riferimenti di entità e di carattere potrebbero entrambi essere usati per codificare in carattere escape la parentesi angolare sinistra, la "e commerciale", e gli altri delimitatori. Un insieme di entità generali (amp, lt, gt, apos, quot) viene specificato a questo scopo. Anche i riferimenti numerici di carattere potrebbero essere utilizzati; essi vengono espansi immediatamente quando riconosciuti e devono essere trattati come dati carattere, così i riferimenti numerici di carattere "<" e "&" potrebbero essere usati per codificare in caratteri escape < e & quando ricorrono nei dati carattere.]

Tutti i processori XML devono riconoscere queste entità se vengono dichiarate o no. Per interoperabilità, i documenti XML validi dovrebbero dichiarare queste entità, come qualsiasi altra, prima di utilizzarle. Se le entità lt o amp vengono dichiarate, esse devono venire dichiarate come entità interne il testo sostitutivo delle quali è un riferimento di carattere al rispettivo carattere da codificarsi in caratteri escape (segno di minore-di o "e commerciale"); la doppia codifica in caratteri escape è Richiesta per queste entità cosicché i riferimenti ad esse producano un risultato ben-formato. Se le entità gt, apos, o quot vengono dichiarate, esse devono venire dichiarate come entità interne il testo sostitutivo delle quali è un singolo carattere codificato in caratteri escape (o un riferimento di carattere a quel carattere; la doppia codifica in caratteri escape è facoltativa, ma innocua). Per esempio:

<!ENTITY lt     "&#38;#60;">
<!ENTITY gt     "&#62;">
<!ENTITY amp    "&#38;#38;">
<!ENTITY apos   "&#39;">
<!ENTITY quot   "&#34;">

4.7 Dichiarazioni di Notazione

[Definizione: Le notazioni identificano per nome il formato di entità non parsed, il formato degli elementi che portano un attributo di notazione, oppure l'applicazione alla quale viene indirizzata un'istruzione di processo.]

[Definizione: Le dichiarazioni di notazione forniscono un nome per la notazione, per l'uso nelle dichiarazioni di entità e di elenco-attributo e nelle specificazioni di attributo, e un identificatore esterno per la notazione che potrebbe permettere a un processore XML o alla sua applicazione client di localizzare un'applicazione di supporto capace di elaborare i dati nella notazione fornita.]

Dichiarazioni di Notazione

I processori XML devono fornire alle applicazioni nome e identificatore/i di qualsiasi notazione dichiarata e referenziata in un valore di attirbuto, in una definizione di attributo, o in una dichiarazione di entità. In aggiunta essi hanno facoltà di risolvere l'identificatore esterno nell'identificatore di sistema, nel nome di file, o in altre informazioni necessarie per consentire all'applicazione di chiamare un processore per i dati nella notazione descritta. (È un errore, comunque, per i documenti XML dichiarare e riferirsi a notazioni per le quali non sono disponibili, sul sistema dove sta girando il processore XML o l'applicazione, applicazioni specifiche per la notazione stessa.)

4.8 Entità Documento

[Definizione: L'entità documento serve come radice dell'alberatura delle entità e come punto di partenza per un processore XML.] Questa specifica non precisa come l'entità documento debba essere localizzata da un processore XML; a differenza di altre entità, l'entità documento non ha nome e potrebbe comparire bene in un flusso di dati in ingresso per un processore senza alcuna identificazione.

5.1 Processori Validanti e Non-Validanti

I processori XML conformi ricadono in due classi: validanti e non-validanti.

I processori validanti e non-validanti devono riportare allo stesso modo le violazioni dei vincoli di buona-formazione di questa specifica nel contenuto dell'entità documento e di qualsiasi altra entità parsed che essi leggono.

[Definizione: I processori validanti devono, a facoltà dell'utente, riportare le violazioni dei vincoli espressi dalle dichiarazioni nella DTD, e i fallimenti nell'adempiere ai vincoli di validità forniti in questa specifica.] Per conseguire ciò, i processori XML validanti devono leggere ed elaborare l'intera DTD e tutte le entità parsed esterne alle quali si fa riferimento nel documento.

I processori non-validanti sono obbligati a controllare la buona-formazione solo dell'entità documento, includendo l'intero sotto-insieme interno della DTD. [Definizione: Mentre essi non sono obbligati a controllare la validità del documento, sono obbligati a processare tutte le dichiarazioni che leggono nel sotto-insieme interno della DTD e in qualsiasi entità parametro, fino al primo riferimento a un'entità parametro che non leggono; vale a dire, essi devono utilizzare le informazioni in quelle dichiarazioni per normalizzare i valori di attributo, includere il testo sostitutivo delle entità interne, e supportare i valori predefiniti di attributo.] Eccetto quando standalone="yes", essi devono processare le dichiarazioni di entità o le dichiarazioni di elenco-attributo incontrate dopo un riferimentoa un'entità parametro che non viene letta, da momento che l'entità potrebbe contenere dichiarazioni sovrascriventi; quando standalone="yes", i processori devono elaborare queste dichiarazioni.

Si noti che quando si elaborano documenti non validi con un processore non-validante l'applicazione potrebbe non essere presentata con informazioni consistenti. Per esempio, alcuni requisiti per l'unicità all'interno del documento potrebbero non essere rispettati, includendo più di un solo elemento con lo stesso id, dichiarazioni duplicate di elementi o notazioni con lo stesso nome, etc. In questi casi il comportamento del parser rispetto al dispaccio di tali informazioni verso l'applicazione non è definito.

XML 1.1 processors MUST be able to process both XML 1.0 and XML 1.1 documents. Programs which generate XML SHOULD generate XML 1.0, unless one of the specific features of XML 1.1 is required.

5.2 Usare i Processori XML

• Certi errori di buona-formazione, specificatamente quelli che richiedono la lettura di entità esterne, potrebbero non essere rilevati da un processore non-validante. Esempi comprendono i vincoli intitolati Entità Dichiarata, Entità Parsed, e Nessuna Ricorsività, così come alcuni dei casi descritti come proibiti in 4.4 Trattamento del processore XML di Entità e di Riferimenti.
• Le informazioni passate dal processore all'applicazione potrebbero variare, in dipendenza del fatto che il processore legga le entità parametro ed esterne. Per esempio, un processore non-validante potrebbe fallire nel normalizzare i valori di attributo, nell'includere il testo sostitutivo di entità interne, o supportare i valori predefiniti di attributo, quando farlo dipenda dall'aver letto le dichiarazioni nelle entità esterne e di parametro.

Per la massima affidabilità nell'interoperazione fra diversi processori XML, le applicazioni che utilizzano processori non-validanti non dovrebbero far affidamento su alcun comportamento non richiesto a tali processori. Le applicazioni che richiedono le capacità della DTD relative alla convalida (come la dichiarazione degli attributi predefiniti e delle entità interne che sono o potrebbero essere specificate nelle entità esterne) dovrebbero utilizzare processori XML validanti.