[This local archive copy is from the official and canonical URL, http://www.iat.cnr.it/xml/REC-xml-19980210-it.html; please refer to the canonical source document if possible.]

REC-xml-19980210-it

REC-xml-19980210-it

Extensible Markup Language (XML) 1.0

Questo documento è una copia tradotta della Raccomandazione del W3C "Extensible Markup Language (XML) 1.0"
Questo documento può contenere errori di traduzione.
La normativa, in lingua inglese, è a disposizione presso: http://www.w3.org/TR/1998/REC-xml-19980210.
Questo documento può essere trovato a: http://www.iat.cnr.it/xml/REC-xml-19980210-it.html

Traduttore

Copyright ©  1998 W3C (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply. /P>

Questo documento: Copyright © IAT-CNR, tutti i diritti di questa traduzione sono riservati

Ogni errore trovato in questa traduzione può essere segnalato a <Andrea.Marchetti@iat.cnr.it>


W3C REC-xml-19980210


Extensible Markup Language (XML) 1.0

Questa versione:

http://www.w3.org/TR/1998/REC- xml-19980210
http://www.w3.org/TR/1998/ REC-xml-19980210.xml
http://www.w3.org/TR/1998 /REC-xml-19980210.html
http://www.w3.org/TR/1998/ REC-xml-19980210.pdf
http://www.w3.org/TR/1998/R EC-xml-19980210.ps

Versione attuale:

http://www.w3.org/TR/REC-xml

Versione precedente:

http://www.w3.org/TR/PR-xml-971208

Editori:

Tim Bray (Textuality and Netscape) <tbray@textuality.com>
Jean Paoli (Microsoft) <jeanpa@microsoft.com>
C. M. Sperberg-McQueen (University of Illinois at Chicago) <cmsmcq@uic.edu>

Abstract

Extensible Markup Language (XML) è un sottoinsieme di SGML, e sarà completamente descritto in questo documento. Il suo obiettivo è quello di consentire ad un generico documento SGML di essere fornito, ricevuto e elaborato su Web nel modo in cui adesso è possibile con HTML. XML è stato progettato nell'ottica di una facile implementazione e per l'interoperabilità sia con SGML che con HTML

Stato di questo documento

Questo documento è stato rivisto dai membri del W3C e da altri gruppi interessati ed è stato approvato dal Direttore come una raccomandazione del W3C. È un documento stabile e può essere usato come materiale di riferimento da un altro documento. Il ruolo del W3C nel fare la Raccomandazione è quello di segnalare all'attenzione le specifiche e di promuoverne l' impiego più ampio e diffuso. Questo incrementa la funzionalità e l'interoperabilità del Web.

Questo documento specifica una sintassi creata estraendo un sottoinsieme da uno standard di elaborazione di testi largamente usato a livello internazionale (Standard Generalized Markup Language, ISO 8879:1986(E) come rivisto e corretto) per un uso sul World Wide Web. È un prodotto della attività su XML del W3C, i cui dettagli possono essere trovati a http://www.w3.org/XML. Una lista delle Raccomandazioni W3C e di altri documenti tecnici possono essere trovati a http://www.w3.org/TR.

Queste specifiche usano il termine URI, che è stato definito da [Berners-Lee et al.], un lavoro non ancora terminato e che aggiornerà  [IETF RFC1738] e [IETF RFC1808].

La lista degli errori noti presenti in queste specifiche è disponibile a http://www.w3.org/XML/xml-19980 210-errata.

Per favore riportare gli errori trovati in questo documento a xml-editor@w3.org.

Tabella dei contenuti

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 Character Data e Markup
    2.5 Commenti
    2.6 Istruzioni di elaborazione
    2.7 Sezioni CDATA
    2.8 Prologo e Document Type Declaration
    2.9 Dichiarazione di documento "standalone"
    2.10 Trattamento degli spazi bianchi
    2.11 Trattamento degli End-of-Line
    2.12 Identificazione del Linguaggio
3. Strutture logiche
    3.1 Tag-di-inizio, tag-di-fine, e tag degli elementi vuoti
    3.2 Dichiarazioni di "Element Type"
        3.2.1 Contenuto di soli elementi
        3.2.2 Contenuto misto
    3.3 Dichiarazioni di lista di attributi
        3.3.1 Tipi di attributo
        3.3.2 Default di attributo
        3.3.3 Normalizzazione del valore dell'attributo
    3.4 Sezioni condizionali
4. Strutture fisiche
    4.1 Riferimenti a carattere e entità
    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 dei caratteri nelle entità
    4.4 Come un processore XML tratta le entità e i riferimenti a entità
        4.4.1 Non riconosciuto
        4.4.2 Incluso
        4.4.3 Incluso se validante
        4.4.4 Proibito
        4.4.5 Incluso nel letterale
        4.4.6 Notificare
        4.4.7 Oltrepassato
        4.4.8 Incluso come un' entità parametrica
    4.5 Costruzione del testo di sostituzione delle 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 Uso dei processori XML
6. Notazione

Appendici

A. Riferimenti
    A.1 Riferimenti alle normative
    A.2 Altri riferimenti
B. Classi di caratteri
C. XML e SGML (non-normativo)
D. Espansione dei riferimenti a entità e a carattere (non-normativo)
E. Modelli di contenuto deterministici (non-normativo)
F. Rilevamento automatico della codifica dei caratteri (non-normativo)
G. Gruppo di lavoro XML del W3C (non-normativo)

1. Introduzione

Extensible Markup Language, abbreviato XML, descrive una classe di dati chiamati documenti XML e descrive parzialmente il comportamento dei programmi che li elaborano. XML è un profilo di applicazione o forma ristretta di SGML, lo Standard Generalized Markup Language [ISO 8879]. Per la loro struttura, i documenti XML sono conformi ai documenti SGML.

I documenti XML sono costituiti da unità di memoria dette entità, che contengono sia dati analizzati che non analizzati. I dati analizzati sono costituiti da caratteri, alcuni dei quali formano i character data, e alcuni i markup. I markup codificano una descrizione dell' organizzazione di memorizzazione e della struttura logica del documento. XML fornisce un meccanismo per imporre dei vincoli sull' organizzazione di memorizzazione e sulla struttura logica.

Un modulo software detto processore XML viene usato per leggere documenti XML e fornire l'accesso al loro contenuto e alla loro struttura. Si presuppone che un processore XML farà il suo lavoro per conto di un altro modulo, che viene chiamato applicazione. Queste specifiche descrivono il comportamento che un processore XML deve tenere nel leggere i dati XML e l' informazione che deve fornire all' applicazione.

1.1 Origine e obiettivi

XML fu sviluppato da XML Working Group (originariamente noto come SGML Editorial Review Board) costituitosi sotto gli auspici del World Wide Web Consortium (W3C) nel 1996. Esso era presieduto da Jon Bosak della Sun Microsystems con la partecipazione attiva dell' XML Special Interest Group (precedentemente noto come SGML Working Group) anch'esso organizzato dal W3C. I membri del XML Working Group sono segnalati in una appendice. Dan Connolly fece da intermediario tra WG e W3C.

Gli obiettivi progettuali di XML sono:

  1. XML deve essere utilizzabile in modo semplice su Internet.
  2. XML deve supportare un gran numero di applicazioni.
  3. XML deve essere compatibile con SGML.
  4. Deve essere facile lo sviluppo di programmi che elaborino documenti XML.
  5. Il numero di caratteristiche opzionali deve essere mantenuto al minimo possibile, idealmente a zero.
  6. I documenti XML dovrebbero essere leggibili da un uomo e ragionevolmente chiari.
  7. La progettazione XML dovrebbe essere rapida.
  8. La progettazione XML deve essere formale e concisa.
  9. I documenti XML devono essere facili da creare.
  10. Non è di nessuna importanza l'economicità nel markup XML.

Queste specifiche, insieme agli standard associati (Unicode e ISO/IEC 10646 per i caratteri, Internet RFC 1766 per i tag di identificazione del linguaggio, ISO 639 per i codici dei nomi dei linguaggi, e ISO 3166 per i codici dei nomi dei paesi), forniscono tutte le informazioni necessarie per comprendere la versione 1.0 di XML e per costruire programmi per elaborarlo.

Questa versione delle specifiche XML può essere distribuita liberamente, fintanto che tutto il testo e le osservazioni legali rimangano intatte.

1.2 Terminologia

La terminologia usata per descrivere i documenti XML è definita nel corpo di queste specifiche. I termini definiti nella lista seguente sono usati nella costruzione delle definizioni e nella descrizione delle azioni di un processore XML:

può (may)
Documenti conformi e processori XML possono aderire al comportamento descritto ma la cosa non è obbligatoria.
deve (must)
Documenti conformi e processori XML devono aderire al comportamento descritto; altrimenti sono in errore.
errore (error)
Una violazione delle regole di queste specifiche; i risultati sono indefiniti. Il software conforme può rilevare e riportare un errore e può recuperare da esso.
errore fatale (fatal error)
Un errore che un processore XML conforme deve rilevare e segnalare all'applicazione. Dopo aver incontrato un errore fatale, il processore XML può continuare l'elaborazione dei dati per cercare ulteriori errori e può segnalare tali errori all'applicazione. Per essere di ausilio alla correzione degli errori, il processore può restituire all'applicazione i dati non elaborati del documento (con character data e markup mischiati). Una volta che un errore fatale viene rilevato, tuttavia, il processore non deve continuare la normale elaborazione (cioè, non deve continuare a passare character data e informazione sulla struttura logica del documento all'applicazione nel modo normale).
a opzione dell'utente (at user option)
Software conforme può o deve (dipende dall'ausiliare presente nella affermazione) comportarsi come descritto; se lo fa, deve fornire all'utente i mezzi per abilitare o disabilitare il comportamento descritto.
vincolo di validità (validity constraint)
Una regola che si applica a tutti i documenti validi XML. Le violazioni dei vincoli di validità sono errori; essi devono, a opzione dell'utente, essere segnalati dai processori XML validanti.
vincolo di ben-formatezza (well-formedness constraint)
Una regola che si applica a tutti i documenti XML ben-formati. Le violazioni ai vincoli well-formedness sono errori fatali.
essere concorde con (match)
(Di stringhe o nomi:) Due stringhe o due nomi che confrontati devono risultare identici. Caratteri che possono avere molteplici rappresentazioni in ISO/IEC 10646 (e.g. caratteri con forme sia precomposte che base+diacritic) sono concordi solo se hanno la stessa rappresentazione in entrambe le stringhe. A opzione dell'utente, i processori possono normalizzare tali caratteri in qualche forma canonica. Nessun "case folding" è eseguito. (Di stringhe e regole nella grammatica:) Una stringa è concorde con una produzione grammaticale se appartiene al linguaggio generato da quella produzione. (Di contenuto e di modelli di contenuto:) Un elemento è concorde con la sua dichiarazione quando si conforma nel modo descritto nel vincolo "Elemento valido".
per compatibilità (for compatibility)
Una caratteristica di XML inclusa unicamente per garantire che XML rimanga compatibile con SGML.
per interoperabilità (for interoperability)
Una raccomandazione non vincolante inclusa per aumentare le possibilità che i documenti XML possano essere elaborati dalla base di processori SGML installati e esistenti prima dell'annesso a ISO 8879 sulle modifiche del WebSGML (WebSGML Adaptations Annex to ISO 8879).

2. Documenti

Un dato è un documento XML se è ben-formato, come definito in queste specifiche. Un documento XML ben-formato può in aggiunta essere valido se esso rispetta certi altri vincoli.

Ciascun documento XML ha una struttura logica e fisica. Fisicamente, il documento è composto di unità dette entità. Un entità può indirizzare altre entità per includerle nel documento. Un documento inizia con una "radice" o entità documento. Logicamente, il documento è composto di dichiarazioni, elementi, commenti, riferimenti a caratteri, e istruzioni di elaborazione, ciascuno dei quali è indicato nel documento da espliciti markup. Le struttura logica e quella fisica devono annidarsi propriamente come descritto nella sezione "4.3.2 Entità analizzate ben-formate (Well-Formed Parsed Entities)".

2.1 Documenti XML ben-formati

Un oggetto testuale è un documento ben-formato se:

  1. Preso nel suo complesso, è concorde con la produzione etichettata document.
  2. Rispetta tutti i vincoli "well-formedness" espressi in queste specifiche.
  3. Ciascuna entità analizzata che viene riferita direttamente o indirettamente all'interno del documento risulta ben-formata.
Documento
[1]  document ::=  prolog element Misc*
 

Essere concordi con la produzione document implica che:
  1. Il documento contiene uno o più elementi.
  2. C'è un solo elemento, detto radice, o "document element", di cui nessuna parte occorre nel contenuto di qualche altro elemento. Per tutti gli altri elementi, se il tag di partenza si trova nel contenuto di un altro elemento allora anche il tag di fine si trova nel contenuto dello stesso elemento. Più semplicemente si può dire che, gli elementi, delimitati dal tag-di-inizio e dal tag-di-fine si annidano uno dentro l'altro.
Come conseguenza di questo, per ciascun elemento C non-radice presente nel documento, ce ne è un altro P tale che C è nel contenuto di P, ma non si trova nel contenuto di altri elementi che stanno nel contenuto di P. P è detto genitore di C, e C è detto figlio di P.

2.2 Caratteri

Una entità analizzata (parsed entity) contiene testo, cioè una sequenza di caratteri, che possono rappresentare sia "markup" che "character data".
Un carattere è una unità atomica di testo come specificato da ISO/IEC 10646 [ISO/IEC 10646]. I caratteri "tab", "carriage return", "line feed", e i caratteri grafici legali di Unicode e di ISO/IEC 10646 sono tutti caratteri legali. L'uso di caratteri di compatibilità (compatibility characters), come definito nella sezione 6.8 di [Unicode], è scoraggiato.
 
Rango dei caratteri
[2]  Char ::=  #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF] /*  qualsiasi carattere Unicode, esclusi i blocchi surrogati, FFFE, e FFFF. */
 

Il meccanismo per codificare il codice dei caratteri in combinazioni particolari di bit può variare da entità a entità. Tutti i processori XML devono accettare le codifiche UTF-8 e UTF-16 del 10646; i meccanismi per specificare quale dei due è in uso, o per portare altre codifiche in gioco, sono discusse più tardi, nella sezione "4.3.3 La codifica dei caratteri nelle entità".

2.3 Costrutti sintattici comuni

Questa sezione definisce alcuni simboli che poi verranno usati largamente nella grammatica.

S (spazio bianco) consiste di uno o più "space character" (#x20), "carriage return", "line feed", o "tab".
 
Spazio bianco
[3]  S ::=  (#x20 | #x9 | #xD | #xA)+
 

I caratteri sono classificati per convenienza come lettere, cifre, o altri caratteri. Le lettere consistono di un carattere di base alfabetico o sillabico possibilmente seguito da uno o più caratteri combinanti, oppure consistono di un carattere ideografico. Le definizioni complete dei caratteri specifici in ciascuna classe sono fornite in Appendice B. Classi di caratteri".

Un Nome è un "token" che inizia con una lettera o con uno dei pochi caratteri di punteggiatura, e continua con lettere, cifre, trattini, caratteri di sottolineatura, due punti, o punti, tutti insieme noti come "namechar". I nomi inizianti con la stringa "xml", o qualsiasi stringa del tipo (('X'|'x') ('M'|'m') ('L'|'l')), sono riservati per la standardizzazione in queste specifiche o nelle versioni future.

Nota: Il carattere "due punti" all'interno dei nomi XML è riservato per la sperimentazione dei "namespaces". Il suo significato sta per essere standardizzato in qualche data futura, a quel punto tutti quei documenti che hanno usato i due punti per scopi sperimentali potranno avere bisogno di essere aggiornati. (Infatti non c'è nessuna garanzia che il meccanismo adottato da XML userà proprio i due punti come delimitatore di "name-space"). In pratica, questo significa che gli autori non dovrebbero usare i due punti all'interno dei nomi XML eccetto come parte di esperimenti sui namespaces, ma i processori XML dovrebbero accettare i due punti come un "namechar".

Un Nmtoken (name token) è una qualsiasi combinazione di "namechar".
 
Nomi e Token
[4]  NameChar ::=  Letter | Digit | '.' | '-' | '_' | ':' | CombiningChar | Extender
[5]  Name ::=  (Letter | '_' | ':') (NameChar)*
[6]  Names ::=  Name (S Name)*
[7]  Nmtoken ::=  (NameChar)+
[8]  Nmtokens ::=  Nmtoken (S Nmtoken)*
 

Il dato letterale è una qualsiasi stringa di caratteri tra apici non contenente il carattere usato come delimitatore per quella stringa. I letterali sono usati per specificare il contenuto di entità interne (EntityValue), il valore degli attributi (AttValue), e gli identificatori esterni (SystemLiteral). Notare che un SystemLiteral può essere analizzato senza verificare la presenza di markup.
 
Dati 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] |Ý[-'()+,./:=?;!*#@$_%]
 

2.4 Character Data e Markup

Il Testo consiste di character data e markup mescolati. I markup prendono la forma di tag-di-inizio, tag-di-fine, tag di elemento-vuoto, riferimenti a entità, riferimenti a carattere, commenti, delimitatori di sezione CDATA, dichiarazione di document type, e istruzioni di elaborazione (processing instructions).

Tutto il testo che non è markup costituisce i character data del documento.

La e-commerciale (&) e la parentesi angolare sinistra (<) possono apparire nella loro forma letterale soltanto quando sono usati come delimitatori di markup, oppure all'interno di un commento, di una istruzione di elaborazione, o di una CDATA section. Inoltre sono ammessi all'interno del value entity letterale di una dichiarazione di entità interna; vedi sezione "4.3.2 Entità analizzate ben-formate". Se sono necessari da altre parti, allora devono essere "escaped" usando o i riferimenti numerici ai caratteri oppure usando rispettivamente le stringhe "&amp;" e "&lt;". La parentesi angolare destra (>) può essere rappresentata usando la stringa "&gt;", e deve, per compatibilità, essere "escaped" usando o la stringa "&gt;" o il riferimento a carattere quando appare nella stringa "]]>", allorquando tale stringa non stia marcando la fine di una sezione CDATA.

Nel contenuto degli elementi, i "character data" sono qualsiasi stringa di caratteri che non contenga il delimitatore di partenza di un qualsiasi markup. In una sezione CDATA, i "character data" sono qualsiasi stringa di caratteri che non includa il delimitatore di chiusura della sezione CDATA, "]]>".

Per consentire ai valori degli attributi di contenere sia gli apici che i doppi apici, l'apostrofo o carattere di apice (') può essere rappresentato come "&apos;", e il doppio apice (") come "&quot;".
 
Character Data
[14]  CharData ::=  [^<&]* - ([^<&]* ']]>' [^<&]*)
 

2.5 Commenti

I Commenti possono apparire ovunque in un documento fuorché all'interno degli altri markup; in aggiunta, possono apparire all'interno della "Document Type Declaration" nei luoghi consentiti dalla grammatica. Non fanno parte dei character data del documento; un processore XML può, ma non necessariamente, far si che una applicazione possa recuperare il testo contenuto nei commenti. Per compatibilità, la stringa"--" (doppio trattino) non deve capitare all'interno dei commenti.
 
Commenti
[15]  Comment ::=  '<!--' ((Char - '-') | ('-' (Char - '-')))* '-->'
 

Un esempio di commento:
 
<!-- dichiarazione per <head> & <body> -->

2.6 Istruzioni di elaborazione (Processing Intruction)

Le istruzioni di elaborazione (PIs) consentono ai documenti di contenere delle istruzioni per le applicazioni.
 
Istruzioni di elaborazione
[16]  PI ::=  '<?' PITarget (S (Char* - (Char* '?>' Char*)))? '?>'
[17]  PITarget ::=  Name - (('X' | 'x') ('M' | 'm') ('L' | 'l'))
 

Le PI non fanno parte dei character data del documento, ma devono essere fornite all'applicazione. Le PI iniziano con un "obiettivo" (PITarget) usato per identificare l'applicazione a cui l'istruzione è diretta. I nomi di obiettivi "XML", "xml", e simili, sono riservati per la standardizzazione in queste specifiche e nelle versioni future. Il meccanismo delle Notazioni XML può essere usato come dichiarazione formale degli obiettivi delle PI.

2.7 Sezioni CDATA

Le sezioni CDATA possono capitare ovunque capitino i character data; esse sono usate per inserire senza che siano interpretati (escape) blocchi di testo contenenti caratteri che altrimenti sarebbero riconosciuti come markup. Le sezioni CDATA iniziano con la stringa "<![CDATA[" e terminano 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 markup, per cui sia la parentesi angolare sinistra (<) che la e-commerciale (&) possono capitare nella loro forma letterale; essi non hanno bisogno (e non possono) di essere "escaped" usando "&lt;" e "&amp;". Le sezioni CDATA non possono annidarsi.

Un esempio di sezione CDATA, in cui "<greeting>" e "</greeting>" sono riconosciuti come character data, e non come markup:
 
<![CDATA[<greeting>Hello, world!</greeting>]]>

2.8 Prologo e Document Type Declaration

I documenti XML possono, e dovrebbero, iniziare con una dichiarazione XML che specifica la versione XML utilizzata. Ad esempio, il seguente è un documento XML completo, ben-formato ma non valido:
 
<?xml version="1.0"?>
<greeting>Hello, world!</greeting>

ed altrettanto è il seguente:
 
<greeting>Hello, world!</greeting>

Il numero di versione "1.0" dovrebbe essere usato per indicare la conformità a questa versione di specifiche; è un errore per un documento usare il valore "1.0" se esso non è conforme a questa versione di specifiche. È nell'intento del gruppo di lavoro XML di produrre nuove versioni di queste specifiche oltre la "1.0", ma questa intenzione non indica un impegno a produrre una qualsiasi versione futura di XML, né se saranno prodotte, ad usare un qualche particolare schema di numerazione. Poiché non sono escluse versioni future, questo costrutto viene fornito come un mezzo per avere un riconoscimento automatico della versione, dovesse questo divenire necessario. I processori XML possono segnalare un errore se essi ricevono documenti etichettati con versioni che non supportano.

La funzione dei markup in un documento XML è quella di descrivere la sua organizzazione fisica e logica e quella di associare coppie di attributi-valore ai suoi componenti logici. XML fornisce un meccanismo, il document type declaration, per definire i vincoli sulla struttura logica e per supportare l'uso di unità di memoria predefinite.
Un qualsiasi documento XML è valido se ha associato un "document type declaration" e se il documento rispetta i vincoli in esso espressi.

Il "document type declaration" deve apparire prima del primo elemento del 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 ::=  ([a-zA-Z0-9_.:] | '-')+
[27]  Misc ::=  Comment | PIS
 

Il document type declaration di XML contiene oppure punta alle dichiarazioni dei markup le quali forniscono una grammatica per una classe di documenti. Questa grammatica è conosciuta come "document type definition", o DTD. La "document type declaration" può puntare a un sottoinsieme esterno (un genere speciale di entità esterna) contenente le dichiarazioni dei markup, oppure può contenere direttamente le dichiarazioni dei markup in un sottoinsieme interno, oppure può fare entrambe le cose. Il DTD per un documento è formato dall'unione dei due sottoinsiemi.

Una dichiarazione di markup è una dichiarazione di elemento, una dichiarazione di lista di attributi, una dichiarazione di entità, o una dichiarazione di notazione. Queste dichiarazioni possono essere contenute interamente o in parte all'interno di entità parametriche, come descritto sotto nei vincoli di ben-formato e validità. Per informazioni più complete, vedere il capitolo "4. Strutture fisiche".
 
Document Type Definition
[28]  doctypedecl ::=  '<!DOCTYPE' S Name (S ExternalID)? S? ('[' (markupdecl | PEReference | S)* ']' S?)? '>' VC: Root Element Type ]
[29]  markupdecl ::=  elementdecl | AttlistDecl | EntityDecl | NotationDecl | PI | Comment VC: Proper Declaration/PE Nesting ]
WFC: PEs in Internal Subset ]
 

La dichiarazione dei markup può essere costituita interamente o in parte dal testo di sostituzione delle entità parametriche. Le successive regole di produzione in queste specifiche per ciascun non-terminale (elementdecl, AttlistDecl, e così via) descrivono le dichiarazioni dopo che tutte le entità parametriche sono state incluse

Vincolo di validità: "Element Type" della radice
Il Name nel "document type declaration" deve coincidere con "element type" dell' elemento radice.

Vincolo di validità: Dichiarazione propria / annidamento delle PE
Il testo di sostituzione delle entità-parametriche deve essere annidato propriamente con le dichiarazioni dei markup. Cioè a dire, se il primo carattere o l'ultimo di una dichiarazione di markup (vedi sopra markupdecl) è contenuto nel testo di sostituzione associato ad un riferimento di entità parametrica, entrambi devono essere contenuti nel medesimo testo di sostituzione.

Vincoli di ben-formato: Le PE nel sottoinsieme interno
Nei sottoinsiemi dei DTD interni, i riferimenti alle entità-parametriche possono capitare solo dove capitano le dichiarazioni dei markup, non all'interno delle dichiarazioni di markup. (Questo non si applica ai riferimenti che capitano nelle entità-parametriche esterne o al sottoinsieme esterno.)

Come il sottoinsieme interno, quello esterno e qualsiasi entità parametrica esterna riferita nel DTD devono consistere di una serie di dichiarazioni di markup complete del tipo consentito dal simbolo non-terminale markupdecl, mischiate con spazi bianchi o con riferimenti a entità-parametriche. Tuttavia, porzioni dei contenuti del sottoinsieme esterno o delle entità-parametriche esterne possono condizionalmente essere ignorate usando il costrutto della sezione condizionale; questo non è consentito nel sottoinsieme interno.
 
Sottoinsieme Esterno
[30]  extSubset ::=  TextDecl? extSubsetDecl
[31]  extSubsetDecl ::=  ( markupdecl | conditionalSect | PEReference | S )*
 

Inoltre il sottoinsieme esterno e le entità parametriche esterne differiscono dal sottoinsieme interno in quanto nei primi i riferimenti a entità-parametriche sono permessi anche all'interno delle dichiarazioni di markup, non solo tra le dichiarazioni dei markup.

Un esempio di documento XML con document type declaration:
 
<?xml version="1.0"?>
<!DOCTYPE greeting SYSTEM "hello.dtd">
<greeting>Hello, world!</greeting>

L' identificatore di sistema "hello.dtd" fornisce l' URI di un DTD per il documento.

Le dichiarazioni possono essere date anche localmente, come in questo esempio:
 
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE greeting [
  <!ELEMENT greeting (#PCDATA)>
]>
<greeting>Hello, world!</greeting>

Nel caso in cui sia il sottoinsieme esterno che quello interno siano usati, il sottoinsieme interno è considerato prima del sottoinsieme esterno. Questo comporta che le dichiarazioni delle entità e delle liste degli attributi nel sottoinsieme interno hanno la precedenza sopra quelle contenute nel sottoinsieme esterno.

2.9 Dichiarazione di documento "standalone"

Le dichiarazione dei markup possono influire sul contenuto del documento, quando questo è passato da un processore XML ad una applicazione. La dichiarazione di documento "standalone", che può figurare come un componente della dichiarazione XML, segnala se ci sono o no tali dichiarazioni che sono esterne all' entità documento.
 
Dichiarazione di documento "standalone"
[32]  SDDecl ::=  S 'standalone' Eq (("'" ('yes' | 'no') "'") | ('"' ('yes' | 'no') '"'))  VC: Standalone Document Declaration ]
 

In una dichiarazione di documento "standalone", il valore "yes" indica che non ci sono dichiarazioni di markup esterne all' entità documento (sia nel sottoinsieme esterno del DTD, o in un'entità parametrica esterna referenziata dal sottoinsieme interno) che influenzano l'informazione passata dal processore XML all'applicazione. Il valore "no" indica che ci sono o che ci possono essere dichiarazioni esterne di markup. Notare che la dichiarazione di documento "standalone" denota solo la presenza di dichiarazioni esterne; la presenza, in un documento, di riferimenti a entità esterne, quando quelle entità sono dichiarate internamente, non cambia il suo stato di "standalone".

Se non ci sono dichiarazioni esterne di markup, la dichiarazione di documento "standalone" non ha nessun significato. Se ci sono dichiarazioni esterne di markup ma non c'è nessuna dichiarazione di documento "standalone", si assume il valore "no".

Qualsiasi documento per cui standalone="no" può essere convertito algoritmicamente ad un documento "standalone", che può essere desiderabile per alcune applicazioni di consegna su rete.

Vincolo di validità: Dichiarazione di documento "standalone"
La dichiarazione di documento "standalone" deve avere il valore "no" se qualsiasi dichiarazione esterna di markup contenga dichiarazioni di:

Un esempio di dichiarazione XML con una dichiarazione di documento "standalone"
 
<?xml version="1.0" standalone='yes'?>

2.10 Trattamento degli spazi bianchi

Nella redazione di documenti XML, è spesso conveniente usare "spazi bianchi" (spazi, tabulazioni, e linee bianche, denotate in queste specifiche dal non terminale S) per distinguere i markup ed ottenere una maggiore leggibilità. Tipicamente questi spazi bianchi non sono intesi per una inclusione nella versione distribuita del documento. D'altra parte, spazi bianchi "significativi" che dovrebbero essere conservati sono comuni per esempio nella poesia e nel codice sorgente.

Un processore XML deve sempre passare all'applicazione tutti i caratteri presenti in un documento che non siano markup. Un processore XML validante deve inoltre informare l'applicazione quali di questi caratteri costituiscono spazi bianchi che figurano in element content (contenuti di soli elementi).

Un attributo speciale chiamato xml:space può essere attaccato ad un elemento per segnalare un'intenzione che in quell'elemento, gli spazi bianchi dovrebbero essere preservati dalle applicazioni. Nei documenti validi, questo attributo, come ogni altro, deve essere dichiarato se usato. Quando è dichiarato, gli deve essere assegnato il tipo enumerato i cui possibili valori sono solo "default" e "preserve". Per esempio:
 
    <!ATTLIST poem   xml:space (default|preserve) 'preserve'>

Il valore "default" segnala che i modi di default di elaborazione degli spazi bianchi da parte dell'applicazione sono accettabili per questo elemento; il valore "preserve" indica l'intento che le applicazioni conservino tutti gli spazi bianchi. Questa intenzione dichiarata si estende a tutti gli elementi interni al contenuto dell'elemento in cui è specificata, a meno che non sia soprascritta da un'altra istanza dell'attributo xml:space.

L' elemento radice di qualsiasi documento, per default, non segnala all'applicazione alcuna intenzione a proposito del trattamento degli spazi bianchi, a meno che fornisca un valore per questo attributo oppure che l'attributo sia dichiarato con un valore di default.

2.11 Trattamento del fine-riga

Le entità parsed XML sono spesso memorizzate su file che, per convenienza di editing, sono organizzati in linee. Queste linee sono tipicamente separate da qualche combinazione dei caratteri di carriage-return (#xD) e line-feed (#xA).

Per semplificare i compiti delle applicazioni, dovunque una entità parsed esterna o il valore letterale di una parsed entity interna contenga o la sequenza letterale dei due caratteri "#xD#xA" o un isolato #xD, un processore XML deve passare all'applicazione il singolo carattere #xA. (Questo comportamento può essere convenientemente prodotto normalizzando in ingresso tutti i line break a #xA , prima di analizzarli.)

2.12 Identificazione del linguaggio

Nell'elaborazione di un documento, spesso è utile identificare il linguaggio naturale o formale in cui il contenuto è scritto. Uno attributo speciale chiamato xml:lang può essere inserito nei documenti per specificare il linguaggio usato nei contenuti e nei valori degli attributi di ogni elemento di un documento XML. Nei documenti validi, questo attributo, come ogni altro, se è usato deve essere dichiarato. I valori di questo attributo sono gli identificatori di linguaggio come definiti da [IETF RFC 1766], "Tag per la identificazione dei linguaggi":
 
Identificazione del linguaggio
[33]  LanguageID ::=  Langcode ('-' Subcode)*
[34]  Langcode ::=  ISO639CodeIanaCodeUserCode
[35]  ISO639Code ::=  ([a-z] | [A-Z]) ([a-z] | [A-Z])
[36]  IanaCode ::=  ('i' | 'I') '-' ([a-z] | [A-Z])+
[37]  UserCode ::=  ('x' | 'X') '-' ([a-z] | [A-Z])+
[38]  Subcode ::=  ([a-z] | [A-Z])+
 

Il Langcode può essere uno dei seguenti:

Ci possono essere qualsiasi numero di segmenti Subcode; se il primo segmento subcode esiste e il Subcode consiste di due lettere, allora deve essere un codice di paese da [ISO 3166], "Codici per la rappresentazione dei nomi di paesi." Se il primo subcode consiste di più di due lettere, deve essere un subcode per il linguaggio in questione registrato con lo IANA, a meno che il Langcode inizi con il prefisso "x-" o "X-".

È abitudine scrivere il codice di linguaggio in minuscolo, e il codice di paese (se presente) in maiuscolo. Da notare che questi valori, a differenza degli altri nomi nei documenti XML sono "case insensitive".

Ad 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 portata della dichiarazione xml:lang si estende a tutti gli attributi e al contenuto dell'elemento in cui è specificata, a meno che non sia soprascritta da un'altra istanza di xml:lang di un altro elemento interno a quel contenuto.

Una semplice dichiarazione per xml:lang potrebbe prendere la forma
 
xml:lang  NMTOKEN  #IMPLIED

ma valori di default specifici possono anche essere dati, se appropriati. In una raccolta di poemi francesi per studenti inglesi, con voci di glossario e note in inglese, l'attributo xml:lang potrebbe essere dichiarato in questo modo:
 
    <!ATTLIST poem   xml:lang NMTOKEN 'fr'>
    <!ATTLIST gloss  xml:lang NMTOKEN 'en'>
    <!ATTLIST note   xml:lang NMTOKEN 'en'>

3. Strutture logiche

Ciascun documento XML contiene uno o più elementi, i cui confini sono delimitati da un tag-di-inizio e da un tag-di-fine, oppure, per gli elementi vuoti, da un tag di elemento vuoto. Ciascun elemento ha un tipo, identificato da un nome, talvolta detto il suo "generic identifier" (GI), e può avere un insieme di specifiche di attributi. Ciascuna specifica di attributo ha un nome e un valore.
 
Elemento
[39]  element ::=  EmptyElemTag
| STag content ETag WFC: Element Type Match ]
VC: Element Valid ]
 

