[This local archive copy mirrored from the canonical site: http://www.agora.ro/~cmatei/xml/RecXMLVR.html; links may not have complete integrity, so use the canonical document at this URL if possible.]

Extensible Markup Language (XML) 1.0

Versiunea în limba engleză se află la adresa: http://www.w3.org/TR/1998/REC-xml-19980210.html.

În limba română el se află la adresa: http://www.agora.ro/~cmatei/xml/RecXMLVR.html.

Traducerea şi adaptarea pentru limba română a fost realizată de către Crystian (cmatei@agora.ro).

Copyright  ©  1998 World Wide Web Consortium, (Massachusetts Institute of Technology, Institut National de Recherche en Informatique et en Automatique, Keio University), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.

Această versiune

Ultima versiune

Editori

Abstract

Statutul acestui document

Acest document specifică o sintaxă creată prin reducerea unui standard de procesare al textului existent şi utilizat pe o arie largă în toată lumea (Standard Generalized Markup Language, ISO 8879:1986(E) amendat şi corectat), pentru utilizarea ei pe World Wide Web. Ea este un produs al W3C XML Activity, despre care puteţi găsi detalii la http://www.w3.org/XML. O listă a recomandăriilor W3C şi a altor documente tehnice poate fi găsită la http://www.w3.org/TR.

Această specificaţie utilizează termenul de URI, care este definit de către [Berners-Lee], o muncă ce se află în desfăşurare care se aşteaptă să întregească [RFC1738] şi [RFC1808].

O listă a erorilor cunoscute a acestei specificaţii este disponibilă la http://www.w3.org/XML/xml-19980210-errata.

Vă rugăm să raportaţi erorile din acest document la xml-editor@w3.org. (N.T. Pentru versiunea românească a acestei specificaţii, vă rugăm să raportaţi erorile la cmatei@agora.ro.)

Anexe

Documentele XML sunt realizate din unităţi de stocare numite entităţi, ce conţin date parsate sau neparsate. Datele parsate sunt realizate din caractere, unele dintre ele formând date caracter iar altele ca marcaje. Marcajele codifică o descriere a schemei de stocare a documentului şi structura logică. XML furnizează un mecanism pentru a impune constrîngeri asupra schemei de stocare şi a structurii logice.

Un modul software numit procesor XML este utilizat pentru a citi documente XML şi pentru a da acces la structura şi conţinutul lor. Se consideră că un procesor XML îşi face munca în spatele unui alt modul, numit aplicaţie. Această specificaţie descrie comportamentul cerut unui procesor XML în termeni ce spun cum trebuie să citească datele XML şi ce informaţii trebuie să-i furnizeze aplicaţiei.

Scopurile proiectate pentru XML sunt:

1. XML trebuie să fie simplu de utilizat pe Internet.
2. XML trebuie să suporte o mare verietate de aplicaţii.
3. XML trebuie să fie compatibil cu SGML.
4. Trebuie să fie uşor să fie scrise programe ce vor procesa documente XML.
5. Numărul facilităţiilor opţionale din XML sunt reduse la minimum, ideal, la zero.
6. Documentele XML trebuie să fie citibile de către utilizatori şi clare într-un mod rezonabile.
7. Designul XML ar trebui să fie pregătită rapid.
8. Designul XML trebuie să fie formal şi concis.
9. Documentele XML trebuie să fie uşor de creat.
10. Caracterul lapidar din marcajele XML să fie de o importanţă minimă.

Această versiune a specificaţiilor XML poate fi distribuită liber, atâta timp cât tot textul cât şi toate notiţele legale rămân intacte.

poate (may)

Documentele care se conformează şi procesoarele pot să facă acest lucru dar nu trebuie să se comporte conform descrierierii.

trebuie (must)

Documentele care se conformează şi procesoarele trebuie să se comporte conform descrierii; altfel vor da o eroare.

eroare (error)

O violare a regulilor din această specificaţie; rezultatele sunt nedefinite. Software-ul specific poate să detecteze şi să raporteze aceste erori şi poate să le soluţioneze.

eroare fatală (fatal error)

O eroare pe care un procesor XML specific trebuie să o detecteze şi să o raporteze aplicaţiei. După întâlnirea unei astfel de erori, procesorul poate continua căutarea unor astfel de erori şi poate să le raporteze aplicaţiei. În loc să proceseze erorile procesorul poate face disponibilă  aplicaţiei informaţia din document, sub formă neprocesată (cu toate datele caracter şi cu marcaje). Oricum, odată ce o eroare fatală a fost descoperită, procesorul trebuie să nu mai continuie procesarea normală. (de exemplu nu mai trebuie să-i furnizeze aplicaţiei în continuare datele şi informaţiile despre structura logică a documentului).

la cererea utilizatorului (to the user option)

Software-ul specializat poate sau trebuie (depinde de verbul modal din propoziţie) să se comporte conform descrierii; dacă o fac, atunci ele trebuie să le furnizeze utilizatorilor posibilitatea de a permite sau nu comportamentul respectiv.

cosntrângere de validitate (validity constraint)

O regulă care se aplică tuturor documentelor XML valide. Violarea acestor constrângeri de validitate sunt erori; ele trebuie, la cererea utilizatorului, să fie raportate de câtre procesoarele XML ce fac şi validare.

cânstrângere pentru documentele bine formate (well-formedness constraint)

O regulă care se aplică tuturor documentelor XML bine formate. Violarea acestor constrângeri sunt erori fatale.

potrivire (match)

(A numelor şi a şirurilor:) Două şiruri sau nume ce sunt comparate trebuie să fie identice. Caracterele cu mai multe reprezentări posibile în ISO/IEC 10646 (de exemplu caracterele cu formă atât precompusă cât şi bayă+diacritică) se potrivesc numai dacă au aceiaşi reprezentare în ambele şiruri. La cererea utilizatorului, procesoarele pot normaliza asemenea caractere la anumite forme canonice. Nu se fac nici un fel de convertiri de mărimi ale caracterelor. (A şirurilor şi regulilor din gramatică:) Un şir se potriveşte cu o producţie gramaticală dacă aparţine limbajului gramaticii generate de acea poducţie. (A conţinutului şi a modelelor de conţinut:) Un element se potiveşte cu declararea lui când se conformează cu modelul descris în constrângerea din Secţiunea 3: Element Valid.

pentru compatibilitate (for compatibility)

O facilitate a XML inclusă doar pentru a asigura faptul că XML-ul rămâne compatibil cu SGML-ul.

pentru interoperabilitate (for interoperability)

O recomandare inclusă pentru a creşte şansele ca documentele XML să poată fi procesate de pocesoarele existente de SGML, ce se supun la WebSGML Adaption Annex to ISO 8879.

Fiecare document are atât o structură logică cât şi una fizică. Fizic, documentul este compus din unităţi numite entităţi. O entitate poate face referinţe la alte entităţi pentru a cauza includerea lor în document. Un document începe într-o rădăcină sau o entitate document. Logic, documentul este compus din declaraţii, elemente, comentarii, referinţe la caractere şi instrucţiuni de procesare, toate fiind indicate în document prin marcaje explicite. Structura fizică şi cea logică trebuie să se îmbine corect, după cum este descris în Secţiunea 4.3.2: Entităţi parsate bine formate.

1. Luat ca şi întreg, se potriveşte cu producţia numită document.
2. Îndeplineşte toate constrângerile pentru documentele bine formate date în această specificaţie.
3. Fiecare entitate parsată ce este referită direct sau indirect în document este bine formată.

1. Conţine unul sau mai multe documente.
2. Este un singur element numit rădăcină (root), sau element document, a cărui parte nu va apare in conţinutul altui element. Pentru toate celelalte elemente, dacă marcajul de început este în conţinutul altui element, marcajul de sfârşit trebuie să fie în acelaşi element. Mai simplu spus, elementele delimitate de marcaje tebuie să coexiste unul în celălalt.

S (spaţiu alb) constă din unul sau mai multe caractere spaţiu (#x20), enter, sfârşit de linie sau tab-uri.
 

Spaţiu alb (White Space)
[3]	S	::= (#x20 | #x9 | #xD | #xA )+

 
Caracterele sunt clasificate pentru simplitate în litere, cifre sau alte caractere. Literele constau în caracter dintr-un alfabet sau o un caracter da bază a unei silabe, urmată probabil de unul sau mai multe caractere combinate sau de un caracter ideografic. Întreaga definiţie a caracterelor specifice din fiecare clasă este dată în Anexa B: Clase de caractere.

Un nume (Name) este un cuvânt ce începe cu o literă sau cu unul dintre puţinele caractere de punctuaţie. El poate continua cu litere, cifre, cratime, liniuţe de subliniere, două puncte sau cu puncte, toate cunoscute ca şi caractere pentru nume. Numele ce încep cu şirul "xml" sau cu alte şiruri ce se potrivesc cu (('X' | 'x') ('M' | 'm') ('L' | 'l')) sunt rezervate pentru standardizare în următoarele versiuni ale acestei specificaţii.

NOTĂ: Caracterul două puncte din numele XML este rezevat pentru experiment ca şi spaţii între nume. Înţelesul lui, se aşteaptă să devină standardizat undeva în viitor, punct în care acele documente care le utilizează în scop experimental vor trebui reactualizate. (Nu este nici o garanţie că că orice mecanism de spaţii între nume adoptat pentru XML va utiliza două puncte ca şi delimitator între nume.) În practică, acest lucru semnifică că autorii nu ar trebui să utilizeze două puncte în numele XML, excepţie făcând acele documente utilizate pentru experimentarea spaţiilor dintre nume, dar procesoarele XML ar trebui să accepte două puncte ca şi caracter din nume.

Tot textul care nu face parte dintr-un marcaj reprezintă datele caracter (character data) ale documentului.

Caracterul and (&) şi paranteza unghiulară deschisă (<) pot apărea în forma lor literală numai atunci când este utilizat ca şi delimitator de marcaj sau într-un comentariu, o instrucţiune de procesare sau o secţiune CDATA. Ele sunt, de asemenea, legale între valorile entităţiilor literale a unei declaraţii de entitate internă; vezi Secţiunea 4.3.2: Entităţi parsate bine formate. Dacă este nevoie de ele în altă parte, ele vor trebui să fie incluse utilizându-se fie referinţele numerice la caractere sau şirurile "&amp;" şi respectiv "&lt;". Paranteza unghiulară închisă (>) poate fi reprezentată utilizând şirul "&gt;" şi trebuie, pentru compatibilitate, să fie inclusă utilizând "&gt;" sau o referinţă la caracter atunci când ea apare în şirul "]]>", când şirul nu delimitează o secţiune CDATA.

În conţinutul elementelor, datele caracter sunt orice şir de caractere ce nu conţine delimitatorul de început al unui marcaj. Într-o secţiune CDATA, datele caracter sunt orice şir de caractere ce nu include delimitatorul de sfârşit al secţiuni CDATA, "]]>".

Pentru a permite valorilor atributelor să conţină atât apostroafe simple cât şi duble, caracterul apostrof sau ghilimeaua (') trebuie să fie reprezentată ca şi "&apos;", iar caracterul ghilimele (") ca şi "&quot;".
 

Dată caracter (Character Data)
[14]	CharData	::= [^<&]* - ([^<&]* ']]>' [^<&]*)

Un exemplu a unei secţiuni CDATA, în care "<greeting>" şi "</greeting>" sunt recunoscute ca şi date caracter şi nu ca marcaje:
 

<![CDATA[<greeting>Hello World!</greeting>]]>

Funcţia unui marcaj într-un document XML, este de a descrie ceea ce conţine şi structura logică şi pentru a asocia perechi de atribute-valori la structura lui logică. XML furnizează un mecanism, numit declaraţia tipului de document, pentru a defini constrângeri pe structura logică şi pentru a suporta unităţi de stocare predefinite. Un document XML este valid dacă are asociată o declaraţie de tip de document şi dacă documentul este conform constrângerilor din ea.

Declaraţia tipului de document trebuie să apară înaintea primului element din document.
 

Prologul (Prolog)
[22]	polog	::= XMLDecl? Misc* (doctypedecl Misc*)?
[23]	XMLDecl	::= '<?xml' VersionInfo EncodingDecl? SDDecl? S? '?>')
[24]	VersionInfo	::= S 'version' Eq ( 'VesionNum' | "VersionNum")
[25]	Eq	::= S? '=' S?
[26]	VersionNum	::=([a-zA-Z0-9_.:] | '-')+
[27]	Misc	::= Comment | PI | S

 
Declaraţia tipului de document XML (document type declaration) conţine sau indică spre declaraţile de marcaje ce furnizează a o gramatică pentru o clasă de documente. Această gramatică este cunoscută sub numele de definiţia tipului de document sau DTD. Declaraţia tipului de document poate indica spre un subset extern (un tip special de entitate externă) ce conţine declaraţii de marcaje sau poate conţine declaraţii de marcaje direct într-un subset intern sau în ambele părţi. DTD-ul unui document este format din ambele subseturi luate împreună.

Declaraţia unui marcaj (markup declaration) este o declarare a unui tip de element, o declarare a unei liste de atribute, declararea unei entităţi sau a unei declaraţii de notaţie. Toate aceste declaraţii pot fi conţinute în întregime sau numai o parte dintre ele între entităţiile parametru, după cum sunt descrise în censtrângerile documentelor bine formate şi valide. Pentru mai multe informaţii vezi Secţiunea 4: Structuri fizice.
 

Definiţia tipului de document (Document Type Definition)
[28]	doctypedecl	::= '<!DOCTYPE' S Name (S ExternalID)? S? ( ' [ ' (markupdecl | PEReference | S)* ']' S?)? '>'	[VC: Tipul elementului rădăcină]
[29]	markupdecl	::= elementdecl | AttlistDecl | EntityDecl | NotationDecl | PI | Comment	[VC: Declaraţie/ Includerea entităţiilor parametru propice]  [WFC: Entităţile parametru din subsetul intern]

 
Declaraţia marcajului poate fi în întregime sau numai în parte formată din textul de înlocuit de la entităţiile parametru. În producţiile de mai târziu din această specificaţie referitoare la nonterminali individuali, sunt descrise declaraţiile după ce toate entităţiile parametru au fost incluse.

VC (Constrângere de validitate): Tipul de element rădăcină. Numele (Name) în declaraţia tipului de document trebuie să se potrivească cu tipul elementului rădăcină.

VC (Constrângere de validitate):  Declaraţie/ Includerea entităţiilor parametru propice. Textul de înlocuit al entităţii parametru  trebuie să fie inclus propice în declaraţia de marcaj. Altfel spus, dacă primul caracter sau ultimul caracter al unei declaraţii de marcaj (markupdecl mai sus) este conţinut în textul de înlocuit pentru referinţa la o entitate parametru, ambele trebuie să fie conţinute în acelaşi text de înlocuit.

WFC (Constrângere de document bine format): Entităţile parametru din subsetul intern. În subsetul intern al DTD-ului, referinţele la entităţile parametru pot apare numai unde pot apare şi declaraţile de marcaje. (Aceasta nu se aplică la referinţele ce apar în entităţiile parametru externe sau în subsetul extern.)

Un exemplu de document XML cu o declaraţie de tip de document:
 

<?xml version="1.0"?>  <!DOCTYPE greeting SYSTEM "hello.dtd">  <greeting>Hello World!</greeting>

 
Identificatorul sistem "hello.dtd" este URI-ul unui DTD al unui document.

Declaraţiile pot fi date şi local ca în exemplul de mai jos:
 

<?xml version="1.0" encoding="UTF-8" ?>  <!DOCTYPE greeting [      <!ELEMENT greeting (#PCDATA)>  ]>  <greeting>Hello World!</greeting>

 
Dacă sunt utilizate ambele subseturi, atât cele externe, cât şi cele interne, se consideră că subsetul intern va apare înaintea subsetului extern. Aceasta va avea ca şi efect faptul că declaraţiile entitatăţilor şi a listelor de atribute în subsetul intern vor avea o precedenţă faţă de cele din subsetul extern.

Dacă nu există declaraţii de marcaje externe, declaraţia documentului indpendent nu are sens. Dacă există declaraţii de marcaje externe, dar nu există declararea documentului independent este asociată automat valoarea "no".

Un document XML pentru care standalone="no" poate fi convertit printr-un algoritm într-un document independent, ce poate fi cerut de anumite aplicaţii de livrare prin reţea.
 

• atributelor cu valori implicite, dacă elementele asupa cărora se aplică apar în document fără specificarea valorilor acestor atribute sau
• entităţilor (altele decât amp, lt, gt, apos, quot), dacă referinţele la acele entităţi apar în document sau
• atributelor a căror valoare intră în procesul de normalizare, unde atributele apar în document cu o valoare care se va schimba ca şi rezultat al normalizării sau
• tipurilor de elemente ce au şi conţinut, dacă spaţiile albe apar direct în orice instanţă ale acelor tipuri.

Un procesor XML trebuie întotdeauna să trimită toate caracterele ce nu sunt marcaje spre aplicaţie. Un procesor XML validator trebuie să informeze aplicaţia care dintre aceste caractere constituie spaţii albe ce apar în conţinutul unui element.

Un atribut special numit "xml:space" poate fi ataşat unui element pentru a semnala o intenţie că în acel element, spaţiile albe ar trebui păstrate de către aplicaţie. În documentele valide, acest atribut, ca şi celelalte trebuie să fie daclarat dacă este utilizat. Când este declarat, trebuie dat ca şi tip enumeraţie, a cărui valori posibile sunt "default" şi "preserve". De exemplu:
 

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

 
Valoarea "default" semnalează că modurile de procesare implicite ale spaţiilor albe ale aplicaţiilor sunt acceptabile pentru acest document; valoarea "preserve" indică intenţia ca aplicaţia să păstreze toate spaţiile albe. Această intenţie declarată se consideră că se aplică la toate elementele din conţinutul elementelor în care a fost specificată, mai puţin acolo unde a fost suprascrisă cu o altă instanţă a atributului "xml:space".

Elementul rădăcină al oricărui document se consideră că nu are nici o intenţie în ceea ce priveşte manipularea spaţiilor de către aplicaţie, mai puţin atunci când furnizează o valoare a acestui atribut sau când atributul este declarat cu o valoare implicită.

Pentru a simplifica munca aplicaţilor, oricând o entitate parsată externă sau valoarea entitate literală a unei entităţi parsate internă  conţine fie combinaţia literală de două caractere "#xD#xA" sau literalul independent #xD, procesorul trebuie să-i transmită aplicaţiei numai caracterul #xA. (Acest comportament poate fi produs cu uşurinţă prin conversia tuturor sfârşiturilor de linii în caracterul #xA, la intrare, înainte de parsare.)

• un cod de limbaj de două litere precum este definit în [ISO639], "Codes for the representation of names of languages"
• un identificator de limbaj înregistrat cu Internet Assigned Numbers Autority (IANA); acestea încep cu prefixul "i-"(sau cu "I-")
• un identificator de limbaj asociat de către utilizator sau agreat între părţi pentru un uz privat; acestea trebuie să înceapă cu prefixul "x-" sau "X-" pentru a fi siguri că nu intră în conflict cu nume standardizate sau înregistrate mai târziu cu IANA.

Este un obicei să se dea codul limbajului cu litere mici şi codul ţării (dacă există) cu litere mari. De menţionat că aceste valori, spre deosebire de alte nume în documentele XML, nu sunt senzitive la mărimea literelor.

De exemplu:
 

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

 
Intenţia declarată cu "xml:lang" se consideră că se aplică la toate atributele şi la conţinutul elementelor în care este specificat, mai puţin atunci când este suprascrisă cu o altă instanţă a xml:lang de către un alt element din acel conţinut.

O simplă declaraţie xml:lang poate lua forma:
 

xml:lang NMTOKEN #IMPLIED

 
dar valori specifice implicite pot fi deasemenea date, dacă este adecvat. Într-o colecţie de poezii franceze pentru studenţi englezi, cu glosă şi notiţe în engleză, atributul xml:lang poate fi declarat astfel:
 

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

 

WFC (Contrângere pentru documente bine formate): Potrivirea tipului elementului. Numele (Name) din marcajul de la sfârşitul elementului trebuie să se potrivească cu tipul elementului din marcajul de la început.

VC (Constrângere de validitate): Validitatea elementului. Un element este valid dacă există o declaraţie ce se potriveşte cu elementdecl unde numele (Name) se potriveşte cu tipul elementului şi se întâmplă una dintre următoarele situaţii:

1. Declaraţia se potriveşte cu EMPTY şi elementul nu are conţinut.
2. Declaraţia se potriveşte cu children, iar secvenţa de elemente copil aparţine limbajului generat de expresia normală din modelul conţinutului, cu spaţii albe opţionale (caractere ce se potrivesc cu nonterminalul S) între fiecare pereche de elemente copil.
3. Declaraţia se potriveşte cu Mixed, iar conţinutul constă din date caracter şi elemente copil a căror tipuri se potrivesc cu nume din modelul conţinutului.
4. Declaraţia se potriveşte cu ANY, şi tipurile oricărui element copil au fost declarate.

WFC (Constrângere pentru documentele bine formate): Specificaţie pentru unicitatea unui atribut. Nici un nume de atribut nu poate apărea de mai multe ori în în acelaşi marcaj de început sau în acelaşi marcaj al unui element gol.

VC (Constrângere de validitate): Tipul valorii atributului. Atributul trebuie să fi fost declarat; valoarea trebuie să fie de tipul celei declarate pentru atribut. Pentru tipurile atributelor vezi Secţiunea 3.3: Declaraţile listelor de atribute)

WFC (Constrângere pentru documentele bine formate): Fără referinţe la entităţi externe. Valorile atributelor nu pot conţine referinţe directe sau indirecte spre entităţi externe.

WFC (Constrângere pentru documentele bine formate): Fără < în valoarea atributelor. Textul de înlocuit al oricărei entităţi referite direct sau indirect în valoarea atributului (altul decât "&lt;"), nu poate conţine caracterul <.

Exemple de elemente goale:
 

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

Declaraţia tipului unui element (element type declaration) ia forma:
 

Declaraţiile tipurilor de elemente (Element Type Declaration)
[45]	elementdecl	::= '<!ELEMENT' S Name S contentspec S? '>'	[VC: Declaraţie de tip de element unică]
[46]	contentspec	::='EMPTY' | 'ANY' | Mixed | children

 
unde numele (Name) indică tipul elementului ce va fi declarat.

Validity Constraint (Constrângere de validitate): Declaraţie de tip de element unică. Nici un element nu poate fi declarat de mai multe ori.

Conţinutul unui element se potriveşte cu un model de conţinut, dacă şi numai dacă este posibil să se extragă o cale prin modelul conţinutului, conformându-se operatorilor ce impun secvenţa, alegera şi repeţiţia şi dacă fiecare element din conţinut se potriveşte cu un element din modelul conţinutului. Pentru compatibilitate, este o eroare dacă un element din document se potriveşte cu mai mule instanţe a unui tip de element din modelul de conţinut. Pentru mai multe informaţii, vezi Anexa E: Modele de conţinut deterministice.

VC(Constrângere de validitate): Grup/Includerea entităţilor parametru propice. Textele de înlocuit ale entităţilor parametru trebuie să se potrivescă cu grupurile parametrizate. Cu alte cuvinte, dacă una dintre parantezele deschise sau închise dintr-o alegere (choise), secvenţă (seq) sau mixaj (Mixed), este conţinută într-un text de înlocuit pentru o entitate parametu, atunci şi perechea ei trebuie să fie conţinută în acelaşi text de înlocuit.

Pentru interoperabilitate, dacă o referinţă la o entitate parametru apare într-o alegere (choise), secvenţă (seq) sau mixaj (Mixed), textul ei de înlocuit nu trebuie să fie gol şi nici primul sau ultimul caracter non-spaţiu nu trebuie să fie un conector (| sau ,).

VC (Constrângere de validitate): Fără tipuri duplicate. Acelaşi nume nu trebuie să apară de mai multe ori într-un singur conţinut mixat.

• Pentru a defini un set de atribute ce aparţin unui tip de element.
• Pentru a stabili constrângeri legate de tipul acestor atribute.
• Pentru a da valori implicite pentru atribute.

Dacă sunt declarate mai multe liste de atribute (AttlistDecl)pentru acelaşi tip de element, conţinutul tuturora este concatenat. Dacă există mai multe definiţii pentru acelaşi atribut al unui tip de element, numai prima dinte este luată în considerare, celelalte fiind ignorate. Pentru interoperabilitate, cei ce scriu un DTD pot să scrie mai multe declaraţii de liste de atribute pentru acelaşi tip de element, cel mult o definiţie pentru un nume dat de atribut şi cel puţin o definiţie a unui atribut în fiecare declaraţie a unei liste de atribute. Pentru interoperabilitate, procesorul XML poate, la cererea utilizatorului, să genereze o atenţionare atunci când pentru un tip de element sunt date mai multe declaraţii de liste de atribute sau atunci când pentru un anumit atribut dat sunt date mai multe declaraţii de atribute, dar toate acestea nu sunt erori.

VC (Constrângere de validitate): ID. Valorile tipului ID trebuie să se potrivească cu producţia Name. Un nume nu trebuie să apară de mai multe ori într-un document XML ca şi valoare a acestui tip; de exemplu, valorile ID trebuie să identifice într-un mod unic elementele de care ţin.

VC (Constrângere de validitate):  Un ID pentru un tip de element. Nici un tip de element nu poate avea specificat mai mult de un atribut ID.

VC (Constrângere de validitate): IDREF. Valorile de tip IDREF trebuie să se potrivească cu producţia Name şi valoriile de tip IDREFS trebuie să se potrivească cu producţia Names; fiecare nume (Name) trebuie să se potrivească cu valoarea unui atribut ID dintr-un element din documentul XML; de exemplu, IDREF trebuie să se potrivească cu valoarea unui atribut ID.

VC (Constrângere de validitate): Numele entităţii. Valorile tipului ENTITY trebuie să se potrivească cu producţia Name, iar valorile de tip ENTITIES trebuie să se potrivească cu poducţia Names; fiecare nume (Name) trebuie să se potrivească cu numele unei entităţi neparsate declarate în DTD.

VC (Constrângere de validitate): Numele cuvântului. Valorile tipului NMTOKEN trebuie să se potrivească cu producţia Nmtoken; valorile tipului NMTOKENS trebuie să se potrivească cu producţia Nmtokens.

VC (Constrângere de validitate): Atributele notaţie. Valorile acestui tip trebuie să se potrivească cu unul dintre numele notaţilor (notation) incluse în declaraţie; toate numele de notaţii din declaraţie trebuie să fi fost declarate.

VC (Constrângere de validitate): Enumerare. Valorile acestui tip trebuie să se potrivească cu unul dintre cuvintele din declaraţia Nmtoken .

VC (Contrângere de validitate): Atribut obligatoriu. Dacă declaraţia implicită conţine cuvântul cheie #REQUIRED, atunci atributul va trebui specificat în toate elementele tipului respectiv în listele lor de atribute.

VC (Constrângere de validitate): Valoare implicită legală. Valoarea implicită declarată trebuie să se supună constrângerilor lexicale din declaraţia tipului de atribut.

VC (Constrângere de validitate): Valoare implicită fixă. Dacă un atribut are o valoare implicită declarată împreună cu cuvântul cheie #FIXED, instanţele acelui atribut trebuie să se potrivească cu valoarea implicită.

• o referinţă la un caracter este procesată prin adăugarea caracterului referit la valoarea atributului
• o referinţă la o entitate este procesată recursiv prin înlocuirea a textului de înlocuit
• un caracter spaţiu (#x20, #xD, #xA, #x9) este procesat prin adăugarea valorii #x20 la valoarea normalizată, cu excepţia că doar un singur caracter #x20 este adăugat pentru o secvenţă "#xD#xA" ce este parte a unei entităţi externe parsate sau a unei valori a unei entităţi literale dintr-o entitate internă parsată
• alte caractere sunt normalizate prin adăugarea lor la valoarea normalizată

Toate atributele pentru care nu a fost citită nici o declaraţie trebuie tratate de către un parser non-validator ca şi cum ar fi declarate CDATA.

Dacă cuvântul cheie al secţiunii este INCLUDE, atunci conţinutul secţiunii condiţionale este parte a DTD-ului. Dacă cuvântul cheie al secţiunii condiţionale este IGNORE, atunci conţinutul secţiunii condiţionale nu face logic parte din DTD. De menţionat că pentru o parsare corectă, trebuie citite chiar şi conţinutul secţiuniior condiţionale ignorate, pentru a detecta secţiuniile condiţionale incluse în secţiunea curentă şi pentru a fi siguri că sfârşitul secţiunii ignorate, cea mai cuprinzătoare, este ales corect. Dacă o secţiune codiţională ce are ca şi cuvânt cheie INCLUDE, apare în conţinutul unei secţiuni condiţionale cu cuvântul cheie IGNORE, atunci ambele secţiuni pomenite vor fi ignorate.

Dacă cuvântul cheie al secţiunii condiţionale este o referinţă la o entitate parametru, atunci entitatea parametru trebuie înlocuită cu conţinutul său înainte ca procesorul să decidă dacă să includă sau să ignore secţiunea condiţională.

Un exemplu:
 

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

Entităţile pot fi parsate sau neparsate. Conţinuturile unei entităţilor parsate (parsed entity) sunt referite pentru textele înlocuitoare; acest text este considerat o parte integrantă a documentului.

O entitate neparsată (unparsed entity) este o resursă al cărei conţinut, poate sau nu poate să fie text, iar dacă este text, poate să nu fie XML. Fiecare entitate neparsată are asoiată o notaţie, identificată prin nume. În spatele cerinţei ca un procesor XML să-i facă disponibile unei aplicaţii, identificatorii entităţii şi ai notaţiei, XML-ul nu face nici o restricţie asupra conţinutului entităţilor neparsate.

Entităţile parsate sunt invocate prin nume, utilizând referinţe la entităţi; entităţile neparsate prin nume, dat ca şi valoare a atributelor ENTITY sau ENTITIES.

Entităţile generale (general entities) sunt entităţile ce sunt utilizate în conţinutul unui document. În această specificaţie, entităţile generale sunt uneori referite cu ajutorul termenului necalificat entitate, atunci când acesta nu produce confuzii. Entităţile parametru sunt entităţi parsate ce sunt utilizate în interiorul DTD-ului. Aceste două tipuri de entităţi utilizează forme diferite de referinţe şi sunt recunoscute în contexte diferite. Mai mult, ele ocupă diferite domenii de nume; o entitate parametru şi o entitate generală cu acelaşi nume, sunt două entităţi distincte.

WFC (Constrângere pentru documentele bine formate): Caracter Legal. Caracterele referite prin utilizarea referinţelor la caractere trebuie să respecte producţia Char.

O referinţă la o entitate (entity reference) indică spre conţinutul unei entiţăti cu nume. Referinţele spre entităţile generale parsate, utilizează caracterele (&) şi (;) ca şi delimitatori. Referinţele la entităţile parametru (parameter-entity references) utilizează semnul procent (%) şi punctul şi virgula (;) ca şi delimitatori.
 

Referinţa la o entitate (Entity Reference)
[67]	Reference	::= EntityRef | CharRef
[68]	EntityRef	::= '&' Name ';'	[WFC: Entitate declarată]  [VC: Entitate declarată]  [WFC: Entitate parsată]  [WFC: Fără recursivitate]
[69]	PEReference	::= '%' Name ';'	[VC: Entitate declarată]  [WFC: Fără recursivitate]  [WFC: În DTD]

 

WFC (Constrângere pentru documente bine formate): Entitate declarată. Într-un document fără nici un DTD, într-un document ce are doar un subset DTD intern ce nu conţine nici o referinţă la entităţi parametru sau într-un document cu "standalone='yes'", numele (Name) dat în referinţa la entitate trebuie să se potriveascu cu cea dată în declaraţia entităţii, cu exepţia că documentele bine formate nu trebuie să declare nici una dintre entităţiile: amp, lt, gt, apos, quot. Declaraţia unei entităţi parametru trebuie să preceadă orice referinţă spre ea. Similar, declaraţia unei entităţi generale trebuie să preceadă orice referinţă la ea, ce apare în valoarea implicită, într-o declaraţie a unei liste de atribute.

De menţionat că, dacă există entităţii declarate în subsetul extern sau în entităţiile parametru externe, un procesor non-validator nu este obligat să le citească şi să le proceseze declaraţiile; pentru astfel de documente, regula că o entitate trebuie declarată este o constrângere pentru documente bine formate numai dacă standalone='yes'.

VC (Constrângere de validitate): Entitate declarată. Într-un document cu un subset extern sau cu entităţi parametru externe cu "standalone='no'", numele (Name) dat în referinţa parametru trebuie să se potrivească cu cel dat într-o declaraţie a unei entităţi. Pentru interoperabilitate, documentele valide ar trebui să declare entităţiile amp, lt, gt, apos şi quot în forma specificată în Secţiunea 4.6.: Entităţi predefinite. Declaraţia unei entităţi parametru trebuie să preceadă orice declaraţie spre ea. Similar, declaraţia unei entităţi generale trebuie să preceadă orice referinţă spre ea, referinţă ce poate apare în valoarea implicită într-o declaraţie a unei liste de atribute.

WFC (Constrângere pentru documentele bine formate): Entitate parsată. O referinţă la o entitate nu trebuie să conţină numele unei entităţi neparsate. Entităţile neparsate pot fi referite numai în valorile atributelor declarate a fi de tipul ENTITY sau ENTITIES.

WFC (Constrângere pentru documentele bine formate): Fără recursivitate. O entitate parsată nu trebuie să conţină a referinţă recursivă la ea însăşi, nici direct, nici indirect.

WFC (Constrângere pentru documente bine formate): În DTD. Referinţele la entităţile parametru pot apare numai în DTD.

O entitate internă este o entitate parsată.

Exemplu al unei declaraţii a unei entităţi interne:
 

<!ENTITY Pub-status "This is a pre-release of the specification.">

VC(Constrângere de validitate): Notaţie declarată. Numele (Name) trebuie să se potrivească cu numele declarat al unei notaţii.

Un procesor XML ar trebui să trateze un caracter non-ASCII dintr-un URI prin reprezentarea lui în setul UTF-8 prin unul sau mai mulţi octeţi şi apoi prin schimbarea acestor octeţi printr-un mecanism de schimbare URI (de exemplu prin cenvertirea fiecăriu octet la forma %HH, unde HH este o reprezentare hexazecimală a valorii octetului).

În plus la un identificator sistem, un identificator extern poate să-i includă un identificator public (public identifier). Un procesor XML ce încearcă să încarce conţinutul unei entităţi poate utiliza identificatorul public pentru a încerca să genereze un URI alternativ. Dacă procesorul este incapabil să facă acest lucru, atunci el trebuie să utilizeze URI-ul specificat în literalul sistem. Înainte de a se încerca o potrivire, toate şirurile de spaţii albe din identificatorul public trebuie să fie normalizate la câte un singur caracter spaţiu (#x20), iar spaţiile albe de la început şi de la sfârşit trebuie înlăturate.

Exemple de declaraţii de entităţi externe:
 

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

O consecinţă a entităţilor bine formate este faptul că structurile fizică şi logică a unui document XML sunt bine îmbricate; nici un marcaj de început, de sfârşit, nici un marcaj marcaj gol, nici un element, comentariu, instrucţiune de procesare, referinţă caracter sau referinţă entitate nu poate începe într-o entitate şi să se termine în alta.

Entităţile codificate cu ajutotul UTF-16, trebuie să înceapă cu marcajul ordinii octeţilor (Byte Order Mark) descris de către ISO/IEC 10646 Anexa E şi de către Unicode Anexa B (caracterul ZERO WIDTH NO-BREAK SPACE, #xFEFF). Acesta este doar o semnătură de codificare, deci nu face parte din nici un marcaj sau dată caracter din documentul XML. Procesoarele XML trebuie să fie capabile să utilizeze acest caracter pentru a face diferenţa dintre documentele codificate cu UTF-8 şi cu UTF-16.

Deşi unui procesor XML i se cere să citească doar entităţi codificate cu UTF-8 sau UTF-16, este cunoscut faptul că mai există şi alte codificări utilizate în lume, şi poate că există dorinţa de ca procesoare XML care să poată citi şi entităţi care le folosesc. Entităţiile parsate ce sunt stocate utilizându-se alte codificări decât UTF-8 sau UTF-16, trebuie să înceapă cu o declaraţie de text (text declaration) ce conţine o declaraţie de codificare:
 

Declaraţia codificării (Encoding Declaration)
[80]	EncodingDecl	::= S 'encoding' Eq ('"' EncName '"' | "'" EncName "'")
[81]	EncName	::= [A-Za-z] ([A-Za-z0-9._] | '-')*	/*Numele codificării conţine numai caractere latine*/

 
În entitatea document, declaraţia codificării este o parte a declaraţiei XML. EncName dă numele codificării utilizate.

Într-o declaraţie de codificare, valorile "UTF-8", "UTF-16", "ISO-10646-UCS-2" şi "ISO-10646-UCS-4" trebuie să fie utilizate pentru diferite codificări şi transformări ale Unicode / ISO / IEC 10646, valoriile "ISO-8859-1", "ISO-8859-2", ... şi "ISO-8859-9" trebuie să fie utilizate pentru părţi ale ISO 8859, iar valoriile "ISO-2022-JP", "Shift_JIS", şi "EUC-JP" trebuie să fie utilizate pentru diferite forme de codificare ale JIS-0208-1997. Procesoarele XML pot recunoaşte şi alte codificări; este recomandabil ca codificăriile înregistrate (ca şi seturi de caractere) la Internet Assigned Numbers Authotity [IANA], altele decât cele pomenite deja, să fie referite utilizându-se numele lor înregistrate. De menţionat că aceste nume înregistrate sunt definite ca fiind insenzitive la mărimea literelor, deci procesoarele care doresc să le recunoască trebuie să o facă într-un mod insenzitiv la mămimea literelor.

În absenţa unor informaţii furnizate de un protocol de transport extern (de exemplu HTTP sau MIME), avem de a face cu o eroare, atunci când o entitate ce are o declaraţie de codificare şi îi este prezentată procesorului utilizându-se o altă codificare decât cea declarată, atunci când declaraţia de codificare apare în altă parte decât la începutul unei entităţii externe sau atunci când o entitate nu începe nici cu marcajul ordinii octeţilor (Byte Order Mark) şi nici cu o declaraţie de codificare şi utilizează o altă codificare decât UTF-8. De menţionat faptul că, odată ce ASCII este un subset al lui UTF-8, pentru entităţiile ce utilizează doar setul ASCII nu este necesar să posede o declaraţie a codificării.

Avem de a face cu o eroare fatală, atunci când un procesor XML întâlneşte o entitate cu o codificare pe care nu o poate procesa.

Exemple de declaraţii de codificare:
 

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

Referinţă în conţinut

determină o referinţă aflată oriunde între marcajul de început şi marcajul de sfârşit al unui element; corespunde non-terminalului content.

Referinţă în valoarea atributelor

determină o referinţă aflată în valoarea unui atribut într-un marcaj de început sau dat ca şi valoare implicită în declaraţia unui atribut; corespunde non-terminalului AttValue.

Apare ca şi valoare a unui atribut

determină un nume (Name), nu o referinţă, ce apare ca şi valoare a unui atribut ce a fost declarată de tip ENTITY sau ce apare ca şi una dintre unitaţile (tokens) separate prin spaţiu, în valoarea unui atribut ce a fost declarat de tip ENTITIES.

Referinţă în valoarea entităţii

determină o referinţă dintr-un parametru sau o valoare literale a unei entităţi interne în declararea unei entităţi; corespunde non-terminalului EntityValue.

Referinţă în DTD

determină o referinţă aflată într-un subset DTD intern sau extern, dar în afara unei valori a unei entităţii (EntityValue) sau a unei valori a unui atribut (AttValue).

Regula se bazează pe recunoaşterea că includerea automată furnizată de mecanismul entităţilor din SGML şi XML, proiectat la început pentru a suporta modularitate în crearea documentelor, nu este în mod necesar în concordanţă cu alte aplicaţii şi în particular, cu navigatoarele. Navigatoarele, de exemplu, când întâlnesc o referinţă la entitate externă parsată, pot alege indicarea vizuală a prezenţei unei entităţi şi poate să o încarce şi să o afişeze numai la cerere.

• apariţia unei referinţe la o entitate neparsată.
• apariţia oricărui caracter sau a unei referiţe la o entitate generală în DTD, excepţie fiind în valoarea atribut (EntityValue) sau în valoarea entitate (AttValue).
• o referinţă la o entitate externă în valoarea unui atribut.

Valoarea literală a entităţii, aşa cum este ea dată în declaraţia entităţii (EntityValue) poate conţine referinţe la caractere, la entităţi parametru şi la entităţi generale. Astfel de referinţe, trebuie să fie conţinute în întregime în valoarea literală a entităţii. Textul efectiv de înlocuit ce este inclus după descrierea anterioară trebuie să conţină textul de înlocuit al oricărei entităţi parametru referite şi trebuie să conţină toate caracterele referite, în locul oricărei referinţe la caracter în valoarea literală a entităţii; oricum, referinţele la entităţi generale trebuie lăsate aşa cum sunt, neexpandate. De exemplu, dată fiind următoarea declaraţie:
 

<!ENTITY % pub "&#xc9;digitions Gallimard">  <!ENTITY rights "All rights reserved">  <!ENTITY book "La Peste: Albert Camus,      &#xA9; 1947 %pub;. &rights;">

 
textul de înlocuit al entităţii "book" este:
 

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

 
Referinţa la entitatea generală "%rights;" va fi expandată atunci când referinţa "&book;" va trebui să apară în conţinutul documentului sau în valoarea unui atribut.

Aceste reguli simple pot avea repercursiuni complexe; pentru o discuţie mai detailată a unui exemplu mai dificil, vezi Anexa D: Expandarea referinţelor la entităţi şi la caractere.

Toate procesoarele XML trebuie să recunoască aceste entităţi chiar dacă sunt declarate sau nu. Pentru interoperabilitate, documenetele XML valide trebuie să declare aceste entităţi, împreună cu celelalte entităţi, înainte de a le utiliza. Dacă entităţile în discuţie sunt declarate, ele trebuie să fie declarate ca şi entităţi interne a căror text de înlocuit să fie un doar caracterul ce a fost înlocuit sau să fie declarate ca şi referinţe la aceste caractere, cum este arătat mai jos:
 

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

 
De menţionat că caracterele < şi & din declaraţiile "lt" şi "amp" sunt înlocuite de două ori pentru a îndeplini condiţia ca înlocuirea entităţii să fie bine formată.

Declaraţiile de notaţii (notation declarations) furnizează un nume pentru notaţie, pentru utilizarea acestuia în declaraţiile unor entităţi sau liste de atribute şi în specificaţiile atributelor şi un identificator extern pentru notaţie, ce va permite procesoarelor XML sau aplicaţiilor client să localizeze o aplicaţie ce va veni în ajutor, capabilă să proceseze datele dintr-o notaţie dată.
 

Declaraţii de notaţii (Notation Declarations)
[82]	NotationDecl	::= '<!NOTATION' S Name S (ExternalID | PublicID) S? '>'
[83]	PublicID	::= 'PUBLIC' S PubidLiteral

 
Procesoarele XML trebuie să le furnizeze aplicaţiilor numele şi identificatorul extern al oricărei notaţii declarate şi referită în valoarea unui atribut, în definiţia unui atribut sau în declaraţia unei entităţi. Ele pot în plus să descompună identificatorul extern într-un identificator system, într-un nume de fişier sau în alte informaţii ce vor permite aplicaţiei să apeleze un procesor pentru datele din notaţia descrisă. (Oricum, este o eroare ca documentele XML să declare şi să facă referinţe la notaţii pentru care nu există aplicaţii specifice disponibile pe sistemul pe care rulează procesorul XML şi aplicaţia XML.)

Procesoarele validatoare şi non-validatoare seamănă prin faptul că trebuie să raporteze violările constrângerilor pentru documentele bine formate prezente în această specificaţie, din entitatea document şi din orice altă entitate pe care ele o citesc.

Procesoarele validatoare (validating processors) trebuie să raporteze violările constrângerilor date în DTD şi orice eşec al completitudinii constrângerilor de validare date în această specificaţie. Pentru a face acest lucru, procesoarele DTD trebuie să citească şi să proceseze tot DTD-ul şi toate entităţile externe spre care se fac referiri în document.

Procesoarelor non-validatoare li se cere să verifice numai entitatea document, incluzând întregul subset DTD intern, pentru constrângerile pentru documentele bine formate. Odată ce lor nu li se cere să verifice validitatea documentului, lor li se cere să proceseze toate declaraţile pe care le citesc din subsetul DTD-ului intern şi din orice entitate parametru pe care o citesc, până la prima referinţă la o entitate parametru pe care nu o mai citesc; cu alte cuvinte, ele trebuie să utilizeze din acele declaraţii pentru a normaliza valorile atributelor, pentru a include textele de înlocuit ale entităţilor interne şi pentru a furniza valorile implicite ale atributelor.
Ele nu trebuie să proceseze declaraţiile de entităţi sau declaraţiile listelor de atribute întâlnite după o referinţă la o entitate parametru ce nu este citită, odată ce acea entitate poate conţine declaraţii ce ar trebui suprascrise.

• Anumite erori determinate de constrângerile pentru documentele bine formate, în special acelea ce necesită citirea entităţilor externe, pot să nu fie detectate de către un procesor non-validator. Exemplele includ constrângerile de sub titlurile Entitate declarată, Entitate parsată şi Fără recursivitate, ca şi câteva dintre cazurile descrise ca şi interzis din Secţiunea 4.4: Tratamentul aplicat de către procesorul XML entităţiilor şi referinţelor.
• Informaţiile transmise de către procesor către aplicaţie pot varia, în funţie de faptul că procesorul citeşte sau nu entităţile parametru şi pe cele externe. De exemplu, un procesor non-validator nu poate normaliza valorile atributelor, include şi textul de înlocuit al entităţilor interne sau să furnizeze valorile implicite ale atributelor, iar unde face acest lucru depinde dacă a citit entităţile parametru şi cele externe.

Într-o expresie din partea dreaptă a unei reguli, următoarele expresii sunt utilizate pentru a se potrivi cu şiruri cu unul sau mai multe caractere:

#xN

unde N este un întreg hexazecimal. Expresia se potriveşte cu un caracter în ISO/IEC 10646, al cărei valoare codificată canonic (UCS-4), atunci când este interpretat ca şi număr binar fără semn, are valoarea indicată. Numărul de numere de zero de la începutul expresiei #xN este nesemnificativ; numărul de cifre zero de la început din valorii codificate corespondente este guvernat de codificarea carcterelor utilizată curent şi nu este semnificativ pentru XML.

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

se potriveşte cu orice caracter a cărui valoare intră în gama (gamele) indicată (inclusiv).

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

se potriveşte cu orice caracter a cărui valoare este în afara gamei indicate.

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

se potriveşte cu orice caracter ce are o valoare diferită de cele ale caracterelor date.

"string"

se potriveşte cu un şir literal ce se potriveşte cu cel dat între ghilimelele duble.

'string'

se potriveşte cu un şir literal ce se potriveşte cu cel dat între ghilimelele simple.

(expresie)

expresia este tratată ca şi unitate şi poate fi combinată după descrierile din această listă.

A?

se potriveşte cu A sau cu nimic; A opţional.

A B

se potriveşte cu A urmată de B.

A | B

se potriveşte cu A sau cu B, dar nu cu ambele.

A - B

se potriveşte cu orice şir ce se potriveşte cu A, dar nu se potriveşte cu B.

A+

se potriveşte cu una sau mai multe apariţii a lui A.

A*

se potriveşte cu mai multe apariţii a lui A sau cu nici o apariţie.

/* ... */

comentariu.

[ wfc: ... ]

o constrângere pentru documente bine formate; aceasta identifică prin nume o constrângere asupra documentelor bine formate asociate cu o producţie.

[ vc: ... ]

constrângere de validitate; aceasta indentifică prin nume o constrângere asupra documentelor valide asociate cu o producţie.

IANA

(Internet Assigned Numbers Authority) Official Names for Character Sets, ed. Keld Simonsen şi alţii. Vezi ftp://ftp.isi.edu/in-notes/iana/assignments/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 -- Partea 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) -- Partea 1: Architecture and Basic Multilingual Plane. [Geneva]: International Organization for Standardization, 1993 (plus amendamentele de la AM 1 la AM 7).

Unicode

The Unicode Consortium. The Unicode Standard, Versiunea 2.0. Reading, Mass.: Addison-Wesley Developers Press, 1996.

Aho/Ullman

Aho, Alfred V., Ravi Sethi, şi Jeffrey D. Ullman. Compilers: Principles, Techniques, and Tools. Reading: Addison-Wesley, 1986, rpt. corr. 1988.

Berners-Lee şi alţii

Berners-Lee, T., R. Fielding, şi L. Masinter. Uniform Resource Identifiers (URI): Generic Syntax and Semantics. 1997. (În lucru; vezi noutăţile de la 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. Întreaga versiune în teoria informaticii 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). Prima ediţie -- 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.

• Caracterele de început ale numelor trebuie să fie din una dintre categoriile Ll, Lu, Lt, Nl.
• Caracterele din nume, altele decât caracterele de început ale numeler trebuie să fie din una dintre categoriile Mc, Me, Mn, Lm sau Nd.
• Caracterele din zona de compatibilitate (de exemplu, cu un cod de caracter mai mare decât #xF900 şi mai mic decât #xFFFE) nu sunt permise în numele XML.
• Caracterele ce au un font sau o descompunere de compatibilitate (de exemplu, acelea cu un marcaj de formatare compatibilă - compatibility formatting tag - în câmpul 5 al bazei de date -- marcat de către câmpul 5 ce începe cu un "<") nu sunt permise.
• Următoarele caractere sunt tratate caractere de început ale numelor, mai curând decât caractere din nume, pentru că fişierul de prorpietăţi le clasifică ca şi alfabetice (Alphabetic): [#x02BB-#x02C1], #x0559, #x06E5, #06E6.
• Caracterele #x20DD-#x20E0 sunt excuse (în conformitate cu Unicode, secţiunea 5.14).
• Caracterul #x00B7 este clasificat ca şi extensie, pentru că lista de proprietăţi aşa îl identifică.
• Caracterul #x0387 este adăugat la caracterele numelor, deoarece #x00B7 este echivalentul său canonic.
• Caracterele ':' şi '_' sunt permise ca şi caractere pentru începutul numelor.
• Caracterele '-' şi '.' sunt permise ca şi caractere din nume.

Dacă DTD-ul conţine declaraţia
 

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

 
atunci procesorul XML va recunoaşte refinţele la carctere când va parsa declaraţia entităţii şi le va rezolva înaintea stocării următorului şir ca şi valoare a entităţii "example":
 

<p> An ampersand (&#38;) may be escaped  numerically (&#38;#38;) or with a general entity  (&amp;amp;). </p>

 
O referinţă din document la "&example;", va cauza ca textul să fie reparsat, moment în care marcajul de început şi marcajul de sfârşit al elementului "p" vor fi recunoscute, iar cele trei referinţe vor fi recunoscute şi expandate, rezultând un element "p" cu următorul conţinut (totul este dată, fără delimitatori sau marcaje):
 

An ampersand (&) may be escaped  numerically (&) or with a general entity  (&).

 
Un exemplu şi mai complex va ilustra regulele cu toate efectele lor. În exemplul următor, numerele liniilor sunt date doar pentru referinţe.
 

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>

 
Acesta va produce:

• în linia 4, referinţa la caracterul 37 este expandată imediat, şi entitatea parametru "xx" este stocată în tabela sibolurilor cu valoarea "%zz;". Odată ce textul de înlocuit nu este rescanat, referinţa la entitatea parametru "zz" nu este recunoscută. (Şi ar fi generat o eroare, odată ce "zz" nu este declarat încă.)
• în linia 5, referinţa la caracter, "&#60;" este expandată imediat, iar entitatea parametru "zz" este stocată cu textul de înlocuit "<!ENTITY tricky "error-prone" >", ce este o declaraţie de entitate bine formată.
• în linia 6, referinţa la "xx" este recunoscută, iar textul de înlocuit al lui "xx" (numit "%zz;") este parsat. Referinţa la "zz" este recunoscută la rândul ei, iar textul ei de înlocuit ("<!ENTITY tricky "error-prone" >") este parsat. Entitatea "tricky" generată a fost acum declarată, cu textul de înlocuit "error-prone".
• în linia 8, referinţa la entitatea generală "tricky" este recunoscută şi expandată, deci întregul conţinut al elementului "test" este textul care se descrie (negramatical) This sample shows a error-prone method.

SGML-ul necesită modele de conţinut deterministice (pe care el le numeşte "nambigue"); procesoarele XML construite pe sistemele SGML pot semnala modelele de conţinut nedeterministice prin erori.

De exemplu, modelul de conţinut ((b, c) | (b,d)) este nedeterministic, deoarece având un b iniţial, parserul nu va putea şti cărui model va aparţine un b fără să se uite înainte pentru a vedea ce element urmează după b. În acest caz, cele două referinţe la b pot fi combinate într-o singură referinţă, refâcând modelul sub forma (b, (c | d)). Un b iniţial se va potrivi acum, în mod clar cu un singur nume din modelul de conţinut. Parserul nu va trebui să se mai uite înainte pentru a vedea ce urmează; va fi acceptat c sau d.

Mai formal: din modelul de conţinut poate fi construit un automat finit, utilizând algoritmii standard; de exemplu, algoritmul 3.5 din secţiunea 3.9 din lucrarea lui Aho, Sethi şi Ullman [Aho]. În mulţi algoritmi de acest gen, sunt construite seturi în fiecare poziţie a unei expresii regulate (de exemplu, fiecare nod frunză arborele sintaxtic asociat expresiei regulare); dacă una dintre poziţii are un set în care un nume de tip de element apare în mai multe poziţi imediat următoare, atunci modelul de conţinut este eronat şi poate fi raportat ca şi eroare.

Există algoritmi ce pot reduce aproape toate modelele de conţinut nedeterministice, la modele de conţinut deterministice echivalente; vezi Brüggenmann-Klein [ABK].

Deoarece fiecare entitate XML ce nu este codificată cu formatul UTF-8 sau cu UTF-16, trebuie să înceapă cu o declaraţie de codificare XML, caz în care primele caractere trebuie să fie '<?xml', orice procesor normal poate detecta, după primii doi sau patru octeţi, care din cazurile următoare sunt aplicate. În citirea acestei liste, este bine de ştiut că în UCS-4, caracterul '<' este "#x0000003C", iar '?' este "#x0000003F" şi marcajul ordinii octeţilor (Byte Order Mark) cerut de fluxul de date UTF-16 este "#xFEFF".

• 00 00 00 3C: UCS-4, o maşină ce utilizează sistemul big-endian (ordinea 1234)
• 3C 00 00 00: UCS-4, o maşină ce utilizează sistemul little-endian (ordinea 4321)
• 00 00 3C 00: UCS-4, o ordine a octeţilor neobişnuită (2143)
• 00 3C 00 00: UCS-4, o ordine a octeţilor neobişnuită (3421)
• FE FF: UTF-16, big-endian
• FF FE: UTF-16, little-endian
• 00 3C 00 3F: UTF-16, big-endian, fără marcaj al ordinii octeţilor (şi astfel, vorbind strict, avem o eroare)
• 3C 00 3F 00: UTF-16, little-endian, fără marcaj al ordinii octeţilor (şi astfel, vorbind strict, avem o eroare)
• 3C 3F 78 6D: UTF-8, ISO 646, ASCII, o parte a ISO 8859, Shift-JIS, EUC sau alte codificări de 7 sau 8 biţi sau mixaje ale mărimii, ce ne asigură că caracterele ASCII se află în poziţia lor, cu mărimea şi cu valorile normale;declaraţia codificării trebuie citită pentru a afla care dintre codificări este utilizată, dar odată ce toate aceste codificări utilizează aceleaşi modele de biţi pentru caracterele ASCII, declaţia de codificare poate fi citită corect
• 4C 6F A7 94: EBCDIC (în câteva forme; întreaga declaraţie de codificare trebuie citită pentru a şti care cod de paginiă este utilizat)
• alţii: UTF-8 fără o declaraţie de codificare sau fluxul de date este corupt, fragmentat sau pus într-o formă de un anumit tip

Deoarece conţinutul declaraţiei de codificare conţine doar caractere ASCII, procesorul poate să citească întreaga declaraţie de codifiare imediat ce a detectat ce familie de codificări este utilzată. Odată ce, în practică, toate codificările de caractere larg utilizate, intră în una dintre categoriile descrise, declaraţia de codificare XML permite o etichetare a codificării caracterelor sigură, chiar şi atunci când sursele externe de informaţii ale sistemului de operare sau ale protocolului de transport, nu sunt disponibile.

Oadă ce procesorul a detectat codificarea caracterelor utilizată, el poate să se comporte corespunzător, fie prin apelul unei rutine separate pentru fiecare caz, fie prin apelul funcţiei de conversie propice pentru fiecare caracter de la intrare.

Ca şi orice alt sistem care se etichetează singur, declaraţia de codificare XML nu va merge dacă vre-un soft schimbă setul de caractere al entităţii sau codificarea fără a reactualiza declaraţia de codificare. Implementatorii rutinelor de codificare a caracterelor trebuie să asigure acurateţea informaţiilor interne şi externe utilizate pentru a eticheta entitatea.

Al doilea caz posibil, apare atunci când entitatea XML este însoţită de o informaţie de codificare, ce este dată în câteva sisteme de fişiere şi în câteva protocoale de reţea. Când sunt disponibile mai multe surse de informaţie, prioritatea lor relativă şi metoda preferată de tratare a conflictelor, trebuie să fie specificată în protocolul de la nivelul cel mai înalt, utilizat pentru trimiterea XML-ului. Regulile pentru prioritatea relativă a etichetelor interne şi şi nivelul tipului MIME dintr-un antet extern, de exemplu, ar trebui să fie părţi componente ale documentului RFC ce definesc tipurile MIME text/xml şi aplication/xml. Oricum, în interesul interoperabilităţii, sunt recomandate următoarele reguli.

• dacă o entitate XML este într-un fişier, atunci marcajul ordinii octeţilor şi instrucţiunea de procesare cu declaraţia  de codificare (dacă este prezentă) sunt utilizate pentru a determina codificarea caracterelor. Toate celelalte euristice şi surse de informare vor fi prezente doar pentru recuperarea erorilor.
• Dacă o entitate XML este trimisă cu un tip MIME, text/xml, atunci parametru charset din tipul MIME va determina metoda de codificare a caracterelor; toate celelalte euristice şi surse de informare vor fi prezente doar pentru recuperarea erorilor.
• Dacă o entitate XML este trimisă cu un tip MIME, aplication/xml, atunci marcajul ordinii octeţilor şi instrucţiunea de procesare cu declaraţia  de codificare (dacă este prezentă) sunt utilizate pentru a determina codificarea caracterelor. Toate celelalte euristice şi surse de informare vor fi prezente doar pentru recuperarea erorilor.

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