W3CREC-xml-19980210

Extensible Markup Language (XML) 1.0

W3C soovitus 10-February-1998

Käesolev versioon:
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/REC-xml-19980210.ps
Viimane versioon:
http://www.w3.org/TR/REC-xml
Eelmine versioon:
http://www.w3.org/TR/PR-xml-971208
Toimetajad:
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>

Referaat

Käesolev dokument on SGML alamhulga, laiendatava märgistuskeele XML (Extensible Markup Language)  täielik kirjeldus.  XMLi eesmärgiks on võimaldada üldistatud SGML teksti serveerida, vastu võtta ja  töödelda veebis samal moel nagu see on võimalik  praegu HTML tekstidega. XML on projekteeritud lihtsustamaks SGML kasutamist ja tagamaks  SGML ja HTML risttöödeldavust.
 

Dokumendi staatus

Käesolev dokument on läbi vaadatud W3C liikmete ja teiste huvitatud poolte poolt ja on kinnitatud W3C direktori poolt W3C-soovitusena. Muutmatu dokumendina võib soovitust kasutada teatmematerjalina või tsiteerida kui normatiivset teksti teistes dokumentides. W3C roll seda soovitust luues, on pöörata tähelepanu spetsifikatsioonile ja edendada tema laialdast kasutamist. Soovituse kasutamine tõstab veebi funktsionaalsust ja ristrakendatavust.

Dokument spetsifitseerib WWW (World Wide Web) tehnoloogias kasutatava keele süntaksi. Keel  on loodud alamhulgana eksisteerivast ja laialt kasutatavast rahvusvahelisest tekstitöötlusstandardist SGML (Standard Generalized Markup Language, ISO 8879:1986(E) koos täienduste ja muudatustega).  Ta on W3C XML-organisatsiooni tegevuse produkt, mille üksikasju võib leida aadressil  http://www.w3.org/XML. W3C praegu kehtiv soovituste loetelu ja muud tehnilised dokumendid on leitavad aadressil http://www.w3.org/TR.

See spetsifikatsioon kasutab [Berners-Lee et al.] defineeritud   terminit URI,  teoksil oleva tööga loodetakse uuendada soovitusi  [IETF RFC1738] ja [IETF RFC1808].

Spetsifikatsiooni teadaolevad vead on kättesaadavad aadressil http://www.w3.org/XML/xml-19980210-errata.

Käesoleva dokumendi vigadest palume teatada e-aadressil  xml-editor@w3.org.

Extensible Markup Language (XML) 1.0

Sisukord

1. Sissejuhatus
    1.1 Saamislugu ja eesmärgid
    1.2 Terminoloogia
2. Dokumendid
    2.1 Trimmis XML dokumendid
    2.2 Märgid
    2.3 Üldised süntaktilised konstruktsioonid
    2.4 Märkandmed ja märgistus
    2.5 Kommentaarid
    2.6 Töötluseeskirjad
    2.7 CDATA-sektsioonid
    2.8 Dokumendi proloog ja tüübi deklaratsioon
    2.9 Iseseisva dokumendi deklaratsioon
    2.10 Tühiruumi käsitlemine
    2.11 Realõpu töötlemine
    2.12 Keele identifitseerimine
3. Loogiline struktuur
    3.1 Algusmärgised, lõpumärgised ja tühielemendi märgised
    3.2 Elemendi tüübideklaratsioon
        3.2.1 Elementsisu
        3.2.2 Kombineereitud sisu
    3.3 Atribuudiloetelu deklaratioon
        3.3.1 Atribuutide tüübid
        3.3.2 Atribuutide vaikeväärtused
        3.3.3 Atribuutide väärtuste normaliseerimine
    3.4 Tingimuslikud sektsioonid
4. Füüsiline  Struktuur
    4.1 Märgi- ja üksuseviidad
    4.2 Üksuse deklaratsioonid
        4.2.1 Sisemised üksused
        4.2.2 Välised üksused
    4.3 Parsitud üksused
        4.3.1 Teksti deklaratsioon
        4.3.2 Trimmis parsitud üksused
        4.3.3 Märkide kodeerimine üksustes
    4.4 XML-üksuste ja viitade protsessoripoolne käsitlemine
        4.4.1 Tuvastamata
        4.4.2 Kaasatud
        4.4.3 Kaasatud kehtestamisel
        4.4.4 Keelatud
        4.4.5 Kaasatud literaalis
        4.4.6 Teadistama
        4.4.7 Edastatud
        4.4.8 Kaasatud nagu PE
    4.5 Sisemise üksuse asendusteksti konstruktsioon
    4.6 Eeldefineeritud üksused
    4.7 Notatsiooni  deklaratsioon
    4.8 Dokumentüksus
5. Kohandamine
    5.1 Valideerivad ja mittevalideerivad  protsessorid
    5.2 XML-protsessorite kasutamine
6. Notatsioon

Lisad

A. Viited
    A.1 Normatiivsed viited
    A.2 Muud viited
B. Märgistike klassid
C. XML ja SGML (mittenormatiivne)
D. Üksusviitade ja märkviitade laiendamine (mittenormatiivne)
E. Deterministlik sisu mudel (mittenormatiivne)
F. Märkide kodeerimise automaatne määramine (mittenormatiivne)
G. W3C XML-töögrupp (mittenormatiivne)

1. Sissejuhatus

Laiendatav märgistuskeel, lühendatult XML, kirjeldab üht andmeobjektide klassi  XML-dokumente (XML documents)   ja osaliselt arvutiprogrammide käitumist nende töötlemisel. XML on SGMLi  (Standard Generalized Markup Language [ISO 8879]), standardprofiil või kitsendatud vorm. XML-dokumendid ühtivad oma konstruktsiooni poolest SGML-dokumentidega.

XML-dokumendid  koosnevad  säilituskirjetest, mida kutsutakse  üksusteks (entities), mis sisaldab kas grammatiliselt parsitud (analüüsitud) või parsimata andmeid. Parsitud andmed koosnevad märkidest  (characters), kas märkandmete (character data) või märgistuse (markup) vormis. Märgistusega kodeeritakse andmete paigutus dokumendis  ja dokumendi loogilise struktuuri kirjeldus. XML-mehhanismidega  kehtestatakse piirangud dokumendi paigutusele ja loogilisele struktuurile.

Tarkvara moodulit  XML-protsessor kasutatakse XML-dokumentide lugemiseks ja juurdepääsu tagamiseks dokumendi  sisule ja struktuurile. Eeldatakse, et XML-protsessor töötab teise tarvara mooduli  - rakenduse - huvides. Käesolev spetsifikatsioon kirjeldab XML-protsessori nõutavat käitumist: kuidas ta peab lugema XML-andmeid ja  kuidas ta peab tagama rakenduse informeerimise.

1.1 Saamislugu ja eesmärgid

XML töötati välja XML-töögrupi  (algselt  tuntud kui SGMLi redaktsiooniliselt läbivaatava nõukogu - SGML Editorial Review Board) poolt, mis loodi World Wide Web Konsortsiumi patronaazhi all 1996. aastal. Töögruppi juhtis Jon Bosak, Sun Microsystemsist aktiivses koostöös W3C poolt organiseeritud XML-erihuvigrupiga (varem tuntud SGML-töögrupina). XML-töögrupi koosseis on antud lisas. Dan Connolly  oli töögrupi  kontaktisik suhtlemisel  W3Cga.

XMLi  projekteerimise eesmärgid on:
1. XML on jalamaid kasutatav Interneti kaudu.
2. XML toetab laia valikut rakendusi.
3. XML  ühildub SGMLga.
4. On lihtne kirjutada XML-dokumentide töötlemise programme.
5. Fakultatiivsete omaduste hulga  peab XMLs hoidma absoluutses miinimumis, ideaaljuhul nad puuduvad.
6. XML-dokumendid on inimloetavad ja loogiliselt selged.
7. XML-projektid  on kiiresti realiseeritavad.
8. XML on formaalne ja napisõnaline
9. XML-dokumente  on lihtne luua.
10. XML-dokumentide margistuse kokkusurutus on minimaalse tähtsusega.

Käesolev spetsifikatsioon koos seonduvate standarditega (Unicode ja ISO/IEC 10646 märgistiku kohta, Interneti RFC 1766 keele identifitseerimismärkide kohta ja ISO 3166 riiginimede koodide kohta), tagavad kogu informatsiooni, mis on vajalik XMLi versioonist 1.0 arusaamiseks ja arvutiprogrammide koostamiseks XML-dokumentide töötlemiseks. Käesolevat XMLi spetsifikatsiooni versiooni võib levitada vabalt niikaua kuni kogu tekst ja kehtivad märkused jäävad muutmatuks.
 

1.2 Terminoloogia

XML-dokumentide kirjeldamiseks kasutatav terminoloogia on defineeritud käesoleva spetsifikatsiooni tekstis. Definitsioonide ülesehituses ja XML-protsessori tegevuse kirjeldamisel on kasutatud  järgnevas loetelus defineeritud  mõisteid.
võib
Dokumentide ja XML-protsessorite vastavus nõudele on lubatud, kuid nad ei tarvitse käituda kirjelduse kohaselt.
peab
Dokumentide ja XML-protsessorite käitumise vastavus kirjeldatud nõudele on nõutav; vastasel korral on nad vigased.
viga
Käesoleva spetsifikatsiooni reeglite rikkumine; tulemused on määratlemata. Vastav tarkvara peab avastama ja teatama veast ja tohib selle parandada.
hukutav viga
Viga, mille vastav XML-protsessor ( XML processor ) peab avastama ja teatama rakendusele. Peale kohtumist hukutava veaga võib protsessor jätkata andmetöötlust leidmaks järgmisi vigu ja võib neist vigadest teadistada rakendust.  Toetamaks vea parandamist, võib  protsessor töötlemata andmed (segu märkandmetest ja märgistusest) teha kättesaadavaks rakendusele. Hukutava vea avastamisel peab protsessor ometi jalamaid katkestama normaalse töötluse (st ta peab mitte jätkama märkandmete normaalsel moel üleandmist rakendusele  ja info edastamist  dokumendi loogilise struktuuri kohta).
kasutaja valikul
Vastav tarkvara võib või peab (sõltuvalt lauses kasutatavast modaalverbist) käituma vastavalt kirjeldusele;  kui tingimus on kehtestatud, siis peab kasutajale olema tagatud  vahendid kirjeldatud käitumise võimaldamiseks või keelamiseks.
kehtivuse kitsendus
Kõigile  kehtivatele (valid ) XML-dokumentidele rakenduv reegel. Siduva kitsenduse rikkumised on vead: valideeriv XML-protsessor (validating XML processors) peab  kasutaja valikul neist informeerima.
trimmisuse kitsendus
Trimmis (well-formed ) XML-dokumentidele rakenduv reegel. Trimmisuse reegli rikkumine on hukutav viga (fatal error).
klapp
(Stringide või nimede:) Kaks võrreldavat stringi või nime peavad olema identsed. Mitme võimaliku esitusega märgid ISO/IEC 10646 järgi (näiteks eelnevalt määratud liitmärgid ja põhimärk + diakriitik ) klapivad  ainult siis, kui nad on mõlemas stringis samas esituses. Kasutaja valikul võib protsessor sellised märgid teisendada mingile kanoonilisele kujule. Tõsttundetus pole lubatud.
(Stringide  ja grammatikareeglite: ) String klapib grammatilise produktsiooniga kui ta kuulub keelde, mis genereeris selle produktsiooni.
(Sisu ja sisumudelite: ) Element klapib oma deklaratsiooniga kui  ta vastab kujule, mis on kirjeldatud piirangus "Kehtiv element" (Element Valid).
ühilduvus
XML omadus, toodud sisse üksnes  garanteerimaks XMLi ühildumist SGMLga.
risttöödeldavus
Mittesiduv soovitus on toodud sisse XML-dokumentide  töötlemisvõimaluste suurendamiseks olemasolevate SGML protsessoritega, mis ennetavad dokumenti WebSGML Adaption Annex ISO 8879.

2. Dokumendid

Andmeobjekt on XML-dokument, kui ta on trimmis (well-formed) käesolevas spetsifikatsioonis defineeritud moel. Trimmis XML-dokument võib olla lisaks kehtiv (valid), kui ta vastab kindlatele lisapiirangutele.
Igal XML-dokumendil on loogiline ja füüsiline struktuur. Füüsiliselt  koosneb dokument kirjetest, mida kutsutakse üksusteks (entities). Üksus võib viidata (refer) teistele üksustele põhjustades nende kaasamise dokumenti. Dokument algab juur- ehk dokumendiüksusega (document entity). Loogiliselt koosneb dokument deklaratsioonidest, elementidest, kommentaaridest, viitadest märkidele, töötluseeskirjadest, mis on kõik üksikasjaliku märgistusega ära näidatud  dokumendis. Loogiline ja füüsiline struktuur peavad olema sisestatud  (nested) õigesti vastavalt kirjeldusele "4.3.2. Trimmis  parsitud üksused"  ( "4.3.2 Well-Formed Parsed Entities").

2.1 Trimmis XML-dokumendid