Questa specifica non vincola la semantica, l'uso, o (al di sopra della sintassi) i nomi degli "element type" e degli attributi, ad eccezione dei nomi che iniziano con (('X'|'x')('M'|'m')('L'|'l')) che sono riservati per la standardizzazione in questa o nelle versioni future di queste specifiche.

Vincolo di ben-formato: corrispondenza di "element type"
Il Name nel tag-di-fine di un elemento deve essere uguale all' "element type" contenuto nel tag-di-inizio.

Vincolo di validità: Elemento valido
Un elemento è valido se esiste una dichiarazione che rispetta la produzione elementdecl dove il Name corrisponde al tipo di elemento, e si verifica una delle seguenti condizioni:

  1. La dichiarazione corrisponde a EMPTY e l'elemento non ha nessun contenuto.
  2. La dichiarazione corrisponde a children e la sequenza di elementi figlio appartiene al linguaggio generato dall'espressione regolare che si trova nel modello di contenuto, con gli opzionali spazi bianchi (caratteri che corrispondono al non terminale S) tra ciascuna coppia di elementi figlio.
  3. La dichiarazione corrisponde a Mixed e il contenuto consiste di character data e elementi figlio il cui tipo corrisponde ai nomi presenti nel modello di contenuto.
  4. La dichiarazione corrisponde a ANY, e sono stati dichiarati i tipi di qualsiasi elemento figlio.

