Linguaggio Estensibile di Marcatura (XML) 1.0 (Terza Edizione) (original) (raw)

1 Introduzione

Il Linguaggio Estensibile 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 dacaratteri, alcuni dei quali formano idati 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.

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 unprocessore 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 daiprocessori che convalidano XML.]

vincolo di buona-formazione

[Definizione: Una regola che si applica a tutti i documenti XMLben-formati. Le violazioni dei vincoli di buona-formazione sonoerrori 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.]

2 Documenti

[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} oentità 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.

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 delleentità parsed alla quale si fa riferimento direttamente o indirettamente all'interno del documento èben-formata.
Documento

[1]

document

::=

[prolog](#NT-prolog) [element](#NT-element) [Misc](#NT-Misc)*

Aderire alla produzione del documentoimplica 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 iltag-di-inizio è contenuto in un altro elemento, iltag-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 Pcome 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

[2]

Char

::=

#x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF]

/* qualsiasi carattere Unicode, esclusi i blocchi surrogati, FFFE, e FFFF . */

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

2.3 Costrutti Sintattici Comuni

Questa sezione definisce alcuni simboli usati largamente nella grammatica.

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

Spazio Bianco

[3]

S

::=

(#x20 | #x9 | #xD | #xA)+

I caratteri sono classificati per convenienza in lettere, cifre, o altri caratteri. Una lettera consiste in un carattere di base alfabetico o sillabico oppure in un carattere ideografico. Definizioni complete di caratteri specifici in ogni classe vengono fornite in B Classi di Carattere.

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

Name e Token

[4]

NameChar

::=

[Letter](#NT-Letter) | [Digit](#NT-Digit) | '.' | '-' | '_' | ':' | [CombiningChar](#NT-CombiningChar) | [Extender](#NT-Extender)

[5]

Name

::=

([Letter](#NT-Letter) | '_' | ':') ([NameChar](#NT-NameChar))*

[6]

Names

::=

[Name](#NT-Name) (#x20 [Name](#NT-Name))*

[7]

Nmtoken

::=

([NameChar](#NT-NameChar))+

[8]

Nmtokens

::=

[Nmtoken](#NT-Nmtoken) (#x20 [Nmtoken](#NT-Nmtoken))*

Nota:

Le produzioni di Names e di Nmtokens vengono usate per definire la validità di valori di attributo resi come token dopo la normalizzazione (vedi 3.3.1 Tipi di Attribut o).

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

[9]

EntityValue

::=

'"' ([^%&"] | [PEReference](#NT-PEReference) | [Reference](#NT-Reference))* '"'

| "'" ([^%&'] | [PEReference](#NT-PEReference) | [Reference](#NT-Reference))* "'"

[10]

AttValue

::=

'"' ([^<&"] | [Reference](#NT-Reference))* '"'

| "'" ([^<&'] | [Reference](#NT-Reference))* "'"

[11]

SystemLiteral

::=

('"' [^"]* '"') | ("'" [^']* "'")

[12]

PubidLiteral

::=

'"' [PubidChar](#NT-PubidChar)* '"' | "'" ([PubidChar](#NT-PubidChar) - "'")* "'"

[13]

PubidChar

::=

#x20 | #xD | #xA | [a-zA-Z0-9] | [-'()+,./:=?;!*#@$_%]

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.

2.4 Dati carattere e Marcatura

Il testo consiste di dati carattere e marcatura frammisti. [Definizione: La **marcatura**prende la forma ditag-di-inizio, tag-di-fine, tag di elemento-vuoto, riferimenti di entità, riferimenti di carattere, commenti, delimitatori disezioni 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 uncommento, di un'istruzione di processo, o di una sezione CDATA. Se si rendono necessari da qualche altra parte, essi_devono_ essericodificati in carattere escape usando sia iriferimenti numerici di carattere che rispettivamente le stringhe "&amp;" e "&lt;". La parentesi angolare destra (>)potrebbe essere rappresentata usando la stringa "&gt;", e_deve, per compatibilità, essere codificata in caratteri escape usando sia "&gt;" che un riferimento di carattere quando appare nel contenuto della stringa "]]>", quando quella stringa non sta marcando la fine di unasezione 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 "&apos;", e il carattere di doppie virgolette (") come "&quot;".

Dati Carattere

[14]

CharData

::=

[^<&]* - ([^<&]* ']]>' [^<&]*)

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:

Salve, mondo!

e così anche questo:

Salve, mondo!

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, ladichiarazione 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.

[22]

prolog

::=

[XMLDecl](#NT-XMLDecl)? [Misc](#NT-Misc)* ([doctypedecl](#NT-doctypedecl) [Misc](#NT-Misc)*)?

[23]

XMLDecl

::=

'<?xml' [VersionInfo](#NT-VersionInfo) [EncodingDecl](#NT-EncodingDecl)? [SDDecl](#NT-SDDecl)? [S](#NT-S)? '?>'

[24]

VersionInfo

::=

[S](#NT-S) 'version' [Eq](#NT-Eq) ("'" [VersionNum](#NT-VersionNum) "'" | '"' [VersionNum](#NT-VersionNum) '"')

[25]

Eq

::=

[S](#NT-S)? '=' [S](#NT-S)?

[26]

VersionNum

::=

'1.0'

[27]

Misc

::=

[Comment](#NT-Comment) | [PI](#NT-PI) | [S](#NT-S)

[Definizione: La **dichiarazione di tipo di documento**XML contiene o punta adichiarazioni di marcaturache 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 dientità 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** è unadichiarazione del tipo di elemento, unadichiarazione dell'elenco-attributo, unadichiarazione di entità, o unadichiarazione di notazione.] Queste dichiarazioni potrebbero essere contenute per intero o in parte all'interno dientità 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

[28]

doctypedecl

::=

'<!DOCTYPE' [S](#NT-S) [Name](#NT-Name) ([S](#NT-S) [ExternalID](#NT-ExternalID))? [S](#NT-S)? ('[' [intSubset](#NT-intSubset) ']' [S](#NT-S)?)? '>'

[VV: Tipo di Elemento Radice]

[VBF: Sotto-insieme esterno]

[28a]

DeclSep

::=

[PEReference](#NT-PEReference) | [S](#NT-S)

[VBF: PE fra Dichiarazioni]

[28b]

intSubset

::=

([markupdecl](#NT-markupdecl) | [DeclSep](#NT-DeclSep))*

[29]

markupdecl

::=

[elementdecl](#NT-elementdecl) | [AttlistDecl](#NT-AttlistDecl) | [EntityDecl](#NT-EntityDecl) | [NotationDecl](#NT-NotationDecl) | [PI](#NT-PI) | [Comment](#NT-Comment)

[VV: Nidificazione Dichiarazione/PE Appropriata]

[VBF: i PE nel Sotto-insieme Interno]

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 datesto in sostituzione dientità 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.

Vincolo di Validità: Nidificazione Dichiarazione/PE appropriata

Iltesto sostitutivo di entità-parametro deve essere nidificato in modo appropriato con dichiarazioni di marcatura. Vale a dire, se sia il primo carattere oppure l'ultimo di una dichiarazione di marcatura (il markupdecl di cui sopra) è contenuto in un testo sostitutivo per unriferimento di entità-parametro, entrambi _devono_essere contenuti nello stesso testo sostitutivo.

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 oriferimenti 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 disezione condizionale; ciò non è permesso nel sotto-insieme interno, ma è permesso nelle entità parametro esterne referenziate nel sotto-insieme interno.

Sotto-insieme Esterno

[30]

extSubset

::=

[TextDecl](#NT-TextDecl)? [extSubsetDecl](#NT-extSubsetDecl)

[31]

extSubsetDecl

::=

( [markupdecl](#NT-markupdecl) | [conditionalSect](#NT-conditionalSect) | [DeclSep](#NT-DeclSep))*

Anche il sotto-insieme esterno e le entità parametro esterne differiscono dal sotto-insieme interno, nel fatto che in loro, i riferimenti a entità-parametrosono 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:

Salve, mondo!

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:

]> Salve, mondo!

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.

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

[32]

SDDecl

::=

[S](#NT-S) 'standalone' [Eq](#NT-Eq) (("'" ('yes' | 'no') "'") | ('"' ('yes' | 'no') '"'))

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

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:

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

2.10 Gestione dello Spazio Bianco

Nella manipolazione di documenti XML, spesso è conveniente usare lo "spazio bianco" (spaziature, tabulazioni, e righe bianche) per dividere la marcatura a favore di una maggiore leggibilità. Tale spazio bianco tipicamente non viene incluso nella versione definitiva del documento. D'altro canto, è comune la presenza di spazio bianco "significativo" che dovrebbe essere preservato nella versione definitiva, per esempio in poesia e in codice sorgente.

Un processore XML deve sempre passare tutti i caratteri di un documento che non sono marcatura verso l'applicazione. Unprocessore XML validanteinoltre _deve_informare l'applicazione di quali di questi caratteri costituisce lo spazio bianco che compare nelcontenuto 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 untipo enumerato i valori del quale sono uno o entrambi quelli di "default" e "preserve". Per esempio:

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 sia la sequenza di due caratteri #xD #xA che ciascun carattere #xD che non sia seguito da uno #xA, in un singolo carattere #xA.

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:

The quick brown fox jumps over the lazy dog.

What colour is it?

What color is it?

Habe nun, ach! Philosophie, Juristerei, und Medizin und leider auch Theologie durchaus studiert mit heißem Bemüh'n.

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:langla reimposti.

Una semplice dichiarazione per xml:lang potrebbe prendere la forma

ma potrebbero anche essere dati valori specifici predefiniti, se appropriati. In una raccolta di poemi francesi per studenti inglesi, con glosse e note in inglese, l'attributo xml:langpotrebbe essere dichiarato in questo modo:

3 Strutture logiche

[Definizione: Ognidocumento XML contiene uno o più elementi, i limiti dei quali sono delimitati sia datag-di-inizio etag-di-fine, che, per elementi vuoti, da untag 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.

Elemento

[39]

element

::=

[EmptyElemTag](#NT-EmptyElemTag)

| [STag](#NT-STag) [content](#NT-content) [ETag](#NT-ETag)

[VBF: Corrispondenza del Tipo di Elemento]

[VV: Elemento Valido]

Questa specifica non vincola la semantica, l'uso, o (al di là della sintassi) i nomi dei tipi di elemento e degli attributi, eccetto che per quei nomi che iniziano con una corrispondenza a (('X'|'x')('M'|'m')('L'|'l')) i quali sono riservati alla standardizzazione in questa o in future versioni della presente specifica.

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 afigli e la sequenza deglielementi 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, edelementi figli i cui tipi sono stati dichiarati.

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

[40]

STag

::=

'<' [Name](#NT-Name) ([S](#NT-S) [Attribute](#NT-Attribute))* [S](#NT-S)? '>'

[VBF: Att Spec Unico]

[41]

Attribute

::=

[Name](#NT-Name) [Eq](#NT-Eq) [AttValue](#NT-AttValue)

[VV: Tipo di Valore d'Attributo]

[VBF: Nessun Riferimento a Entità Esterne]

[VBF: Nessun < nei Valori d'Attributo]

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:

[Definizione: La fine di ogni elemento che comincia con un tag-di-inizio_deve_ essere marcata da un tag-di-finecontenente un nome che ricalchi il tipo d'elemento così come dato nel tag-di-inizio:]

Tag-di-fine

[42]

ETag

::=

'</' [Name](#NT-Name) [S](#NT-S)? '>'

Un esempio di tag-di-fine:

[Definizione: Il testo fra il tag-di-inizio e il tag-di-fine viene chiamato il contenuto dell'elemento:]

Contenuto degli Elementi

[43]

content

::=

[CharData](#NT-CharData)? (([element](#NT-element) | [Reference](#NT-Reference) | [CDSect](#NT-CDSect) | [PI](#NT-PI) | [Comment](#NT-Comment)) [CharData](#NT-CharData)?)*

[Definizione: Un elemento con nessun contenuto si dice esserevuoto.] 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

[44]

EmptyElemTag

::=

'<' [Name](#NT-Name) ([S](#NT-S) [Attribute](#NT-Attribute))* [S](#NT-S)? '/>'

[VBF: Att Spec Unico]

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:




3.2 Dichiarazioni del Tipo di Elemento

La struttura di elemento di undocumento 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 comefigli 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 elementoprende la forma:]

Dichiarazione del Tipo di Elemento

[45]

elementdecl

::=

'<!ELEMENT' [S](#NT-S) [Name](#NT-Name) [S](#NT-S) [contentspec](#NT-contentspec) [S](#NT-S)? '>'

[VV: Dichiarazione Unica del Tipo di Elemento]

[46]

contentspec

::=

'EMPTY' | 'ANY' | [Mixed](#NT-Mixed) | [children](#NT-children)

dove il Name fornisce il tipo di elemento da dichiararsi.

Esempi di dichiarazioni del tipo di elemento:

3.2.1 Contenuto dell'Elemento

[Definizione: Untipo di elemento possiede un contenuto di elemento quando gli elementi di quel tipo_devono_ contenere solo gli elementifigli (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:

Modelli di contenuto d'elemento

[47]

children

::=

([choice](#NT-choice) | [seq](#NT-seq)) ('?' | '*' | '+')?

[48]

cp

::=

([Name](#NT-Name) | [choice](#NT-choice) | [seq](#NT-seq)) ('?' | '*' | '+')?

[49]

choice

::=

'(' [S](#NT-S)? [cp](#NT-cp) ( [S](#NT-S)? '|' [S](#NT-S)? [cp](#NT-cp) )+ [S](#NT-S)? ')'

[VV: Nidificazione Appropriata di Gruppo/PE]

[50]

seq

::=

'(' [S](#NT-S)? [cp](#NT-cp) ( [S](#NT-S)? ',' [S](#NT-S)? [cp](#NT-cp) )* [S](#NT-S)? ')'

[VV: Nidificazione Appropriata di Gruppo/PE]

dove ogni Name è il tipo di un elemento che ha facoltà di comparire come unfiglio. Ogni particella di contenuto in un elenco di scelte_ha facoltà_ di comparire nelcontenuto dell'elementonel posto dove compare l'elenco di scelte nella grammatica; particelle di contenuto che ricorrono in un elenco di sequenze_devono_ comparire ciascuna nelcontenuto dell'elementonell'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:

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:

[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

[52]

AttlistDecl

::=

'<!ATTLIST' [S](#NT-S) [Name](#NT-Name) [AttDef](#NT-AttDef)* [S](#NT-S)? '>'

[53]

AttDef

::=

[S](#NT-S) [Name](#NT-Name) [S](#NT-S) [AttType](#NT-AttType) [S](#NT-S) [DefaultDecl](#NT-DefaultDecl)

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.

3.3.3 Normalizzazione del Valore di Attributo

Prima che il valore di un attributo sia passato all'applicazione o verificato nella validità, il processore XML_deve_ normalizzare il valore di attributo applicando l'algoritmo sottostante, oppure usando qualche altro metodo tale che il valore passato all'applicazione sia lo stesso di quello prodotto dall'algoritmo.

  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:

le specificazioni di attributo nella colonna sinistra sottostante sarebbero normalizzate con le sequenze di carattere della colonna centrale se l'attributo aviene dichiarato NMTOKENS e con quelli della colonna destra se aviene dichiarato CDATA.

Specificazione di attributo a è NMTOKENS a è CDATA
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

Si noti che l'ultimo esempio non è valido (ma ben-formato) se aviene dichiarato essere di tipo NMTOKENS.

3.4 Sezioni Condizionali

[Definizione: Le **sezioni condizionali** sono porzioni delsotto-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

[61]

conditionalSect

::=

[includeSect](#NT-includeSect) | [ignoreSect](#NT-ignoreSect)

[62]

includeSect

::=

'<![' `[S](#NT-S)` `? 'INCLUDE' ` [S](#NT-S) ? '[' [extSubsetDecl](#NT-extSubsetDecl) ']]>'

[VV: Nidificazione Appropriata Sezione Condizionale/PE]

[63]

ignoreSect

::=

'<![' `[S](#NT-S)` `? 'IGNORE' ` [S](#NT-S) ? '[' [ignoreSectContents](#NT-ignoreSectContents)* ']]>'

[VV: Nidificazione Appropriata Sezione Condizionale/PE]

[64]

ignoreSectContents

::=

[Ignore](#NT-Ignore) ('<![' [ignoreSectContents](#NT-ignoreSectContents) ']]>' [Ignore](#NT-Ignore))*

[65]

Ignore

::=

[Char](#NT-Char)* - ([Char](#NT-Char)* ('<![' | ']]>') [Char](#NT-Char)*)

Come i sotto-insiemi di DTD interni ed esterni, un sezione condizionale potrebbe contenere una o più dichiarazioni complete, commenti, istruzioni di processo, o sezioni condizionali nidificate, inframmezzate da spazio bianco.

Qualora la parola chiave della sezione condizionale sia INCLUDE, allora i contenuti della sezione condizionale devono essere considerati parte della DTD. Qualora la parola chiave della sezione condizionale sia IGNORE, allora i contenuti della sezione condizionale devono essere considerati come non facenti parte in modo logico della DTD. Qualora ricorra una sezione condizionale con una parola chiave INCLUDE all'interno di una sezione condizionale più ampia con la parola chiave IGNORE, sia le sezioni condizionali più esterne che quelle più interne_devono_essere ignorate. I contenuti di una sezione condizionale ignorata_devono_essere analizzati in modo logico ignorando tutti i caratteri dopo la "[" che segue la parola chiave, eccetto qualora la sezione condizionale inizi con "<![" e finisca con "]]>", finché non viene trovata la corrispondente fine di sezione condizionale. I riferimenti di entità parametro non devono essere riconosciuti in questo processo.

Se la parola chiave della sezione condizionale è un riferimento di entità-parametro, l'entità parametro_deve_ essere sostituita con il suo contenuto prima che il processore decida se includere o ignorare la sezione condizionale.

Un esempio:

<![%draft;[ ]]> <![%final;[ ]]>

4 Strutture Fisiche

[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 ilsotto-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 ilprocessore 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 suotesto 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à parametrosono 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.

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

[66]

CharRef

::=

'&#' [0-9]+ ';'

| '&#x' [0-9a-fA-F]+ ';'

[VBF: Carattere Legale]

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: Unriferimento 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à

[67]

Reference

::=

[EntityRef](#NT-EntityRef) | [CharRef](#NT-CharRef)

[68]

EntityRef

::=

'&' [Name](#NT-Name) ';'

[VBF: Entità Dichiarata]

[VV: Entità Dichiarata]

[VBF: Entità Parsed]

[VBF: Nessuna Ricorsività]

[69]

PEReference

::=

'%' [Name](#NT-Name) ';'

[VV: Entità Dichiarata]

[VBF: Nessuna Ricorsività]

[VBF: Nella DTD]

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-validantinon sono obbligati aleggere 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 minore-di (<) per salvare le opzioni. Questo documento è stato preparato il &datadoc; ed è classificato &livello-sicurezza;.

Esempio di un riferimento di entità-parametro:

%ISOLat2;

4.2 Dichiarazioni di Entità

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

Dichiarazione di Entità

[70]

EntityDecl

::=

[GEDecl](#NT-GEDecl) | [PEDecl](#NT-PEDecl)

[71]

GEDecl

::=

'<!ENTITY' [S](#NT-S) [Name](#NT-Name) [S](#NT-S) [EntityDef](#NT-EntityDef) [S](#NT-S)? '>'

[72]

PEDecl

::=

'<!ENTITY' [S](#NT-S) '%' [S](#NT-S) [Name](#NT-Name) [S](#NT-S) [PEDef](#NT-PEDef) [S](#NT-S)? '>'

[73]

EntityDef

::=

[EntityValue](#NT-EntityValue)| ([ExternalID](#NT-ExternalID) [NDataDecl](#NT-NDataDecl)?)

[74]

PEDef

::=

[EntityValue](#NT-EntityValue) | [ExternalID](#NT-ExternalID)

Il Name identifica l'entità in unriferimento 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.

4.2.1 Entità Interne

[Definizione: Se la definizione di entità è un EntityValue, l'entità definita viene chiamata un'entità interna. Non c'è un oggetto di allocazione fisico separato, e il contenuto dell'entità è dato nella dichiarazione.] Si noti che potrebbero essere richieste alcune elaborazioni dei riferimenti di entità e di carattere nelvalore letterale di entitàper produrre il correttotesto sostitutivo: vedi 4.5 Costruzione di Testo Sostitutivo per Entità Interna.

Un entità interna è un'entità parsed.

Esempio di una dichiarazione di entità interna:

4.2.2 Entità Esterne

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

Dichiarazione di Entità Esterna

[75]

ExternalID

::=

'SYSTEM' [S](#NT-S) [SystemLiteral](#NT-SystemLiteral)

| 'PUBLIC' [S](#NT-S) [PubidLiteral](#NT-PubidLiteral) [S](#NT-S) [SystemLiteral](#NT-SystemLiteral)

[76]

NDataDecl

::=

[S](#NT-S) 'NDATA' [S](#NT-S) [Name](#NT-Name)

[VV: Notazione Dichiarata]

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 ilsotto-insieme esterno di DTD, oppure a qualche altraentità 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:

4.3 Entità parsed

4.3.3 Codifica di Carattere nelle Entità

Ogni entità parsed esterna in un documento XML_ha facoltà_ di usare una codifica differente per i suoi caratteri. Tutti i processori XML_devono_ essere in grado di leggere entità sia nella codifica UTF-8 che in quella UTF-16. I termini "UTF-8" e "UTF-16" in questa specifica non si applicano alle codifiche di carattere con qualsiasi altra etichetta, perfino se le codifiche o le etichette sono molto simili a UTF-8 o a UTF-16.

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:

Dichiarazione di Codifica

[80]

EncodingDecl

::=

[S](#NT-S) 'encoding' [Eq](#NT-Eq) ('"' [EncName](#NT-EncName) '"' | "'" [EncName](#NT-EncName) "'" )

[81]

EncName

::=

[A-Za-z] ([A-Za-z0-9._] | '-')*

/* Il nome di codifica contiene solo caratteri Latini */

In un entità documento, la dichiarazione di codifica fa parte delladichiarazione 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. È unerrore 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:

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 iltag-di-inizio e prima deltag-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 untag-di-inizio, che un valore predefinito in unadichiarazione 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 delvalore 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).

.

Tipo di Entità Carattere
Parametro Generale Interna Parsed Generale Esterna Non Parsed
Riferimento nel Contenuto Non riconosciuto Incluso Incluso se validante Proibito Incluso
Riferimento nel Valore di Attributo Non riconosciuto Incluso alla lettera Proibito Proibito Incluso
Ricorre come Valore di Attributo Non riconosciuto Proibito Proibito Notifica Non riconosciuto
Riferimento in Valore di Entità Incluso alla lettera Aggirato Aggirato Errore Incluso
Riferimento in DTD Incluso come PE Proibito Proibito Proibito Proibito

4.4.2 Incluso

[Definizione: Un'entità è **inclusa** quando il suotesto 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 siadati carattere che (eccetto per le entità parametro) marcatura, che_deve essere riconosciuto nel modo usuale. (La stringa "AT&amp;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 è inclusoquando il carattere indicato viene elaborato al posto del riferimento stesso.

4.4.3 Incluso Se Validante

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.

4.4.4 Proibito

Ciò che segue è proibito, e costituisce errore fatale:

4.4.5 Incluso alla Lettera

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

mentre questo non lo è:

<element attribute='a-&EndAttr;>

4.4.6 Notifica

Quando il nome di un'entità non parsed compare come un token nel valore di un attributo del tipo dichiarato ENTITY o ENTITIES, un processore validante_deve_ informare l'applicazione del sistema e degli identificatori pubblici (se presenti) sia per l'entità che per la suanotazione associata.

4.4.8 Incluso come PE

Proprio come le entità parsed esterne, le entità parametro necessitano solo di essere incluse se validanti. Quando un riferimento di entità-parametro viene riconosciuta nella DTD e inclusa, il suotesto sostitutivo _deve_essere allargato dall'annessione di un singolo carattere di spaziatura (#x20) in testa e in coda; l'intento è quello di vincolare il testo sostitutivo delle entità parametro a contenere un numero intero di token grammaticali nella DTD. Questo comportamento non deve applicarsi ai riferimenti di entità parametro all'interno di valori di entità; questi vengono descritti in 4.4.5 Incluso alla Lettera.

4.4.9 Errore

È un errore per un riferimento a entità non parsed comparire nell'EntityValue in una dichiarazione di entità.

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'EntityValuenon-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:

allora il testo sostitutivo per l'entità "book" è:

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

Il riferimento di entità-generale "&rights;" sarebbe stato espanso se il riferimento "&book;" dovesse comparire nel contenuto del documento o in un valore di attributo.

Queste semplici regole potrebbero avere interazioni complesse; per una trattazione dettagliata di un esempio difficile, si veda D Espansione dei Riferimenti di Entità e di Carattere.

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 "&#60;" e "&#38;" 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:

4.7 Dichiarazioni di Notazione

[Definizione: Le **notazioni** identificano per nome il formato dientità 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

[82]

NotationDecl

::=

'<!NOTATION' [S](#NT-S) [Name](#NT-Name) [S](#NT-S) ([ExternalID](#NT-ExternalID) | [PublicID](#NT-PublicID)) [S](#NT-S)? '>'

[VV: Nome Univoco di Notazione]

[83]

PublicID

::=

'PUBLIC' [S](#NT-S) [PubidLiteral](#NT-PubidLiteral)

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 unprocessore 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 Conformità

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 altraentità 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 normalizzarei valori di attributo, includere il testo sostitutivo delle entità interne, e supportarei valori predefiniti di attributo.] Eccetto quando standalone="yes", essi devono processare le dichiarazioni di entità ole 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.

5.2 Usare i Processori XML

Il comportamento di un processore XML validante è altamente prevedibile; esso deve leggere ogni pezzo di un documento e riportare tutte le violazioni di buona-formazione e di validità. Viene richiesto meno a un processore non-validante; esso non ha bisogno di leggere qualsiasi parte del documento diversa dall'entità documento. Ciò ha due effetti che potrebbero essere importanti per gli utenti dei processori XML:

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.