Tekstiobjekt on trimmis XML-dokument, kui:
  1. Tervikuna käsitletuna ta klapib produktsiooniga document.
  2. Ta vastab kõigile käesolevas spetsifikatsioonis antud trimmisuse piirangutele.
  3. Iga parsitud üksus (parsed entities), millele viidatakse vahetult või kaudselt dokumendis, on trimmis ( well-formed).
Dokument
[1]  document ::=  prolog elementMisc*

Dokumendi (document) klapp produktsiooniga tähendab, et:

  1. Ta sisaldab  ühte või mitut elementi (elements).
  2. Eksisteerib üks ja ainult üks element, mida nimetatakse juur- ehk dokumendielemendiks, mille ükski osa  ei esine  mitte üheski teise elemendi sisus (content) . Kõikide teiste elementide korral, kui lähtemärgis asub mingi teises elemendis, siis lõpumärgis on samas elemendis. Lihtsamalt väljendades, lähte- ja lõpumärgisega eraldatud elemendid sisestuvad (nest) üksteises õigesti.
Sellest järeldub, et iga dokumendi mitte-juurelemendi C jaoks leidub dokumendis teine element P,  nii et C sisaldub Ps, kuid ei sisaldu üheski teises Ps sisalduvas  elemendis. P on C ema ja C on P tütar.

2.2 Märgid

Parsitud üksus sisaldab teksti, märkide (characters)  jada, mis võivad kujutada märgistust või andmemärke. Märk on teksti atomaarne element vastavalt spetsifikatsioonile ISO/IEC 10646 [ISO/IEC 10646]. Lubatavad märgid on taab (tabeldusmärk), kelgu tagasijooks, reavahetus ja Unicode ja ISO/IEC 10646 lubatud märgid. Unicode paragrahvis 6.8 [Unicode] kirjeldatud "Ühilduvate tärkide"  kasutamine ei ole soovitav.
 
Märkide vahemikud
[2]  Char ::=  #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF] /*  mistahes Unicode märk, välja arvatud asendusplokid, plokid FFFE ja FFFF. */

Märkide kodeerimismehhanism võib varieeruda ühest üksusest teise. Kõik XML-protsessorid peavad tunnistama  ISO 10646 koode UTF-8 ja UTF-16. Mehhanismid signaliseerimaks, missugune neist kahest on kasutuses ja mehhanismid mingid teise kodeerimise mängu toomiseks on kirjeldatud  hiljem peatükis "4.3.3. Märkide kodeerimine üksustes" ("4.3.3 Character Encoding in Entities").

2.3 Üldised süntaktilised konstruktsioonid

See paragrahv defineerib mõned grammatikas laialt kasutatud märgid.