3.1 Tag-di-inizio, tag-di-fine, e tag degli elementi vuoti

L'inizio di ogni elemento XML non vuoto è indicato da un tag-di-inizio.
 
Tag-di-inizio
[40]  STag ::=  '<' Name (S Attribute)* S? '>' WFC: Unique Att Spec ]
[41]  Attribute ::=  Name Eq AttValue VC: Attribute Value Type ]
WFC: No External Entity References ]
WFC: No < in Attribute Values ]
 

Il Name nel tag-di-inizio e nel tag-di-fine fornisce il tipo dell'elemento. La coppia Name-AttValue sono riferiti come le specifiche dell'attributo dell'elemento, con il Name in ciascuna coppia riferito come nome dell'attributo e il contenuto dell' AttValue (il testo tra i delimitatori ' o ") come il valore dell'attributo.

Vincolo di ben-formato: Specifica di attributo unico (Unique Att Spec)
Nessun nome di attributo può apparire più di una volta nello stesso tag-di-inizio o nel tag di elemento vuoto

Vincolo di validità: Tipo del valore dell' attributo
L'attributo deve essere stato dichiarato; il valore deve essere del tipo dichiarato. (Per i tipi degli attributi, vedere la sezione "3.3 Dichiarazione lista degli attributi".)

Vincolo di ben-formato: Nessun riferimento ad entità esterna
I valori degli attributi non possono contenere riferimenti diretti o indiretti a entità esterne.

