[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 Andrea Marchetti (Istituto Applicazioni Telematiche - CNR) <Andrea.Marchetti@iat.cnr.it> 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>

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

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.

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.

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 "&" e "<". La parentesi angolare destra (>) può essere rappresentata usando la stringa ">", e deve, per compatibilità, essere "escaped" usando o la stringa ">" 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 "'", e il doppio apice (") come """.
 

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 "<" e "&". 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 | PI |  S

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:

• attributi con valori di default, se gli elementi a cui questi attributi si applicano sono presenti nel documento senza le specifiche di valore per quegli attributi, o
• entità (oltre che amp, lt, gt, apos, quot), se i riferimenti a quelle entità sono presenti nel documento, o
• attributi con valori soggetti a normalizzazione, dove l'attributo è presente nel documento con un valore che cambierà come risultato della normalizzazione, o
• tipi di elemento con "element content", se spazi bianchi compaiono direttamente all'interno di qualche istanza di quei tipi.

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 ::=  ISO639Code |  IanaCode |  UserCode [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:

• un codice di linguaggio di due lettere come definito da [ISO 639], "Codici per la rappresentazione dei nomi di linguaggi"
• un identificatore di linguaggio registrato con la Internet Assigned Numbers Authority [IANA]; questi iniziano con il prefisso "i-" (or "I-")
• un identificatore di linguaggio assegnato dall'utente, o convenuto tra le parti per un uso privato; questi devono iniziare con il prefisso "x-" or "X-" per assicurare che non entrino in conflitto con i nomi standardizzati più tardi o registrati con IANA

È 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 "<") 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:

• Per definire l'insieme degli attributi pertinenti a un dato "element type".
• Per definire i tipi di vincoli per questi attributi.
• Per fornire dei valori di default per gli attributi.

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 né #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:

• un riferimento a carattere è elaborato inserendo il carattere referenziato nel valore dell'attributo
• un riferimento a entità è elaborato mediante una elaborazione ricorsiva del testo di sostituzione dell'entità
• un carattere di spazio bianco (#x20, #xD, #xA, #x9) è elaborato inserendo un #x20 nel valore normalizzato, eccetto che un solo #x20 è aggiunto per una sequenza "#xD#xA" che faccia parte di una entità parsed esterna o del valore letterale di una entità parsed interna
• i restanti caratteri sono elaborati inserendoli nel valore normalizzato

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.

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.

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&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:,

• la presenza di un riferimento ad una entità unparsed.
• la presenza di qualsiasi riferimento a entità carattere o entità generale nel DTD al di fuori di un EntityValue o AttValue.
• un riferimento ad una entità esterna in un valore di attributo.

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 "<" e "&" 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

• Certi errori di well-formedness, in particolare quelli che richiedono la lettura delle entità esterne, possono non essere rilevati da un processore non-validante. Esempi includono i vincoli intitolati Entity Declared, Parsed Entity, e No Recursion, così come alcuni dei casi descritti come proibiti nella sezione "4.4 Come un processore XML gestisce le entità e i riferimenti a entità".
• L'informazione passata dal processore XML all'applicazione può variare, a seconda che il processore legga le entità parametriche e quelle esterne. Ad esempio un processore non-validante non può normalizzare i valori degli attributi, includere il testo di sostituzione delle entità interne, o fornire i valori di default degli attributi, dove questo dipenda dall'aver letto le dichiarazioni nelle entità esterne o in quelle parametriche.

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.

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

/* ... */

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:

• I caratteri che iniziano i nomi devono avere una delle categorie Ll, Lu, Lo, Lt, Nl.
• I caratteri dei nomi oltre che i caratteri che iniziano i nomi devono avere una delle categorie Mc, Me, Mn, Lm, or Nd.
• I caratteri nell'area di compatibilità (cioè con codice di carattere maggiore di #xF900 e minore di #xFFFE) non sono consentiti nei nomi XML.
• I caratteri che hanno un font o una decomposizione di compatibilità (cioè quelli con un "tag di formattazione di compatibilità" nel campo 5 dell'archivio -- segnato dal campo 5 che inizia con un "<") non sono permessi.
• I seguenti caratteri sono trattati come caratteri che iniziano i nomi piuttosto che come caratteri nome, poiché il file di proprietà li classifica come Alfabetici: [#x02BB-#x02C1], #x0559, #x06E5, #x06E6.
• I caratteri #x20DD-#x20E0 sono esclusi (in accordo con Unicode, sezione 5.14).
• Il carattere x00B7 è classificato come estensore, poiché la lista di proprietà lo identifica così.
• Il carattere #x0387 è aggiunto come nome carattere, poiché #x00B7 è il suo equivalente canonico.
• I caratteri ':' and '_' sono consentiti come caratteri che iniziano i nomi.
• I caratteri '-' and '.' sono consentiti come caratteri nomi.

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 (&) or with a general entity (&).

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:

• alla linea 4, il riferimento al carattere 37 è espanso immediatamente, e l'entità parametrica "xx" è memorizzata nella tabella dei simboli con il valore "%zz;". poiché il testo di sostituzione non è analizzato di nuovo, il riferimento all'entità parametrica "zz" non è riconosciuto. (E sarebbe un errore se lo fosse, in quanto "zz" non è stata ancora dichiarata.)
• alla linea 5, il riferimento al carattere "<" è immediatamente espanso e l'entità parametrica "zz" è memorizzata con il testo di sostituzione "<!ENTITY tricky "error-prone" >", che è una dichiarazione di entità well-formed.
• alla linea 6, il riferimento a "xx" è riconosciuto, e il testo di sostituzione di "xx" (ovvero "%zz;") è analizzato. A sua volta il riferimento a "zz" è riconosciuto, e il suo testo di sostituzione ("<!ENTITY tricky "error-prone" >") è analizzato. Ora l'entità generale "tricky" è stata dichiarata, con il testo di sostituzione "error-prone".
• alla linea 8, il riferimento all'entità generale "tricky" è riconosciuto, ed è espanso, in questo modo il contenuto completo dell'elemento "test" è la stringa auto-descrivente (e sgrammaticata) This sample shows a error-prone method.

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

• 00 00 00 3C: UCS-4, macchina "big-endian"   (ordine dei byte 1234)
• 3C 00 00 00: UCS-4, macchina "little-endian" (ordine dei byte 4321)
• 00 00 3C 00: UCS-4, ordine dei byte inusuale (2143)
• 00 3C 00 00: UCS-4, ordine dei byte inusuale (3412)
• FE FF: UTF-16, big-endian
• FF FE: UTF-16, little-endian
• 00 3C 00 3F: UTF-16, big-endian, nessun Byte Order Mark (e per cui, in poche parole, in errore)
• 3C 00 3F 00: UTF-16, little-endian, nessun Byte Order Mark (e per cui, in poche parole, in errore)
• 3C 3F 78 6D: UTF-8, ISO 646, ASCII, qualche parte di ISO 8859, Shift-JIS, EUC, o qualche altra codifica a 7-bit, 8-bit, o ad ampiezza mista che assicura che i caratteri ASCII abbiano le loro posizioni, ampiezze, e valori normali; la dichiarazione di codifica reale deve essere letta per rilevare quale di queste si applica, ma poiché tutte queste codifiche usano gli stessi "bit pattern" dei caratteri ASCII, la stessa dichiarazione di codifica può essere letta in modo sicuro.
• 4C 6F A7 94: EBCDIC (la dichiarazione completa di codifica deve essere letta per distinguere quale pagina di codice è in uso)
• altro: UTF-8 senza dichiarazione di codifica, o anche il flusso dei dati è alterato, frammentario, o racchiuso in un involucro di qualche genere

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.

• Se una entità XML è un file, il Byte-Order Mark e la PI di dichiarazione di codifica sono usate (se presenti) per determinare la codifica dei caratteri. Tutti gli altri metodi euristici e le sorgenti di informazioni servono unicamente per un "error recovery".
• Se una entità XML è consegnata con un tipo MIME text/xml, allora il parametro charset sul tipo MIME determina la codifica di carattere. Tutti gli altri metodi euristici e le sorgenti di informazioni servono unicamente per un "error recovery".
• Se una entità XML è consegnata con un tipo MIME application/xml, allora il Byte-Order Mark e la PI di dichiarazione di codifica sono usate (se presenti) per determinare la codifica dei caratteri. Tutti gli altri metodi euristici e le sorgenti di informazioni servono unicamente per un "error recovery".

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.