S (tühiruum) koosneb ühest või mitmest tühikust (#20), kelgu tgasijooksust, reavahetusest või taabist.
Tühiruum
[3]  S ::=  (#x20 | #x9 | #xD | #xA)+

Märgid  on klassifitseeritud  tähtedeks, numbriteks, või teisteks märkideks. Tähed koosnevad alfabeetilistest või silpkirja märkidest, millele võib järgneda  üks või mitu kombineeritud märki või ideograafilist märki. Spetsiifiliste märkide täielikud definitsioonid klasside kaupa on toodud jaotises "B. Märgiklassid" (B. Character Classes).

Nimi on lekseem, mis algab tähega või ühega vähestest punktuatsioonimärkidest ja jätkub tähtedega, numbritega, sidekriipsudega, alakriipsudega, koolonitega, või punktidega, mida kõiki koos tuntakse nimemärkidena. Stringiga  "xml"  algavad nimed ja  avaldisega (('X'|'x') ('M'|'m') ('L'|'l')) klappivad stringid on reserveeritud kasutamiseks selles  või selle spetsifikatsiooni tulevikuversioonides.

Märkus: Märk koolon XML-nimes on reserveeritud eksperimentideks nimeruumiga. Tema tähendus kavatsetakse standardiseerida mingil tulevikuhetkel, millest alates need dokumendid, mis sisaldavad eksperimentaaleesmärkidel koolonit, võivad vajada uuendamist. (Ei ole garantiid, et mingi XMLi jaoks kohandatud nimeruumi mehhanism  ei võiks kasutada faktiliselt koolonit nimeruumi eraldajana). Praktikas tähendab see seda, et autorid ei tohiks kasutada koolonit XML-nimedes, välja arvatud nimeruumi eksperimentides, aga XML-protsessorid peaksid aktsepteerima koolonit nimemärgina.

Lekseem Nmtoken (name token) on mistahes nimemärkide  segu.
 
Nimed ja lekseemid
[4]  NameChar ::=  Letter | Digit | '.' | '-' | '_' | ':' | CombiningChar | Extender
[5]  Name ::=  (Letter | '_' | ':') (NameChar)*
[6]  Names ::=  Name (S Name)*
[7]  Nmtoken ::=  (NameChar)+
[8]  Nmtokens ::=  Nmtoken (SNmtoken)*

Literaal on mistahes jutumärkides string, mis ei sisalda selle stringi eraldajana kasutatavaid jutumärke. Literaale kasutatakse siseüksuste (EntityValue), sisu spetsifitserimiseks, atribuutite väärtuseks (AttValue) ja välisteks identifikaaoriteks (SystemLiteral). Märgime, et  literaali  SystemLiteral võib parsida ilma märgistust skaneerimata.
 
Literaalid
[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 Märkandmed ja märgistus

 Tekst (text) on märkandmete  (character data) ja märgistuse segu.Märgistus esineb algusmärgistena (start-tags), lõpumärgistena (end-tags), tühjade märgistena (empty-element tags), üksuseviitadena (entity references), märgiviitadena (character eferences), kommentaaridena (comments), CDATA-sektsiooni ( CDATA section) eraldajatena, dokumendi tüübi deklaratsioonidena (document type declarations) ja töötluseeskirjadena (processing instructions).

Kogu märgistusse mittekuuluv tekst moodustab dokumendi märkandmed.

Ampersand (&) ja vasak nurksulg  (<)  võib  literaalina esineda ainult siis, kui teda kasutatakse märgistuse eraldajatena, või kommentaari  (comment) tekstis või töötluseeskirjas (processing instruction) või  CDATA-sektsioonis (CDATA section). Need märgid on lubatud ka siseüksuse deklaratsiooni literaalüksuse väärtuses (literal entity value) vt  "4.3.2 Trimmis parsitud üksused". Kui neid märke vajatakse kuskil mujal, peab  nad esitama paojadana (escaped) kasutades numbrilisi märgiviitu (numeric character references) või vastavalt stringe   "&amp;" ja "&lt;". Parema nurksulu  (>) võib esitada stringina  "&gt;", ja ta peab ühilduvuseks ( for compatibility)    esitama stringis "]]>" paojadana "&gt;"  või numbrilise märgiviidana, kui see string ei märgista CDATA-sektsiooni (CDATA section) lõppu.

Märkandmed elemendi sisus on mistahes string,  mis ei sisalda ühtegi märgise alguseraldajat. Märkandmed CDATA-sektsioonis  on mistahes string, mis ei sisalda CDATA sektsiooni sulgevat eraldajat  "]]>".

Lubamaks atribuutide väärtustes ülakoma ja jutumärkide sisaldumist, võib ülakoma   (') esitada  kujul "&apos;" ja  jutumärki (") kujul "&quot;".
 
Märkandmed
[14]  CharData ::=  [^<&]* - ([^<&]* ']]>' [^<&]*)

2.5 Kommentaarid

Kommentaarid võivad esineda igal pool dokumendis väljaspool märgistust (markup); lisaks võivad nad esineda dokumendi tüübi deklaratsioonis grammatikaga lubatud  kohtades Nad pole osa dokumendi märkandetest (character data); XML-protsessor võib, kuid ei pea võimaldama rakendusel leida kommentaari teksti. Ühilduvusesks ( for compatibility) ei tohi string "--" (topelt sidekriips) sisalduda kommentaaris.
 
Kommentaarid
[15]  Comment ::=  '<!--' ((Char - '-') | ('-' (Char - '-')))* '-->'

Kommentaari näide:
 
<!-- declarations for <head> & <body> -->

2.6 Töötluseeskirjad

Töötluseeskirjad PI (processing instructions)  lubavad dokumentides anda rakendustele eeskirju nende töötlemiseks.
 
Töötluseeskirjad
[16]  PI ::=  '<?' PITarget (S (Char* - (Char* '?>' Char*)))? '?>'
[17]  PITarget ::=  Name - (('X' | 'x') ('M' | 'm') ('L' | 'l'))

PId ei ole osa dokumendi märkandmetest (character data),  aga nad peab antama üle rakendusele. PId algavad  sihtmärgiga (PITarget),  mis  identifitseerib rakenduse, millele see eeskiri on suunatud. Standariseerimiseeesmärkidel on käesoleva  spetsifikatsiooni praeguses või tulevikuversioonides sihtmärgi nimed "XML", "xml" ja teised  sarnased reserveeritud. PI sihtmärgi formaalseks deklareerimiseks võib kasutada XML-notatsiooni (notation) mehhanisme.

2.7 CDATA-sektsioonid

CDATA-sektsioonid võivad esineda kõikjal, kus võib esineda märkandmeid; neid kasutatakse selliste tekstiplokkide varjestamiseks, mis sisaldavad märke, mida peab tuvastama märgistusest erinevalt. CDATA-sektsioonid algavad stringiga  "<![CDATA[" ja lõpevad stringiga  "]]>":
 
CDATA-sektsioonid
[18]  CDSect ::=  CDStart CDataCDEnd
[19]  CDStart ::=  '<![CDATA['
[20]  CData ::=  (Char* - (Char* ']]>' Char*))
[21] CDEnd ::=  ']]>'

CDATA-sektsioonis tuvastatakse ainult  CDEnd stringi märgistusena,  nii et vasakud nurksulud ja ampersandid võivad esineda oma literaalkujul: neid pole vaja (ja ei saa) varjestada  "&lt;" ja "&lt;" abil. CDATA-sektsioone ei saa üksteisesse sisestada.

CDATA-sektsiooni näide, kus  "<greeting>"  ja "</greeting>"  tuvastatakse märkkandmetena (character data) mitte märgistusena (markup):
 
<![CDATA[<greeting>Hello, world!</greeting>]]>

2.8 Dokumendi proloog ja tüübideklaratsioon

XML-dokumendid võivad ja peavad algama XML-deklaratsiooniga, mis spetsifitseerib kasutatava XMLi versiooni. Näiteks on järgnev  XML-dokument trimmis (well-formed), kuid mitte kehtiv (valid):
 
<?xml version="1.0"?>
<greeting>Hello, world!</greeting>

ja samuti ka see:
 
<greeting>Hello, world!</greeting>

Versiooni numbrit "1.0" peab kasutama  viitamaks kooskõlale selle spetsifikatsiooni selle versiooniga; kui dokument ei ole kooskõlas spetsifikatsiooni selle versiooniga, on väärtuse "1.0" kasutamine viga. XML-töögrupi tahe on anda selle spetsifikatsiooni hilisematele versioonidele väärtusest "1.0" erinevaid numbreid, kuid see tahe ei viita kohustusele töötada välja mõni XMLi versioon tulevikus, aga ometi,   kui mingi versioon töötatakse  välja, siis kasutatakse sama nummerdusskeemi. Kuni tulevikuversioonid pole välistatud, on see konstruktsioon  ette nähtud  vahendina lubamaks vajaduse tekkimisel automaatset versioonituvastust. Protsessorid võivad anda veasignaali, kui nad saavad dokumendi, mis on märgistatud versiooninumbriga, mida nad ei toeta.

XML-dokumendi märgistuse funktsioon on kirjeldada tema salvestamist  ja loogilist struktuuri ja seostada atribuudi-väärtuse paarid tema loogilise struktuuriga. XML näeb ette dokumendi tüübi deklaratsiooni (document type declaration) mehhanismi, et defineerida loogilise struktuuri kitsendused ja toetada eeldefineeritud salvestusüksuste kasutamist. XML dokument on kehtiv, kui ta on seotud dokumendi tüübideklaratsiooniga ja kui dokument rahuldab temas väljendatud kitsendusi.

Dokumendi tüübideklaratsioon peab olema enne dokumendi esimest elementi (element).
 
Proloog
[22]  prolog ::=  XMLDecl? Misc* (doctypedecl Misc*)?
[23]  XMLDecl ::=  '<?xml' VersionInfoEncodingDecl? SDDecl? S? '?>'
[24]  VersionInfo ::=  S 'version' Eq (' VersionNum ' | " VersionNum ")
[25]  Eq ::=  S? '=' S?
[26]  VersionNum ::=  ([a-zA-Z0-9_.:] | '-')+
[27]  Misc ::=  Comment | PI | S

XML-dokumendi tüübideklaratsioon sisaldab või viitab märgistuse deklaratsioonile (markup declarations), millega määratakse kogu dokumendiklassi  grammatika. Seda grammatikat nimetatakse dokumendi tüübidefinitsiooniks või DTDks (document type definition). Dokumendi tüübidefinitsioon võib viidata  välisele märgistuse deklaratsioone  sisaldavale alamhulgale (välisüksuse (external entity) erijuht), ta võib  sisaldada märgistuse deklaratsioone vahetult sisemises alamhulgas, ta võib esitada kombineerides mõlemaid mooduseid. Dokumendi DTD moodustavad mõlemad alamhulgad kokkuvõetuna.

Märgituse deklaratsioon on elemendi tüübideklaratsioon (element type declaration), atribuutide loetelu deklaratsioon (attribute-list declaration),  üksuse deklaratsioon (entity declaration), või notatsiooni deklaratsioon (notation declaration). Need deklaratsioonid võivad sisalduda tervikuna või osaliselt parameeterüksuses (parameter entities), nagu on kirjeldatud trimmisuse ja kehtivuse piirangutes allpool. Täielikuma informatsiooni saamiseks vaata  "4. Füüsiline struktuur".
 
Dokumendi  tüübi deklaratsioon
[28]  doctypedecl ::=  '<!DOCTYPE' S Name (S ExternalID)? S? ('[' (markupdecl | PEReference | S)* ']' S?)? '>' VC: Juurelemendi tüüp (Root Element Type)]
[29]  markupdecl ::=  elementdecl | AttlistDecl | EntityDecl | NotationDecl | PI | Comment VC: Õige deklaratsioonide/PE sisestus (Proper Declaration/PE Nesting)]
WFC: PEd sisemises alalamhulgas (PEs in Internal Subset)]

Märgistuse   deklaratsioon  võib olla esitatud tervikuna või osaliselt parameeterüksuste asendustekstis (replacement text of parameter entities) Käesoleva spetsifikatsiooni allpool toodud indviduaalsete mitteterminalide (elementdecl, AttlistDecl, jt) produktsioonid kirjeldavad deklaratsioone pärast  parameeterüksuste sisselülitamist.

Kehtivuse kitsendus: juurelement
 Name dokumendi tüübikirjelduses peab klappima elemenditüübiga juurelement (root element).

Kehtivuse kitsendus: õige deklaratsiooni/PE sisestuse nõue
Parameeterüksuse asendustekst (replacement text) peab olema koos märgistuse deklaratsioonidega sisestatud (nested) õigesti. See tähendab, kui märgistuse deklaratsiooni   (ülaltoodud markupdecl ) kas esimene või viimane märk sisaldub parameeterüksuse viida asendustekstis, peavad mõlemad sisalduma samas asendustekstis.

Trimmisuse kitsendus: PE sisemises alamhulgas
Sisemises DTD  alamhulgas võib parameeterüksuse viit (parameter-entity references) esineda ainult seal, kus võib esineda märgistuse deklaratsioon. (See ei rakendu viitadele, mis esinevad välistes parameeterüksustes  ega välistele alamhulkadele).

Nagu sisemine alamhulk, peab DTDle viitav väline alamhulk ja iga väline parameeterüksus sisaldama täieliku märgistuse deklaratsioonide jada, mis on lubatud mitterminaali markupdecl  poolt, segamini tühimikega või parameeterüksuse viitadega (parameter-entity references). Kuigi väliseid alamhulki, või väliseid parameeterüksusi võib tingimuslikult ignoreerida, kasutades tingimusliku sektsiooni (conditional section) konstruktsioone; pole see lubatud sisemises alamhulgas.
 
Väline alamhulk
[30]  extSubset ::=  TextDecl? extSubsetDecl
[31]  extSubsetDecl ::=  ( markupdecl | conditionalSect | PEReference | S )*

Väline alamhulk ja väline parameeterüksus erinevad samuti sisemisest alamhulgast selle poolest, et parameeterüksuse viidad (parameter-entity references) on lubatud mitte ainult märgistusdeklaratsioonide vahel, vaid ka märgistusdeklaratsiooni sees.

Dokumenditüübi deklaratsiooniga XML-dokumendi näide:
 
<?xml version="1.0"?>
<!DOCTYPE greeting SYSTEM "hello.dtd">
<greeting>Hello, world!</greeting>

Süsteemi identifikaator (system identifier) "hello.dtd" on dokumendi DTD URI.

Deklaratsiooni võib anda ka lokaalselt, nagu järgnevas näites:
 
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE greeting [
  <!ELEMENT greeting (#PCDATA)>
]>
<greeting>Hello, world!</greeting>

Kui kasutatakse mõlemaid, nii väliseid kui ka sisemisi alamhulki, vaadeldakse sisemist alamhulka  enne välist alamhulka. Selle efekt on selles, et sisemise alamhulga üksust ja atribuutide loetelu deklaratsiooni eelistatakse võrreldes välise alamhulgaga.

2.9 Iseseisva dokumendi deklaratsioon

Märgistuse deklaratsioonid võivad mõjutada dokumendi sisu, kuna nad ju  antakse XML protsessori (XML processor)  poolt rakendusele; näideteks on atribuutide vaikeväärtused ja üksuse deklaratsioonid. Iseseisev dokumendideklaratsioon, mis võib olla XML dokumendideklaratsiooni komponendiks, signaliseerib, kas seal on,  või mitte selliseid deklaratsioone, mis on välised dokumendiüksuse (document entity) suhtes.
 
Iseseisva dokumendi deklaratsioon
[32]  SDDecl ::=  S 'standalone' Eq (("'" ('yes' | 'no') "'") | ('"' ('yes' | 'no') '"')) VC: Iseseisva dokumendi deklaratsioon (Standalone Document Declaration)]

Väärtus "yes" iseseisva dokumendi deklaratsioonis  näitab, et dokumendis  ei ole dokumendiüksuse (document entity) suhtes väliseid märgistuse deklaratsioone (ükspuha kas välise alamhulga DTDs, või sisemisest alamhulgast viidatud välistes parameeterüksustes), mis mõjutavad XML-protsessori poolt rakendusele üleantavat informatsiooni.  Väärtus "no"  näitab, et dokumendis on, või võib olla, selliseid väliseid märgistuse deklaratsioone. Märgime, et iseseisev dokumendi deklaratsioon ainult märgistab välise deklaratsiooni olemasolu;  olemasolu dokumendis, viitades välistele üksustele, kui need üksused ei ole sisemiselt defineeritud, ei muuda iseseisvuse staatust.

Kui dokumendis puuduvad välise märgistuse deklaratsioonid, siis pole iseseisva dokumendi deklaratsioonil tähendust. Kui seal on välised märgistuse deklaratsioonid,  kuid ei ole iseseisva dokumendi deklaratsiooni, peetakse enesestmõistetavaks väärtust   "no".

Iga XML-dokument, mille jaoks kehtib standalone="no", saab algoritmiliselt konverteerida iseseisvaks dokumendiks, mis võib olla mõnede  võrgurakenduste jaoks ihaldatav.

Kehtivuse piirang: iseseisva dokumendi deklaratsioon
Iseseisva dokumendi deklaratsioon peab omama väärtust "no", kui  mistahes väline märgistuse deklaratsioon sisaldab

Iseseisva XML dokumendi deklaratsiooni näide:
 
<?xml version="1.0" standalone='yes'?>

2.10 Tühiruumi käsitlemine

XML-dokumentide toimetamisel on parema loetavuse huvides sageli otstarbekas käsitleda "tühiruumi" (tühikuid, tabulaatoreid, tühje ridasid, mida käesolevas spetsifikatsioonis on märgistatud  mitteterminaliga  S ) eraldi märgistusest. Tüüpilistel juhtudel pole selline tühiruum  mõeldud lülitamiseks edastavasse dokumendiversiooni. Teiselt poolt peab tähenduslik tühiruum edastavas dokumendiversioonis säiluma, näiteks poeesias ja lähtekoodis.

XML-protsessor  (XML processor) peab alati dokumendi märgistusest erinevad märgid üle andma rakendusele. Valideeriv XML-protsessor  (validating XML processor) peab lisaks rakendust informeerima, millised tühiruumi märgid esinesid elementsisus (element content).

Elemendile võib lisada erilise xml:space atribuudi (attribute)  signaliseerimaks tahet, et selles elemendis peab rakendusele säiluma tühiruumi märgid. Nagu kõik teisedki atribuudid kehtivas dokumendis, peab selle atribuudi kasutamise korral olema ta deklareeritud (declared). Kui ta on deklareeritud, peab ta olema esitatud loetelutüübina, mille ainukesed võimalikud väärtused on "default" ja "preserve". Näiteks:
 
    <!ATTLIST poem   xml:space (default|preserve) 'preserve'>

Väärtus "default"  signaliseerib rakendusi, et selle elemendi jaoks on vastuvõetav vaikimisi kasutatav tühiruumi töötlemismoodused; väärtus "preserve" viitab tahtele, et rakendused säilitavad kõik  tühiruumi märgid. See deklareeritud tahe on arvestatud rakendada kõigi elementide sisule, kus ta on spetsifitseeritud, kuni spetsifikatsiooni pole ümber lükatud teise xml:space atribuudi  eksemplari poolt.

Mistahes dokumendi root elemendi  (root element) kohta eeldatakse, et tema jaoks on signaliseeritud tahte puudumine vaadelda rakenduses tühiruumi töötlust, kui temal puudub selle atribuudi väärtus, või atribuut on deklareeritud oma vaikeväärtusega.

2.11 Realõpu töötlemine

Parsitud XML-üksusi  (parsed entities)  salvestatakse sageli arvutifailidese, mis on redigeerimise eesmärgil organiseeritud ridadena. Need read on tavaliselt eraldatud mõne kombinatsiooniga märkidest kelgu tagasilüke  (#xD) ja reavahetus (#xA).

Rakenduste (applications) töö lihtsustamiseks annab XML-protsessor  (XML processor) rakendusele ükskõik millises parsitud välisüksuses või parsitud siseüksuse literaalis sisalduva kahemärgise literaali  "#xD#xA" või üksikliteraali #xD asemel üksikmärgi #xA. (Sellist käitumist võib traditsiooniliselt tekitada kõikide reavahetuste normaliseerimise teel märgiks #xA sisestusprotsessis enne parsimist).

2.12 Keele identifitseerimine

Dokumendi töötlemisel on sageli kasulik identifitseerida sisu kirjutamiseks kasutatud loomulik keel. Kasutatava keele spetsifitseerimiseks XML-dokumendi mistahes välja sisus ja atribuudi väärtustes võib dokumenti lülitada eriatribuudi (special attribute) xml:lang. Kehtivas dokumendis peab see atribuut, nagu mistahes teine atribuut, olema   tema kasutamise korral deklareeritud (declared). Atribuutide väärtusteks on keele identifikaatorid kujul nagu nad on defineeritud dokumendis  [IETF RFC 1766], "Tags for the Identification of Languages":
 
Keele identifitseerimine
[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])+

 Langcode võib olla mistahes järgnevatest:

Alamkoodi (subcode) segmente võib olla kuitahes palju; kui esimene  alamkoodi segment on olemas ja kui alamkood sisaldab kahte tähemärki, siis ta peab olema riigi kood vastavalt standardile [ISO 3166], "Codes for the representation of names of countries." Kui esimene alamkood sisaldab enam kui kaht tähte, siis peab ta olema siis ta peab olema  IANA poolt registreeritud keele kood, kui mitte Langcode ei alga eesliitega "x-" või "X-".

Keele koodi on kombeks esitada väiketähtedega, ja riigi koodi (kui mingi esitatakse) suurtähtedega. Märgime, et erinevalt teistest XML-dokumendi nimedest, on need väärtused tõsttundetud.

Näiteks:
 
<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>

Atribuudiga xml:lang deklareeritud tahe rakendub kõigile atribuutidele ja elemendi sisule, kus ta on spetsifeeritud, kuni ta pole üle defineeritud antud elemendi sisus paikneva mingi teise elemendi xml:lang eksemplariga.

Atribuut xml:lang võib lihtsamal juhul olla kujul
 
xml:lang  NMTOKEN  #IMPLIED

kuid vaikeäärtused võivad samuti olla antud, kui nad on asjakohased. Inglise üliõpilaste jaoks  kirjutatud prantsuse luuletuste kogumikus, mis sisaldab ingliskeelseid tõlgitsusi ja  märkusi, võib xml:lng atribuut olla deklareeritud nii:
 
    <!ATTLIST poem   xml:lang NMTOKEN 'fr'>
    <!ATTLIST gloss  xml:lang NMTOKEN 'en'>
    <!ATTLIST note   xml:lang NMTOKEN 'en'>

3. Loogiline struktuur

Iga  XML-dokument  (XML document) sisaldab ühte või mitut elementi, mis on piiritletud kas algusmärgistega (start-tags) ja  lõpumärgistega  (end-tags),  või tühielemendi (empty)  korral tühielemendi märgisega  (empty-element tag). Igal elemendil on nimega identifitseeritav tüüp, mida mõnikord kutsutakse tema "sootunnuseks" (GI - generic identifier) ja võib omada kogumi atribuutide spetsifikatsioone. Iga atribuudi spetsifikatsioonil on nimi   (name) ja väärtus (value).
 
Element
[39]  element ::=  EmptyElemTag
| STag contentETag WFC: Elemenditüübi klapp (Element Type Match) ]
VC: Elemendi kehtivus  (Element Valid)  ]