Vincolo di ben-formato: Nessun carattere < nel valore degli attributi
The testo di sostituzione di qualsiasi entità riferita direttamente o indirettamente in un valore di attributo (a parte "&lt;") non deve contenere il carattere <.

Un esempio di un tag-di-inizio:
 
<termdef id="dt-dog" term="dog">

La fine di ciascun elemento che inizia con un tag-di-inizio deve essere marcata da un tag-di-fine contenente un nome che ripete il tipo dell'elemento come dato nel tag-di-inizio.
 
Tag-di-fine
[42]  ETag ::= '</' Name S? '>'
 

Un esempio di tag-di-fine:
 
</termdef>

Il testo tra il tag-di-inizio e il tag-di-fine viene chiamato contenuto dell'elemento:
 
Contenuto degli elementi
[43]  content ::=  (element | CharData | Reference | CDSect | PI | Comment)*
 

Se un elemento è vuoto, deve essere rappresentato da un tag-di-inizio immediatamente seguito da un tag-di-fine oppure da un tag di elemento-vuoto. Un tag di elemento vuoto ha una forma speciale:
 
Tag per elementi vuoti
[44]  EmptyElemTag ::=  '<' Name (S Attribute)* S? '/>' WFC: Unique Att Spec ]
 

I tag di elementi vuoti possono essere usati per qualsiasi elemento che non ha contenuto, sia che sia stato o meno dichiarato usando la parola chiave EMPTY. Per interoperabilità, il tag di elemento vuoto deve essere usato, e può solo essere usato, per gli elementi che sono stati dichiarati EMPTY.

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

3.2 Dichiarazioni di "Element Type"

La struttura di un elemento di un documento XML può, per scopi di validazione, essere vincolata usando dichiarazioni di element type e attribute-list. Una dichiarazione di element type vincola il contenuto dell'elemento.

Le dichiarazioni dell' element type spesso vincolano quali element type possono apparire come figli dell'elemento. A scelta dell'utente, un processore XML può avvisare quando una dichiarazione menziona un element type per cui non è stata fornita nessuna dichiarazione, ma questo non è un errore.

Una dichiarazione di element type prende la forma:
 
Dichiarazione di element type
[45]  elementdecl ::=  '<!ELEMENT' S Name S contentspec S? '>' VC: Unique Element Type Declaration ]
[46]  contentspec ::=  'EMPTY' | 'ANY' | Mixed | children
 

dove il Name fornisce l' element type che viene dichiarato.

Vincolo di validità: Dichiarazione di element type unico
Nessun element type può essere dichiarato più di una volta.

Esempi di dichiarazioni di element type:
 
<!ELEMENT br EMPTY>
<!ELEMENT p (#PCDATA|emph)* >
<!ELEMENT %name.para; %content.para; >
<!ELEMENT container ANY>

3.2.1 Contenuto di soli elementi (Element Content)

Un element type ha un element content quando gli elementi di quel tipo devono contenere solo elementi figlio (nessun character data), opzionalmente separati con spazi bianchi (caratteri che soddisfano il non terminale S). In questo caso, il vincolo include un modello di contenuto, una semplice grammatica che stabilisce i tipi consentiti degli elementi figlio e l'ordine in cui devono apparire. La grammatica è costruita su particelle di contenuto (content particle cp), che consistono di nomi, liste di scelta di particelle di contenuto, o sequenze di liste di particelle di contenuto:
 
Modelli di contenuto di soli elementi (Element-content)
[47]  children ::=  (choice | seq) ('?' | '*' | '+')?
[48]  cp ::=  (Name | choice | seq) ('?' | '*' | '+')?
[49]  choice ::=  '(' S? cp ( S? '|' S? cp )* S? ')' VC: Proper Group/PE Nesting ]
[50]  seq ::=  '(' S? cp ( S? ',' S? cp )* S? ')' VC: Proper Group/PE Nesting ]
 

dove ciascun Name è il tipo di un elemento che può apparire come figlio. Qualsiasi particella di contenuto presente in una lista di scelta può apparire all'interno dell' element content nel punto in cui la lista di scelta appare nella grammatica; particelle di contenuto che capitano in una lista di sequenza devono ciascuna apparire nell' element content nell'ordine dato nella lista. Il carattere opzionale che segue un nome o una lista stabilisce se l'elemento o le particelle di contenuto nella lista possono capitare una o più volte (+), zero o più volte (*), oppure zero o una volta (?). L'assenza di un tale operatore significa che l'elemento o la particella di contenuto deve apparire esattamente una volta. Questa sintassi e questo significato sono identici a quelli usati nelle produzioni di queste specifiche.

Il contenuto di un elemento è concorde ad un modello di contenuto se e solo se è possibile seguire un cammino attraverso il "content model", che obbedisca alla sequenza, alla scelta, e agli operatori di ripetizione e che a ciascun elemento del contenuto corrisponda un "element type" nel "content model". Per compatibilità, è un errore se un elemento del documento può corrispondere a più di una occorrenza di un "element type" nel "content model". Per maggiore informazione, vedere l' Appendice "E. "Content model" deterministici"

Vincolo di validità: Gruppo proprio / Annidamento delle entità parametriche (PE)
Il testo di sostituzione di una entità parametrica deve essere propriamente annidato con gruppi racchiusi tra parentesi. In altre parole, se una delle parentesi di apertura o di chiusura di un costrutto tipo choice, seq, o Mixed è contenuta nel testo di sostituzione di una entità parametrica, allora entrambi devono essere contenute nel medesimo testo di sostituzione. Per interoperabilità, se un riferimento ad una entità-parametrica compare in un costrutto tipo choice, seq, o Mixed, il suo testo di sostituzione non dovrebbe essere vuoto, inoltre né il primo né l'ultimo carattere diverso da "blank" del testo di sostituzione dovrebbe essere un connettore (| or ,).

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

3.2.2 Contenuto misto (Mixed Content)

Un "element type" ha contenuto misto quando gli elementi di quel tipo possono contenere "character data", opzionalmente mescolati con elementi figlio. In questo caso, i tipi degli elementi figlio possono essere vincolati, ma non l'ordine o il numero delle loro occorrenze:
 
Dichiarazione "Mixed-content"
[51]  Mixed ::=  '(' S? '#PCDATA' (S? '|' S? Name)* S? ')*' 
| '(' S? '#PCDATA' S? ')'  VC: Proper Group/PE Nesting ]
VC: No Duplicate Types ]
 

dove i Name forniscono gli "element-type" che possono apparire come figli

Vincolo di validità: Nessun tipo duplicato
Lo stesso nome non deve apparire più di una volta in una singola dichiarazione "mixed content".

Esempi di dichiarazioni "mixed content":
 
<!ELEMENT p (#PCDATA|a|ul|b|i|em)*>
<!ELEMENT p (#PCDATA | %font; | %phrase; | %special; | %form;)* >
<!ELEMENT b (#PCDATA)>

3.3 Dichiarazioni di lista di attributi (Attribute-List)

Gli attributi sono usati per associare coppie di nome-valore agli elementi. Le specifiche di attributo possono apparire solo all'interno dei tag-di-inizio e dei tag degli elementi vuoti; per cui, le produzioni usate per riconoscerli compaiono nella sezione "3.1 Tag-di-inizio, tag-di-fine, e tag di elementi vuoti". Le dichiarazioni degli attribute-list possono essere usate:

Le dichiarazioni di "attribute list" specificano il nome, il tipo dei dati, e il valore di default (se presente) di ciascun attributo associato con un dato "element-type":
 
Dichiarazione di Attribute-list
[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 scelta dell'utente, un processore XML può avvisare se sono dichiarati attributi per un "element type" che non è stato dichiarato, ma questo non è un errore. Il Name nella regola AttDef è il nome dell'attributo

Quando più di una AttlistDecl è fornita per un dato "element type", i contenuti di tutte quelle fornite sono raggruppati. Quando più di una definizione è fornita per lo stesso attributo di un dato "element type", la prima dichiarazione viene registrata e le successive sono ignorate. Per interoperabilità, gli autori dei DTD possono scegliere di fornire al più una dichiarazione di "attribute-list" per un dato "element type", al più una definizione di attributo per un dato nome di attributo, e almeno una definizione di attributo in ciascuna "attribute-list". Per interoperabilità, un processore XML può a discrezione dell'utente avvisare quando viene fornita più di una dichiarazione di "attribute-list" per un dato "element type", 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 attributi XML sono di tre generi: un tipo stringa, un insieme di tipi "tokenized", e tipi enumerati. Il tipo stringa può prendere come valore qualsiasi stringa letterale; i tipi "tokenized" hanno vincoli lessicali e semantici che variano, come annotato:
 
Attribute Types
[54]  AttType ::=  StringType | TokenizedType | EnumeratedType
[55]  StringType ::=  'CDATA'
[56]  TokenizedType ::=  'ID' VC: ID ]
VC: One ID per Element Type ]
VC: ID Attribute Default ]
| 'IDREF' VC: IDREF ]
| 'IDREFS' VC: IDREF ]
| 'ENTITY' VC: Entity Name ]
| 'ENTITIES' VC: Entity Name ]
| 'NMTOKEN' VC: Name Token ]
| 'NMTOKENS' VC: Name Token ]
 

