Nota di Traduzione

Extensible Markup Language (XML) 1.0 (Third Edition)

Nel tradurre questo documento, pur avendo solo l'originale valore normativo, si è cercato di attenersi il più possibile fedeli al testo inglese. A volte, per ragioni di esattezza scientifica, si è ritenuto di:

Segnalazioni di errori e refusi o richieste di informazioni possono essere indirizzate a: w3c@dkg.it.

Traduttore: Daniele Gabriele. Data di pubblicazione: 11 novembre 2005. Data di ultima revisione: 03 gennaio 2006.

W3C

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

Raccomandazione W3C 04 febbraio 2004

Questa versione:
http://www.w3.org/TR/2004/REC-xml-20040204
Ultima versione:
http://www.w3.org/TR/REC-xml
Versione precedente:
http://www.w3.org/TR/2003/PER-xml-20031030
Curatori:
Tim Bray, Textuality e Netscape mailto:tbray@textuality.com
Jean Paoli, Microsoft mailto:jeanpa@microsoft.com
C. M. Sperberg-McQueen, W3C mailto:cmsmcq@w3.org
Eve Maler, Sun Microsystems, Inc. mailto:elm@east.sun.com - Seconda Edizione
François Yergeau mailto:francois@yergeau.com - Terza Edizione

Si prega di far riferimento agli errata di questo documento, i quali potrebbero includere alcune correzioni normative.

Questo documento è anche disponibile nei seguenti formati non-normativi: XMLXHTML con indicatori colorati di revisione.

Si vedano anche le traduzioni.


Sintesi

Il Linguaggio Estensibile di Marcatura {Extensible Markup Language} (XML) è un sotto-insieme di SGML il quale viene descritto in modo completo in questo documento. Il suo obiettivo è quello di mettere SGML in grado di essere servito, ricevuto, ed elaborato sul Web nel modo in cui è attualmente possibile con HTML. XML è stato progettato per una facile implementazione e per l'interoperabilità sia con SGML che con HTML.

Status di questo Documento

Questa sezione descrive lo status del presente documento al momento della sua pubblicazione. Altri documenti potrebbero far decadere questo documento. Un elenco delle pubblicazioni attuali del W3C e l'ultima revisione di questa relazione tecnica possono trovarsi nell'indice delle relazioni tecniche del W3C presso http://www.w3.org/TR/.

Questo documento è una Raccomandazione del W3C. È stata revisionato dai Membri del W3C e da altre parti interessate, ed è stato approvato dal Direttore come una Raccomandazione del W3C. È un documento definitivo è può essere utilizzato come materiale di riferimento o citato come riferimento normativo da un altro documento. Il ruolo del W3C nel produrre la Raccomandazione è attirare l'attenzione sulla specifica e promuoverne la diffusa implementazione. Tutto ciò rafforza la funzionalità e l'interoperabilità del Web.

Questo documento specifica una sintassi creata a partire dal sotto-insieme di uno standard di elaborazione testuale esistente e ampiamente utilizzato a livello internazionale (Linguaggio Standard Generalizzato di Marcatura {Standard Generalized Markup Language}, ISO 8879:1986(E) così come emendato e corretto) per l'impiego nel World Wide Web. È un prodotto del Gruppo di Lavoro per XML Core come parte dell'Attività di XML. La versione in inglese di queste specifiche è l'unica normativa. In ogni caso, per le traduzioni di questo documento, si veda http://www.w3.org/2003/03/Translations/byTechnology?technology=REC-xml.