Käesolev spetsifikatsioon ei piira elementide semantikat, nende kasutamist, ega  elemendi tüübi ja atribuutide süntaksiväliseid nimesid, välja arvatud seda, et nimed mille algused klapivad avaldisega (('X'|'x')('M'|'m')('L'|'l'))  on reserveeritud standardiseerimiseks käesoleva spetsifikatsioni praeguses või tulevikuversioonides.

Trimmisuse piirang: elemenditüübi klapp
Elemendi lõpumärgise  nimi  (Name) peab klappima elemendi tüübiga algusmärgises.

Kehtivuse piirang: Elemendi kehtivus
Element on kehtiv, kui leidub  elementdecl klappiv deklaratsioon, kus Name klapib elemendi tüübiga ja kehtib üks järgnevatest:

1. Deklaratsioon klapib EMPTYga ja elemendil puudub sisu (content).
2.  Deklaratsioon klapib tütrega  (children) ja tütarelementide (child elements) jada kuulub keelde, mis on sisu mudeli regulaaravaldise poolt genereeritud, koos võimalike tühiruumi märkidega (mitteterminaliga S klappivad märgid) iga tütarelementide paari vahel.
3. Deklaratsioon klapib avaldisega  Mixed ja sisu koosneb märkandmetest   (character data) ja tütarelementidest  ( child elements),  mille tüübid vastavad nimedele sisu mudelis.
4. Deklaratsioon klapib  ANY, ja iga tütarelemendi  (child elements) tüüp on deklareeritud

3.1 Algusmärgised, lõpumärgised ja tühielemendi märgised

Mistahes mittetühi XML element on märgistatud algusmärgisega.
 
Start-tag
[40]  STag ::=  '<' Name (SAttribute)* S? '>' WFC: Att spetsifikatsiooni unikaalsus (Unique Att Spec) ]
[41]  Attribute ::=  Name EqAttValue VC: Atribuudi väärtuse tüüp (Attribute Value Type) ]
WFC:  Puuduvad viidad välisüksustele (No External Entity References) ]
WFC: Atribuudi väärtuses pole märki < (No < in Attribute Values) ]

Atribuut Name algus- ja lõpumärgendites annab elemendi tüübi..Paar Name-AttValue esitab elemendi atribuudi spetsifikatsiooniName mistahes paaris esitab atribuudi nime ja AttValue sisu (tekst eraldajate  ' või " vahel) atribuudi väärtuse.

Trimmisuse kitsendus:  Att spetsifikatsiooni unikaalsus
Ühes ja samas algusmärgises või tühielemendi märgises  ei või atribuudi nimi esineda rohkem kui üks kord.

Kehtivuse kitsendus: atribuudi väärtuse tüüp
Atribuut peab olema deklareeritud; väärtus peab vastama deklareeritule. (Atribuutide tüübid on kirjeldatud jaotises  "3.3 Atribuutloetelu deklaratsioon".)

Trimmisuse kitsendus: puuduvad viidad välisüksustele
Atribuutide väärtused ei saa sisaldada vahetud või kaudset üksuse viita välisüksustele.

Kehtivuse piirang: Atribuudi väärtuses pole märki <
Mistahes üksuse asendustekst  (replacement text) esitatuna atribuudi väärtusena (erinev "&lt;") ei tohi vahetult või kaudselt sisaldada märki <.

Algusmärgise näide:
 
<termdef id="dt-dog" term="dog">

Iga algusmärgisega algava elemendi lõpp peab olema märgistatud lõpumärgisega, mis sisaldab nime, mis kordab algusmärgises antud elemendi tüüpi:
 
Lõpumärgis
[42]  ETag ::=  '</' Name S? '>'

Lõpumärgise näide:
 
</termdef>

Algusmärgise ja lõpumärgise vahelist teksti  (text) nimetatakse elemendi sisuks:
 
 Elementide sisu
[43]  content ::=  (element | CharData | Reference | CDSect | PI | Comment)*

Kui  element on tühi, siis peab ta olema esitatud kas algusmärgisega ja temale vahetult järgneva lõpumärgisega või tühielemendi märgisega. Tühielemendi märgis omab erilise kuju:
 
Tühielementide märgised
[44]  EmptyElemTag ::=  '<' Name (SAttribute)* S? '/>' WFC: Att spetsifikatsiooni unikaalsus (Unique Att Spec) ]

Tühielemendi märgist võib kasutada mistahes elemendi korral, millel puudub sisu, kui ta mitte ei ole deklareeritud  võtmesõna EMPTY abil. Risttöödeldavuseks (for interoperability) peab  tühielemendi märgist kasutatama  ja võib ainult kasutada elementide korral, mis on deklareeritud (declared)  võtmesõna EMPTY abil.

Tühielementide näited:
 
<IMG align="left"
 src="http://www.w3.org/Icons/WWW/w3c_home" />
<br></br>
<br/>

3.2 Elemendi tüübideklaratsioonid

XML-dokumendi (XML document) elemendi  (element) elemendi struktuurile võib kehtivuse (validation) eesmärkidel esitada piiranguid  kasutades elemendi tüübi deklaratsiooni  ja atribuutide loetelu. Elemendi tüübi deklaratsioon piirab elemendi sisu (content).

Elemendi tüübi deklaratsioon  piirab sageli seda, missuguse elemendi tüüp esineb elemendi tütrena (children). XML-protsessor võib kasutaja suvandi korral  väljastada hoiatuse, kui  deklaratsioonis mainitakse elemendi tüüpi, mille jaoks pole deklaratsiooni, kuid see pole viga.

Elemendi tüübi deklaratsioon on kujul:
 
Elemendi tüübi deklaratsioon
[45]  elementdecl ::=  '<!ELEMENT' S NameScontentspecS? '>' VC: Elemendi tüübi deklaratsiooni unikaalsus (Unique Element Type Declaration) ]
[46]  contentspec ::=  'EMPTY' | 'ANY' | Mixed | children

kus Name määrab deklareeritava elemendi tüübi

Kehtivse piirang: Elemendi tüübi deklaratsiooni unikaalsus
Ühtegi elemendi tüüpi ei tohi deklareerida rohkem kui üks  kord.

Näited elemendi tüübi deklaratsioonidest:
 
<!ELEMENT br EMPTY>
<!ELEMENT p (#PCDATA|emph)* >
<!ELEMENT %name.para; %content.para; >
<!ELEMENT container ANY>

3.2.1 Elementsisu

Elementsisuga elemendi tüüp (type) sisaldab ainult tütarelemente (child elements) (mitte märkandmeid), mis võivad olla eraldatud tühiruumi märkidega (mitteterminaliga  S klappivad märgid). Sel juhul sisaldab kitsendus sisu mudelit, lihtsat grammatikat, mis katab lubatud tütarelementide tüübid ja järjestuse, milles neil on lubatud esineda. Grammatika on ehitatud üles sisu partiklitele (content particles (cps)), mis sisaldavad nimesid, sisupartiklite valikuloetelusid, või sisupartiklite järjestikulist loetelu:
 
Elementsisu mudelid
[47]  children ::=  (choice | seq) ('?' | '*' | '+')?
[48]  cp ::=  (Name | choice | seq) ('?' | '*' | '+')?
[49]  choice ::=  '(' S? cp ( S? '|' S? cp )* S? ')' VC: Õige Group/PE sisestus (Proper Group/PE Nesting) ]
[50]  seq ::=  '(' S? cp ( S? ',' S? cp )* S? ')' VC: Õige Group/PE sisestus  (Proper Group/PE Nesting) ]

kus iga nimi ( Name) on elemendi tüüp, mis võib esineda  elemendi tütrena (child). Mistahes sisu partikkel valikuloetelus võib esineda elemendi sisus (element content) samas kohas, kus valikuloetelu asub grammatikas; järjestikulises loetelus toodud sisupartiklid peavad kõik esinema elemendi sisus (element content ) loetelus esitatud järjestuses. Mittekohustuslik märk  nime või loetelu taga nõuab, et kas element või sisupartikkel loetelus võib korduda üks või rohkem (+), null või rohkem (*) korda. Sellise operaatori puudumine tähendab, et element või sisupartikkel peab esinema täpselt üks kord. See süntaks ja tähendus on identne käesolevas spetsifikatsioonis produktsioonides kasutatavale.

Elemendi sisu klapib sisu mudeliga siis ja ainult siis, kui on võimalik kindlaks teha tee läbi sisu mudeli, kuuletumine järjestuse, valiku ja korduvuse operaatoritele ja iga elemendi klapp sisus sisumudeli  elemendiga. Ühilduvuseks (for compatibility) loetakse veaks, kui dokumendi element võib sisu mudelis klappida enam kui ühe elemendi tüübi eksemplariga.  Rohkem infot on jaotises "E. Deterministlikud sisumudelid".

Kehtivuse piirang:  õige grupi/PE sisestus
Parameeterüksuse asendustekst (replacement text) peab olema õigesti sisestatud (nested) koos sulgudesse võetud gruppidega. Teiste sõnadega, kui avav või sulgev sulg valiku, järjestuse või kombineeritud konstruktsioonides choice, seq, or Mixed sisaldub parameeterüksuse (parameter entity) asendustekstis, peavad nad mõlemad sisalduma samas asendustekstist. Risttöödeldavuseks (for interoperability),  kui valiku, järjestuse või kombineeritud konstruktsioonides (choice, seq, or mixed construct) esineb parameeterüksuse viit, siis tema asendustekst ei tohi olla tühi ja ei esimene ega viimane asendusteksti mittetühi märk ei tohi olla seostaja (| või ,).

Näited elementsisuga mudelitest:
 
<!ELEMENT spec (front, body, back?)>
<!ELEMENT div1 (head, (p | list | note)*, div2*)>
<!ELEMENT dictionary-body (%div.mix; | %dict.mix;)*>

3.2.2 Kombineeritud sisu

Elemendi tüüp (type) on  kombineeritud kui seda tüüpi element võib sisaldada märkandmeid vaheldumisi mittekohustuslike tütarelementidega (child elements). Sel juhul võivad tütarelementide tüübid olla kitsendatud, kuid mitte ende järjestus ja nende esinemiste arv:
 
Kombineeritud sisu deklaratsioon
[51]  Mixed ::=  '(' S? '#PCDATA' (S? '|' S? Name)* S? ')*' 
| '(' S? '#PCDATA' S? ')' VC: Õige grupi/PE sisestus (Proper Group/PE Nesting) ]
VC: Dublikaattüüpide keeld (No Duplicate Types) ]

kus nimed  (Name) määravad nende tütarelementide elementide tüübi, mis võivad esineda elemendis.

Kehtivuse piirang: Dublikaattüüpide keeld
Sama nimi ei tohi rohkem kui üks kord üksikus või kombineeritud deklaratsioonides.