Vincolo di validità: ID
I valori di tipo ID devono rispettare la produzione Name. Un nome non deve apparire 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à: Un solo ID per un "element type"
Nessun "element type" può avere specificato più di un attributo di tipo ID.

Vincolo di validità: default dell'attributo ID
Un attributo ID deve avere un default che sia dichiarato #IMPLIED o #REQUIRED.

Vincolo di validità: IDREF
Valori di tipo IDREF devono rispettare la produzione Name, e i valori di tipo IDREFS devono rispettare la produzione Names; a ciascun Name deve corrispondere il valore di un attributo ID di qualche elemento del documento XML; cioè i valori IDREF devono essere uguali al valore di qualche attributo ID.

Vincolo di validità: Nome di entità
Valori di tipo ENTITY devono rispettare la produzione Name, valori di tipo ENTITIES devono rispettare la produzione Names; a ciascun Name deve corrispondere il nome di una entità unparsed dichiarata nel DTD.

Vincolo di validità: Name Token
Valori di tipo NMTOKEN devono rispettare la produzione Nmtoken, valori di tipo NMTOKENS devono rispettare la produzione Nmtokens.

Attributi enumerati possono assumere uno dei valori tratti da una lista fornita nella dichiarazione. Ci sono due generi di tipi enumerati:
 
Enumerated Attribute Types
[57]  EnumeratedType ::=  NotationType | Enumeration
[58]  NotationType ::=  'NOTATION' S '(' S? Name (S? '|' S? Name)* S? ')'  VC: Notation Attributes ]
[59]  Enumeration ::=  '(' S? Nmtoken (S? '|' S? Nmtoken)* S? ')' [ < /CODE> VC: Enumeration ]
 

Un attributo NOTATION identifica una notazione, dichiarata nel DTD con associato identificatori "system" e/o "public", da essere usati nell'interpretazione dell'elemento a cui l'attributo è attaccato.

Vincolo di validità: Attributi Notazione
Valori di questo tipo devono essere uguali a uno dei nomi di notazione inclusi nella dichiarazione; tutti i nomi di notazione presenti nella dichiarazione devono essere dichiarati.

Vincolo di validità: Enumerazione
Valori di questo tipo devono essere uguali a uno dei token Nmtoken presenti nella dichiarazione.

Per interoperabilità, lo stesso Nmtoken non dovrebbe capitare più di una volta nei tipi di attributi enumerati di un singolo "element type".

3.3.2 Default di attributo (Attribute Default)

Una dichiarazione di attributo informa se la presenza di un attributo è richiesta, e se non lo è, come un processore XML dovrebbe reagire se un attributo dichiarato è assente in un documento.
 
Default di attributo
[60]  DefaultDecl ::=  '#REQUIRED' |Ý'#IMPLIED' 
| (('#FIXED' S)? AttValue) VC: Required Attribute ]
VC: Attribute Default Legal ]
WFC: No < in Attribute Values ]
VC: Fixed Attribute Default ]
 

In una dichiarazione di attributo, #REQUIRED significa che l'attributo deve sempre essere fornito, #IMPLIED significa che nessun valore di default è fornito. Se la dichiarazione non è né #REQUIRED#IMPLIED, allora il valore AttValue contiene il valore di default dichiarato; la parola chiave #FIXED stabilisce che l'attributo deve sempre avere il valore di default. Se un valore di default è dichiarato, allora quando un processore XML incontra un attributo omesso, deve comportarsi come se l'attributo fosse presente con il valore dichiarato di default.

Vincolo di validità: Attributo richiesto
Se la dichiarazione di default è la parola chiave #REQUIRED, allora l'attributo deve essere specificato per tutti gli elementi di tipo specificato nella dichiarazione "attribute-list".

Vincolo di validità: Attributo di default legale
Il valore di default dichiarato dev e rispettare i vincoli lessicali del tipo di attributo lessicale.

Vincolo di validità: Attributo di default fissato
Se un attributo ha un valore di default dichiarato con la parola chiave #FIXED, allora tutte le istanze di quell' attributo devono contenere il valore di default.

Esempi di dichiarazioni di liste di attributi
 
<!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 dell'attributo

Prima che il valore di un attributo sia passato all'applicazione o sia controllato per la validità, il processore XML deve normalizzarlo come segue:

Se il valore dichiarato non è CDATA, allora il processore XML deve elaborare ulteriormente il valore normalizzato dell'attributo scartando ogni carattere di spazio (#x20) di testa e di coda, e sostituendo le sequenze di caratteri di spazio (#x20) con un singolo carattere di spazio (#x20).

Tutti gli attributi per cui non è stata trovata nessuna dichiarazione dovrebbero essere trattati da un parser non-validante come se fossero dichiarati CDATA.

3.4 Sezioni condizionali

Le sezioni condizionali sono porzioni del sottoinsieme esterno del "document type declaration" che sono incluse o escluse dalla struttura logica del DTD in base ad una parola chiave che le governa.
 
Sezioni condizionali
[61]  conditionalSect ::=  includeSect | ignoreSect
[62]  includeSect ::=  '<![' S? 'INCLUDE' S? '[' extSubsetDecl ']]>' 
[63]  ignoreSect ::=  '<![' S? 'IGNORE' S? '[' ignoreSectContents* ']]>'
[64]  ignoreSectContents ::=  Ignore ('<![' ignoreSectContents ']]>' Ignore)*
[65]  Ignore ::=  Char* - (Char* ('<![' | ']]>') Char*) 
 

Come i sottoinsiemi interni o esterni del DTD, una sezione condizionale può contenere una o più dichiarazioni complete, commenti, istruzioni di elaborazione, o sezioni condizionali annidate, intramezzati con spazi bianchi.

Se la parola chiave della sezione condizionale è INCLUDE, allora i contenuti della sezione condizionale sono parte del DTD. Se la parola chiave della sezione condizionale è IGNORE, allora i contenuti della sezione condizionale non sono logicamente parte del DTD. Notare che per un parsing affidabile, anche i contenuti delle sezioni condizionali ignorate devono essere letti per rilevare sezioni condizionali annidate ed assicurarsi che la fine della sezione condizionale (ignorata) più esterna sia propriamente rilevata. Se una sezione condizionale con una parola chiave INCLUDE capita dentro una sezione condizionale più grande con una parola chiave IGNORE, entrambi le sezioni condizionali esterna e interna sono ignorate.

Se la parola chiave della sezione condizionale è un riferimento ad una entità parametrica, l'entità parametrica deve essere sostituita con il suo contenuto prima che il processore decida se includere o ignorare la sezione.

Un esempio:
 
<!ENTITY % draft 'INCLUDE' >
<!ENTITY % final 'IGNORE' >

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

4. Strutture fisiche

Un documento XML può consistere di una o più unità di memoria. Queste sono dette entità; esse hanno tutte un contenuto e sono tutte (eccetto per l'entità documento, vedi sotto, e per il sottoinsieme esterno del DTD) identificate da un nome. Ciascun documento XML ha una entità detta l'entità documento, che serve come punto di partenza per il processore XML e può contenere tutto il documento.

Le entità possono essere sia parsed (analizzate) che unparsed (non-analizzate). I contenuti di una entità parsedsono riferiti come il suo testo di sostituzione; questo testo è considerato una parte integrale del documento.

Un' entità unparsed è una risorsa i cui contenuti possono essere o non essere testo, e se sono testo, possono non essere XML. Ciascuna entità unparsed ha una notazione associata, identificata da un nome. Al di là del requisito che un processore XML renda disponibile all'applicazione gli identificatori per l'entità e la notazione, XML non pone nessun vincolo sui contenuti delle entità unparsed.

Le entità parsed sono invocate con il nome usando i riferimenti alle entità; le entità unparsed sono invocate con il nome, fornito nel valore degli attributi di tipo ENTITY o ENTITIES.

Le entità generali sono entità da usare all'interno del documento. In queste specifiche, le entità generali sono talvolta riferite con il termine non qualificato di entitàquando questo non conduca ad ambiguità. Le entità parametriche sono entità parsed da usare all'interno del DTD. Queste due tipi di entità usano forme differenti di riferimento e sono riconosciute in contesti differenti. Inoltre, esse occupano differenti namespace; un'entità parametrica e un'entità generale con lo stesso nome sono due entità distinte.

4.1 Riferimenti a carattere e entità

Un riferimento a carattere indirizza ad un carattere specifico appartenente al set di caratteri ISO/IEC 10646, per esempio ad un carattere non accessibile direttamente dai dispositivi di input disponibili.
 
Riferimento a carattere
[66]  CharRef ::=  '&#' [0-9]+ ';' 
| '&#x' [0-9a-fA-F]+ ';' WFC: Legal Character ]
 

Vincolo di well-formedness: Carattere legale (Legal Character)
I caratteri indirizzati usando i riferimenti a carattere devono essere compatibili con la produzione Char.

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

Un riferimento a entità indirizza il contenuto dell'entità nominata. I riferimenti a entità generali parsed usano come delimitatori la e-commerciale (&) e il punto-e-virgola (;). I riferimenti a entità parametriche usano come delimitatori la percentuale (%) e il punto-e-virgola (;).
 
Riferimento a entità
[67]  Reference ::=  EntityRef | CharRef
[68]  EntityRef ::=  '&' Name ';' WFC: Entity Declared ]
VC: Entity Declared ]
WFC: Parsed Entity ]
WFC: No Recursion ]
[69]  PEReference ::=  '%' Name ';' VC: Entity Declared ]
WFC: No Recursion ]
WFC: In DTD ]
 

Vincolo well-formedness: entità dichiarata
In un documento senza alcun DTD, in un documento con soltanto il sottoinsieme interno del DTD che non contenga riferimenti ad entità parametrica, o in un documento con "standalone='yes'", il Name dato nel riferimento all'entità deve essere uguale a quello presente in una dichiarazione di entità, ad eccezione di quanto detto i documenti well-formed non hanno bisogno di dichiarare nessuna delle seguenti entità: amp, lt, gt, apos, quot. La dichiarazione di una entità parametrica deve precedere qualsiasi riferimento ad essa. Similmente, la dichiarazione di una entità generale deve precedere qualsiasi riferimento ad essa che appaia in un valore di default all'interno di una dichiarazione di attribute-list. Notare che se le entità sono dichiarate nel sottoinsieme esterno o in una entità parametrica esterna, un processore non-validante non è obbligato a leggere e ad elaborare le loro dichiarazioni; per tali documenti, la regola che un'entità deve essere dichiarata è un vincolo well-formedness solo se standalone='yes'.

Vincolo di validità: Entità dichiarata
In un documento con un sottoinsieme esterno o un'entità parametrica esterna con "standalone='no'", il Name dato nel riferimento di entità deve essere uguale a quella in una dichiarazione di entità. Per interoperabilità, i documenti validi dovrebbero dichiarare le entità amp, lt, gt, apos, quot, nella forma specificata nella sezione "4.6 Entità predefinite". La dichiarazione di un'entità parametrica deve precedere qualsiasi riferimento ad essa. Similmente, la dichiarazione di una entità generale deve precedere qualsiasi riferimento ad essa che appaia in un valore di default all'interno di una dichiarazione di attribute-list.

