Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from http://www.dkg.it/w3c/TR/2004/REC-xml11-20040204/it/index.htm below:

Linguaggio Estensibile di Marcatura (XML) 1.1

Il Linguaggio Estendibile di Marcatura {Extensible Markup Language}, abbreviato in XML, descrive una classe di oggetti di dati chiamati documenti XML e descrive parzialmente il comportamento dei programmi per computer che li elaborano. XML è un profilo applicativo o una forma ristretta di SGML, il Linguaggio Standard Generalizzato di Marcatura {Standard Generalized Markup Language} [ISO 8879]. Nella costruzione, i documenti XML sono conformi a documenti SGML.

I documenti XML sono costituiti da unità di allocazione chiamate entità, le quali contengono dati sia parsed [N.d.T.: analizzati in modo logico] che non parsed. I dati parsed sono costituiti da caratteri, alcuni dei quali formano i dati carattere, altri formano la marcatura. La marcatura codifica una descrizione dello schema di allocazione del documento e della struttura logica. XML fornisce un meccanismo per imporre dei vincoli sullo schema di allocazione e sulla struttura logica.

[Definizione: Un modulo software chiamato un processore XML viene usato per leggere i documenti XML e fornire accesso alla loro struttura e al loro contenuto.] [Definizione: Si presume che un processore XML stia svolgendo il suo compito sulla base di un altro modulo, chiamato l'applicazione.] Questa specifica descrive il comportamento richiesto a un processore XML nei termini di come esso debba leggere i dati XML e dell'informazione che esso deve fornire all'applicazione.

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.

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.]

[Definizione: Un oggetto dati è un documento XML se è ben-formato, come definito in questa specifica. In aggiunta, il documento XML è valido se rispetta certi altri vincoli.]

Ogni documento XML possiede sia una struttura logica che fisica. Fisicamente, il documento è composto da unità chiamate entità. Un entità ha facoltà di riferirsi ad altre entità con lo scopo di ottenere la loro inclusione nel documento. un documento inizia in una "radice" {root} o entità di documento. Logicamente, il documento è composto di dichiarazioni, elementi, commenti, riferimenti di carattere, e istruzioni di processo, le quali sono tutte indicate nel documento da esplicita marcatura. Le strutture logiche e fisiche devono essere nidificate in maniera appropriata, come descritto in 4.3.2 Entità Parsed Ben-Formate.

[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.

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.]

[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. ]

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à.

Nota:

Gli autori di documenti sono incoraggiati a evitare i "caratteri di compatibilità", come definiti nella sezione 6.8 di [Unicode] (si veda inoltre D21 nella sezione 3.6 di [Unicode3]). Anche i caratteri definiti negli intervalli seguenti non sono incoraggiati. Sono presenti sia caratteri di controllo che caratteri Unicode non definiti in maniera permanente:

[#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].

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

[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.

Nota:

L'Ambito dei Nomi {Namespace} nella Raccomandazione XML [Nomi XML] assegna un significato ai nomi contenenti i caratteri dei due punti. Perciò, gli autori non dovrebbero usare i due punti nei nomi XML eccetto che per scopi di ambito dei nomi, ma i processori XML devono accettare i due punti come un carattere di nome.

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à.

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.

Nota:

Sebbene la produzione di EntityValue consenta la definizione di un'entità generale consistente in un singolo esplicito < nel letterale (ad es., <!ENTITY mylt "<">), si consiglia fortemente di evitare questa pratica dal momento che ogni riferimento a quell'entità causerà un errore di buona-formazione.

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 """.

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

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.

[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 "]]>":]

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>]]> 

[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.

[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.

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.

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.

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).]

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.

Vincolo di validità: Dichiarazione di Documento Autonomo

La dichiarazione di documento autonomo deve assumere il valore "no" se qualsiasi dichiarazione esterna di marcatura contenga dichiarazioni di:

• attributi con valori predefiniti, se gli elementi ai quali si applicano questi attributi compaiano nel documento senza specificazioni di valori per questi attributi, oppure di
• entità (diverse da amp, lt, gt, apos, quot), se i riferimenti a quelle entità compaiano nel documento, oppure di
• attributi con i tipi resi come token, dove l'attributo compare nel documento con un valore tale che la normalizzazione produrrà un valore differente da quello che avrebbe prodotto in assenza della dichiarazione, oppure di
• tipi di elemento con contenuto di elemento, se ricorre dello spazio bianco direttamente all'interno di ciascuna istanza di quei tipi.

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

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

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.

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.

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.

Nota:

L'informazione sulla lingua può anche essere fornita da protocolli esterni di trasporto (ad es. HTTP o MIME). Quando disponibile, questa informazione potrebbe essere usata da applicazioni XML, ma dovrebbe considerarsi che l'informazione più locale fornita da xml:lang la reimposti.

Una semplice dichiarazione per xml:lang potrebbe prendere la forma

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

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.

Nota:

I caratteri componenti sono tutti i caratteri Unicode di classe combinante non-zero, più un piccolo numero di caratteri di classe-zero i quali non di meno prendono parte come un carattere non-iniziale in certe decomposizioni canoniche di Unicode. Dal momento che ci si aspetta che questi caratteri seguano i caratteri di base, impedire ai costrutti rilevanti (incluso il contenuto) dal cominciare con un carattere componente non diminuisce in modo significativo l'espressività di XML.

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.

[Definizione: Ogni documento XML contiene uno o più elementi, i limiti dei quali sono delimitati sia da tag-di-inizio e tag-di-fine, che, per elementi vuoti, da un tag di elemento-vuoto. Ogni elemento ha un tipo, identificato da un nome, a volte chiamato il suo "identificatore generico" {generic identifier} (GI), e potrebbe avere un insieme di specificazioni d'attributo.] Ogni specificazione d'attributo ha un nome e un valore.

Vincolo di Validità: Elemento Valido

Un elemento è valido se esiste una dichiarazione corrispondente a elementdecl dove il Name corrisponde al tipo di elemento, ed è valida una delle seguenti:

1. La dichiarazione corrisponde a EMPTY e l'elemento non ha contenuto (nemmeno riferimenti di entità, commenti, PI o spazio bianco).
2. La dichiarazione corrisponde a figli e la sequenza degli elementi figli appartiene al linguaggio generato dall'espressione regolare nel modello di contenuto, con spazio bianco, commenti e PI facoltativi (ovvero marcatura corrispondente a produzione [27] Misc) fra il tag-di-inizio e il primo elemento figlio, fra elementi figli, o fra l'ultimo elemento figlio e il tag-di-fine. Si noti che una sezione CDATA contenente un solo spazio bianco o un riferimento a un'entità il testo sostitutivo della quale è uguale a riferimenti di carattere convertibili in spazio bianco, non corrisponde a S non-terminale, e quindi non può comparire in queste posizioni; comunque, un riferimento a un'entità interna con un valore letterale consistente di riferimenti di carattere convertibili in spazio bianco non corrisponde a S, dal momento che il suo testo sostitutivo è spazio bianco risultante dalla conversione dei riferimenti di carattere.
3. La dichiarazione corrisponde a Misto, e il contenuto (dopo aver rimpiazzato ogni riferimento di entità con il suo testo sostitutivo) consiste di dati carattere (incluse le sezioni CDATA), commenti, PI e elementi figli i cui tipi corrispondono ai nomi nel modello di contenuto.
4. La dichiarazione corrisponde a ANY, e il contenuto (dopo aver rimpiazzato ogni riferimento di entità con il suo testo sostitutivo) consiste di dati carattere, sezioni CDATA, commenti, PI, ed elementi figli i cui tipi sono stati dichiarati.

[Definizione: L'inizio di ogni elemento XML non-vuoto è marcato da un 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">

[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:]

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/>

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:]

dove il Name fornisce il tipo di elemento da dichiararsi.

Vincolo di Validità: Dichiarazione Unica del Tipo di Elemento

Un tipo di elemento non deve essere dichiarato più di una volta.

Esempi di dichiarazioni del tipo di elemento:

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

[Definizione: Un tipo di elemento possiede un contenuto di elemento quando gli elementi di quel tipo devono contenere solo gli elementi figli (nessun dato carattere), facoltativamente separato da spazio bianco (caratteri corrispondenti alla S non-terminale).] [Definizione: In questo caso, il vincolo include un modello di contenuto, una semplice grammatica che governi i tipi ammessi degli elementi figli e l'ordine nel quale a essi è consentito di comparire.] La grammatica è costruita sulle particelle di contenuto (le cp {particles content}), che consistono in nomi, in elenchi di scelte di particelle di contenuto, o in elenchi di sequenze di particelle di contenuto:

dove ogni Name è il tipo di un elemento che ha facoltà di comparire come un figlio. Ogni particella di contenuto in un elenco di scelte ha facoltà di comparire nel contenuto dell'elemento nel posto dove compare l'elenco di scelte nella grammatica; particelle di contenuto che ricorrono in un elenco di sequenze devono comparire ciascuna nel contenuto dell'elemento nell'ordine dato dall'elenco. Il carattere facoltativo che segue un nome o un elenco stabilisce se gli elementi o le particelle di contenuto nell'elenco possano ricorrere una o più volte (+), zero o più volte (*), oppure zero o una volta (?). L'assenza di tale operatore significa che l'elemento o la particella di contenuto devono comparire esattamente una volta sola. Questa sintassi e il significato sono identici a quelli usati nelle produzioni di questa specifica.

Il contenuto di un elemento corrisponde al modello di contenuto se e solo se è possibile rintracciare un percorso attraverso il modello di contenuto, obbedendo alla sequenza, alla scelta, e agli operatori di ripetizione ed effettuando la corrispondenza di ogni elemento nel contenuto con un tipo di elemento nel modello di contenuto. Per compatibilità, è un errore se il modello di contenuto permette a un elemento di corrispondere con più di un'occorrenza di un tipo di elemento nel modello di contenuto. Per maggiori informazioni, si veda E Modelli Deterministici di Contenuto.

Vincolo di Validità: Nidificazione Appropriata di Gruppo/PE

Il testo sostitutivo di entità-parametro deve essere appropriatamente nidificato con gruppi parentesificati. Vale a dire, se la parentesi sia di apertura che di chiusura in un costrutto choice, seq, o Mixed è contenuta in un testo sostitutivo per un'entità di parametro, entrambe devono essere contenute nello stesso testo sostitutivo.

Per interoperabilità, se un riferimento a entità-parametro compare in un costrutto choice, seq, o Mixed, il suo testo sostitutivo dovrebbe contenere almeno un carattere non-bianco, e né il primo né l'ultimo carattere non-bianco del testo sostitutivo dovrebbe essere un connettore (| oppure ,).

Esempi di modelli di contenuto d'elemento:

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

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:]

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.

1. Tutte le interruzioni di riga devono essere state normalizzate in ingresso con  #xA come descritto in 2.11 Gestione del Fine-Riga, cosicché il resto di questo algoritmo opera su testo normalizzato in questo modo.
2. Comincia con un valore normalizzato consistente nella stringa vuota.
3. Per ogni carattere, riferimento di entità, o riferimento di carattere nel valore di attributo non normalizzato, a cominciare dal primo e continuando fino all'ultimo, eseguire ciò che segue:
   • Per un riferimento di carattere, aggiungere il carattere referenziato al valore normalizzato.
   • Per un riferimento di entità, applicare ricorsivamente il passo 3 di questo algoritmo al testo sostitutivo dell'entità.
   • Per un carattere di spazio bianco (#x20, #xD, #xA, #x9), aggiungere un carattere di spaziatura (#x20) al valore normalizzato.
   • Per altro carattere, aggiungere il carattere al valore normalizzato.

Se il tipo di attributo non è CDATA, allora il processore XML deve elaborare ulteriormente il valore di attributo normalizzato scartando tutti i caratteri di spaziatura (#x20)  in testa e in coda, e sostituendo le sequenze di spaziatura (#x20) con una singola spaziatura (#x20).

Si noti che se il valore di attributo non normalizzato contiene un riferimento di carattere a un carattere di spazio bianco diverso dalla spaziatura (#x20), il valore normalizzato contiene il carattere referenziato stesso (#xD, #xA or #x9). Ciò è in contrasto con il caso in cui il valore non normalizzato contenga un carattere di spazio bianco (non un riferimento), il quale è sostituito con una spaziatura (#x20) nel valore normalizzato ed è anche in contrasto con il caso di un riferimento di entità, il testo sostitutivo del quale contenga un carattere di spazio bianco; essendo elaborato in maniera ricorsiva, il carattere di spazio bianco è sostituito con una spaziatura (#x20) nel valore normalizzato.

Tutti gli attributi per i quali non è stata letta alcuna dichiarazione dovrebbero essere trattati da un processore non-validante come se fossero CDATA dichiarati.

È un errore se un valore di attributo contiene un riferimento a un'entità per la quale non è stata letta alcuna dichiarazione.

Appresso vengono degli esempi di normalizzazione di attributo. Date le seguenti dichiarazioni:

<!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

[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.]

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

[Definizione: Un documento XML potrebbe consistere di una o molte unità di allocazione. Queste vengono chiamate entità; tutte loro possiedono contenuto e tutte sono (eccetto per l'entità documento e per il sotto-insieme esterno di DTD) identificate dal nome dell'entità.] Ogni documento XML possiede un'entità chiamata l'entità documento, la quale funge da punto di partenza per il processore XML e potrebbe contenere l'intero documento.

Le entità potrebbero essere sia parsed che non parsed. [Definizione: Si fa riferimento ai contenuti di un'entità parsed come al suo testo sostitutivo; questo testo viene considerato parte integrale del documento.]

[Definizione: Un'entità non parsed è una risorsa i contenuti della quale potrebbero o non potrebbero essere testo, e qualora siano testo, potrebbero essere qualcosa di diverso da XML. Ogni entità non parsed ha associata una notazione, identificata dal nome. Al di là del requisito che un processore XML renda gli identificatori dell'entità e la notazione disponibili all'applicazione, XML non pone alcun vincolo sui contenuti delle entità non parsed.]

Le entità parsed vengono invocate per nome usando i riferimenti di entità; le entità non parsed per nome, dato nel valore degli attributi di ENTITY o ENTITIES.

[Definizione: Le entità generali sono entità per uso interno del contenuto del documento. In questa specifica, a volte ci si riferisce alle entità generali con il termine non qualificato di entità quando ciò non porti a nessuna ambiguità.] [Definizione: le entità parametro sono entità parsed per uso interno alla DTD.] Questi due tipi di entità utilizzano forme differenti di riferimento e vengono riconosciute in contesti differenti. inoltre, occupano differenti ambiti dei nomi; un'entità parametro e un'entità generale con lo stesso nome sono due entità distinte.

[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.]

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.]

Vincolo di Buona-Formazione: Entità Dichiarata

In un documento senza alcuna DTD, un documento con solo un sotto-insieme interno di DTD che non contiene alcun riferimento di entità parametro, oppure un documento con "standalone='yes'", per un riferimento di entità che non ricorre all'interno del sotto-insieme esterno o un'entità parametro, il Name dato nel riferimento di entità deve corrispondere a quello in una dichiarazione di entità che non ricorre all'interno del sotto-insieme esterno o di un entità parametro, eccetto quello che i documento necessitano per non dichiarare una qualsiasi fra le seguenti entità: amp, lt, gt, apos, quot. La dichiarazione di un'entità generale deve precedere qualsiasi riferimento ad essa che appaia in un valore predefinito dentro una dichiarazione di elenco-attributo.

Si noti che i processori non-validanti non sono obbligati a leggere ed elaborare dichiarazioni di entità ricorrenti nelle entità parametro o nel sotto-insieme esterno; per tali documenti, la regola che un'entità deve essere dichiarata è un vincolo di buona-formazione solo se standalone='yes'.

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;

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

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.

[Definizione: Se l'entità non è interna, è un'entità esterna, dichiarata come segue:]

Se è presente il NDataDecl, questo è un'entità non parsed generale; altrimenti è un'entità parsed.

[Definizione: Il SystemLiteral viene chiamato l'identificatore di sistema dell'entità. Si intende che venga convertito in un riferimento di URI (come definito in [IETF RFC 2396], aggiornata da [IETF RFC 2732]), come parte del processo del suo de-referenziamento per ottenere il dato in ingresso per il processore XML al fine di costruire il testo sostitutivo dell'entità.] È un errore per un identificatore di frammento (che inizia con un carattere #) far parte di un identificatore di sistema. A meno che non sia fornita diversamente da informazioni al di fuori dell'ambito di questa specifica (ad es. da un tipo di elemento speciale di XML definito da una particolare DTD, o da un'istruzione di processo definita da una particolare specifica di applicazione), gli URI relativi sono relativi al luogo della risorsa all'interno della quale ricorre la dichiarazione di entità. Ciò viene definito essere un'entità esterna contenente il '<' che dà inizio alla dichiarazione, nel momento in cui subisce il parsing come una dichiarazione. Un URI potrebbe così essere relativo all'entità documento, all'entità contenente il sotto-insieme esterno di DTD, oppure a qualche altra entità parametro esterna. Tentativi di recuperare la risorsa identificata da un URI potrebbero essere re-indirizzati al livello di parser (per esempio, in un risolutore di entità) o più sotto (al livello di protocollo, per esempio attraverso un'intestazione HTTP Location:). In assenza di informazioni aggiuntive fuori dell'ambito di questa specifica all'interno della risorsa, l'URI di base di una risorsa è sempre l'URI della risorsa corrente restituita. In altre parole, è l'URI della risorsa recuperata dopo che sono ricorsi tutti i re-indirizzamenti.

Gli identificatori di sistema (e altre stringhe XML intese ad essere usate come riferimenti di URI) potrebbero contenere caratteri che, in accordo a [IETF RFC 2396] e a [IETF RFC 2732], devono essere codificati in caratteri escape prima che un URI possa essere usata per recuperare la risorsa referenziata. I caratteri da codificarsi in caratteri escape sono quelli di controllo da #x0 a #x1F e #x7F (molti dei quali non possono comparire in XML), la spaziatura #x20, i delimitatori '<' #x3C, '>' #x3E e '"' #x22, i caratteri non-significanti '{' #x7B, '}' #x7D, '|' #x7C, '\' #x5C, '^' #x5E e '`' #x60, così come tutti i caratteri sopra #x7F. Dal momento che la codifica in caratteri escape non sempre è un processo reversibile, deve essere eseguito solo quando assolutamente necessario e il più tardi possibile nella catena di elaborazione. In particolare, né il processo di conversione di un URI relativo in uno assoluto né il processo di passaggio di un riferimento di URI a un processo o componente software responsabile del de-referenziamento dovrebbe far scattare la codifica in caratteri escape. Quando questa codifica comunque ricorra, essa deve essere eseguita come segue:

1. Ogni carattere da codificarsi viene rappresentato in UTF-8 [Unicode3] come uno o più byte.
2. I byte risultanti vengono codificati con il meccanismo di codifica in caratteri escape degli URI (cioè, convertiti in %HH, dove HH è la notazione esadecimale del valore di byte).
3. Il carattere originale viene sostituito dalla sequenza di caratteri risultante.

[Definizione: In aggiunta a un identificatore di sistema, un identificatore esterno potrebbe includere un identificatore pubblico.] Un processore XML che tenti di recuperare il contenuto dell'entità potrebbe usare qualsiasi combinazione fra identificatori di sistema così come informazioni aggiuntive al di fuori dell'ambito di questa specifica per tentare di generare un riferimento alternativo di URI. Se il processore non è in grado di fare così, deve usare il riferimento di URI specificato nel letterale di sistema. Prima che si tenti una corrispondenza, tutte le stringhe di spazio bianco nell'identificatore pubblico devono essere normalizzate in spaziature (#x20) singole, e lo spazio bianco in testa e in coda deve essere rimosso.

Esempi di dichiarazioni di entità esterne:

<!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 >

Le entità codificate in UTF-16 devono e le entità codificate in UTF-8 hanno facoltà di iniziare con il Segno di Ordine di Byte {Byte Order Mark} descritto dall'Annex H di [ISO/IEC 10646:2000], sezione 2.4 di [Unicode], e sezione 2.7 di [Unicode3] (il carattere di LUNGHEZZA ZERO SPAZIO DI NON-INTERRUZIONE, #xFEFF). Questa è una firma di codifica, non facente parte né della marcatura, né dei dati carattere del documento XML. I processori XML devono essere in grado di usare questo carattere per operare la differenza tra i documenti codificati in UTF-8 e in UTF-16.

Sebbene a un processore XML si richieda di saper leggere solo le entità nelle codifiche UTF-8 e UTF-16, viene riconosciuto che altre codifiche vengono usate nel mondo, e si potrebbe desiderare che i processori XML leggano le entità che le utilizzano. In assenza di informazioni esterne sulla codifica di carattere (come le intestazioni MIME), le entità parsed che sono allocate in una codifica diversa sia dalla UTF-8 che dalla UTF-16 devono iniziare con una dichiarazione di testo (vedi 4.3.1 La Dichiarazione di Testo) contenente una dichiarazione di codifica:

In un entità documento, la dichiarazione di codifica fa parte della dichiarazione XML. L'EncName è il nome della codifica utilizzata.

In una dichiarazione di codifica, i valori "UTF-8", "UTF-16", "ISO-10646-UCS-2", and "ISO-10646-UCS-4" dovrebbero essere usati per le varie codifiche e trasformazioni di Unicode / ISO/IEC 10646, i valori "ISO-8859-1", "ISO-8859-2", ... "ISO-8859-n" (dove n è il numero di parte) dovrebbero essere usati per le parti di ISO 8859, e i valori "ISO-2022-JP", "Shift_JIS", e "EUC-JP" dovrebbero essere usati per le varie forme codificate di JIS X-0208-1997. È Raccomandato che ci si riferisca alle codifiche di carattere registrate (come charset) dall'Autorità Internet per i Numeri Assegnati {Internet Assigned Numbers Authority} [IANA-CHARSETS], diverse da quelle appena elencate, usando i loro nomi registrati; altre codifiche dovrebbero usare i nomi che iniziano con un prefisso "x-". I processori XML dovrebbero confrontare i nomi delle codifiche di carattere in una maniera indifferente alle maiuscole {case-insensitive} e dovrebbero sia interpretare un nome registrato in IANA come la codifica registrata presso IANA per quel nome sia trattarlo come sconosciuto (i processori, naturalmente, non sono obbligati a supportare tutte le codifiche registrate in IANA).

In assenza di informazioni fornite da un protocollo esterno di trasporto (ad es. HTTP o MIME), è un errore fatale per un'entità includere una dichiarazione di codifica che deve essere presentata al processore XML in una codifica differente da quella che è stata nominata nella dichiarazione, o per un'entità che inizi né con un Segno di Ordine di Byte, né con una dichiarazione di codifica per usare una codifica diversa dalla UTF-8. Si noti che dal momento che ASCII è un sotto-insieme di UTF-8, le entità ordinarie di ASCII non hanno strettamente necessità di una dichiarazione di codifica.

È un errore fatale per una TextDecl ricorrere in un punto diverso dall'inizio di un'entità esterna.

È un errore fatale quando un processore XML incontra un'entità con una codifica che esso non è in grado di elaborare. È un errore fatale se un'entità XML viene determinata (attraverso valore predefinito, dichiarazione di codifica, o protocolli di più alto livello) essere di una certa codifica ma contiene sequenze di byte che non sono legali in quella codifica. In special modo, è un errore fatale se un'entità codificata in UTF-8 contiene qualsiasi sequenza di unità di codice irregolari, come definito in Unicode 3.1 [Unicode3]. A meno che una codifica non sia determinata da un protocollo di più alto livello, inoltre è un errore fatale se un'entità XML non contiene alcuna dichiarazione di codifica e il suo contenuto non è UTF-8 o UTF-16 legale.

Esempi di dichiarazioni di testo contenenti dichiarazioni di codifica:

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

Ogni entità, inclusa l'entità documento, può essere dichiarata separatamente come XML 1.0 o XML 1.1. La dichiarazione di versione che compare nell'entità documento determina la versione del documento nel suo intero. Un documento XML 1.1 potrebbe invocare entità esterne XML 1.0, cosicché versioni in altro modo duplicate delle entità esterne, in particolare i sotto-insiemi esterni di DTD, non hanno bisogno di manutenzione. Comunque, in tali casi le regole di XML 1.1 vengono applicate all'intero documento.

Se un'entità (inclusa l'entità documento) non é etichettata con un numero di versione, viene trattata come se fosse etichettata come versione 1.0.

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).

.

[Definizione: Un'entità è inclusa quando il suo testo sostitutivo viene recuperato ed elaborato, al posto del riferimento stesso, come se fosse parte del documento nel posto in cui il riferimento è stato riconosciuto.] Il testo sostitutivo potrebbe contenere sia dati carattere che (eccetto per le entità parametro) marcatura, che deve essere riconosciuto nel modo usuale. (La stringa "AT&T;" si espande in "AT&T;" e la "e commerciale" rimanente non viene riconosciuta come un delimitatore di riferimento di entità.) Un riferimento di carattere è incluso quando il carattere indicato viene elaborato al posto del riferimento stesso.

Quando un processore XML riconosce un riferimento a un'entità parsed, per validare il documento, il processore deve includere il suo testo sostitutivo. Se l'entità è esterna, e il processore non sta tentando di validare il documento XML, il processore ha facoltà, ma non ha bisogno, di includere il testo sostitutivo dell'entità. Se un processore non-validante non include il testo sostitutivo, esso deve informare l'applicazione che ha riconosciuto, ma non ha letto, l'entità.

Questa regola si basa sul riconoscimento che l'inclusione automatica fornita dal meccanismo di entità di SGML e XML, primariamente progettato per supportare la modularità nella creazione di documenti, non è necessariamente appropriato per altre applicazioni, in particolare la navigazione fra i documenti. I browser, per esempio, quando incontrano un riferimento di entità parsed esterna, potrebbero scegliere di fornire un'indicazione visiva della presenza dell'entità e recuperarla in visualizzazione solo su richiesta.

Quando un riferimento di entità compare in un valore di attributo, o un riferimento di entità parametro compare in un valore di entità letterale, il suo testo sostitutivo deve essere elaborato al posto del riferimento stesso come se fosse parte del documento nel posto in cui è stato riconosciuto il riferimento, eccetto per il fatto che un carattere di virgolette singole o doppie nel testo sostitutivo deve sempre venire trattato come un carattere dato normale e non deve terminare il letterale. Per esempio, questo è ben-formato:

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

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

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;

[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;">

[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.]

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.)

[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.

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.

• 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.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.3