Kombineeritud elementide deklaratsioonide näited:
 
 
<!ELEMENT p (#PCDATA|a|ul|b|i|em)*>
<!ELEMENT p (#PCDATA | %font; | %phrase; | %special; | %form;)* >
<!ELEMENT b (#PCDATA)>

3.3 Atribuudiloetelu deklaratsioon

Atribuute (Attributes) kasutatakse paari nimi-väärtus sidestamiseks elementidega (elements). Atribuudi spetsifikatsioon saab esineda ainult algusmärgitses (start-tags) ja tühielementmärgistes (empty-element tags); niisiis neid tuvastavad produktsioonid on esitatud jaotises  "3.1 Algusmärgised, lõpumärgised ja tühielementmärgised". Atribuudiloetelu deklaratsioone saab kasutada: Atribuudiloetelu deklaratsioonid  spetsifitseerivad etteantud elemendi tüübi iga atribuudi nime, andmetüübi ja vaikeväärtuse (kui on olemas):
 
Atribuudiloetelu deklaratsioon
[52]  AttlistDecl ::=  '<!ATTLIST' S NameAttDef* S? '>'
[53]  AttDef ::=  S Name SAttTypeSDefaultDecl

Name reeglis AttlistDecl on elemendi tüüp. XML-protsessor võib kasutaja valikul väljastada hoiatuse, kui atribuudid on deklareeritud elemendi tüübi kohta, mida ennast pole deklareeritud, kuid see pole viga. Nimi Name  reeglis  AttDef on atribudi  nimi.

Kui rohkem kui üks reegel AttlistDecl  on ette nähtud etteantud elemendi tüübi jaoks, siis mestitakse kõik elemendi tüübi jaoks ette nähtud reeglite  sisud. Kui etteantud elemendi tüübi jaoks on samal atribuudil rohkem kui üks definitsioon, siis seostatakse neist esimene deklaratsioon ja järgnevaid deklaratsioone ignoreeritakse. Risttöödeldavuseks (for interoperability)  võivad DTD  kirjutajad otsustada ette näha ette antud elemendi tüübi jaoks mitte enam kui  ühe atribuudiloetelu deklaratsiooni ja iga atribuudiloetelu deklaratsiooni kohta vähemalt ühe atribuudi definitsiooni. XML-protsessor võib ristkasutatavuseks väljastada kasutaja suvandi korral hoiatuse, kui etteantud elemendi tüübi jaoks on rohkem kui üks atribuudiloetelu deklaratsioon, või kui etteantud atribuudi jaoks on ette nähtud rohkem kui üks atribuuti, kuid see pole viga.

3.3.1Atribuutide tüübid

XML atribuutide tüüpe on kolm:  string tüüp, lekseemtüüp ja loendurtüüp. String tüüp võib omada väärtuseks mistahes literaalidest koosneva stringi; lekseemtüüp võib omada mitmesuguseid  leksikalisi ja semantilisi piiranguid, nagu:
 
Atribuutide tüübid
[54]  AttType ::=  StringType | TokenizedType | EnumeratedType
[55]  StringType ::=  'CDATA'
[56]  TokenizedType ::=  'ID' VC: ID ]
VC: Iga elemenditüübi jaoks üks ID (One ID per Element Type) ]
VC: ID atribuudi vaikeväärtus  (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 ]

Kehtivuse piirang: ID
ID-väärtused peavad klappima produktsiooniga  Name. Nimi ei tohi esineda rohkem kui üks kord XML-dokumendis selle tüübi väärtusena;  st ID väärtused  peavad üheselt identifitseerima elemente, mis on nad sünnitanud.

Kehtivuse piirang: Iga elemendi jaoks üks ID
ID-atribuudiga spetsifitseeritud elemendi tüüpe ei või olla rohkem kui üks.

Kehtivuse piirang: ID-atribuudi vaikevaärtus
ID-atribuudi jaoks peab olema deklareeritud vaikeväärtus konstruktsiooni  #IMPLIED või #REQUIRED abil.

Kehtivuse piirang: IDREF
Tüübi IDREF väärtused peavad klappima produktsiooniga Name ja tüübi IDREFS väärtused peavad klappima produktsioonidega Names; iga  Name peab klappima mõne XML-dokumendi elemendi ID-atribuudi väärtusega; st IDREF väärtused peavad klappima mõne  ID-atribuudi väärtusega.

Kehtivuse piirang: üksuse nimi
Tüübi  ENTITY väärtused peavad klappima produktsiooniga Name, tüübi ENTITIES väärtused peavad klappima Names; iga Name peab klappima DTDs deklareeritud parsimata üksuse (unparsed entity) nimega.

Kehtivuse piirang: nime lekseem
Tüübi NMTOKEN väärtused peavad klappima produktsiooniga Nmtoken; tüübi  NMTOKENS väärtused peavad klappima produktsiooniga Nmtokens .

Loenduratribuudid võivad võtta ühe väärtuse, mis on deklaratsiooni väärtuste loetelus ette nähtud. Loendurtüüpe on kaks:
 
Loenduratribuudi tüübid
[57]  EnumeratedType ::=  NotationType | Enumeration
[58]  NotationType ::=  'NOTATION' S '(' S? Name (S? '|' S? Name)* S? ')' VC: Notatsiooni atribuudid (Notation Attributes) ]
[59]  Enumeration ::=  '(' S? Nmtoken (S? '|' S? Nmtoken)* S? ')' VC: Numeratsioon (Enumeration) ]

NOTATION atribuut identifitseerib notatsiooni  (notation), mis on deklareeritud DTDs koos süsteemi ja/või avaliku identifikaatoriga, mida kasutatakse selle elemendi interpreteerimisel, millele atribuut on lisatud.

Kehtivuse piirang: notatsiooni atribuudid
Selle tüübi väärtused peavad klappima  ühega deklaratsiooni lülitatud notatsiooni  (notation) nimega; kõik notatsiooni nimed deklaratsioonis peavad olema deklareeritud.

Kehtivuse piirang: Loendamine
Seda tüüpi väärtused peavad klappima ühega deklaratsioonis toodud lekseemiga Nmtoken.

Risttöödeldavuseks (for interoperability)  ei tohi  sama lekseem  Nmtoken  esineda rohkem kui üks kord üksikelemendi tüübi loenduratribuudi tüübis.

3.3.2 Atribuutide vaikeväärtused

Atribuudi deklaratsioon (attribute declaration) näeb ette informatsiooni esitamise selle kohta, kas atribuudi olemasolu on nõutav ja kui ei ole nõutav, siis selle, kidas XML protsessor peab reageerima situatsioonile, kus dokumendis puudub deklareeritud atribuut.
 
Atribuudi vaikeväärtus
[60]  DefaultDecl ::=  '#REQUIRED' | '#IMPLIED' 
| (('#FIXED' S)? AttValue) VC: Kohustuslik atribuut (Required Attribute) ]
VC: Seaduslik atribuut vaikimisi (Attribute Default Legal) ]
WFC: Märgi < puudumine atribuudi väärtuses  (No < in Attribute Values) ]
VC: Fikseeritud atribuut vaikimisi  (Fixed Attribute Default) ]

REQUIRED atribuudi deklaratsioonis tähendab, et atribuut peab alati esinema, #IMPLIED, et  vaikeväärtust pole ette nähtud.  Kui deklaratsioonis ei ole ei #REQUIRED ega  #IMPLIED, siis AttValue  väärtus sisaldab deklareeritud vaikeväärtust;  võtmesõna #FIXED sedastab, et atribuudil peab alati olema vaikeväärtus. Kui vaikeväärtus on defineeritud ja  XML-protsessor kohtab vahele jäetud  atribuuti, peab ta käituma nagu atribuut eksisteeriks oma deklareeritud vaikevaärtusega.

Kehtivuse piirang: Kohustuslik atribuut
Kui vaikedeklaratsioon on võtmesõna #REQUIRED, siis atribuudiloetelu deklaratsioonis peab atribuut olema spetsifitseeritud kõigi selle tüübi elementide jaoks.

Kehtivuse piirang: seaduspärane atribuut vaikimisi
Deklareeritud vaikeväärtus peab järgima deklareeritud atribuudi tüübi leksikaalseid piiranguid.

Kehtivisuse piirang: fikseeritud atribuut vaikimisi
Kui atribuudil  on vaikeväärtus defineeritud võtmesõnaga  #FIXED, selle atribuudi eksemplarid  peavad klappima vaikeväärtusega.

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

3.3.3 Atribuudi väärtuste normaliseerimine

Enne atribuudi väärtuse üleandmist rakendusele või enne valideerimist, peab XML-protsessor seda normaliseerima järgmiselt Kui deklareeritud väärtus ei ole CDATA, siis peab XML-protsessor normaliseeritud atribuudi väärtust edasi töötlema, eemaldama kõik tühikumärgid  (#20) atribuudi väärtuse algusest ja lõpust ja asendama  tühikujadad (#x20) ühe tühikumärgiga (#x20).

Kõiki deklareerimata atribuute peab käsitlema mittevalideeriva  parseri poolt kui deklareeritud CDATA-sektsiooni.

3.4 Tingimuslikud sektsioonid

Tingimuslikud sektsioonid  on välise alamhulga dokumendi tüübi (document type declaration external subset) portsjonid, mis on DTDl baseeruvusse loogilisse struktuuri kas lülitatud sisse, või välja.
 
Tingimuslikud sektsioonid
[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*)

Analoogselt sisemistele ja välistele DTD alamhulkadele, võib tingimuslik sektsioon sisaldada ühte või enamat terviklikku deklaratsiooni, kommentaare, töötluseeskirju, sisestatud tingimuslikke sektsioone, mis on kokku segatud tühiruumi märkidega.

Kui tingimusliku sektsiooni võtmesõnaks on INCLUDE, siis on tingimusliku sektsiooni sisuks DTD osa. Kui tingimusliku sektsiooni võtmesõnaks on IGNORE, siis tingimusliku sektsiooni osaks pole loogikaliselt DTD osa.  Märgime, et usaldusväärseks analüüsiks peab isegi ignoreeritud tingimusliku sektsiooni sisu loetama,  et avastada sisestatud tingimuslikke sektsioone ja kindlustama, et kaugeima (ignoreeritud) tingimusliku sektsiooni lõpp oleks korrektselt kindlaks tehtud. Kui tingimuslik sektsioon võtmesõnaga INCLUDE esineb laiemas tingimuslikus sektsioonis võtmesõnaga  IGNORE,  ignoreeritakse mõlemaid nii välist kui ka sisemist  tingimuslikku sektsiooni.

Kui tingimusliku sektsiooni võtmesõnaks on parameeterüksuse viit, siis parameeterüksus peab olema asendatud tema sisuga enne kui protsessor otsustab kas tingimuslik sektsioon lülitada sisse või ignoreerida teda.

Näide:
 
<!ENTITY % draft 'INCLUDE' >
<!ENTITY % final 'IGNORE' >

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

4. Füüsiline struktuur

XML dokument võib sisaldada ühte või mitut säilituskirjet. Neid kutsutakse üksusteks; neil kõigil on sisu ja nad kõik on  (välja arvatud dokumendiüksus, vaata allpool, ja väline DTD (external DTD subset )) identifitseeritud nimega. Igal XML-dokumendil on üks üksus, mida kutsutakse dokumendiüksuseks (document entity), mis on XML-protsessori  (XML processor) jaoks stardipunktiks ja mis võib sisaldada kogu dokumendi.

Üksused võivad olla kas parsitud või parsimata.Parsitud üksuste sisule viidatakse nagu tema asendustekstile (replacement textreplacement text); seda teksti  (text) käsitletakse dokumendi lahutamatu osana.

Parsimata üksus on  ressurss, mille sisuks võib ja võib ka mitte olla, tekst (text) ja kui ta on tekst, siis ta võib olla mitte  XML-tekst. Igal parsimata üksusel on temaga assotsieeruv notatsioon (notation), mis on identifitseeritav nimega. XML ei kitsenda parsimata üksuste sisu, välja arvatud nõue, et XML-protsessor teeb üksuste identifikaatorid ja notatsiooni kättesaadavaks rakendusele.

Parsitud üksused kutsutakse välja kasutades üksuseviita; parsimata üksused atribuutide  ENTITY või ENTITIES  väärtustes esitatud nimede järgi.

Üldüksused on dokumendi sisus kasutatavad üksused. Selles spetsifikatsioonis on üldüksustele mõnikord viidatud  kvalifitseerimata terminiga üksus (entity), seda juhul  kui see ei tekita kahemõttelisust.  Parameeterüksused on parsitud üksused kasutamiseks DTDs. Need kaks üksuse tüüpi kasutavad erinevas vormis viitamist ja tuvastatakse erinevates kontekstides. Liiatigi haaravad nad erinevad nimeruumid; sama nimega parameeterüksus ja üldüksus on kaks eri üksust.

4.1 Märgi- ja üksuseviidad

Märgiviit viitab ISO/IEC 10646 märgistiku erimärgile, näiteks sellisele, mis pole vahetult kättesaadav olemasolevatest sisendseadmetest.
 
Märgiviit
[66]  CharRef ::=  '&#' [0-9]+ ';' 
| '&#x' [0-9a-fA-F]+ ';' WFC: Õige märk (Legal Character) ]

Trimmisuse kitsendus: Lubatavad märgid
Märgiviida poolt viidatavad märgid peavad klappima produktsiooniga Char.
Kui märgiviit algab jadaga "&#x", numbrid ja tähed kuni lõpetava märgini ; moodustavad ISO/IEC 10646 märgi  kuueteistkümnesüsteemse esituse. Kui ta algab märgijadaga  "&#", siis kümnendarvud kuni lõpetava märgini  ; moodustavad märgi kümnendsüsteemis esituse.

Üksuseviiit viitab nimega üksuse sisule. Viidad parsitud üldüksustele kasutavad eraldajatena märke ampersand (&) ja semikoolon (;). Parameeterüksuse  viidad kasutavad eraldajatena protsendimärki (%) ja semikolonit (;).
 
Üksuseviit
[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 ]

Trimmisuse piirang: üksuse deklareeritus
Dokumendis täiesti ilma DTDta, dokumendis ainult sisemise DTD alamhulgaga, mis ei sisalda parameeterüksuse viita, või  dokumendis parameetriga "standalone='yes'", peab üksuse viidas toodud Name klappima (match), antuga üksuse deklaratsioonis (entity declaration), välja arvatud asjaolu, et trimmis dokumendis pole vajadust deklareerida järgmisi üksusi: amp, lt, gt, apos, quot. Parameeterüksuse viida deklaratsioon peab eelnema mistahes temale suunatud viidale. Analoogselt peab üldüksuse viida deklaratsioon eelnema mistahes temale suunatud  viidale, mis on toodud atribuutloetelu deklaratsiooni vaikeväärtuses.  Märgime et kui üksused on deklareeritud välises alamhulgas või välises parameeterüksuses, ei ole mittesiduv protsessor kohustatud (not obligated to)   nende deklaratsioone lugema ja töötlema,  trimmisuse piirang standalone='yes'  toob kaasa  üksuse deklareerituse nõude.