Questa terza edizione non è una nuova versione di XML. Per convenienza di chi legge, incorpora le modifiche dettate dagli errata accumulatisi nel tempo (disponibili presso http://www.w3.org/XML/xml-V10-2e-errata) per la Seconda Edizione di XML 1.0, datata 6 ottobre 2000. In aggiunta, è stata introdotta la marcatura su una porzione significativa delle prescrizioni della specifica, chiarendo quando parole chiave normative come DEVE, DOVREBBE e ha facoltà/pOTREBBE vengono usate nel significato formale definito in [IETF RFC 2119]. Per convenienza di chi legge, viene fornita anche una versione XHTML con indicatori colorati di revisione; questa versione evidenzia ogni modifica dovuta a un erratum in quell'elenco. La maggior parte degli errata nell'elenco forniscono la motivazione della modifica.

Un rapporto di implementazione è disponibile presso http://www.w3.org/XML/2003/09/xml10-3e-implementation.html.

La documentazione per proprietà intellettuale in qualche modo attinente a questa raccomandazione si può trovare presso la pubblica pagina di divulgazione dell'IPR del Gruppo di Lavoro.

Si prega di riportare gli errori del presente documento a xml-editor@w3.org; sono disponibili degli archivi. L'elenco degli errata per questa terza edizione è disponibile presso http://www.w3.org/XML/xml-V10-3e-errata.

Viene mantenuta una Suit di Test per aiutare a valutare la conformità a questa specifica.

Sommario

1 Introduzione
    1.1 Origine e Obiettivi
    1.2 Terminologia
2 Documenti
    2.1 Documenti XML Ben-Formati
    2.2 Caratteri
    2.3 Costrutti Sintattici Comuni
    2.4 Dati carattere e Marcatura
    2.5 Commenti
    2.6 Istruzioni di Processo
    2.7 Sezioni CDATA
    2.8 Prologo e Dichiarazione del Tipo di Documento
    2.9 Dichiarazione di Documento Autonomo
    2.10 Gestione dello Spazio Bianco
    2.11 Gestione del Fine-Riga
    2.12 Identificazione della Lingua
3 Strutture Logiche
    3.1 Tag-di-Inzio, Tag-di-Fine, e Tag di Elemento-Vuoto
    3.2 Dichiarazioni del Tipo di Elemento
        3.2.1 Contenuto dell'Elemento
        3.2.2 Contenuto Misto
    3.3 Dichiarazioni di Elenco-Attributo
        3.3.1 Tipi di Attributo
        3.3.2 Valori Predefiniti di Attributo
        3.3.3 Normalizzazione del Valore di Attributo
    3.4 Sezioni Condizionali
4 Strutture fisiche
    4.1 Riferimenti di Entità e di Carattere
    4.2 Dichiarazioni di Entità
        4.2.1 Entità Interne
        4.2.2 Entità Esterne
    4.3 Entità Parsed
        4.3.1 La Dichiarazione di Testo
        4.3.2 Entità Parsed Ben-Formate
        4.3.3 Codifica di Carattere nelle Entità
    4.4 Trattamento del Processore XML di Entità e Riferimenti
        4.4.1 Non Riconosciuto
        4.4.2 Incluso
        4.4.3 Incluso Se Validante
        4.4.4 Proibito
        4.4.5 Incluso alla Lettera
        4.4.6 Notifica
        4.4.7 Aggirato
        4.4.8 Incluso come PE
        4.4.9 Errore
    4.5 Costruzione di Testo Sostitutivo di Entità Interne
    4.6 Entità Predefinite
    4.7 Dichiarazioni di Notazione
    4.8 Entità Documento
5 Conformità
    5.1 Processori Validanti e Non-Validanti
    5.2 Usare i Processori XML
6 Notazione

Appendici

A Riferimenti
    A.1 Riferimenti Normativi
    A.2 Altri Riferimenti
B Classi di Carattere
C XML e SGML (Non-Normativo)
D Espansione dei Riferimenti di Entità e di Carattere (Non-Normativo)
E Modelli di Contenuto Deterministici (Non-Normative)
F Autorilevamento delle Codifiche di Carattere (Non-Normativo)
    F.1 Rilevamento Senza Informazione Esterna della Codifica
    F.2 Priorità nella Presenza di Informazioni della Codifica Esterne
G Gruppo di Lavoro per XML del W3C (Non-Normativo)
H Gruppo di Lavoro per XML Core del W3C (Non-Normativo)
I Note di Produzione (Non-Normativo)


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

1.1 Origine e Obiettivi

XML è stato sviluppato da un Gruppo di Lavoro per XML (in origine conosciuto come il Comitato di Revisione Editoriale {Editorial Review Board} di SGML) formato sotto l'egida del World Wide Web Consortium (W3C) nel 1996. È stato presieduto da Jon Bosak della Sun Microsystems con l'attiva partecipazione di un Gruppo di Interesse Speciale per XML {Special Interest Group} (conosciuto in precedenza come il Gruppo di Lavoro per SGML) anch'esso organizzato dal W3C. Le adesioni al Gruppo di Lavoro per XML vengono fornite in appendice. Dan Connolly ha svolto il ruolo di contatto fra il Gruppo di Lavoro e il W3C.

Gli obiettivi progettuali per XML sono:

  1. XML dovrebbe essere utilizzabile direttamente su Internet.

  2. XML dovrebbe supportare una vasta varietà di applicazioni.

  3. XML dovrebbe essere compatibile con SGML.

  4. Dovrebbe essere facile scrivere programmi che elaborano documenti XML.

  5. Il numero di caratteristiche facoltative in XML deve mantenersi al minimo assoluto, idealmente a zero.

  6. I documenti XML dovrebbero essere leggibili da esseri umani e ragionevolmente espliciti.

  7. La progettazione di XML dovrebbe essere approntata rapidamente.

  8. La progettazione di XML dovrebbe essere formale e concisa.

  9. I documenti XML dovrebbero essere facili da creare.

  10. Nella marcatura XML la concisione è di importanza minima.

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

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

1.2 Terminologia

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

errore

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

errore fatale

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

a facoltà dell'utente

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

vincolo di validità

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

vincolo di buona-formazione

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

corrispondenza

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

per compatibilità

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

per interoperabilità

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

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

2.1 Documenti XML Ben-Formati

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

  1. Preso per intero, corrisponde alla produzione etichettata come documento.

  2. Aderisce ai vincoli di buona-formazione forniti in questa specifica.

  3. Ciascuna delle entità parsed alla quale si fa riferimento direttamente o indirettamente all'interno del documento è ben-formata.

Documento
[1]    document    ::=    prolog element Misc*

Aderire alla produzione del documento implica che:

  1. Contiene uno o più elementi.

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

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

2.2 Caratteri

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

Intervalli di Carattere
[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)+

Nota:

La presenza di #xD nella precedente produzione è stata mantenuta puramente per compatibilità all'indietro con la Prima Edizione. Come spiegato in 2.11 Gestione del Fine-Riga, tutti i caratteri #xD presenti in modo letterale in un documento XML sono sia rimossi che rimpiazzati dai caratteri #xA prima che venga fatta qualsiasi altra elaborazione. L'unico modo per far sì che un carattere #xD aderisca a questa produzione è di usare un riferimento di carattere in un valore letterale di entità.

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 | Digit | '.' | '-' | '_' | ':' | CombiningChar | Extender
[5]    Name    ::=    (Letter | '_' | ':') (NameChar)*
[6]    Names    ::=    Name (#x20 Name)*
[7]    Nmtoken    ::=    (NameChar)+
[8]    Nmtokens    ::=    Nmtoken (#x20 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 Attributo).

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 | Reference)* '"'
|  "'" ([^%&'] | PEReference | Reference)* "'"
[10]    AttValue    ::=    '"' ([^<&"] | Reference)* '"'
|  "'" ([^<&'] | Reference)* "'"
[11]    SystemLiteral    ::=    ('"' [^"]* '"') | ("'" [^']* "'")
[12]    PubidLiteral    ::=    '"' PubidChar* '"' | "'" (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 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 "&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 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 "&apos;", e il carattere di doppie virgolette (") come "&quot;".

Dati Carattere
[14]    CharData    ::=    [^<&]* - ([^<&]* ']]>' [^<&]*)

2.5 Commenti

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

Commenti
[15]    Comment    ::=    '<!--' ((Char - '-') | ('-' (Char - '-')))* '-->'

Un esempio di commento:

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

Si noti che la grammatica non permette a un commento di terminare in --->. L'esempio seguente non è ben-formato.

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

2.6 Istruzioni di Processo

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

Istruzioni di Processo
[16]    PI    ::=    '<?' PITarget (S (Char* - (Char* '?>' Char*)))? '?>'
[17]    PITarget    ::=    Name - (('X' | 'x') ('M' | 'm') ('L' | 'l'))

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

2.7 Sezioni CDATA

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

Sezioni CDATA
[18]    CDSect    ::=    CDStart CData CDEnd
[19]    CDStart    ::=    '<![CDATA['
[20]    CData    ::=    (Char* - (Char* ']]>' Char*))
[21]    CDEnd    ::=    ']]>'

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 "&lt;" e "&amp;". Le sezioni CDATA non possono essere nidificate.

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

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

2.8 Prologo e Dichiarazione del Tipo di Documento

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

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

e così anche questo:

<greeting>Salve, mondo!</greeting>

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

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

Prologo
[22]    prolog    ::=    XMLDecl? Misc* (doctypedecl Misc*)?
[23]    XMLDecl    ::=    '<?xml' VersionInfo EncodingDecl? SDDecl? S? '?>'
[24]    VersionInfo    ::=    S 'version' Eq ("'" VersionNum "'" | '"' VersionNum '"')
[25]    Eq    ::=    S? '=' S?
[26]    VersionNum    ::=    '1.0'
[27]    Misc    ::=    Comment | PI | S

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

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

Definizione del Tipo di Documento
[28]    doctypedecl    ::=    '<!DOCTYPE' S Name (S ExternalID)? S? ('[' intSubset ']' S?)? '>' [VV: Tipo di Elemento Radice]
[VBF: Sotto-insieme esterno]
[28a]    DeclSep    ::=    PEReference | S [VBF: PE fra Dichiarazioni]
[28b]    intSubset    ::=    (markupdecl | DeclSep)*
[29]    markupdecl    ::=    elementdecl | AttlistDecl | EntityDecl | NotationDecl | PI | 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 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.

Vincolo di Validità: Tipo di Elemento Radice

Il Name nella dichiarazione di tipo di documento deve corrispondere al tipo di elemento dell'elemento radice.

Vincolo di Validità: Nidificazione Dichiarazione/PE appropriata

Il testo 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 un riferimento di entità-parametro, entrambi devono essere contenuti nello stesso testo sostitutivo.

Vincolo di Buona-Formazione: i PE nel Sotto-insieme Interno

Nel sotto-insieme di DTD interno, i riferimenti di entità-parametro non devono ricorrere all'interno di dichiarazioni di marcatura; essi potrebbero ricorrere dove possono ricorrere le dichiarazioni di marcatura. (Ciò non si applica ai riferimenti che ricorrono in entità parametro esterne o a sotto-insiemi esterni.)

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

Sotto-insieme Esterno
[30]    extSubset    ::=    TextDecl? extSubsetDecl
[31]    extSubsetDecl    ::=    ( markupdecl | conditionalSect | 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à-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.

2.9 Dichiarazione di Documento Autonomo

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

Dichiarazione di Documento Autonomo
[32]    SDDecl    ::=    S 'standalone' 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:

  • 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.0" standalone='yes'?>

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. Un processore XML validante inoltre deve informare l'applicazione di quali di questi caratteri costituisce lo spazio bianco che compare nel contenuto dell'elemento.

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

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

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

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

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

2.11 Gestione del Fine-Riga

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

Per semplificare i compiti delle applicazioni, il processore XML deve comportarsi come se avesse normalizzato tutte le interruzioni di riga in entità esterne parsed (inclusa l'entità documento) in ingresso, prima del parsing, traducendo 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:

<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ßem Bemü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

xml:lang CDATA #IMPLIED

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:lang potrebbe essere dichiarato in questo modo:

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

3 Strutture logiche

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

Elemento
[39]    element    ::=    EmptyElemTag
| STag content 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 Buona-Formazione: Corrispondenza del Tipo di Elemento

Il Name nel tag-di-fine di un elemento deve corrispondere al tipo di elemento nel tag-di-inizio.

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.

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 (S Attribute)* S? '>' [VBF: Att Spec Unico]
[41]    Attribute    ::=    Name Eq 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.

Vincolo di Buona-Formazione: Nessun < nei Valori d'Attributo

Il testo sostitutivo di una qualsiasi entità a cui ci si riferisca direttamente o indirettamente in un valore d'attributo non deve contenere un <.

Un esempio di tag-di-inizio:

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

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

Tag-di-fine
[42]    ETag    ::=    '</' Name S? '>'

Un esempio di tag-di-fine:

</termdef>

[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? ((element | Reference | CDSect | PI | Comment) CharData?)*

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

Tag per Elementi Vuoti
[44]    EmptyElemTag    ::=    '<' Name (S Attribute)* 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:

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

3.2 Dichiarazioni del Tipo di Elemento

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

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

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

Dichiarazione del Tipo di Elemento
[45]    elementdecl    ::=    '<!ELEMENT' S Name S contentspec S? '>' [VV: Dichiarazione Unica del Tipo di Elemento]
[46]    contentspec    ::=    'EMPTY' | 'ANY' | Mixed | children

dove il Name fornisce il tipo di elemento da dichiararsi.

Esempi di dichiarazioni del tipo di elemento:

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

3.2.1 Contenuto dell'Elemento

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

Modelli di contenuto d'elemento
[47]    children    ::=    (choice | seq) ('?' | '*' | '+')?
[48]    cp    ::=    (Name | choice | seq) ('?' | '*' | '+')?
[49]    choice    ::=    '(' S? cp ( S? '|' S? cp )+ S? ')' [VV: Nidificazione Appropriata di Gruppo/PE]
[50]    seq    ::=    '(' S? cp ( S? ',' S? cp )* S? ')' [VV: Nidificazione Appropriata di Gruppo/PE]

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;)*>

3.3 Dichiarazioni di Elenco-Attributo

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

  • Per definire l'insieme degli attributi pertinenti a un dato tipo di elemento.

  • Per stabilire i vincoli di tipo per questi attributi.

  • Per fornire valori predefiniti per gli attributi.

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

Dichiarazione di elenco-attributo
[52]    AttlistDecl    ::=    '<!ATTLIST' S Name AttDef* S? '>'
[53]    AttDef    ::=    S Name S AttType S 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.1 Tipi di Attributo

I tipi di attributo XML sono di tre specie: un tipo stringa, un insieme di tipi tokenized, e i tipi enumerati. Il tipo stringa accetta qualsiasi stringa letterale come valore; i tipi tokenized hanno vincoli lessicali e semantici che variano. I vincoli di validità annotati nella grammatica vengono applicati dopo che il valore di attributo è stato normalizzato come descritto in 3.3.3 Normalizzazione dei Valori-Attributo.

Tipi di Attributo
[54]    AttType    ::=    StringType | TokenizedType | EnumeratedType
[55]    StringType    ::=    'CDATA'
[56]    TokenizedType    ::=    'ID' [VV: ID]
[VV: Unico ID per Tipo di Elemento]
[VV: Attributo di ID Predefinito]
| 'IDREF' [VV: IDREF]
| 'IDREFS' [VV: IDREF]
| 'ENTITY' [VV: Nome di Entità]
| 'ENTITIES' [VV: Nome di Entità]
| 'NMTOKEN' [VV: Token di Name]
| 'NMTOKENS' [VV: Token di Name]

Vincolo di Validità: ID

I valori di tipo ID devono corrispondere alla produzione del Name. Un nome non deve comparire più di una volta in un documento XML come un valore di questo tipo; cioè, i valori ID devono identificare univocamente gli elementi che li portano.

Vincolo di Validità: IDREF

I valori di tipo IDREF devono corriposndere alla produzione del Name, e i valori di tipo IDREFS devono corrispondere a Names; ciascun Name deve corrispondere al valore di un attributo ID su qualche elemento nel documento XML; cioè i valori IDREF devono corrispondere al valore di qualche attributo ID.

Vincolo di Validità: Nome di Entità

I valori di tipo ENTITY devono corrispondere alla produzione del Name, i valori del tipo ENTITIES devono corrispondere a Names; ciascun Name deve corrispondere al nome di un'entità non parsed dichiarato nella DTD.

[Definizione: gli attributi enumerati devono prendere uno solo di un elenco di valori forniti nella dichiarazione]. Esistono due specie di tipi enumerati:

Tipi di Attributo Enumerato
[57]    EnumeratedType    ::=    NotationType | Enumeration
[58]    NotationType    ::=    'NOTATION' S '(' S? Name (S? '|' S? Name)* S? ')' [VV: Attributi di Notazione]
[VV: Una sola Notazione per Tipo di Elemento]
[VV: Nessuna Notazione per l'Elemento Vuoto]
[VV: Nessun Token Duplicato]
[59]    Enumeration    ::=    '(' S? Nmtoken (S? '|' S? Nmtoken)* S? ')' [VV: Enumerazione]
[VV: Nessun Token Duplicato]

Un attributo NOTATION identifica una notazione, dichiarata nella DTD con identificatori associati di sistema e/o pubblici, da usarsi nell'interpretare l'elemento al quale l'attributo è annesso.

Vincolo di Validità: Attributi di Notazione

I valori di questo tipo devono corrispondere a uno dei nomi di notazione inclusi nella dichiarazione; tutti i nomi di notazione nella dichiarazione devono essere dichiarati.

Vincolo di Validità: Nessuna Notazione per l'Elemento Vuoto

Per compatibilità, un attributo del tipo NOTATION non deve essere dichiarato per un elemento dichiarato EMPTY.

Per interoperabilità, lo stesso Nmtoken non dovrebbe ricorrere più di una volta nei tipi di attributo enumerato di un singolo tipo di elemento.

3.3.2 Valori Predefiniti di Attributo

Una dichiarazione di attributo fornisce informazioni sulla possibilità che la presenza dell'attributo sia Richiesta, e se no, come deve reagire un processore XML qualora un attributo dichiarato è assente in un documento.

Valori Predefiniti di Attributo
[60]    DefaultDecl    ::=    '#REQUIRED' | '#IMPLIED'
| (('#FIXED' S)? AttValue) [VV: Attributo Richiesto]
[VV: Valore Predefinito di Attributo Sintatticamente Corretto]
[VBF: Nessun < nei Valori di Attributo]
[VV: Valore Predefinito di Attributo Dichiarato "Fixed"]

In una dichiarazione di attributo, #REQUIRED significa che l'attributo deve sempre essere fornito, #IMPLIED che non è fornito alcun valore predefinito. [Definizione: Se la dichiarazione non è #REQUIRED#IMPLIED, allora il valore di AttValue contiene il valore predefinito dichiarato; la parola chiave #FIXED afferma che l'attributo  deve sempre avere il valore predefinito. Quando un processore XML incontra un elemento senza una specificazione per un attributo per il quale esso ha letto una dichiarazione di valore predefinito, esso deve restituire all'applicazione l'attributo con il valore predefinito dichiarato.]

Vincolo di Validità: Valore Predefinito di Attributo Sintatticamente Corretto

Il valore predefinito dichiarato deve rispettare i vincoli sintattici del tipo di attributo dichiarato. Cioè, il valore predefinito di un attributo:

Si noti che qui solo i vincoli sintattici del tipo sono richiesti; altri vincoli (ad es. che il valore sia il nome di un'entità unparsed dichiarata, per un attributo di tipo ENTITY) saranno riportati da un parser validante solo se ricorra effettivamente un elemento senza una specificazione per questo attributo.

Esempi di dichiarazioni di elenco-attributo:

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

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:

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

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

Specificazione di attributo a è NMTOKENS a è CDATA
a="

xyz"
x y z
#x20 #x20 x y z
a="&d;&d;A&a;&#x20;&a;B&da;"
A #x20 B
#x20 #x20 A #x20 #x20 #x20 B #x20 #x20
a=
"&#xd;&#xd;A&#xa;&#xa;B&#xd;&#xa;"
#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 a viene dichiarato essere di tipo NMTOKENS.

3.4 Sezioni Condizionali

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

Sezione Condizionale
[61]    conditionalSect    ::=    includeSect | ignoreSect
[62]    includeSect    ::=    '<![' S? 'INCLUDE' S? '[' extSubsetDecl ']]>' [VV: Nidificazione Appropriata Sezione Condizionale/PE]
[63]    ignoreSect    ::=    '<![' S? 'IGNORE' S? '[' ignoreSectContents* ']]>' [VV: Nidificazione Appropriata Sezione Condizionale/PE]
[64]    ignoreSectContents    ::=    Ignore ('<![' ignoreSectContents ']]>' Ignore)*
[65]    Ignore    ::=    Char* - (Char* ('<![' | ']]>') 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:

<!ENTITY % draft 'INCLUDE' >
<!ENTITY % final 'IGNORE' >

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

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

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

Riferimento di Entità
[67]    Reference    ::=    EntityRef | CharRef
[68]    EntityRef    ::=    '&' Name ';' [VBF: Entità Dichiarata]
[VV: Entità Dichiarata]
[VBF: Entità Parsed]
[VBF: Nessuna Ricorsività]
[69]    PEReference    ::=    '%' 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-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'.

Vincolo di Validità: Entità Dichiarata

In un documento con un sotto-insieme esterno o con i riferimenti di entità parametro esterne con "standalone='no'", il Name dato nel riferimento di entità deve corrispondere a quello in una dichiarazione di entità. Per interoperabilità, i documenti validi dovrebbero dichiarare le entità amp, lt, gt, apos, quot, nella forma specificata in 4.6 Entità Predefinite. La dichiarazione di un'entità parametro deve precedere qualsiasi riferimento ad essa. In modo similare, la dichiarazione di un'entità generale deve precedere qualsiasi dichiarazione di elenco-attributo contenente un valore predefinito con un riferimento diretto o indiretto a quell'entità generale.

Vincolo di Buona-Formazione: Entità Parsed

Un riferimento di entità non deve contenere il nome di un'entità non parsed. Si potrebbe fare riferimento a entità non parsed solo nei valori di attributo dichiarati essere del tipo ENTITY o ENTITIES.

Esempi di riferimenti di carattere e di entità:

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

Esempio di un riferimento di entità-parametro:

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

4.2 Dichiarazioni di Entità

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

Dichiarazione di Entità
[70]    EntityDecl    ::=    GEDecl | PEDecl
[71]    GEDecl    ::=    '<!ENTITY' S Name S EntityDef S? '>'
[72]    PEDecl    ::=    '<!ENTITY' S '%' S Name S PEDef S? '>'
[73]    EntityDef    ::=    EntityValue| (ExternalID NDataDecl?)
[74]    PEDef    ::=    EntityValue | ExternalID

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.

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 nel valore letterale di entità per produrre il corretto testo sostitutivo: vedi 4.5 Costruzione di Testo Sostitutivo per Entità Interna.

Un entità interna è un'entità parsed.

Esempio di una dichiarazione di entità interna:

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

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 SystemLiteral
| 'PUBLIC' S PubidLiteral S SystemLiteral
[76]    NDataDecl    ::=    S 'NDATA' S Name [VV: Notazione Dichiarata]

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

Vincolo di Validità: Notazione Dichiarata

Il Name deve corrispondere al nome dichiarato di una notazione.

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

4.3 Entità parsed

4.3.2 Entità Parsed Ben-Formate

L'entità documento è ben-formata se corrisponde alla produzione etichettata documento. Un'entità parsed generale esterna è ben-formata se corrisponde alla produzione etichettata extParsedEnt. Tutte le entità parametro esterne sono ben-formate per definizione.

Nota:

Solo le entità parsed alle quali si fa riferimento direttamente o indirettamente dall'interno del documento sono obbligate a essere ben-formate.

Entità Parsed Esterne Ben-Formate
[78]    extParsedEnt    ::=    TextDecl? content

Un'entità parsed generale interna è ben-formata se il suo testo sostitutivo corrisponde alla produzione etichettata contenuto. Tutte le entità parametro interne sono ben-formate per definizione.

Una conseguenza della buona-formazione nelle entità generali è che le strutture logiche e fisiche in un documento XML sono nidificate in modo appropriato; nessun tag-di-inizio, tag-di-fine, tag di elemento-vuoto, elemento, commento, istruzione di processo, riferimento di carattere, o riferimento di entità può iniziare in una entità e terminare in un'altra.

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 'encoding' Eq ('"' EncName '"' | "'" 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 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'?>

4.4 Trattamento del Processore XML di Entità e Riferimenti

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

Riferimento nel Contenuto

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

Riferimento nel Valore di Attributo

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

Ricorre come Valore di Attributo

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

Riferimento in Valore di Entità

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

Riferimento in DTD

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

.

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.1 Non Riconosciuto

Al di fuori della DTD, il carattere % non ha un significato speciale; quindi, ciò che sarebbe riferimento di entità parametro nella DTD, non viene riconosciuti come marcatura nel contenuto. In modo simile, i nomi delle entità non parsed non vengono riconosciuti eccetto quando compaiono nel valore di un attributo dichiarato in modo appropriato.

4.4.2 Incluso

[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&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 è incluso quando 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:

  • la comparsa di un riferimento di un'entità non parsed, eccetto nell'EntityValue in una dichiarazione di entità.

  • la comparsa di qualsiasi carattere o riferimento di entità generale nella DTD eccetto all'interno di un EntityValue o di un AttValue.

  • un riferimento a un'entità esterna in un valore di attributo.

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

mentre questo non lo è:

<!ENTITY EndAttr "27'" >
<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 sua notazione associata.

4.4.7 Aggirato

Quando un riferimento di entità generale compare nell'EntityValue in una dichiarazione di entità, esso deve essere aggirato e lasciato così com'è.

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 suo testo 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'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;" >

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:

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

4.7 Dichiarazioni di Notazione

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

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

Dichiarazioni di Notazione
[82]    NotationDecl    ::=    '<!NOTATION' S Name S (ExternalID | PublicID) S? '>' [VV: Nome Univoco di Notazione]
[83]    PublicID    ::=    'PUBLIC' S PubidLiteral

Vincolo di Validità: Nome Univoco di Notazione

Un dato Name non deve essere dichiarato in più di una singola dichiarazione di notazione.

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

4.8 Entità Documento

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

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

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.

6 Notazione

La grammatica formale di XML viene fornita in questa specifica usando una semplice notazione Extended Backus-Naur Form [N.d.T.: Forma Estesa di Backus-Naur] (EBNF). Ogni regola nella grammatica definisce un solo simbolo, nella forma

symbol ::= expression

I simboli sono scritti con una lettera iniziale maiuscola se sono il simbolo di partenza di un linguaggio regolare, altrimenti con una lettera iniziale minuscola. Le stringhe letterali sono virgolettate.

All'interno dell'espressione sul lato destro di una regola, le seguenti espressioni vengono usate per far corrispondere le stringhe a uno o più caratteri:

#xN

dove N è un intero esadecimale, l'espressione corrisponde al carattere il numero (punto codice) del quale è N in ISO/IEC 10646. Il numero di zeri iniziali nella forma #xN è insignificante.

[a-zA-Z], [#xN-#xN]

corrisponde a qualsiasi Char con un valore nell'intervallo/i indicati (estremi compresi).

[abc], [#xN#xN#xN]

corrsiponde a qualsiasi Char con un valore compreso fra i caratteri enumerati. Le enumerazioni e gli intervalli possono essere mischiati in un unico insieme di parentesi.

[^a-z], [^#xN-#xN]

corrisponde a qualsiasi Char con un valore al di fuori dell'intervallo indicato.

[^abc], [^#xN#xN#xN]

corrisponde a qualsiasi Char con un valore non compreso fra i caratteri dati. Le enumerazioni e gli intervalli di valori proibiti possono essere mischiati in un unico insieme di parentesi.

"string"

corrisponde a una stringa letterale corrispondente a ciò che è dato all'interno delle doppie virgolette.

'string'

corrisponde a una stringa letterale corrispondente a ciò che è dato all'interno delle singole virgolette.

Questi simboli potrebbero essere combinati per corrispondere a più schemi complessi come segue, dove A e B rappresentano le espressioni semplici:

(expression)

expression viene trattata come un'unità e potrebbe combinarsi come descritto in questo elenco.

A?

corrisponde ad A o niente; A facoltativa.

A B

corrisponde a A followed by B. This operator has higher precedence than alternation; thus A B | C D is identical to (A B) | (C D).

A | B

corrisponde ad A o B.

A - B

corrisponde a qualsiasi stringa che corrisponda ad A ma non corrisponda a B.

A+

corrisponde a una o più occorrenze di A. La concatenazione ha una precedenza maggiore dell'alternativa; così A+ | B+ è identico a (A+) | (B+).

A*

corrisponde a zero o più occorrenze di A. La concatenazione ha una precedenza maggiore dell'alternativa; così A* | B* è identico a (A*) | (B*).

Altre notazioni usate nelle produzioni sono:

/* ... */

commento.

[ vbf: ... ]

vincolo di buona-formazione; questo identifica per nome un vincolo su documenti ben-formati associati a una produzione.

[ vv: ... ]

vincolo di validità; questo identifica per nome un vincolo su documenti validi associati a una produzione.

A Riferimenti

A.1 Riferimenti Normativi

IANA-CHARSETS
(Internet Assigned Numbers Authority) Official Names for Character Sets, ed. Keld Simonsen et al. (Vedi http://www.iana.org/assignments/character-sets.)
IETF RFC 2119
IETF (Internet Engineering Task Force). RFC 2119: Key words for use in RFCs to Indicate Requirement Levels. Scott Bradner, 1997. (Vedi http://www.ietf.org/rfc/rfc2119.txt.)
IETF RFC 2396
IETF (Internet Engineering Task Force). RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax. T. Berners-Lee, R. Fielding, L. Masinter. 1998. (Vedi http://www.ietf.org/rfc/rfc2396.txt.)
IETF RFC 2732
IETF (Internet Engineering Task Force). RFC 2732: Format for Literal IPv6 Addresses in URL's. R. Hinden, B. Carpenter, L. Masinter. 1999. (Vedi http://www.ietf.org/rfc/rfc2732.txt.)
IETF RFC 3066
IETF (Internet Engineering Task Force). RFC 3066: Tags for the Identification of Languages, ed. H. Alvestrand. 2001. (Vedi http://www.ietf.org/rfc/rfc3066.txt.)
ISO/IEC 10646
ISO (International Organization for Standardization). ISO/IEC 10646-1:2000. Information technology — Universal Multiple-Octet Coded Character Set (UCS) — Part 1: Architecture and Basic Multilingual Plane and ISO/IEC 10646-2:2001. Information technology — Universal Multiple-Octet Coded Character Set (UCS) — Part 2: Supplementary Planes, come, di volta in volta, emendati, sostituiti da una nuova edizione o espansi dall'aggiunta di parti nuove. [Geneva]: International Organization for Standardization. (Vedi http://www.iso.ch/ per l'ultima versione.)
ISO/IEC 10646:2000
ISO (International Organization for Standardization). ISO/IEC 10646-1:2000. Information technology — Universal Multiple-Octet Coded Character Set (UCS) — Part 1: Architecture and Basic Multilingual Plane. [Geneva]: International Organization for Standardization, 2000.
Unicode
Il Consorzio Unicode. The Unicode Standard, Version 2.0. Reading, Mass.: Addison-Wesley Developers Press, 1996.
Unicode3
Il Consorzio Unicode. The Unicode Standard, Version 3.2, definita da: The Unicode Standard, Version 3.0 (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), come emendata dall' Unicode Standard Annex #27: Unicode 3.1 (http://www.unicode.org/reports/tr27/) e dall' Unicode Standard Annex #28: Unicode 3.2 (http://www.unicode.org/reports/tr28/).

A.2 Altri Riferimenti

Aho/Ullman
Aho, Alfred V., Ravi Sethi, and Jeffrey D. Ullman. Compilers: Principles, Techniques, and Tools. Reading: Addison-Wesley, 1986, rpt. corr. 1988.
Brüggemann-Klein
Brüggemann-Klein, Anne. Formal Models in Document Processing. Habilitationsschrift. Facoltà di Matematica presso l'Università di Friburgo, 1993. (Vedi ftp://ftp.informatik.uni-freiburg.de/documents/papers/brueggem/habil.ps.)
Brüggemann-Klein and Wood
Brüggemann-Klein, Anne, and Derick Wood. Deterministic Regular Languages. Universität Freiburg, Institut für Informatik, Bericht 38, Oktober 1991. Sintesi estesa in A. Finkel, M. Jantzen, Hrsg., STACS 1992, S. 173-184. Springer-Verlag, Berlin 1992. Lecture Notes in Computer Science 577. Versione completa intitolata One-Unambiguous Regular Languages in Information and Computation 140 (2): 229-253, Febbraio 1998.
Clark
James Clark. Comparison of SGML and XML. (Vedi http://www.w3.org/TR/NOTE-sgml-xml-971215.)
IANA-LANGCODES
(Internet Assigned Numbers Authority) Registry of Language Tags, ed. Keld Simonsen et al. (Vedi http://www.iana.org/assignments/language-tags.)
IETF RFC 2141
IETF (Internet Engineering Task Force). RFC 2141: URN Syntax, ed. R. Moats. 1997. (Vedi http://www.ietf.org/rfc/rfc2141.txt.)
IETF RFC 3023
IETF (Internet Engineering Task Force). RFC 3023: XML Media Types. eds. M. Murata, S. St.Laurent, D. Kohn. 2001. (Vedi http://www.ietf.org/rfc/rfc3023.txt.)
IETF RFC 2781
IETF (Internet Engineering Task Force). RFC 2781: UTF-16, an encoding of ISO 10646, ed. P. Hoffman, F. Yergeau. 2000. (Vedi http://www.ietf.org/rfc/rfc2781.txt.)
ISO 639
(International Organization for Standardization). ISO 639:1988 (E). Code for the representation of names of languages. [Geneva]: International Organization for Standardization, 1988.
ISO 3166
(International Organization for Standardization). ISO 3166-1:1997 (E). Codes for the representation of names of countries and their subdivisions — Part 1: Country codes [Geneva]: International Organization for Standardization, 1997.
ISO 8879
ISO (International Organization for Standardization). ISO 8879:1986(E). Information processing — Text and Office Systems — Standard Generalized Markup Language (SGML). First edition — 1986-10-15. [Geneva]: International Organization for Standardization, 1986.
ISO/IEC 10744
ISO (International Organization for Standardization). ISO/IEC 10744-1992 (E). Information technology — Hypermedia/Time-based Structuring Language (HyTime). [Geneva]: International Organization for Standardization, 1992. Extended Facilities Annexe. [Geneva]: International Organization for Standardization, 1996.
WEBSGML
ISO (International Organization for Standardization). ISO 8879:1986 TC2. Information technology — Document Description and Processing Languages. [Geneva]: International Organization for Standardization, 1998. (Vedi http://www.sgmlsource.com/8879/n0029.htm.)
XML Names
Tim Bray, Dave Hollander, e Andrew Layman, curatori. Namespaces in XML. Textuality, Hewlett-Packard, e Microsoft. World Wide Web Consortium, 1999. (Vedi http://www.w3.org/TR/REC-xml-names/.)

B Classi di Carattere

Seguendo le caratteristiche definite nello standard Unicode, i caratteri sono stati divisi in classi come caratteri di base (fra gli altri, questi contengono i caratteri alfabetici dell'alfabeto latino), caratteri ideografici, e caratteri combinanti (fra gli altri, questa classe contiene la maggior parte dei diacritici). Vengono anche distinti le cifre e gli estensori.

Caratteri
[84]    Letter    ::=    BaseChar | Ideographic
[85]    BaseChar    ::=    [#x0041-#x005A] | [#x0061-#x007A] | [#x00C0-#x00D6] | [#x00D8-#x00F6] | [#x00F8-#x00FF] | [#x0100-#x0131] | [#x0134-#x013E] | [#x0141-#x0148] | [#x014A-#x017E] | [#x0180-#x01C3] | [#x01CD-#x01F0] | [#x01F4-#x01F5] | [#x01FA-#x0217] | [#x0250-#x02A8] | [#x02BB-#x02C1] | #x0386 | [#x0388-#x038A] | #x038C | [#x038E-#x03A1] | [#x03A3-#x03CE] | [#x03D0-#x03D6] | #x03DA | #x03DC | #x03DE | #x03E0 | [#x03E2-#x03F3] | [#x0401-#x040C] | [#x040E-#x044F] | [#x0451-#x045C] | [#x045E-#x0481] | [#x0490-#x04C4] | [#x04C7-#x04C8] | [#x04CB-#x04CC] | [#x04D0-#x04EB] | [#x04EE-#x04F5] | [#x04F8-#x04F9] | [#x0531-#x0556] | #x0559 | [#x0561-#x0586] | [#x05D0-#x05EA] | [#x05F0-#x05F2] | [#x0621-#x063A] | [#x0641-#x064A] | [#x0671-#x06B7] | [#x06BA-#x06BE] | [#x06C0-#x06CE] | [#x06D0-#x06D3] | #x06D5 | [#x06E5-#x06E6] | [#x0905-#x0939] | #x093D | [#x0958-#x0961] | [#x0985-#x098C] | [#x098F-#x0990] | [#x0993-#x09A8] | [#x09AA-#x09B0] | #x09B2 | [#x09B6-#x09B9] | [#x09DC-#x09DD] | [#x09DF-#x09E1] | [#x09F0-#x09F1] | [#x0A05-#x0A0A] | [#x0A0F-#x0A10] | [#x0A13-#x0A28] | [#x0A2A-#x0A30] | [#x0A32-#x0A33] | [#x0A35-#x0A36] | [#x0A38-#x0A39] | [#x0A59-#x0A5C] | #x0A5E | [#x0A72-#x0A74] | [#x0A85-#x0A8B] | #x0A8D | [#x0A8F-#x0A91] | [#x0A93-#x0AA8] | [#x0AAA-#x0AB0] | [#x0AB2-#x0AB3] | [#x0AB5-#x0AB9] | #x0ABD | #x0AE0 | [#x0B05-#x0B0C] | [#x0B0F-#x0B10] | [#x0B13-#x0B28] | [#x0B2A-#x0B30] | [#x0B32-#x0B33] | [#x0B36-#x0B39] | #x0B3D | [#x0B5C-#x0B5D] | [#x0B5F-#x0B61] | [#x0B85-#x0B8A] | [#x0B8E-#x0B90] | [#x0B92-#x0B95] | [#x0B99-#x0B9A] | #x0B9C | [#x0B9E-#x0B9F] | [#x0BA3-#x0BA4] | [#x0BA8-#x0BAA] | [#x0BAE-#x0BB5] | [#x0BB7-#x0BB9] | [#x0C05-#x0C0C] | [#x0C0E-#x0C10] | [#x0C12-#x0C28] | [#x0C2A-#x0C33] | [#x0C35-#x0C39] | [#x0C60-#x0C61] | [#x0C85-#x0C8C] | [#x0C8E-#x0C90] | [#x0C92-#x0CA8] | [#x0CAA-#x0CB3] | [#x0CB5-#x0CB9] | #x0CDE | [#x0CE0-#x0CE1] | [#x0D05-#x0D0C] | [#x0D0E-#x0D10] | [#x0D12-#x0D28] | [#x0D2A-#x0D39] | [#x0D60-#x0D61] | [#x0E01-#x0E2E] | #x0E30 | [#x0E32-#x0E33] | [#x0E40-#x0E45] | [#x0E81-#x0E82] | #x0E84 | [#x0E87-#x0E88] | #x0E8A | #x0E8D | [#x0E94-#x0E97] | [#x0E99-#x0E9F] | [#x0EA1-#x0EA3] | #x0EA5 | #x0EA7 | [#x0EAA-#x0EAB] | [#x0EAD-#x0EAE] | #x0EB0 | [#x0EB2-#x0EB3] | #x0EBD | [#x0EC0-#x0EC4] | [#x0F40-#x0F47] | [#x0F49-#x0F69] | [#x10A0-#x10C5] | [#x10D0-#x10F6] | #x1100 | [#x1102-#x1103] | [#x1105-#x1107] | #x1109 | [#x110B-#x110C] | [#x110E-#x1112] | #x113C | #x113E | #x1140 | #x114C | #x114E | #x1150 | [#x1154-#x1155] | #x1159 | [#x115F-#x1161] | #x1163 | #x1165 | #x1167 | #x1169 | [#x116D-#x116E] | [#x1172-#x1173] | #x1175 | #x119E | #x11A8 | #x11AB | [#x11AE-#x11AF] | [#x11B7-#x11B8] | #x11BA | [#x11BC-#x11C2] | #x11EB | #x11F0 | #x11F9 | [#x1E00-#x1E9B] | [#x1EA0-#x1EF9] | [#x1F00-#x1F15] | [#x1F18-#x1F1D] | [#x1F20-#x1F45] | [#x1F48-#x1F4D] | [#x1F50-#x1F57] | #x1F59 | #x1F5B | #x1F5D | [#x1F5F-#x1F7D] | [#x1F80-#x1FB4] | [#x1FB6-#x1FBC] | #x1FBE | [#x1FC2-#x1FC4] | [#x1FC6-#x1FCC] | [#x1FD0-#x1FD3] | [#x1FD6-#x1FDB] | [#x1FE0-#x1FEC] | [#x1FF2-#x1FF4] | [#x1FF6-#x1FFC] | #x2126 | [#x212A-#x212B] | #x212E | [#x2180-#x2182] | [#x3041-#x3094] | [#x30A1-#x30FA] | [#x3105-#x312C] | [#xAC00-#xD7A3]
[86]    Ideographic    ::=    [#x4E00-#x9FA5] | #x3007 | [#x3021-#x3029]
[87]    CombiningChar    ::=    [#x0300-#x0345] | [#x0360-#x0361] | [#x0483-#x0486] | [#x0591-#x05A1] | [#x05A3-#x05B9] | [#x05BB-#x05BD] | #x05BF | [#x05C1-#x05C2] | #x05C4 | [#x064B-#x0652] | #x0670 | [#x06D6-#x06DC] | [#x06DD-#x06DF] | [#x06E0-#x06E4] | [#x06E7-#x06E8] | [#x06EA-#x06ED] | [#x0901-#x0903] | #x093C | [#x093E-#x094C] | #x094D | [#x0951-#x0954] | [#x0962-#x0963] | [#x0981-#x0983] | #x09BC | #x09BE | #x09BF | [#x09C0-#x09C4] | [#x09C7-#x09C8] | [#x09CB-#x09CD] | #x09D7 | [#x09E2-#x09E3] | #x0A02 | #x0A3C | #x0A3E | #x0A3F | [#x0A40-#x0A42] | [#x0A47-#x0A48] | [#x0A4B-#x0A4D] | [#x0A70-#x0A71] | [#x0A81-#x0A83] | #x0ABC | [#x0ABE-#x0AC5] | [#x0AC7-#x0AC9] | [#x0ACB-#x0ACD] | [#x0B01-#x0B03] | #x0B3C | [#x0B3E-#x0B43] | [#x0B47-#x0B48] | [#x0B4B-#x0B4D] | [#x0B56-#x0B57] | [#x0B82-#x0B83] | [#x0BBE-#x0BC2] | [#x0BC6-#x0BC8] | [#x0BCA-#x0BCD] | #x0BD7 | [#x0C01-#x0C03] | [#x0C3E-#x0C44] | [#x0C46-#x0C48] | [#x0C4A-#x0C4D] | [#x0C55-#x0C56] | [#x0C82-#x0C83] | [#x0CBE-#x0CC4] | [#x0CC6-#x0CC8] | [#x0CCA-#x0CCD] | [#x0CD5-#x0CD6] | [#x0D02-#x0D03] | [#x0D3E-#x0D43] | [#x0D46-#x0D48] | [#x0D4A-#x0D4D] | #x0D57 | #x0E31 | [#x0E34-#x0E3A] | [#x0E47-#x0E4E] | #x0EB1 | [#x0EB4-#x0EB9] | [#x0EBB-#x0EBC] | [#x0EC8-#x0ECD] | [#x0F18-#x0F19] | #x0F35 | #x0F37 | #x0F39 | #x0F3E | #x0F3F | [#x0F71-#x0F84] | [#x0F86-#x0F8B] | [#x0F90-#x0F95] | #x0F97 | [#x0F99-#x0FAD] | [#x0FB1-#x0FB7] | #x0FB9 | [#x20D0-#x20DC] | #x20E1 | [#x302A-#x302F] | #x3099 | #x309A
[88]    Digit    ::=    [#x0030-#x0039] | [#x0660-#x0669] | [#x06F0-#x06F9] | [#x0966-#x096F] | [#x09E6-#x09EF] | [#x0A66-#x0A6F] | [#x0AE6-#x0AEF] | [#x0B66-#x0B6F] | [#x0BE7-#x0BEF] | [#x0C66-#x0C6F] | [#x0CE6-#x0CEF] | [#x0D66-#x0D6F] | [#x0E50-#x0E59] | [#x0ED0-#x0ED9] | [#x0F20-#x0F29]
[89]    Extender    ::=    #x00B7 | #x02D0 | #x02D1 | #x0387 | #x0640 | #x0E46 | #x0EC6 | #x3005 | [#x3031-#x3035] | [#x309D-#x309E] | [#x30FC-#x30FE]

Le classi di carattere qui definite possono essere derivate dal database di caratteri di Unicode 2.0 come segue:

  • I caratteri che iniziano il Name devono avere una sola delle categorie Ll, Lu, Lo, Lt, Nl.

  • I caratteri di nome diversi dai caratteri che iniziano il Name devono avere una delle categorie Mc, Me, Mn, Lm, or Nd.

  • I caratteri nell'area di compatibilità (cioè il codice di carattere maggiore di #xF900 e minore di #xFFFE) non sono permessi nei nomi di XML.

  • I caratteri che possiedono una decomposizione di tipo o di compatibilità (cioè quelli con un'"etichetta di formato di compatibilità nel campo 5 del database -- marcata dal campo 5 che inizia con un "<") non sono consentiti.

  • I seguenti caratteri vengono trattati come caratteri che iniziano il Name piuttosto che come caratteri di nome, perché il file di proprietà li classifica come Alphabetic: [#x02BB-#x02C1], #x0559, #x06E5, #x06E6.

  • I caratteri #x20DD-#x20E0 sono esclusi (in accordo con 2.0, sezione 5.14).

  • Il carattere #x00B7 viene classificato come un estensore, perché l'elenco di proprietà lo identifica così.

  • Il carattere #x0387 viene aggiunto come un carattere di nome, perché #x00B7 è il suo equivalente canonico.

  • I caratteri ':' e '_' sono consentiti come caratteri che iniziano Name.

  • I caratteri '-' e '.' sono consentiti come caratteri di nome.

C XML e SGML (Non-Normativo)

XML viene progettato per essere un sotto-insieme di SGML, perciò ogni documento XML dovrebbe anche essere un documento conforme a SGML. Per una comparazione dettagliata delle restrizioni aggiuntive che XML pone sui documenti al di là di quelle di SGML, vedi [Clark].

D Espansione dei Riferimenti di Entità e di Carattere (Non-Normativo)

Questa appendice contiene alcuni esempi che illustrano il riconoscimento e l'espansione delle sequenza di riferimento di carattere e di entità, come specificato in 4.4 Trattamento del Processore XML di Entità e di Riferimenti.

Se la DTD contiene la dichiarazione

<!ENTITY example "<p>Una e commerciale (&#38;#38;) potrebbe essere codificata in caratteri escape
numerici (&#38;#38;#38;) o con un'entità generale
(&amp;amp;).</p>" >

allora il processore XML riconoscerà i riferimenti di carattere quando effettua il parsing della dichiarazione di entità, e li risolve prima di allocare la seguente stringa come il valore dell'entità "example":

<p>Una e commerciale (&#38;) potrebbe essere codificata in caratteri escape
numerici (&#38;#38;) o con un'entità generale
(&amp;amp;).</p>

Un riferimento a "&example;" nel documento causerà la ri-effettuazione del parsing sul testo, momento nel quale i tag-di-inizio e -di-fine dell'elemento p saranno riconosciuti e i tre riferimenti saranno riconosciuti ed espansi, risultando in un elemento p con il seguente contenuto (tutti i dati, nessun delimitatore o marcatura):

Una e commerciale (&) potrebbe essere codificata in caratteri escape
numerici (&#38;) o con un'entità generale
(&amp;).

Un esempio più complesso illustrerà in pieno le regole e i loro effetti. Nell'esempio seguente, i numeri di riga vengono messi solamente a scopo di riferimento.

1 <?xml version='1.0'?>
2 <!DOCTYPE test [
3 <!ELEMENT test (#PCDATA) >
4 <!ENTITY % xx '&#37;zz;'>
5 <!ENTITY % zz '&#60;!ENTITY trucchetto "fallace" >' >
6 %xx;
7 ]>
8 <test>Questa prova mostra un metodo &trucchetto;.</test>

Questo produce ciò che segue:

E Modelli di Contenuto Deterministici (Non-Normativo)

Come notato 3.2.1 Contenuto di Elemento, viene richiesto che i modelli di contenuto delle dichiarazioni del tipo di elemento siano deterministici. Questo requisito è per compatibilità con SGML (che chiama i modelli di contenuto deterministici "non ambigui"); i processori XML costruiti usando i sistemi SGML potrebbero segnare i modelli di contenuto non-deterministici come errori.

Per esempio, il modello di contenuto ((b, c) | (b, d)) è non-deterministico, perché data una b iniziale, il processore XML non può sapere a quale b nel modello si debba corrispondere senza guardare avanti per vedere quale elemento venga appresso alla b. In questo caso, i due riferimenti a b possono comprimersi in un singolo riferimento, facendosi leggere nel modello(b, (c | d)). Ora una b iniziale corrisponde chiaramente a un singolo nome nel modello di contenuto. il processore non ha bisogno di guardare avanti per vedere quel che viene appresso; sia c che d sarebbero accettati.

In modo più formale: un'automazione di stato finito potrebbe essere ricostruita dal modello di contenuto usando gli algoritmi standard, ad es. l'algoritmo 3.5 nella sezione 3.9 di Aho, Sethi, e Ullman [Aho/Ullman]. In molti di tali algoritmi, viene costruito un insieme di successioni per ogni posizione nell'espressione regolare (cioè, ogni nodo-foglia nell'albero della sintassi per l'espressione regolare); se una qualsiasi posizione ha un insieme di successioni nel quale più di una posizione successiva è stata etichettata con lo stesso nome del tipo di elemento, allora il modello di contenuto è in errore e potrebbe essere riportato come un errore.

Esistono algoritmi che consentono a molti, ma non a tutti i modelli di contenuto non-deterministici di essere automaticamente ridotti ai modelli deterministici equivalenti; vedi Brüggemann-Klein 1991 [Brüggemann-Klein].

F Autorilevamento delle Codifiche di Carattere (Non-Normativo)

La dichiarazione di codifica XML funziona come un'etichetta interna su ogni entità, indicante quale codifica di carattere sia in uso. Prima che un processore XML possa leggere l'etichetta interna, comunque, apparentemente deve sapere quale codifica di carattere sia in uso — che è ciò che l'etichetta interna sta tentando di indicare. Nel caso generale, questa è una situazione senza speranza. Non è completamente senza speranza in XML, comunque, perché XML limita il caso generale in due modi: si presume che ogni implementazione supporti un insieme finito di codifiche di carattere,e la dichiarazione di codifica XML è ristretta nella posizione e nel contenuto allo scopo di rendere possibile che essa auto-rilevi la codifica di carattere in uso in ogni entità nei casi normali. Inoltre in molti casi sono disponibili altre fonti di informazione in aggiunta al flusso di dati XML stesso. Si potrebbero distinguere due casi, a seconda se l'entità XML sia presentata al processore senza, o con, una qualsiasi informazione di accompagnamento (esterna). Consideriamo innanzitutto il primo caso.

F.1 Rilevamento Senza Informazioni sulla Codifica Esterna

Poiché ogni entità XML non accompagnata da informazioni sulla codifica esterna e non nella codifica UTF-8 o nella UTF-16 deve iniziare con una dichiarazione di codifica XML, nel quale il primo carattere deve essere '<?xml', qualsiasi processore conforme può rilevare, dopo due o quattro ottetti di dati in ingresso, quale fra i casi seguenti vada applicato. Nel leggere l'elenco, potrebbe aiutare sapere che in UCS-4, '<' è "#x0000003C" e '?' è "#x0000003F", e il Segno di Ordine di Byte richiesto dal flusso di dati UTF-16 è "#xFEFF". La notazione ## viene usata per denotare qualsiasi valore di byte eccetto per il fatto che due ## consecutivi non possono essere entrambi 00.

Con un Segno di Ordine di Byte:

00 00 FE FF UCS-4, macchina big-endian (ordine 1234)
FF FE 00 00 UCS-4, macchina little-endian (ordine 4321)
00 00 FF FE UCS-4, ordine di ottetto non usuale (2143)
FE FF 00 00 UCS-4, ordine di ottetto non usuale (3412)
FE FF ## ## UTF-16, big-endian
FF FE ## ## UTF-16, little-endian
EF BB BF UTF-8

Senza un Segno di Ordine di Byte:

00 00 00 3C La UCS-4 o altre codifiche con un'unità di codice a 32-bit e caratteri ASCII codificati come valori ASCII, rispettivamente in big-endian (1234), little-endian (4321) e due ordini di byte non usuali (2143 and 3412). Deve essere letta la dichiarazione di codifica per determinare quale codifica a 32-bit si applichi fra la UCS-4 o le altre supportate.
3C 00 00 00
00 00 3C 00
00 3C 00 00
00 3C 00 3F La UTF-16BE o la big-endian ISO-10646-UCS-2 o altra codifica con un'unità di codice a 16-bit in ordine big-endian e i caratteri ASCII codificati come valori ASCII (deve essere letta la dichiarazione di codifica per determinare quale)
3C 00 3F 00 La UTF-16LE o la little-endian ISO-10646-UCS-2 o altra codifica di un'unità di codice a 16-bit in ordine little-endian e i caratteri ASCII codificati come valori ASCII (deve essere letta la dichiarazione di codifica per determinare quale)
3C 3F 78 6D La UTF-8, la ISO 646, l'ASCII, alcune parti della ISO 8859, la Shift-JIS, la EUC, o qualsiasi altra codifica a 7-bit, a 8-bit, o a grandezza-mista che assicuri che i caratteri ASCII abbiano la loro posizione, grandezza e valori normali; deve essere letta la dichiarazione di codifica corrente per rilevare quale fra queste si applichi, ma dal momento che tutte queste codifiche fanno uso degli stessi modelli di bit per i relativi caratteri ASCII, la dichiarazione di codifica stessa potrebbe essere letta in modo affidabile
4C 6F A7 94 La EBCDIC (in alcune varianti; deve essere letta la dichiarazione di codifica completa per dire quale pagina di codice sia in uso)
Altro La UTF-8 senza una dichiarazione di codifica, o altrimenti il flusso dati viene mal etichettato (mancando un dichiarazione di codifica obbligatoria), oppure viene corrotto, frammentato o racchiuso in un qualche tipo di involucro

Nota:

Nei casi sopra esposti che non richiedono la lettura della dichiarazione di codifica per determinare la codifica, la sezione 4.3.3 richiede ancora che la dichiarazione della codifica, se presente, venga letta e che venga verificato che il nome della codifica corrisponda alla codifica corrente dell'entità. Inoltre, è possibile che saranno inventate nuove codifiche di carattere che renderanno necessario usare la dichiarazione di codifica per determinare la codifica, nei casi in cui ciò al momento non è richiesto.

Questo livello di auto-rilevazione è sufficiente per leggere la dichiarazione di codifica XML ed effettuare il parsing dell'identificatore della codifica di carattere, che è ancora necessario per distinguere i membri individuali di ciascuna famiglia di codifiche (ad es. la UTF-8 dalla 8859, e le parti della 8859 l'una dall'altra, o per distinguere la pagina di codice specifica di EBCDIC, e così via).

Poiché i contenuti della dichiarazione di codifica sono limitati ai caratteri dal repertorio ASCII (comunque codificato), un processore può leggere in modo affidabile l'intera dichiarazione della codifica non appena abbia rilevato quale famiglia di codifiche sia in uso. Dal momento che in pratica, tutte le codifiche maggiormente usate ricadono all'interno di una delle categorie di cui sopra, la dichiarazione di codifica XML permette un'etichettatura delle codifiche di carattere ragionevolmente affidabile e accurata, perfino quando non siano affidabili le fonti di informazione esterne al sistema operativo o al livello del protocollo di trasporto. Le codifiche di carattere come la UTF-7 che fa un uso sovraccaricato di byte valorizzati ASCII potrebbe non essere rilevata in modo affidabile.

Una volta che il processore ha rilevato la codifica di carattere in uso, può agire in modo appropriato, o invocando una routine di ingresso separata per ogni caso, o chiamando la funzione di conversione propria di ogni carattere in ingresso.

Come qualsiasi sistema di auto-etichettatura, la dichiarazione di codifica XML non funzionerà se un qualunque software cambi l'insieme o la codifica di caratteri dell'entità senza aggiornare la dichiarazione di codifica. Chi implementa le routine della codifica di carattere dovrebbe aver cura di assicurare l'accuratezza delle informazioni interne ed esterne utilizzate per etichettare l'entità.

F.2 Priorità nella Presenza di Informazioni della Codifica Esterne

Il secondo caso possibile ricorre quando l'entità XML viene accompagnata dalle informazioni di codifica, come in alcuni file system e alcuni protocolli di rete. Quando sono disponibili molteplici fonti di informazione, dovrebbero essere specificati la loro relativa priorità e il metodo preferito di gestire i conflitti come parti del livello più alto del protocollo usato per consegnare l'XML. In particolare, si prega di far riferimento a [IETF RFC 3023] o sue successive, la quale definisce i tipi MIME text/xml e application/xml e fornisce alcune guide utili. Negli interessi dell'interoperabilità, comunque, viene raccomandata la regola seguente.

  • Se un'entità XML è in un file, vengono usati il Segno di Ordine di Byte e la dichiarazione di codifica (se presenti) per determinare la codifica di carattere.

G Gruppo di Lavoro per XML del W3C (Non-Normativo)

Questa specifica è stata preparata e approvata per la pubblicazione dal Gruppo di Lavoro (WG) per XML del W3C. L'approvazione del WG di questa specifica non implica necessariamente che tutti i membri del WG abbiano votato per la sua approvazione. I partecipanti attuali e precedenti del WG per XML WG sono:

  • Jon Bosak, Sun (Presidente)
  • James Clark (Guida Tecnica)
  • Tim Bray, Textuality and Netscape (Co-curatore XML)
  • Jean Paoli, Microsoft (XML Co-editor)
  • C. M. Sperberg-McQueen, U. di Ill. (Co-curatore XML)
  • Dan Connolly, W3C (Rapporto con il W3C)
  • Paula Angerstein, Texcel
  • Steve DeRose, INSO
  • Dave Hollander, HP
  • Eliot Kimber, ISOGEN
  • Eve Maler, ArborText
  • Tom Magliery, NCSA
  • Murray Maloney, SoftQuad, Grif SA, Muzmo and Veo Systems
  • MURATA Makoto (FAMILY Given), Fuji Xerox Information Systems
  • Joel Nava, Adobe
  • Conleth O'Connell, Vignette
  • Peter Sharpe, SoftQuad
  • John Tigue, DataChannel

H Gruppo di Lavoro per XML Core del W3C (Non-Normativo)

La terza edizione di questa specifica è stata preparata dal Gruppo di Lavoro (WG) per XML Core del W3C. I partecipanti del WG al tempo della pubblicazione di questa edizione erano:

  • Leonid Arbouzov, Sun Microsystems
  • Mary Brady
  • John Cowan
  • John Evdemon, Microsoft
  • Andrew Fang, Arbortext
  • Paul Grosso, Arbortext (Co-Presidente)
  • Arnaud Le Hors, IBM
  • Dmitry Lenkov, Oracle
  • Anjana Manian, Oracle
  • Glenn Marcy, IBM
  • Jonathan Marsh, Microsoft
  • Sandra Martinez, NIST
  • Liam Quin, W3C (Contatto dello Staff)
  • Lew Shannon
  • Richard Tobin, Università di Edimburgo
  • Daniel Veillard
  • Norman Walsh, Sun Microsystems (Co-Presidente)
  • François Yergeau (Curatore della Terza Edizione)

I Note di Produzione (Non-Normativo)

Questa Terza Edizione è stata codificata in una versione leggermente modificata della XMLspec DTD, v2.5. Le versioni XHTML sono state prodotte con una combinazione dei fogli di stile XSLT xmlspec.xsl, diffspec.xsl, e REC-xml-3e.xsl.