Vincolo well-formedness: entità parsed
Qualsiasi riferimento a entità non deve contenere il nome di una entità unparsed. Entità unparsed possono essere riferite solo nei valori di attributo che sono stati dichiarati di tipo ENTITY o ENTITIES.

Vincolo well-formedness: Nessuna ricorsione
Una entità parsed non deve contenere un riferimento ricorsivo su se stessa, sia direttamente che indirettamente.

Vincolo well-formedness: Nel DTD
Riferimenti ad entità parametrica possono apparire solamente nel DTD.

Esempi di riferimenti a carattere e entità
 
Type <key>less-than</key> (&#x3C;) to save options.
This document was prepared on &docdate; and
is classified &security-level;.

Esempio di un riferimento a entità parametrica:
 
<!-- declare the parameter entity "ISOLat2"... -->
<!ENTITY % ISOLat2
         SYSTEM "http://www.xml.com/iso/isolat2-xml.entities" >
<!-- ... now reference it. -->
%ISOLat2;

4.2 Dichiarazioni di entità

Le entità sono dichiarate così:
 
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à o, nel caso di una entità unparsed, nel valore di un attributo ENTITY o ENTITIES. Se la stessa entità è dichiarata più di una volta, la prima dichiarazione incontrata è quella vincolante; a scelta dell'utente, un processore XML può avvisare se le entità sono dichiarate più di una volta.

4.2.1 Entità interne

Se la definizione di entità è un EntityValue, l'entità definita è detta una entità interna. Non ci sono oggetti di memoria fisica separati, e il contenuto dell'entità è dato nella dichiarazione. Notare che per produrre il testo di sostituzione corretto può essere richiesto qualche elaborazione dei riferimenti a entità e dei riferimenti a carattere presenti nel valore letterale dell'entità: vedere la sezione "4.5 Costruzione del testo di sostituzione delle entità interne".

Un'entità interna è un' entità parsed.

Esempio di dichiarazione di entità interna:
 
<!ENTITY Pub-Status "This is a pre-release of the
 specification.">

4.2.2 Entità esterne

Se l'entità non è interna, è una 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 VC: Notation Declared ]
 

Se NDataDecl è presente, questa è un' entità unparsed generale; altrimenti è un' entità parsed.

Vincolo di validità: Notazione dichiarata
Il Name deve corrispondere al nome dichiarato di una notazione.

Il SystemLiteral è detto identificatore di sistema dell'entità. È un URI, che può essere usato per recuperare l'entità. Notare che il simbolo hash (#) e l'identificatore di frammento usato frequentemente con gli URI, formalmente, non sono parte dell' URI stesso; un processore XML può segnalare un errore se un identificatore di frammento viene fornito come parte di un identificatore di sistema. A meno che non sia fornito in altro modo da informazione esterna alla portata di queste specifiche (ad esempio uno speciale "XML element type" definito da un particolare DTD, o una istruzione di elaborazione definita dalle specifiche di una particolare applicazione), URI relativi sono relativi alla locazione della risorsa entro cui la dichiarazione dell'entità capita. Un URI potrebbe così essere relativa all' entità documento, all' entità contenente il sottoinsieme esterno del DTD, o a qualche altra entità parametrica esterna.

Un processore XML dovrebbe gestire un carattere non-ASCII contenuto in una URI rappresentando il carattere in UTF-8 come uno o più byte, e poi "escaping" questi byte con il meccanismo di "URI escaping" (cioè, convertendo ciascun byte a %HH, dove HH è la notazione esadecimale del valore del byte).

In aggiunta ad un identificatore di sistema, un identificatore esterno può includere un identificatore pubblico (public identifier). Un processore XML che tenti di recuperare il contenuto dell'entità può usare l' identificatore pubblico per cercare di generare un URI alternativo. Se il processore non è capace di farlo, deve usare l' URI specificato nel "system literal". Prima di tentare un confronto, tutte le stringhe di spazi bianchi presenti nell'identificatore pubblico devono essere normalizzate a singoli caratteri di spazio (#x20), e i caratteri di spazio bianco iniziali e finali devono essere rimossi.

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 (analizzate)

4.3.1 La dichiarazione di testo

Le entità esterne parsed possono ciascuna iniziare con una dichiarazione di testo.

Dichiarazione di testo
[77]  TextDecl ::=  '<?xml' VersionInfo? EncodingDecl S? '?>'
 

La dichiarazione di testo deve essere fornita letteralmente, e non usando riferimenti ad entità parsed. Nessuna dichiarazione di testo può apparire in una qualche posizione che non sia l'inizio di una entità esterna parsed.

4.3.2 Entità parsed Well-Formed

L'entità documento è well-formed se rispetta la produzione etichettata con document. Una entità parsed generale è well-formed se rispetta la produzione etichettata con extParsedEnt. Una entità parametrica esterna è well-formed se rispetta la produzione etichettata con extPE.
 
Entità parsed esterne Well-Formed
[78]  extParsedEnt ::=  TextDecl? content
[79]  extPE ::=  TextDecl? extSubsetDecl
 

Un'entità parsed generale interna è well-formed se il suo testo di sostituzione rispetta la produzione etichettata con content. Tutte le entità parametriche interne sono well-formed per definizione.

Una conseguenza della "well-formedness" nelle entità è che le strutture logiche e fisiche sono annidate propriamente; nessun tag-di-inizio, tag-di-fine, tag di elemento-vuoto, elemento, commento, istruzione di elaborazione, riferimento a carattere, o riferimento a entità può iniziare in una entità e terminare in un'altra.

4.3.3 Codifica dei caratteri nelle entità

Ciascuna entità parsed esterna in un documento XML può usare una codifica differente per i suoi caratteri. Tutti i processori XML devono essere capaci di leggere entità sia in UTF-8 che in UTF-16.

Entità codificate in UTF-16 devono iniziare con il Byte Order Mark (segno dell'ordine dei byte) descritto nell'annesso E di ISO/IEC 10646 e nell'appendice B di Unicode (il carattere "WIDTH NO-BREAK SPACE", #xFEFF). Questo è una firma di codifica, che non fa parte né dei markup nè dei character data del documento XML. I processori XML devono essere capaci di usare questo carattere per differenziare i documenti codificati in UTF-8 da quelli codificati in UTF-16.

Sebbene ad un processore XML sia richiesto di leggere solo entità codificate in UTF-8 e UTF-16, si sa che altre codifiche sono usate nel mondo, e può essere desiderabile che i processori XML sappiano leggere le entità che le utilizzano. Entità parsed che sono memorizzate in una codifica differente da UTF-8 o UTF-16 devono iniziare con una dichiarazione di testo contenente un dichiarazione di codifica:
Dichiarazione di codifica
[80]  EncodingDecl ::=  S 'encoding' Eq ('"' EncName '"' |  "'" EncName "'" ) 
[81]  EncName ::=  [A-Za-z] ([A-Za-z0-9._] | '-')* /*  Encoding name contains only Latin characters */
 

Nell' entità documento, la dichiarazione di codifica fa parte della dichiarazione di XML. EncName è il nome della codifica usata.

In una dichiarazione di codifica, i valori "UTF-8", "UTF-16", "ISO-10646-UCS-2", e "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-9" 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. I processori XML possono riconoscere altre codifiche; si raccomanda che le codifiche dei caratteri registrate (come charset) con la Internet Assigned Numbers Authority [IANA], oltre a quelle appena elencate, dovrebbero essere riferite usando i loro nomi registrati. Notare che questi nomi registrati sono case-insensitive, per cui i processori che vogliono contemplarli dovrebbero farlo in modo case-insensitive.

Nell'assenza di informazione fornita da un protocollo di trasferimento esterno (ad esempio HTTP o MIME), è un errore che un'entità che includa una dichiarazione di codifica sia presentata ad un processore XML in una codifica differente da quella dichiarata, è un errore che una dichiarazione di codifica capiti in un posto che non sia l'inizio di una entità esterna, è un errore che una entità che non inizia nè con un BOM (Byte Order Mark) né con una dichiarazione di codifica, usi una codifica differente dalla codifica UTF-8. Notare che poiché ASCII è un sottoinsieme di UTF-8, le ordinarie entità ASCII non necessitano strettamente di una dichiarazione di codifica.

È un errore fatale quando un processore XML incontra un'entità con una codifica che è incapace di elaborare.

Esempi di dichiarazione di codifica:
 
<?xml encoding='UTF-8'?>
<?xml encoding='EUC-JP'?>

4.4 Come un processore XML tratta le entità e i riferimenti a entità

La tabella sottostante riassume i contesti in cui i riferimenti a carattere, i riferimenti a entità, e le invocazioni di entità unparsed potrebbero capitare e i comportamenti richiesti in ciascun caso da parte di un processore XML. Le etichette nella colonna più a sinistra descrivono il contesto di riconoscimento:

Riferimento in un contenuto
come un riferimento in qualsiasi parte dopo il tag-di-inizio e prima del tag-di-fine di un elemento; corrisponde al non terminale content.
Riferimento in un valore di attributo
come un riferimento all'interno del valore di un attributo in un tag-di-inizio, o in valore di default in una dichiarazione di attributo; corrisponde al non-terminale AttValue.
Presente come valore di attributo
non come un riferimento ma come un Name che appare o come il valore di un attributo che è stato dichiarato di tipo ENTITY, oppure come uno dei token separati da spazio nel valore di un attributo che è stato dichiarato di tipo ENTITIES.
Riferimento in un valore di entità
come un riferimento all'interno del entity value letterale di una entità parametrica o interna contenuto nella dichiarazione dell'entità; corrisponde al non-terminale EntityValue.
Riferimento in un DTD
come un riferimento dentro i sottoinsiemi interno o esterno del DTD, ma fuori da un EntityValue o AttValue.
Entity Type Carattere
Parametrica Generale Interna Generale Esterna Parsed Unparsed
Riferimento in un contenuto Non riconosciuto Incluso Incluso se validante Proibito Incluso
Riferimento in un valore di attributo Non riconosciuto Incluso nel letterale Proibito Proibito Incluso
Presente come un valore di attributo Non riconosciuto Proibito Proibito Notificare Non riconosciuto
Riferimento in un valore di entità Incluso nel letterale Oltrepassato Oltrepassato Proibito Incluso
Riferimento in un DTD Incluso come PE Proibito Proibito Proibito Proibito

4.4.1 Non riconosciuto

All'esterno del DTD, il carattere % non ha nessun significato speciale; così, quelle cose che nel DTD sarebbero dei riferimenti ad entità parametrica nel content non sono riconosciuti come markup. Similmente, i nomi delle entità unparsed non sono riconosciuti tranne quando appaiono nel valore di un attributo dichiarato appropriatamente.

4.4.2 Incluso

Un'entità è inclusa quando il suo testo di sostituzione è recuperato e elaborato, in luogo del riferimento stesso, come se (il testo di sostituzione) fosse parte del documento nella locazione dove il riferimento è stato riconosciuto. Il testo di sostituzione può contenere sia character data che (tranne che per le entità parametriche) markup, che devono essere riconosciuti nel modo usuale, ad eccezione del testo di sostituzione delle entità usate per riferire (escape) i delimitatori dei markup (cioè le entità amp, lt, gt, apos, quot) il quale viene sempre trattato come dato. (La stringa "AT&amp;T;" si espande in "AT&T;" e la e-commerciale rimanente non viene riconosciuta come delimitatore di un riferimento a entità). Un riferimento a carattere è incluso quando il carattere indirizzato viene elaborato in luogo del riferimento stesso.

4.4.3 Incluso se validante

Quando un processore XML riconosce un riferimento ad una entità parsed, per validare il documento, il processore deve includere il suo testo di sostituzione. Se l'entità è esterna, e il processore non sta cercando di validare il documento XML, il processore può, ma non necessariamente, includere il testo di sostituzione dell'entità. Se un parser non-validante non include il testo di sostituzione, deve informare l'applicazione che ha riconosciuto l'entità, ma non l'ha letta.

Questa regola è basata sul riconoscimento che l'inclusione automatica fornita dal meccanismo delle entità XML e SGML, primariamente progettata per supportare la modularità nell'authoring, non è necessariamente appropriata per altre applicazioni, in particolare nella navigazione di documenti. I Browser, ad esempio, quando incontrano un riferimento ad una entità parsed esterna, potrebbero scegliere di fornire una indicazione visuale della presenza dell'entità e recuperarla per visualizzarla solo su richiesta.

4.4.4 Proibito

I seguenti casi sono proibiti, e costituiscono errori fatali:,

4.4.5 Incluso nel letterale

Quando un riferimento a entità appare in un valore di attributo, oppure quando un riferimento a entità parametrica appare nel valore letterale di una entità, il rispettivo testo di sostituzione viene elaborato in luogo del riferimento stesso come se fosse parte del documento al posto del riferimento che è stato riconosciuto, ad eccezione del carattere di singolo o doppio apice presente nel testo di sostituzione che viene sempre trattato come un normale carattere e quindi non terminerà il letterale. Ad esempio, questo è well-formed:
 
<!ENTITY % YN '"Yes"' >
<!ENTITY WhatHeSaid "He said %YN;" >

mentre questo non lo è:
 
<!ENTITY EndAttr "27'" >
<element attribute='a-&EndAttr;>

4.4.6 Notificare

Quando il nome di una entità unparsed appare come un token nel valore di un attributo di tipo dichiarato ENTITY o ENTITIES, un processore validante deve informare l'applicazione degli identificatori system e public (se presente) sia per l'entità che per la sua notazione associata.

4.4.7 Oltrepassato

Quando un riferimento a entità generale appare nell' EntityValue di una dichiarazione di entità, è oltrepassato e lasciato così com' è.

4.4.8 Incluso come un' entità parametrica (PE)

Proprio come con le entità parsed esterne, le entità parametriche hanno bisogno di essere incluse solo se il processore è validante. Quando un riferimento a entità parametrica è riconosciuto nel DTD e incluso, il suo testo di sostituzione è aumentato inserendo un carattere di spazio (#x20) all'inizio e alla fine; l'intento è di vincolare il testo di sostituzione delle entità parametriche a contenere nel DTD un numero intero di token grammaticali.

4.5 Costruzione del testo di sostituzione delle entità interne

Nel discutere il trattamento delle entità interne, è utile distinguere due forme del valore dell'entità. Il valore letterale dell'entità è la stringa tra apici presente realmente nella dichiarazione di entità, e corrispondente al non terminale EntityValue. Il testo di sostituzione è il contenuto dell'entità, dopo la sostituzione dei riferimenti a carattere e dei riferimenti a entità parametriche.

Il valore letterale dell'entità come fornito nella dichiarazione dell'entità interna (EntityValue) può contenere riferimenti a carattere, a entità parametriche e a entità generali. Tali riferimenti devono essere contenuti completamente all'interno del valore letterale dell'entità. Il testo reale di sostituzione che è incluso come descritto sopra deve contenere il testo di sostituzione di qualsiasi entità parametrica referenziata, e deve contenere il carattere referenziato, al posto di qualsiasi riferimento a carattere nel valore letterale dell'entità; tuttavia, i riferimenti a entità generali devono essere lasciati così come sono, cioè 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 di sostituzione per l'entità "book" è:
 
La Peste: Albert Camus, 
© 1947 Éditions Gallimard. &rights;

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

Queste regole semplici possono avere interazioni complesse; per una dettagliata discussione di un esempio difficile, vedere "D. Espansione di riferimenti a entità e a carattere".

4.6 Entità predefinite

Riferimenti a entità e a carattere possono entrambi essere usati per "escape" la parentesi angolare sinistra, la e-commerciale, e altri delimitatori. Un set di entità generali (amp, lt, gt, apos, quot) è specificato per questo scopo. Inoltre si possono usare i riferimenti numerici a carattere; questi una volta riconosciuti sono espansi immediatamente e devono essere trattati come "character data", così che i riferimenti numerici a carattere "&#60;" e "&#38;" possono essere usati per "escape" < e & quando essi occorrono nei "character data".

Tutti i processori XML devono riconoscere queste entità se sono dichiarate o no. Per interoperabilità, documenti XML validi dovrebbero dichiarare queste entità, come ogni altra, prima di usarle. Se le entità in questione sono dichiarate, devono essere dichiarate come entità interne il cui testo di sostituzione è il singolo carattere che deve essere "escaped" oppure un riferimento a carattere per quel carattere, come mostrato sotto.
 
<!ENTITY lt     "&#38;#60;"> 
<!ENTITY gt     "&#62;"> 
<!ENTITY amp    "&#38;#38;"> 
<!ENTITY apos   "&#39;"> 
<!ENTITY quot   "&#34;"> 

Notare che nelle dichiarazioni di "lt" and "amp" i caratteri < e & sono doppiamente "escaped" per venire incontro al requisito che la sostituzione dell'entità sia well-formed.

4.7 Dichiarazioni di notazione

Le Notazioni identificano tramite un nome il formato di entità unparsed, il formato di elementi che portano un attributo di notazione, oppure l'applicazione a cui una istruzione di elaborazione è indirizzata.

Le dichiarazioni di notazione forniscono un nome per la notazione, da usare nelle dichiarazioni delle entità e delle liste di attributi e da usare nelle specifiche degli attributi, inoltre forniscono un identificatore esterno per la notazione che possa consentire ad un processore XML oppure ad una applicazione client di localizzare un'applicazione di ausilio ("helper") capace di elaborare i dati nella notazione data.
 
Dichiarazioni di notazione
[82]  NotationDecl ::=  '<!NOTATION' S Name S (ExternalID | PublicID) S? '>'
[83]  PublicID ::=  'PUBLIC' S PubidLiteral
 

I processori XML devono fornire alle applicazioni il nome e l'(gli) identificatore(i) di qualsiasi notazione dichiarata e referenziata in un valore di attributo, in una definizione di attributo o nella dichiarazione di entità. Essi possono in aggiunta convertire l'identificatore esterno nell' identificatore di sistema, nome di file, o altra informazione necessaria per consentire all'applicazione di invocare un elaboratore dei dati nella notazione descritta. (Non è un errore, tuttavia, per i documenti XML dichiarare e riferire notazioni per cui applicazioni della notazione specifica non siano disponibili sul sistema dove il processore XML o l'applicazione è in esecuzione.)

4.8 Entità documento

L' entità documento serve come radice dell'albero delle entità e come un punto di partenza per un XML processor. Questa specifiche non rivelano come l'entità documento debba essere localizzata da un processore XML; a differenza delle altre entità, l'entità documento non ha nessun nome e potrebbe tranquillamente apparire sul flusso di input di un processore senza nessuna 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 come quelli non-validanti devono riportare le violazioni di "well-formedness" di queste specifiche, presenti nel contenuto dell' entità documento e di ogni altra entità parsed che leggono.

I processori validanti devono riportare le violazioni dei vincoli espressi dalle dichiarazioni presenti nel DTD, e i mancati rispetti dei vincoli di validità espressi in queste specifiche. Per compiere questo, i processori XML validanti devono leggere e elaborare l'intero DTD e tutte le entità parsed esterne riferenziate nel documento.

I processori non-validanti sono tenuti a controllare solo l' entità documento, che include l'intero sottoinsieme interno del DTD, per determinare la well-formedness. Mentre non sono tenuti a controllare il documento per verificarne la validità, sono tenuti ad elaborare tutte le dichiarazioni che leggono nel sottoinsieme interno del DTD e in qualsiasi entità parametrica che leggono, fino al primo riferimento ad una entità parametrica che nonleggono; cioè a dire, che devono usare l'informazione presente in quelle dichiarazioni per normalizzare i valori di attributo, includere il testo di sostituzione delle entità interne, e fornire i valori di attributo di default. Non devono elaborare le dichiarazioni di entità o le dichiarazioni delle liste di attributi incontrate dopo un riferimento ad una entità parametrica che non è letta, poiché l'entità può contenere delle dichiarazioni sovrastanti.

5.2 Uso dei processori XML

Il comportamento di un processore XML validante è molto prevedibile; esso deve leggere ogni pezzo di un documento e riportare tutte le violazioni di validità e well-formedness. Si richiede meno per un processor non-validante; non c'è bisogno che legga qualsiasi parte del documento eccetto che l'entità documento. Questo ha due effetti che possono essere importanti per gli utenti dei processori XML: Per un'affidabilità massima nella interoperatività tra differenti processori XML, applicazioni che usano processori non-validanti non dovrebbero dipendere da qualsiasi comportamento non richiesto di tali processori. Applicazioni che richiedono facilitazioni (facilities) come l'uso di attributi di default o entità interne che sono dichiarate in entità esterne dovrebbero usare processori XML validanti.

6. Notazione

In queste specifiche la grammatica XML è fornita usando una notazione molto semplice detta Extended Backus-Naur Form (EBNF). Ciascuna regola nella grammatica definisce un simbolo, nella forma
 
symbol ::= expression

I simboli sono scritti con una lettera iniziale maiuscola se sono definiti da un'espressione regolare, o con una lettera minuscola negli altri casi. Le stringhe letterali sono tra apici.

Nell'espressione della parte destra di una regola, si utilizzano le seguenti espressioni per generare (match) stringhe di uno o più caratteri:

#xN
dove N è un intero esadecimale, l'espressione corrisponde al carattere in ISO/IEC 10646 il cui valore del codice canonico (UCS-4), quando interpretato come numero binario senza segno, ha il valore indicato. Il numero degli zero iniziali nella forma #xN è insignificante; Il numero degli zero iniziali nel corrispondente valore di codice è governato dalla codifica di carattere in uso e non è significativo per XML.
[a-zA-Z], [#xN-#xN]
corrisponde a qualsiasi carattere con un valore nel (nei) rango (ranghi) indicato(i) (inclusivo).
[^a-z], [^#xN-#xN]
corrisponde a qualsiasi carattere con un valore esterno al rango indicato.
[^abc], [^#xN#xN#xN]
corrisponde a qualsiasi carattere con un valore non compreso tra i caratteri dati.
"string"
corrisponde ad una stringa letterale uguale (matching) a quella data all'interno dei doppi apici.
'string'
corrisponde ad una stringa letterale uguale (matching) a quella data all'interno dei singoli apici.
Questi simboli possono essere combinati per generare (match) pattern più complessi nel seguente modo, siano A e B espressioni semplici
(expression)
l'espressione è trattata come unità e può essere combinata come descritto in questa lista.
A?
contiene (match) una A o niente; A opzionale.
A B
contiene una A seguita da una B.
A | B
contiene una A o una B ma non entrambi.
A - B
contiene qualsiasi stringa che corrisponda (match) ad A ma non a B.
A+
contiene una o più occorrenze di A.
A*
contiene zero o più occorrenze di A.
Altre notazioni usate nelle produzioni sono:
/* ... */
commento.
[ wfc: ... ]
vincolo di well-formedness (costraint); questo identifica per nome un vincolo sui documenti well-formed associato con una produzione.
[ vc: ... ]
vincolo di validità (validity constraint); questo identifica per nome un vincolo sui documenti validi associato con una produzione.


Appendici

A. Riferimenti

A.1 Riferimenti alle normative

IANA
(Internet Assigned Numbers Authority) Official Names for Character Sets, ed. Keld Simonsen et al. See ftp://ftp.isi.edu/in-notes/iana/assig nments/character-sets.
IETF RFC 1766
IETF (Internet Engineering Task Force). RFC 1766: Tags for the Identification of Languages, ed. H. Alvestrand. 1995.
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/IEC 10646
ISO (International Organization for Standardization). ISO/IEC 10646-1993 (E). Information technology -- Universal Multiple-Octet Coded Character Set (UCS) -- Part 1: Architecture and Basic Multilingual Plane. [Geneva]: International Organization for Standardization, 1993 (plus amendments AM 1 through AM 7).
Unicode
The Unicode Consortium. The Unicode Standard, Version 2.0. Reading, Mass.: Addison-Wesley Developers Press, 1996.

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.
Berners-Lee et al.
Berners-Lee, T., R. Fielding, and L. Masinter. Uniform Resource Identifiers (URI): Generic Syntax and Semantics. 1997. (Work in progress; see updates to RFC1738.)
Brüggemann-Klein
Brüggemann-Klein, Anne. Regular Expressions into Finite Automata. Extended abstract in I. Simon, Hrsg., LATIN 1992, S. 97-98. Springer-Verlag, Berlin 1992. Full Version in Theoretical Computer Science 120: 197-213, 1993.
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.
Clark
James Clark. Comparison of SGML and XML. See http://www.w3.org/TR/NOTE-sgml- xml-971215.
IETF RFC1738
IETF (Internet Engineering Task Force). RFC 1738: Uniform Resource Locators (URL), ed. T. Berners-Lee, L. Masinter, M. McCahill. 1994.
IETF RFC1808
IETF (Internet Engineering Task Force). RFC 1808: Relative Uniform Resource Locators, ed. R. Fielding. 1995.
IETF RFC2141
IETF (Internet Engineering Task Force). RFC 2141: URN Syntax, ed. R. Moats. 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.

B. Classi di caratteri

Seguendo le caratteristiche definite nello standard Unicode, i caratteri cono classificati come caratteri di base (tra gli altri, questi contengono i caratteri alfabetici dell'alfabeto Latino, senza i diacritici), caratteri ideografici, e caratteri che si combinano (tra gli altri, questa classe contiene la maggior parte dei diacritici); queste classi si combinano a formare la classe delle lettere. Cifre e estensori sono anche distinti.
 
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 definite qui possono essere derivate dall'archivio dei caratteri Unicode come segue:

C. XML e SGML (non-normativo)

XML è progettato per essere un sottoinsieme di SGML, pertanto ogni documento XML valido dovrebbe anche essere un documento conforme SGML. Per un confronto dettagliato delle restrizioni aggiuntive che XML introduce sui documenti oltre quelle di SGML, vedere [Clark].

D. Espansione dei riferimenti a entità e a carattere (non-normativo)

Questa appendice contiene alcuni esempi che illustrano la sequenza di riconoscimento e espansione del riferimento a entità e del riferimento a carattere, come specificato nella sezione "4.4 Come un processore XML gestisce le entità e i riferimenti a entità".

Se il DTD contiene la dichiarazione
 
<!ENTITY example "<p>An ampersand (&#38;#38;) may be escaped
numerically (&#38;#38;#38;) or with a general entity
(&amp;amp;).</p>" >

allora il processore XML riconoscerà i riferimenti a carattere quando analizzerà la dichiarazione di entità, e li risolverà prima di registrare come valore dell'entità la stringa seguente "example":
 
<p>An ampersand (&#38;) may be escaped
numerically (&#38;#38;) or with a general entity
(&amp;amp;).</p>

Un riferimento nel documento a "&example;" farà si che il testo sia analizzato di nuovo, questa volta i tag di inizio e fine dell'elemento "p" saranno riconosciuti per cui i tre riferimenti saranno riconosciuti e espansi, risultando in un elemento "p" con il seguente contenuto (tutti dati, nessun delimitatore o markup):
 
An ampersand (&) may be escaped
numerically (&#38;) or with a general entity
(&amp;).

Un esempio più complesso chiarirà meglio le regole e i loro effetti. Nel seguente esempio, i numeri di linea sono solo come riferimento.
 
1 <?xml version='1.0'?>
2 <!DOCTYPE test [
3 <!ELEMENT test (#PCDATA) >
4 <!ENTITY % xx '&#37;zz;'>
5 <!ENTITY % zz '&#60;!ENTITY tricky "error-prone" >' >
6 %xx;
7 ]>
8 <test>This sample shows a &tricky; method.</test>

Questo produce il seguente:

E. Modelli di contenuto deterministici (non-normativo)

Per compatibilità, si richiede che i modelli di contenuto ("content models") nelle dichiarazione degli "element type" siano deterministici

SGML richiede modelli di contenuto deterministici (che chiama "non ambigui"); i processori XML costruiti usando i sistemi SGML possono segnalare i modelli di contenuto non-deterministici come errori.

Ad esempio, il modello di contenuto ((b, c) | (b, d)) è non-deterministico, poiché data una b iniziale il parser non può sapere a quale modello appartiene la b senza guardare in avanti per trovare quale elemento segua b. In questo caso, i due riferimenti a b possono essere riuniti in un singolo riferimento, rendendo il modello (b, (c | d)). Adesso una b iniziale chiaramente corrisponde ad un nome solo nel modello di contenuto. Il parser non ha bisogno di andare avanti per trovare cosa segue; sia c che d sarebbero accettati.

Più formalmente: un automa a stati finiti può essere costruito dal modello di contenuto usando gli algoritmi standard, ad esempio l' algoritmo 3.5 nella sezione 3.9 di Aho, Sethi, e Ullman [Aho/Ullman]. In molti di questi algoritmi, per ciascuna posizione nell'espressione regolare (cioè, per ciascun nodo foglia nell'albero sintattico associato all'espressione regolare) si costruisce un insieme dei successori ("follow set") ; se qualche posizione ha un insieme dei successori ("follow set") in cui più di una posizione seguente è etichettata con lo stesso nome di "element type", allora il modello di contenuto è in errore e può essere riportato come errore.

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

F. Rilevamento automatico della codifica dei caratteri (non-normativo)

La dichiarazione di codifica XML funziona come un'etichetta interna su ciascuna entità, che indica quale codifica di carattere è in uso. Prima che un processore XML possa leggere l'etichetta interna, comunque, apparentemente deve sapere quale codifica di carattere è in uso--che è ciò che l'etichetta interna sta cercando di indicare. Nel caso generale, questa è una situazione senza speranza. Non è interamente senza speranza in XML, tuttavia, poiché XML limita il caso generale in due modi: si assume che ciascuna implementazione debba mantenere ("support") solo un insieme finito di codifiche di caratteri, e la dichiarazione di codifica XML sia ristretta in posizione e contenuto per rendere possibile un rilevamento automatico della codifica di carattere in uso in ciascuna entità nei casi normali. Inoltre, in molti casi altre sorgenti di informazione sono disponibili in aggiunta allo stesso flusso di dati XML. Due casi possono essere distinti, a seconda che l'entità XML sia presentata al processore senza, o con, qualche informazione (esterna) che l'accompagni. Consideriamo dapprima il primo caso.

Dato che ciascuna entità XML non in formato UTF-8 o UTF-16 deve iniziare con una dichiarazione di codifica XML, in cui i primi caratteri devono essere '<?xml', ciascun processore conforme può rilevare, dopo due o quattro ottetti (byte) di input, quale dei seguenti casi applicare. Nel leggere questa lista, può aiutare conoscere che in UCS-4, '<' è "#x0000003C" e '?' è "#x0000003F", e il "Byte Order Mark" richiesto del flusso dei dati UTF-16 è "#xFEFF".

Questo livello di autorilevazione è sufficiente per leggere la dichiarazione di codifica XML e analizzare l'identificatore di codifica dei caratteri, che è ancora necessario per distinguere i singoli membri di ciascuna famiglia di codici (ad esempio per distinguere UTF-8 da 8859, e le parti di 8859 da ciascun altra, o per distinguere le specifiche pagine di codice EBCDIC in uso, e così via).

Poiché i contenuti della dichiarazione di codifica sono ristretti ai caratteri ASCII, un processore può leggere in modo sicuro l'intera dichiarazione di codifica non appena ha rilevato quale famiglia di codifica è in uso. Poiché in pratica, tutte le codifiche di carattere largamente usate ricadono in una delle categorie sopra citate, la dichiarazione di codifica XML consente un etichettamento "in-band" ragionevolmente affidabile delle codifiche dei caratteri, anche quando le sorgenti esterne dell'informazione a livello di sistema operativo o di protocollo di trasporto sono inaffidabili.

Una volta che il processore ha rilevato la codifica di carattere in uso, può agire appropriatamente, o invocando una routine di input separata per ciascun caso, oppure chiamando la propria funzione di conversione su ciascun carattere di input.

Come ogni sistema auto-etichettante, la dichiarazione di codifica XML non lavorerà se un qualche software cambia il "character set" dell' entità o la codifica senza aggiornare la dichiarazione di codifica. I realizzatori delle routine di codifica di caratteri dovrebbero stare attenti per assicurare l'accuratezza dell'informazione interna e esterna usata per etichettare l'entità.

Il secondo possibile caso si presenta quando l'entità XML è accompagnata dall'informazione di codifica, come in qualche file system e in qualche protocollo di rete. Quando sorgenti multiple di informazioni sono disponibili, la loro priorità relativa e il metodo preferito di gestione di conflitto dovrebbero essere specificati come parte del livello più alto del protocollo usato per consegnare XML. Le regole per la priorità relativa dell'etichetta interna e l'etichetta del "MIME-type" in una intestazione esterna, per esempio, dovrebbero essere parte del documento RFC che definisce i tipi MIME text/xml e application/xml. Negli interessi dell'interoperabilità, tuttavia, le seguenti regole sono raccomandate.

Queste regole si applicano soltanto in assenza di una documentazione a livello di protocollo; in particolare, quando i tipi MIME text/xml e application/xml sono definiti, le raccomandazioni del RFC in questione soprassederanno queste regole.

G. Gruppo di lavoro XML del W3C (non-normativo)

Queste specifiche sono state preparate e approvate per la pubblicazione dal gruppo di lavoro (Working Group) XML del W3C. L'approvazione di queste specifiche da parte del WG non implica necessariamente che tutti i membri del WG hanno votato per la sua approvazione. I membri attuali e originari del XML WG sono

Jon Bosak, Sun (Presidenza);
James Clark (Direzione tecnica);
Tim Bray, Textuality and Netscape (coeditore XML);
Jean Paoli, Microsoft (coeditore XML);
C. M. Sperberg-McQueen, U. of Ill. (coeditore XML);
Dan Connolly, W3C (collegamento W3C);
Paula Angerstein, Texcel;
Steve DeRose, INSO; Dave Hollander, HP;
Eliot Kimber, ISOGEN;
Eve Maler, ArborText;
Tom Magliery, NCSA;
Murray Maloney, Muzmo and Grif;
Makoto Murata, Fuji Xerox Information Systems;
Joel Nava, Adobe;
Conleth O'Connell, Vignette;
Peter Sharpe, SoftQuad;
John Tigue, DataChannel

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