Kehtivuse piirang: üksuse deklareeritus
Dokumendis, millel on väline alamhulk või väline parameeterüksus koos määranguga  "standalone='no'", peab üksusviidas ette antud  Name klappima (match ) sellega, mis on antud üksuse deklaratsioonis (entity declaration). Risttöödeldavuseks peab kehtivates dokumentides olema deklareeritud üksused amp, lt, gt, apos, quot, kujul nagu on spetsifitseeritud jaotises "4.6 Eeldefineeritud üksused". Parameeterüksuse deklaratsioon peab eelnema  mistahes temale suunatud viidale. Analoogselt peab üldüksuse deklaratsioon eelnema mistahes temale suunatud viidale, mis asub atribuudiloetelu deklaratsiooni vaikeväärtuses.
.

Trimmisuse piirang: Parsitud üksus
Üksuseviit ei tohi sisaldada parsimata üksuse  (unparsed entity) nime. Parsimata üksustele võib  viidata ainult atribuutide väärtustes (attribute values), mis on deklareeritud tüübina ENTITY või ENTITIES.

Trimmisuse piirang: rekursiivsuse keeld
Analüüsimata üksus ei tohi sisaldada ei otsesel ega kaudsel moel rekursiivset viita iseendale.

Trimmisuse piirang:  DTDs
Parameeterüksuse viit saab esineda ainult DTD piires.

Näited märgi- ja üksuseviitadest:
 
Type <key>less-than</key> (&#x3C;) to save options.
This document was prepared on &docdate; and
is classified &security-level;.

Näide parameeterüksuse viidast:
 
<!-- declare the parameter entity "ISOLat2"... -->
<!ENTITY % ISOLat2
         SYSTEM "http://www.xml.com/iso/isolat2-xml.entities" >
<!-- ... now reference it. -->
%ISOLat2;

4.2 Üksuse deklaratsioonid

Üksused on deklareeritud alljärgnevalt:
 
Üksuse deklaratsioon
[70]  EntityDecl ::=  GEDecl | PEDecl
[71]  GEDecl ::=  '<!ENTITY' S NameSEntityDefS? '>'
[72]  PEDecl ::=  '<!ENTITY' S '%' SNameSPEDefS? '>'
[73]  EntityDef ::=  EntityValue | (ExternalIDNDataDecl?)
[74]  PEDef ::=  EntityValue | ExternalID

Name identifitseerib üksuse üksuseviidas (entity reference) või parsimata üksuse korral atribuudi  ENTITY või ENTITIES väärtuses. Kui üks ja seesama üksus on deklareeritud rohkem kui üks kord, siis on siduv esimene deklaratsioon, kasutaja valikul võib XML-protsessor väljastada mitmekordselt deklareeritud üksuse korral hoiatuse.

4.2.1 Siseüksused

Kui üksuse definitsiooniks on EntityValue, siis nimetatakse defineeritud üksust siseüksuseks. Ta pole eraldiasuv füüsiline säilitatav objekt ja üksuse sisu on esitatud deklaratsioonis. Märgime, et mõne üksuse-  ja märgiviida töötlemine literaalüksuse väärtuses (literal entity value),  võib nõuda õige  asendusteksti ( replacement text) produktsiooni: vaata "4.5 Siseüksuse asendusteksti konstruktsioon".

Siseüksus on parsitud üksus (parsed entity).

Näide siseüksuse deklaratsioonist:
 
<!ENTITY Pub-Status "This is a pre-release of the
 specification.">

4.2.2 Välisüksused

Kui üksus ei ole sisemine, siis on ta välisüksus, mis on deklareeritud alljärgnevalt:
 
External Entity Declaration
[75]  ExternalID ::=  'SYSTEM' S SystemLiteral
| 'PUBLIC' S PubidLiteralSSystemLiteral
[76]  NDataDecl ::=  S 'NDATA' SName VC: Notatsiooni deklareeritus  (Notation Declared) ]

Kui deklaratsioonis on olemas NDataDecl, siis on ta parsitud üldüksus (unparsed entity); vastasel juhul on ta parsitud üksus.

Kehtivuse piirang: Notatsiooni deklareeritus
Name peab klappima notatsioonis (notation) deklareeritud nimega.

SystemLiteral on üksuse süsteemne  identifikaator. Ta on URI, mida võib kasutada üksuse leidmiseks. Märgime, et sageli koos URIga kasutatav numbrimärk (#) ja fragmendi identifikaator ei ole formaalselt iseendast URI osa,  XML-protsessor võib signaliseerida veast,  kui süsteemi identifikaatori osana on esitatud fragmendi identifikaator. Kui väljaspool seda spetsifikatsiooni (näiteks spetsiaalse DTDga defineeritud XML-elemendi tüüp või spetsiaalse rakenduse spetsifikatsiooniga defineeritud töötluseeskiri) skoopi  ei ole  ette nähtud teisiti,  siis on URI suhteline selle ressursi asukoha suhtes, milles üksuse deklaratsioon paikneb.  URI võib järelikult olla suhteline dokumendiüksuse  (document entity) suhtes, välist DTD alamhulka (external DTD subset) sisaldava üksuse suhtes, või mõne teise välise parameeterüksuse (external DTD subset) suhtes.

XML-protsessor peab mitte-ASCII märke URIs käsitlema märgi esitamisega ühe või kahe baidiga  UTF-8  koodina ja seejärel varjestama need baidid  URI varjestamismehhanismiga  (näiteks konverteerides kõik baidid kujule  %HH, kus HH on baidi väärtuse esitus kuueteistkümnendsüsteemis).

Väline identifikaator võib lisaks süsteemsele identifikaatorile sisaldada avalikku identifikaatorit. Otsides üksuse sisu võib XML-protsessor  püüda kasutada avalikku identifikaatorit alternatiivse URI genereerimiseks. Kui protsessoril see ebaõnnestub, peab ta kasutama süsteemses literaalis spetsifitseeritud  URI. Enne klapitamise püüdu peab kõikide avaliku identifikaatori tühiruumi stringid normaliseeritama ühebaidiseks märgiks (#x20),   tühiruum alguses ja lõpus tuleb kustutada.

Välisüksuse deklaratsioonide näited:
 
<!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 Parsitud üksused

4.3.1 Teksti deklaratsioon

Kõik välisüksused võivad alata  teksti deklaratsiooniga.
 
Teksti deklaratsioon
[77]  TextDecl ::=  '<?xml' VersionInfo? EncodingDeclS? '?>'

Teksti deklaratsioon peab olema esitatud literaalina, mitte viidana parsitud üksusele. Teksti deklaratsioon ei saa paikneda  mitte mingis  muus positsioonis peale parsitud välisüksuse alguse.

4.3.2 Parsitud trimmis üksused

Dokumendi üksus on trimmis kui ta klapib produktsiooniga document. Väline parsitud üldüksus on trimmis kui ta kapib produktsiooniga extParsedEnt. Väline parameeterüksus on trimmis kui ta klapib produktsiooniga extPE.
 
Trimmis parsitud välisüksused
[78]  extParsedEnt ::=  TextDecl? content
[79]  extPE ::=  TextDecl? extSubsetDecl

Parsitud üldine siseüksus on trimmis, kui ta asendustekst klapib produktsiooniga content. Kõik sisemised parameeterüksused on trimmis definitsiooni kohaselt.

Trimmisus üksustes on selle asjaolu tagajärg, et XML-dokumendi loogilised ja füüsilised struktuurid on õigesti sisestatud (nested);  algusmärgis (start-tag), lõpumärgis (end-tag), tühielemendi märgis (empty-element tag), element (element), kommentaar (comment), töötluseeskiri (processing instruction), märgiviit (character reference) ja üksuseviit (entity reference) ei saa alata ühes üksuses ja lõppeda teises.
 

4.3.3 Märkide kodeerimine üksustes

Iga XML-dokumendi parsitud välisüksus võib kasutada oma märkide kodeerimise jaoks erinevat moodust. Kõik XML-protsessorid peavad olema võimelised lugeda  UTF-8 ja UTF-16 üksuseid.

UTF-16 koodis üksused peavad  algama  märgiga "Byte Order Mark", mis on kirjeldatud standardis  ISO/IEC 10646 Annex E and Unicode Appendix B (märk NULL LAIUSEGA MITTE KATKESTAV TÜHIK, #xFEFF). See märk on kodeerimise signatuur, mitte osa märgistusest või XML-dokumendi märkandmetest. XML-protsessorid peavad olema võimelised  kasutama seda märki  UTF-8 ja  UTF-16 dokumentide eristamiseks.

Kuigi on nõutav, et XML-protsessor peab olema võimeline lugeda ainult  UTF-8 ja UTF-16 kodeerimissüsteemis üksusi, on tunnustatud teiste kodeerimissüsteemide kasutamist ja XML protsessortitel võib soovitada lugeda neid kasutatavaid üksusi. Kodeerimissüsteeme UTF-8 ja UTF-16 mitte kasutavad parsitud üksused peavad algama teksti deklaratsiooniga  (text declaration), mis sisaldab kodeerimise deklaratsiooni:
 
Kodeerimise deklaratsioon
[80]  EncodingDecl ::=  S 'encoding' Eq ('"' EncName '"' |  "'" EncName "'" )
[81]  EncName ::=  [A-Za-z] ([A-Za-z0-9._] | '-')* /*  Kodeerimise nimi sisaldab ainult ladina tähti */

Dokumendiüksuses (document entity) on kodeerimise deklaratsioon osa XML deklaratsioonist (XML declaration. EncName on kasutatava kodeerimissüsteemi nimi.

Kodeerimise deklaratsioonis peab väärtusi  "UTF-8", "UTF-16", "ISO-10646-UCS-2" ja "ISO-10646-UCS-4" kasutama  Unicode / ISO/IEC 10646 erinevate kodeerimissüsteemide ja transformeerimiste jaoks, väärtusi  "ISO-8859-1", "ISO-8859-2", ... "ISO-8859-9" peab kasutatama  ISO 8859 osade jaoks, ja väärtusi  "ISO-2022-JP", "Shift_JIS" ja "EUC-JP" peab kasutama  JIS X-0208-1997 kodeerimisvormide jaoks. XML protsessorid võivad tuvastada teisi kodeerimismooduseid; on soovitav, et märkide kodeerimine oleks registreeritud ( märgistikuna)  Internet Assigned Numbers Authority [IANA]  poolt, ülaltoodud loetelust erinevad peavad olema viidatud kasutades nende registreeritud nimesid. Märgime, et need registreeritud nimed on defineeritud tõsttundetuna, nii et kui protsessorid tahavad neid klapitada, peavad nad seda tegema tõsttundetul moel.

Välise transpordi protokolli (näiteks HTTP või MIME) poolt üleantud andmetes informatsiooni puudumine on viga (error) üksuse korral, mis sisaldab XML protsessorile esitamiseks kodeerimise deklaratsiooni, kuid on kodeeritud erinevalt deklareeritust; kodeerimise deklaratsiooni korral, kui ta paikneb mujal kui välise üksuse alguses; üksuse korral, mis ei alga ei baidiga Byte Order Mark ega kodeerimise deklaratsiooni kasutamaks UTF-8st erinevat kodeerimist. Märgime, et kuna  ASCII on UTF-8 alamhulk, tavalised  ASCII üksused ei vaja otseselt kodeerimise deklaratsiooni.

On hukutav viga  (fatal error) kui XML-protsessor põrkub üksusega,  mille kodeerimist ta pole võimeline töötlema.

Kodeerimisdeklaratsioonide näited:
 
<?xml encoding='UTF-8'?>
<?xml encoding='EUC-JP'?>

4.4 XML Üksuste ja viitade protsessoripoolne käsitlemine

Alltoodud tabel summeerib kontekstid, milles märgiviidad, üksuseviidad ja parsimata üksuste sissekutsumised võivad esineda ja XML- protsessori (XML processor) nõutavat käitumist igal juhtumil. Tekstid kõige vasakpoolsemas tulbas kirjeldavad vaadeldavat protsessi:

Viit kontekstis
          on viit mistahes kohas elemendis peale algusmärgist  (start-tag) ja enne lõpumärgist (end-tag); on vastavuses mitteterminaliga  content .
Viit atribuudi väärtuses
            on kas viit algusmärgise ( start-tag) atribuudi väärtuses, või vaikeväärtus atribuudi deklaratsioonis ( attribute declaration); on vastavuses mitteterminaliga AttValue.

Esineb atribuudi väärtusena
on nimena  (Name), mite viidana, ilmub kas tüübina ENTITY deklareeritud atribuudi väärtusena, või üheks tühikutega eraldatud lekseemidest tüübina ENTITIE  deklareeritud  atribuudi väärtuses.
Viit üksuse väärtuses
on viit üksuse deklaratsioonis parameeterüksuse või sisemise üksuse literaalses üksuse väärtuses (literal entity value); on vastavuses mitteterminaliga  EntityValue.
Viit DTDs
on viit kas sisemises või välimises DTD alamhulgas, kuid väljaspool EntityValue või  AttValue.
Üksuse tüüp Märk
Parameeter Sisemine
Üldine
Väline 
Parsitud
Üldine
Parsimata
Viit sisus Tuvastamata
Not recognized
Kaasatud
Included
Kaasatud valideerimisel
Included if validating
Keelatud
Forbidden
Kaasatud
Included
Viit atribuudi väärtuses Tuvastamata
Not recognized
Kaasatud literaalis
Included in literal
Keelatud
Forbidden
Keelatud
Forbidden
Kaasatud
Included
Esineb atribuudi väärtusena Tuvastamata
Not recognized
Keelatud
Forbidden
Keelatud
Forbidden
Teadistama
Notify
Tuvastamata
Not recognized
Viit üksuse väärtuses Kaasatud literaalis
Included in literal
Edastatud
Bypassed
Edastatud
Bypassed
Keelatud
Forbidden
Kaasatud
Included
Viit DTDs Kaasatud nagu PE
Included as PE
Keelatud
Forbidden
Keelatud
Forbidden
Keelatud
Forbidden
Keelatud
Forbidden

4.4.1 Tuvastamata - Not Recognized

Väljaspool  DTDd, ei oma märk  % erilist tähendust; niisiis see, mis on DTDs parameeterüksuse viit, jääb tuvastamata sisus (content) märgistusena. Analoogselt jäävad tuvastamata analüüsimata üksuste nimed, välja arvatud kui nad ilmuvad sobivalt deklareeritud atribuutide väärtuses.

4.4.2 Kaasatud - Included

Üksus on kaasatud  kui tema asendustekst (replacement text)  on üles leitud ja töödeldud samas kohas, kus asub  tema viit, just nagu oleks ta dokumendi osa viida tuvastamise paigas. Asendustekst võib sisaldada nii märkandmeid  character data (character data) ja (välja arvatud parameeterüksused) märgistust (markup), mis peab olema tuvastatud tavalisel moel, välja arvatud see, et nende üksuste  asendusteksti, mida kasutatakse märgistuse eraldajate paokoodina (üksused  amp, lt, gt, apos, quot) käsitletakse alati andmetena. (String "AT&amp;T;" kujuneb stringiks  "AT&T;" ja allesjäänud ampersandi ei tuvastata üksusviida eraldajana.)  Märgiviit on kaasatud,  kui osutatud märk on töödeldud temale viitamise kohas.

4.4.3 Kaasatud valdeerimisel - Included If Validating

Kui XML protsessor tuvastab viida parsitud üksusele, siis vastavalt dokumendi valideerimise (validate) korrale, peab protsessor  kaasama (include) tema asendusteksti. Välisüksuse korral, kui protsessor ei püüa XML-dokumenti valideerida, võib (may), kuid ei pea,  protsessor kaasata  üksuste asendusteksti. Kui mittevalideeriv parser ei kaasa asendusteksti, siis peab ta teatama rakendusele, et ta tuvastas üksuse, kuid ei kaasanud teda.

See reegel põhineb äratundmisel, et SGML ja XML üksuste poolt ette nähtud automaatse kaasamise mehhanism, mis projekteeriti eeskätt toetamaks andmete sisestamise modulaarsust ja ei tarvitse tingimata sobida teistele rakendustele, eriti dokumendi lehitsemisel.  Nii näiteks võivad brauserid kohates parsitud välisviita, valida üksuse visuaalse näitamise tagamise ja otsida ta vajadusel ainult kuvamiseks.

4.4.4 Keelatud - Forbidden

Järgnevad situatsioonid on keelatud ja tekitavad hukutavad (fatal) vead:

4.4.5 Kaasatud literaalis - Included in Literal

Kui üksuse viit (entity reference)  on atribuudi väärtuses, või parameeterüksuse viit on literaalüksuse väärtuses, siis tema asendustekst (replacement text) töödeldakse samas kohas, kus asub tema viit, just nagu oleks ta dokumendi osa kohas, kus viit tuvastati, välja arvatud, et asendustekstis koheldakse ülakoma ja jutumärki  tavalise andmemärgina ja nad ei lõpeta literaali. Näiteks on järgnev trimmis:
 
<!ENTITY % YN '"Yes"' >
<!ENTITY WhatHeSaid "He said &YN;" >

sellal kui järgnev ei ole:
 
<!ENTITY EndAttr "27'" >
<element attribute='a-&EndAttr;>

4.4.6 Teadistama - Notify

Kui parsimata üksuse (unparsed entity) nimi esineb lekseemina deklareeritud tüüpide ENTITY või ENTITIES atribuutide väärtustes, peab valideeriv protsessor informeerima rakendust süsteemi (system) ja avaliku (public) (kui on olemas) identifikaatorite olemasolust, nii üksusest kui ka temaga assotsieeruvast notatsioonist (notation).

4.4.7 Edastatud -Bypassed

Kui üksuse deklaratsioonis  EntityValue   sisaldab üldüksuse viita, siis ta edastatakse ja jäetakse samale kujule nagu ta on.

4.4.8 Kaasatud nagu PE - Included as PE

Parameeterüksusi on nagu parsitud välisüksusedki vaja ainult nende kaasamisel valideerimisel (included if validating). Kui parameeterüksuse viit on DTDs tuvastatud ja sinna kaasatud, suurendatakse tema asendusteksti  (replacement text) ühe alguse ja lõpu tühiku (#x20) lisamisega, selle kavatsus on kitsendada parameeterüksuse asendusteksti, nii et ta sisaldaks DTDs grammatiliste lekseemide terviklikku hulka.

4.5 Siseüksuse asendusteksti konstruktsioon

Siseüksuste käitumise käsitlemisel on kasulik eristada kahte üksuse väärtuse vormi. Literaalüksuse väärtus on üksuse deklaratsioonis reaalselt asuv  jutumärkides string, mis vastab mitteterminalilel EntityValueAsendustekst on üksuse sisu pärast märkviitade ja parameeterüksuste asendamist.

Literaalüksuse väärtus sisemises üksuse deklaratsioonis (EntityValue) toodud kujul võib sisaldada märgiviita, parameeterüksuse viita ja üldüksuse viita Sellised viidad peavad täielikult sisalduma literaalüksuse väärtuses. Tegelik asendustekst, mis on ülalkirjeldatud viisil kaasatud (included), peab sisaldama iga viidatud parameeterüksuse asendusteksti ja peab sisaldama viidatavaid märke märgiviida esinemiskohas parameeterüksuse väärtuses; kuigi üldüksuse viit peab jääma samale kujule, ilma laiendamata. Kui näiteks on antud järgmised deklaratsioonid:
 
<!ENTITY % pub    "&#xc9;ditions Gallimard" >
<!ENTITY   rights "All rights reserved" >
<!ENTITY   book   "La Peste: Albert Camus, 
&#xA9; 1947 %pub;. &rights;" >

siis üksuse "book" asendustekst on:
 
La Peste: Albert Camus, 
© 1947 Éditions Gallimard. &rights;

Üldüksuse viit "&rights;" laiendamiseks peab viit "&book;" olema dokumendi sisus või atribuudi väärtuses.

Need lihtsad reeglid võivad omada kompleksseid mõjutusi; keerulise näite detailne käsitlust vaata  " "D. Üksuste ja märkviitade laiendamine".

4.6 Eeldefineeritud üksused

Mõlemaid, nii üksuse- kui ka märgiviita võib kasutada vasaku nurksulu, ampersandi ja teiste eraldajate varjestamiseks. Selleks eesmärgiks on spetsifitseeritud kogum üldüksusi (amp, lt, gt, apos, quot). Numbrilisi märgiviitu võib samuti kasutada; need laiendatakse vahetult tuvastamishetkel ja neid peab kohtlema märkandmetena, nii võib numbrilisi märgiviitu "&#60;" and "&#38;" kasutada märkide  < ja & varjestamiseks, kui nad esinevad märkandmetes.

Kõik  XML-protsessorid peavad need üksused tuvastama sõltumatult sellest, kas nad on deklareeritud või mitte. Risttöödeldavuseks (for interoperability) peaksid kehtivad XML-dokumendid üksused enne nende kasutamist need deklareerima, nagu kõik teisedki üksused. Kui kõnealused üksused on deklareeritud, peavad nad olema deklareeritud sisüksustena, mille asendustekst on üksik varjestatav märk, või selle märgi märgiviit, nagu on näha alljärgnevas.
 
<!ENTITY lt     "&#38;#60;"> 
<!ENTITY gt     "&#62;"> 
<!ENTITY amp    "&#38;#38;"> 
<!ENTITY apos   "&#39;"> 
<!ENTITY quot   "&#34;"> 

Märgime, et märgid  < ja  &  deklaratsioonides "lt" ja "amp" on varjestatud kahekordselt selleks, et täita üksuse asendusteksti kehtivuse nõuet.

4.7 Notatsiooni deklaratsioon

Notatsioon identifitseerib nime järgi parsimata üksuste (unparsed entities) formaadi,  elementide formaadi, mis genereerivad märkuse atribuudi või rakenduse, millele on töötlemiseeskirjad (processing instruction) adresseeritud

Notatsiooni deklaratsioonid varustavad notatsiooni nimega, tema kasutamiseks üksuses ja atribuudiloetelu deklaratsioonis, ja välise identifikaatoriga märkuse jaoks, mis võib lubada XML-protsessoril või tema kliendi rakendusel määrata abistava rakenduse, mis on võimeline töötlema andmeid etteantud märkuses.
 
Notatsiooni deklaratsionid
[82]  NotationDecl ::=  '<!NOTATION' S NameS (ExternalID | PublicID) S? '>'
[83]  PublicID ::=  'PUBLIC' S PubidLiteral

XML-protsessorid peavad  rakendustele teatama mistahes deklareeritud ja atribuudi väärtuses, atribuudi definitsioonis või üksuse deklaratsioonis  viidatud  märkuse nime ja välised identifikaatorid. Lisaks võivad nad lahendada viidad välise identifikaatori süsteemi identifikaatorile (system identifier), faili nimele, või muule informatsioonile, mida vajatakse, et lubada rakendusel välja kutsuda märkuses kirjeldatud andmete jaoks protsessor.  (See ei ole viga, ükskõik kuidas XML-dokumentide jaoks deklareerida ja viidata notatsioonile, mille jaoks pole süsteemis, kus XML-protsessor või  rakendus töötab, notatsioonispetsiifiline rakendus kättesaadav.)

4.8 Dokumentüksus

Dokumentüksus on üksuse puu juureks (root ) ja lähtepunktiks XML-protsessorile (XML processor). Käesolev spetsifikatsioon ei määra, kuidas XML protsessor leiab dokumentüksuse; erinevalt teistest üksustest pole dokumentüksusel nime ja võib täiesti vabalt olla protsessori lähtevoos üleüldse ilma mingi identifitseerimisetal.

5. Kohaldamine

5.1 Valideerivad ja mittevalideerivad protsessorid

Kohaldavad XML protsessorid (XML processors ) jagunevad kahte klassi: valideerivad ja mittevalideerivad.

Valideerivad ja mittevalideerivad protsessorid peavad ühteviisi raporteerima dokumentüksuse  (document entity)  ja mistahes teise parsitud üksuste ( parsed entities) lugemisel käesoleva spetsifikatsiooni trimmisuse piirangute rikkumistest.

Valideerivad protsessorid peavad raporteerima DTD deklaratsioonides väljendatud piirangute rikkumistest  ja käesolevas spetsifikatsioonis toodud kehtivuse piirangute teostamise ebaõnnestumistest. Selle täitmiseks peavad valideerivad XML-protsessorid lugema ja töötlema kogu DTD ja kõik dokumendi poolt viidatud parsitud välisüksused.

Mittevalideerivatel protsessoritel on nõutav kontrollida ainult dokumentüksuse (document entity) trimmisust, kaasa arvatud kogu sisemine DTD alamhulk. Kuna neil pole nõutav kontrollida dokumendi kehtivust, on neil nõutav töödelda kõik sisemisest DTD alamhulgast sisseloetud  deklaratsioonid ja deklaratsioonid  igas sisseloetud parameeterüksuses, kuni selle parameeterüksuse viidani, mida nad ei  loe; see tähendab, et  nad peavad kasutama nendes deklaratsioonides peituvat teavet atribuutide väärtuste normaliseerimiseks  (normalize), kaasama  ( include) sisemiste üksuste asendustekstid  ja  atribuutide vaikeväärtused  (default attribute values). Nad ei pea töötlema  (process) üksuse deklaratsioone (entity declarations), või atribuudiloetelu deklaratsioone  (attribute-list declarations), milleni jõutakse peale mitteloetava parameeterüksuse viita, kuna üksus võib  sisaldada ülekirjutatavaid deklaratsioone.
 

5.2 XML-protsessorite kasutamine

Valideerivate XML-protsessorite käitumine väga täpselt ette määratav; ta peab lugema iga dokumendi osakese ja raporteerima kõigist trimmisuse ja kehtivuse rikkumistest. Mittevalideerivalt protsessorilt nõutakse vähem; tal pole vaja lugeda dokumentüksusest erinevaid dokumendiosasid. XML-protsessori kasutajate jaoks võivad olla olulised kaks efekti: Erinevate XML-protsessorite vahel risttöötlemise  usaldatavuse maksimeerimiseks ei tohiks mittevalideerivaid protsessoreid kasutavad rakendused usaldada selliste protsessorite mistahes mittenõutavat käitumist  Rakendused, mis nõuavad selliseid omadusi nagu atribuutide vaikeväärtuste kasutamine või välistes üksustes deklareeritud sisemiste üksuste kasutamine, peaksid kasutama valideerivaid XML-protsessoreid.

6. Notatsioon

XML formaalne grammatika on käesolevas spetsifikatsioonis esitatud kasutades lihtsat laiendatud Backus-Naur (Extended Backus-Naur Form - EBNF) notatsiooni. Iga reegel grammatikas defineerib ühe sümboli vormis
 
symbol ::= expression

 Sümbolid on kirjutatud suure algustähega, kui nad on defineeritud regulaaravaldisega, vastasel juhul väiketähega. Literaalstringid on jutumärkides.

Reegli parempoolses osas avaldise sees kasutatakse stringi võrdlemiseks ühe  või mitme märgiga järgmist avaldist:

#xN
kus  N  on kuueteistkümnend koodis täisarv, avaldis klapib märgiga  ISO/IEC 10646 märgistikus, mille kanoonilise (UCS-4) koodi väärtus, kui ta on interpreteeritud märgita kahendarvuna, omab näidatud väärtust. Juhtnullide arv vormis #xN on tähtsusetu, juhtnullide arv vastava koodi väärtuses määratakse märkide kodeerimisel ja pole oluline XML jaoks.
[a-zA-Z], [#xN-#xN]
klapib mistahes märgiga  (character), mille väärtus on näidatud vahemikus(es) (kaasa arvatud näidatud väärtused).
[^a-z], [^#xN-#xN]
klapib mistahes märgiga (character), mille väärtus on väljaspool näidatud piire.
[^abc], [^#xN#xN#xN]
klapib mistahes märgiga (character), mille väärtus ei ole antud märkide hulgas.
"string"
klapib literaalstringiga, klapitamine (matching) toimub jutumärkide sees olevaga.
'string'
klapib literaalstringiga, klapitamine (matching) toimub ülakomade sees olevaga.
Neid  sümboleid võib kombineerida palju komplekssemate mallide võrdlemiseks nagu toodud alljärgnevas, kus A ja  B esitavad lihtsaid avaldisi:
(expression)
avaldist käsitletakse tervikuna ja teda võib kombineerida nagu kirjeldatud selles loetelus.
A?
klapib avaldisega A või mitte millegagi; mittekohustuslik  A.
A B
klapib avaldisega  A millele järgneb  B.
A | B
klapib Aga või Bga, kuid mitte mõlemaga.
A - B
klapib mistahes stringiga, mis klapib avaldisega  A , kuid ei klapi avaldisega B.
A+
klapib ühe või enama kordse avaldisega  A.
A*
klapib null või enam korduva avaldisega  A.
Ülejäänud produktsioonides kasutatavad notatsioonid on:
/* ... */
kommentaar.
[ wfc: ... ]
trimmisuse piirang; ta identifitseerib nime kaudu produktsiooniga assotsieeruvat piirangut trimmis (well-formed) dokumendile.
[ vc: ... ]
kehtivuse piirang;  ta identifitseerib nime kaudu produktsiooniga assotsieeruvat piirangut kehtivale  ( valid) dokumendile.

Lisad

A. Viited

A.1 Normatiivsed viited

IANA
(Internet Assigned Numbers Authority) Official Names for Character Sets, ed. Keld Simonsen et al. See 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 -- 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 Muud viited

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. Märgistike klassid

Järgnevad on Unicode standardis defineeritud märgistikud, märgid on klassifitseeritud põhimärkide baasil (teiste hulgas sisaldavad nad Ladina tähestiku tähti ilma diakriitikuteta), ideograafilisu marke ja kombineeritud märke (Teiste hulgas sisaldab see klass kõige rohkem diakriitikuid); need klassid on kombineeritud tähtede klassi formeerimiseks. Numbrid ja laiendused on samuti eristatud.
 
Characters
[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]

Siin defineeritud märkide klassid on tuletatud Unicode  märkide andmebaasist järgmiselt:

C. XML ja SGML (mittenormatiivne)

XML on projekteeritud SGML alamhulgana, iga kehtiv (valid) XML-dokument peab olema ka vastav SGML-dokument. XML-dokumendi  saavutamiseks vajalike SGML lisapiirangute  detailset võrdlust vaata [Clark].

D. Üksuseviitade ja märgiviitade  laiendamine  (mittenormatiivne)

See lisa sisaldab näiteid, mis illustreerivad üksuseviitade ja märgiviitade tuvastamist ja laiendamist, nagu see on spetsifitseeritud jaotises "4.4 Üksuste ja viitade käsitlemine XML-protsessori poolt ".

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

siis peab XML-protsessor tuvastama märgiviida, kui ta parsib üksuse deklaratsiooni ja lahendama need  enne järgneva stringi salvestamist üksuse "example" väärtusena:
 
<p>An ampersand (&#38;) may be escaped
numerically (&#38;#38;) or with a general entity
(&amp;amp;).</p>

Viit dokumendiüksusele "&example;" põhjustab teksti üleparsimise, mille jooksul elemendi "p" algus- ja lõpumärgis tuvastatakse ja kolm viita tuvastatakse ja laiendatakse, mille tulemusena on elemendi "p" sisu järgmine (kõik andmed, ilma eraldajateta ja märgistuseta):
 
An ampersand (&) may be escaped
numerically (&#38;) or with a general entity
(&amp;).

Keerulisem näide illustreerib täielikult reegleid ja nende mõju. Järgnevas näites on rea numbrid ainuüksi viitamiseks.
 
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>

See produtseerib järgneva:

E. Deterministlik sisu mudel (mittenormatiivne)

Ühilduvuseks (for compatibility), on nõutav, et sisu mudelid elemendi tüüpide deklaratsioonides  oleksid deterministlikud.

SGML nõuab deterministlikku sisu mudeleid (seda kutsutakse ühemõttelisuseks ("unambiguous")); SGML-süsteemide baasil ehitatud XML-protsessorid võivad  mittedeterministlikud sisu mudelid märkida vigadena.

Näiteks on sisu mudel ((b, c) | (b, d)) mittedeterministlik, kuna pärast etteantud lähteväärtust  b ei tea parser ilma edasivaatamiseta  elemendile b järgnevat elementi, milline  b mudelis klappis. Sellel juhul võivad kaks viita elemendile b kokku tõmmata üheks viidaks ja teha mudel kujul (b, (c | d)). Alguselement b klapib nüüd selgelt ainult ühe nimega sisu mudelis. Parser ei pea vaatama edasi, et teha kindlaks järgnevat;  nii  c kui ka  d  on aktsepteeritavad.

Enam formaalselt: lõpliku olekutega automaadi saab konstrueerida sisu mudelist kasutades standardseid algoritme, näiteks algoritmi 3.5 jaotises  3.9 kirjutises Aho, Sethi, and Ullman [Aho/Ullman]. Paljudes sellistes algoritmides on täidetav sammude kogum on konstrueeritud iga positsiooni jaoks regulaaravaldises (st regulaaravaldise iga lehe jaoks süntaksi puus); kui mistahes positsioonile järgneb rohkem kui üks positsioon, mis on märgistatud sama elemenditüübi nimega, siis on sisu mudel vigane ja sellest peab raporteerima kui veast.

Eksisteerib algoritme, mis lubavad paljud, kuid mitte kõik mittedeterministlikud sisu mudelid automaatselt taandada ekvivalentseteks deterministlikeks mudeliteks, vaata  Brüggemann-Klein 1991  [Brüggemann-Klein].

F. Märkide kodeerimise automaatne määramine (mittenormatiivne)

XMLi kodeerimise deklaratsiooni funktsiooniks  on mistahes üksuse sisemise märgisega näidata milline kodeerimine on kasutusel. Enne kui  XML-protsessor saab lugeda sisemist märgist, peab ta ükskõik kuidas aparatuurselt teadma, milline  kodeerimine  on kasutuses - mis on selline, mida sisemine märgis püüab näidata. Üldjuhul  on see lootusetu situatsioon. Ometi pole see täiesti lootusetu XML korral, sest üldjuhul limiteerib XML kaks momenti: mistahes rakenduse korral eeldatakse ainult lõpliku hulga kodeerimiste  tuge ja XML kodeerimise deklaratsiooni positsioon XML-dokumendis ja tema sisu on ette antud, selleks et   teha  võimalikuks automaatselt teha kindlaks kasutusel olev märkide kodeerimise süsteem mistahes üksuses normaaljuhtudel. Paljudel juhtudel on ka teised infoallikad  kättesaadavad lisaks XML-andmevoole. Kaks juhtumit  võivad olla eristatud, sõltuvalt sellest, kas XML-üksus on esitatud protsessorile ilma või koos mistahes kaasaskäiva (välise) informatsioonita Vaatleme esimest varianti.

Kuna iga UTF-8 ja UTF-16 formaadist erinevat kasutav üksus peab algama XMLi kodeerimise deklaratsiooniga, kus esimesed märgid peavad olema '<?xml', võib iga kohandav protsessor pärast kahte või nelja sisendvoo oktetti teha kindlaks, milline järgnevatest juhtumitest rakendub. Selle loetelu lugemisel võib olla abiks teadmine, et  UCS-4 korral, '<' on "#x0000003C" ja  '?' is "#x0000003F", ja UTF-16 poolt nõutav Byte Order Mark andmevoog on "#xFEFF".

See automaatne kindlaksmääramise tase on piisav XML kodeerimise deklaratsioonide lugemiseks ja märkkodeerimise identifikaatori analüüsimiseks, mis on ometi vajalik kodeerimisperede liikmete eristamiseks (näiteks eristada UTF-8 ja 8859; 8859 osi üksteisest; teha kindlaks, milline  EBCDIC koodilehekülgedest on kasutuses ja nii edasi).

Kuna kodeerimise deklaratsiooni sisu on piiratud ASCII märkidega, võib  protsessor usaldusväärselt lugeda kogu kodeerimise deklaratsiooni niipea, kui on kindlaks tehtud, missugune kodeerimispere on kasutuses. Senise praktika kohaselt kõik laialt kasutatud märgikodeerimissüsteemid langevad ühte ülaltoodud kategooriatest, XMLi kodeerimise deklaratsioon lubab põhjendatult usaldusväärse märkide kodeerimise, isegi kui välise infoallikas on operatsioonisüsteemi või transportprotokolli taseme osas mitteusaldatavad.

Kui protsessor on kindlaks teinud kindlaks kasutatava märkide kodeerimise, võib ta käituda talle sobivalt, kas kutsuda iga juhu jaoks eri programm, või pöörduda  kohase konverterfunktsiooni poole iga sisendmärgi jaoks.

Sarnaselt mistahes isemärgendava süsteemiga, XMLi kodeerimise deklaratsioon ei tööta, kui mistahes  tarkvara muudab üksuse märgistiku või kodeerimise ilma kodeerimise deklaratsiooni uuendamata. Märke kodeerivate rutiinide kasutajad peavad olema ettevaatlikud ja tegema kindlaks üksuse märgises oleva sisemise ja välise info korrektsuse.

Teine võimalik situatsioon leiab aset, kui  XML-üksus  kaasneb kodeerimise informatsiooniga nagu mõnedes failisüsteemides ja mõnedes võrgu protokollides. Kui juurdepääsetavad on hulk infoallikaid, nende suhtelise prioriteetsuse ja eelistatud käsitlusmeetodi konflikt peaks olema spetsifitseeritud osana XML-dokumente levitava kõrgema taseme protokollist. Sisemise märgise suhtelise prioriteedi reeglid ja MIME-tüüpi märgis välises päises, näiteks võiks olla RFC-dokumendi osa defineeritud text/xml ja  application/xml MIME-tüübina. Risttöödeldavuse huvides  on ometi soovitatud järgmised reeglid.

Need reeglid rakenduvad ainult protokolli taseme dokumentatsiooni puudumise korral; eriti kui on defineeritud  MIME  text/xml ja application/xml tüübid, relevantsed RFC-soovitused asendavad need reeglid.

G. W3C XML-töögrupp (mittenormatiivne)

Käesolev spetsifikatsioon on ette valmistanud ja heaks kiitnud avaldamiseks  W3C XML-töögrupp (Working Group (WG)). Käesoleva spetsifikatsiooni heakskiitmine WG poolt, ei tähenda tingimata, et kõik  WG-liikmed hääletasid selle heakskiidu poolt. Praegused ja endised  XML WG-liikmed on:
Jon Bosak, Sun (Chair); James Clark (Technical Lead); Tim Bray, Textuality and Netscape (XML Co-editor); Jean Paoli, Microsoft (XML Co-editor); C. M. Sperberg-McQueen, U. 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 and Grif; Makoto Murata, Fuji Xerox Information Systems; Joel Nava, Adobe; Conleth O'Connell, Vignette; Peter Sharpe, SoftQuad; John Tigue, DataChannel