Extensible Markup Language (XML) 1.0 (Third Edition)

Magyar fordítás

2006. november

Jelen verzió:
http://mgl.uw.hu/XML1_0_3rd/Extensible Markup Language (XML) 1_0 (Third Edition).htm
Fordító:
Máté Gábor, gabor.lajos.mate@gmail.com <gabor.lajos.mate@gmail.com>

Jelen dokumentum egy W3C-dokumentum fordítása. Mind az eredeti dokumentum, mind pedig a fordítás szerzői jogi védelem alatt áll. Az eredeti dokumentum szerzői jogára vonatkozóan lásd az angol nyelvű copyright megjegyzést. A fordítás nem minősül normatív dokumentumnak. A dokumentum egyetlen normatív verziója az angol nyelvű verzió.

A fordításban talált esetleges hibákat, illetve a fordítással kapcsolatos javaslatokat a fordító fent megadott elérhetőségén lehet jelezni.


W3C

Extensible Markup Language (XML) 1.0 (Harmadik kiadás)

W3C-ajánlás, 2004. február 4.

Jelen verzió:
http://www.w3.org/TR/2004/REC-xml-20040204
Legutolsó verzió:
http://www.w3.org/TR/REC-xml
Előző verzió:
http://www.w3.org/TR/2003/PER-xml-20031030
Szerkesztők:
Tim Bray, Textuality and Netscape mailto:tbray@textuality.com
Jean Paoli, Microsoft mailto:jeanpa@microsoft.com
C. M. Sperberg-McQueen, W3C mailto:cmsmcq@w3.org
Eve Maler, Sun Microsystems, Inc. mailto:elm@east.sun.com - Második kiadás
François Yergeau mailto:francois@yergeau.com - Harmadik kiadás

A dokumentum hibajegyzéke tartalmazhat bizonyos normatív javításokat is, ezért azt mindig vegyük figyelembe a dokumentum olvasásakor.

Ez a dokumentum elérhető nem normatív formátumokban is: XML-ben és színkódolt változáskövetéssel ellátott XHTML-ben.

Ezenkívül lásd még a további fordításokat.


Absztrakt

Jelen dokumentum teljes mértékben specifikálja az Extensible Markup Language-t (röviden: XML-t), ami az SGML részét képezi. Az XML-nek az a célja, hogy lehetővé tegye egy általános formájú SGML dokumentumnak a Weben való publikálását, az onnan való elérhetőségét vagy a Web segítségével történő feldolgozását, hasonlóan ahhoz, ahogy az a HMTL esetében is lehetséges. Az XML-t úgy tervezték meg, hogy könnyű legyen implementálni, és hogy mind az SGML-lel, mind pedig a HTML-lel együtt tudjon működni.

A dokumentum státusza

Jelen alfejezet a dokumentum státuszát a publikálásának az időpontjában rögzíti. Más dokumentumok később hatályon kívül helyezhetik ezt a dokumentumot. Az érvényben lévő W3C publikációk listája a http://www.w3.org/TR/ W3C technikai jelentések indexe oldalán található meg. Ugyanitt megtalálható ennek a dokumentumnak a legújabb verziója is.

Ez a dokumentum a W3C ajánlása. A W3C tagjai, valamint egyéb érdekelt felek is ellenőrizték, és a Director támogatta a W3C-ajánlásként való elfogadását. Ez egy stabil, már nem változó dokumentum, amit referenciaanyagként is lehet használni, vagy más dokumentumban normatív hivatkozásként is meg lehet adni. A W3C szerepe az ajánlás létrehozásában az, hogy felhívja a figyelmet a specifikációra és elősegítse a széleskörű elfogadottságát, ezáltal növelve a Web funkcionalitását és interoperabilitását.

Ez a dokumentum egy olyan szintaxist specifikál, ami egy már meglévo, széles körben használt nemzetközi szöveg-feldolgozási szabvány (a Standard Generalized Markup Language, ISO 8879:1986(E) módosított és javított változatának) egy leegyszerusítését hozza létre, azért, hogy azt a World Wide Web-en lehessen használni. Ezt a dokumentumot az XML Activity keretein belül működő XML Core Munkacsoport hozta létre. Jelen specifikáció angol nyelvu változata az egyetlen normatív változat, mindazonáltal ha a specifikáció valamely fordítása érdekelne bennünket, akkor látogassuk meg a http://www.w3.org/2003/03/Translations/byTechnology?technology=REC-xml oldalt.

Ez a harmadik kiadás nem jelenti az XML új verzióját, mindössze az időközben összegyűlt hibajegyzékben javasolt változtatások bedolgozását jelenti az XML 1.0 2000 október 6-i második kiadásába. (A hibajegyzék a http://www.w3.org/XML/xml-V10-2e-errata címen érhető el.) Ezenfelül kiemeltük a specifikáció előírásainak fontosabb részeit, világossá téve azokat az eseteket, amikor a KELL (MUST), AJÁNLOTT (SHOULD) előírásokat jelentő kulcsszavakat abban a formális értelemben használjuk, ahogy az az eredeti angol verzióban szereplő szavakra az [IETF RFC 2119]-ben definiálva van. Szintén a jobb olvashatóság érdekében készült egy XHTML verzió is, ami színes kiemelésekkel jelez minden olyan változtatást, ami a hibajegyzék valamely hibajelentése miatt került bele a dokumentumba, és egyúttal egy linket is ad, ami a listában a megfelelő hibajelentésre mutat. A legtöbb hibajelentés indoklást is tartalmaz arra vonatkozóan, miért történt a változtatás.

A http://www.w3.org/XML/2003/09/xml10-3e-implementation.html oldalon hozzáférhető továbbá egy jelentés az implementációkról.

A jelen ajánlással kapcsolatba hozható szellemi tulajdon dokumentációja a munkacsoport publikus IPR disclosure oldalán található.

A dokumentum esetleges hibáit lásd az xml-editor@w3.org oldalon. Az archívum szintén hozzáférhető. A harmadik kiadás hibajegyzéke a http://www.w3.org/XML/xml-V10-3e-errata oldalon elérhető.

Folyamatosan aktualizálva van egy tesztkészlet is, ami segítségünkre lehet abban, hogy ennek a specifikációnak megfeleljünk.

Tartalomjegyzék

1 Bevezetés
    1.1 Az XML eredete és célja
    1.2 Terminológia
2 Dokumentumok
    2.1 Jólformált XML dokumentumok
    2.2 Karakterek
    2.3 Általánosan használt szintaktikai szerkezetek
    2.4 A karakteres adat és a markup
    2.5 Megjegyzések
    2.6 Feldolgozó utasítások
    2.7 CDATA szakaszok
    2.8 Prológus és dokumentum-típusdeklaráció
    2.9 Standalone dokumentum deklarációja
    2.10 A white space-ek kezelése
    2.11 A sorvége jel kezelése
    2.12 A nyelv azonosítása
3 Logikai struktúrák
    3.1 Start-tagek, end-tagek és üreselem-tagek
    3.2 Elemtípus-deklarációk
        3.2.1 Elem-tartalom
        3.2.2 Mixed tartalom
    3.3 Attribútumlista-deklarációk
        3.3.1 Attribútumtípusok
        3.3.2 Attribútumok alapértelmezett értékei
        3.3.3 Attribútumérték-normalizálás
    3.4 Feltételes szakaszok
4 Fizikai struktúrák
    4.1 Karakterhivatkozások és entitáshivatkozások
    4.2 Entitásdeklarációk
        4.2.1 Belső entitások
        4.2.2 Külső entitások
    4.3 Elemzett entitások
        4.3.1 A szövegrész-deklaráció
        4.3.2 Jólformált elemzett entitások
        4.3.3 Karakterkódolás az entitásokban
    4.4 Az entitások és a hivatkozások kezelése az XML processzorokban
        4.4.1 Nincs felismerés
        4.4.2 Behelyettesítés
        4.4.3 Behelyettesítés érvényesítés esetén
        4.4.4 Nem megengedett
        4.4.5 Behelyettesítés literálban
        4.4.6 Értesítés
        4.4.7 Figyelmen kívül hagyás
        4.4.8 Behelyettesítés PE-ként
        4.4.9 Hiba
    4.5 Entitás behelyettesítendő szövegrészének a létrehozása
    4.6 Előredefinált entitások
    4.7 Jelölésmód-deklarációk
    4.8 Dokumentumentitás
5 Megfelelés a specifikációnak
    5.1 Érvényességet ellenőrző és érvényességet nem ellenőrző processzorok
    5.2 XML processzorok használata
6 Jelölés

Függelék

A Hivatkozások
    A.1 Normatív hivatkozások
    A.2 Egyéb hivatkozások
B Karakterosztályok
C XML and SGML (nem normatív)
D Entitáshivatkozások és karakterhivatkozások feloldása (nem normatív)
E Determinisztikus tartalommodellek (nem normatív)
F A karakterkódolás automatikus felismerése (nem normatív)
    F.1 Felismerés külső kódolási információ használata nélkül
    F.2 Külső kódolási információ használata esetén alkalmazandó prioritási sorrend
G W3C XML Munkacsoport (nem normatív)
H W3C XML Core Munkacsoport (nem normatív)
I Szerkesztői megjegyzés (nem normatív)


1 Bevezetés

Az Extensible Markup Language, röviden XML, az XML dokumentumoknak nevezett adatobjektumokat specifikálja, és részben tárgyalja azoknak a számítógépes programoknak a viselkedését is, amelyek ezeket az XML dokumentumokat dolgozzák fel. Az XML az SGML, a Standard Generalized Markup Language [ISO 8879] egy felhasználási területe vagy leszűkítése. Felépítésük szempontjából az XML dokumentumok az SGML-nek megfelelõ dokumentumok.

Az XML dokumentumok entitásoknak nevezett tárolóegységekbõl épülnek fel. Ezek az entitások vagy elemzett (parse-olt), vagy elemzés nélküli (parse-olás nélküli) adatokat tartalmaznak. Az elemzett adatok karakterekbõl állnak, amelyek egyik része karakteres adat, másik része pedig markup. A markup a dokumentum tárolóegységeinek az elhelyezkedését és a dokumentum logikai szerkezetét írja le. Az XML biztosít egy olyan mechanizmust, aminek a segítségével a tárolóegységek elhelyezkedésére vonatkozóan és a logikai szerkezet vonatkozásában megszorításokat tehetünk.

[Definíció: XML processzornak nevezzük azt a szoftvermodult, amit arra használunk, hogy az XML dokumentumokat olvassuk és a tartalmukhoz, valamint a szerkezetükhöz hozzáférést biztosítsunk.][Definíció: Feltételezzük, hogy az XML processzor egy másik modul igényei szerint mûködik, és ezt a másik modult alkalmazásnak nevezzük.] Ez a specifikáció az XML processzoroktól megkövetelt funkcionalitást írja le abban az értelemben, hogy hogyan kell beolvasni azokat az XML adatokat és információkat, amelyeket azután biztosítani kell az alkalmazás számára.

1.1 Az XML eredete és célja

Az XML-t a World Wide Web Konzorcium (W3C) berkein belül 1996-ban alakult XML Munkacsoport fejlesztette ki. (Ez a munkacsoport eredetileg az SGML Editorial Review Boardként volt ismert.) A munkacsoport elnöki tisztét Jon Bosak tölti be a Sun Microsystemstõl a szintén a W3C által szervezett XML Special Interest Group aktív részvételével (ami korábban SGML-Munkacsoportként volt ismert). Az XML Munkacsoport tagjait egy függelékben adjuk meg. A W3C felé a munkacsoport kapcsolattartója Dan Connolly.

Az XML tervezésénél a következők voltak a kitűzött célok:

  1. Az XML-nek magától értetõdõen kell használhatónak lennie az Interneten.

  2. Az XML-nek az alkalmazások széles körét kell támogatnia.

  3. Az XML-nek kompatibilisnek kell lennie az SGML-lel.

  4. Könnyű legyen az XML dokumentumokat feldolgozó programokat írni.

  5. Az XML-ben található opcionális tulajdonságok számát az abszolút minimumon kell tartani, ami ideális esetben azt jelenti, hogy ne legyen ilyen tulajdonság.

  6. Az ember által is olvashatónak és megfelelõ mértékben érthetõnek kellene lennie az XML dokumentumoknak.

  7. Rövid idő alatt elkészíthetőnek kellene lennie az XML-nek.

  8. Az XML tervezésének formálisnak és precíznek kell lennie.

  9. Az XML dokumentumoknak könnyen elkészíthetõknek kell lenniük.

  10. Az XML markupban a markup hosszúsága minimális jelentõsséggel bír.

Ez a specifikáció a hozzá kapcsolódó szabványokkal együtt (a Unicode [Unicode] és az ISO/IEC 10646 [ISO/IEC 10646] a karakterek, az Internet RFC 3066 [IETF RFC 3066] a nyelveket azonosító tagek, az ISO 639 [ISO 639] a nyelvek neveinek tartozó kódok és az ISO 3166 [ISO 3166] az országnevekhez tartozó kódok vonatkozásában) az összes szükséges információt biztosítja az XML Version 1.0 megértéséhez és ahhoz, hogy az XML-t feldolgozó számítógépes programokat hozzunk létre.

Az XML specifikáció jelen verziója szabadon terjeszthetõ a teljes szöveg és a szerzõi jogi megjegyzések változatlanul hagyása mellett.

1.2 Terminológia

Az XML dokumentumok leírására használt terminológiát a specifikáció részeként definiáljuk. Ha a KELL (az angol eredetiben: MUST, SHALL, REQUIRED), SZÜKSÉGES (az angol eredetiben: MUST, SHALL, REQUIRED), KÖTELEZŐ (az angol eredetiben: REQUIRED), AJÁNLOTT (az angol eredetiben: SHOULD, RECOMMENDED), LEHET (az angol eredetiben: MAY, OPTIONAL), LEHETŐSÉGE VAN (az angol eredetiben: MAY, OPTIONAL), NEM SZABAD (az angol eredetiben: MUST NOT, SHALL NOT), NINCS LEHETŐSÉGE (az angol eredetiben: MUST NOT, SHALL NOT), és OPCIONÁLIS (az angol eredetiben: MAY, OPTIONAL) kulcsszavak, kifejezések csupa nagybetűvel ki vannak emelve, illetve ha a feltételes mód -HAT, -HET ragja (az angol eredetiben: MAY, OPTIONAL) csupa nagybetűvel ki van elemve, akkor ezeket úgy kell értelmezni, ahogy azt az angol eredetire az [IETF RFC 2119] definiálja. Ezeken kívül a következõ listában definiált kifejezéseket fogjuk használni azokban a definíciókban és azoknak a tevékenységeknek a leírásában, amelyek az XML processzorokra vonatkoznak:

hiba (error)

[Definíció: A jelen specifikáció szabályainak a megsértése. Az hiba következménye definiálatlan. Ha másképp nincs specifikálva, akkor a specifikáció valamely előírásának nem megfelelő betartása hibának minősül, amennyiben ezt az előírást a KELL, SZÜKSÉGES, NEM SZABAD, NINCS LEHETŐSÉGE kulcsszavak, kifejezések valamelyikével határoztuk meg. A szabványnak megfelelõ szoftvereknek LEHETŐSÉGÜK VAN arra, hogy detektálják és jelezzék a hibát, továbbá a hiba lekezelése után LEHETŐSÉGÜK VAN továbbfutni.]

kritikus hiba (fatal error)

[Definíció: Olyan hiba, amit egy a szabványnak megfelelõ XML processzornak detektálnia KELL és jelentie KELL az alkalmazásnak. A kritikus hiba észlelése után LEHETŐSÉGE VAN a processzornak arra, hogy folytassa az adatok feldolgozását további hibák keresése céljából, és jelezze az ezután még talált hibákat az alkalmazásnak. A processzornak LEHETŐSÉGE VAN továbbá arra, hogy átadja az alkalmazásnak dokumentum további feldolgozatlan adatait azzal a céllal, hogy a hibák kijavítását támogassa. (A dokumentum itt a karakteres adat és markup keverékébõl épül fel.) Azonban kritikus hiba észlelése után a processzornak NEM SZABAD folytatni a normál feldolgozást (azaz NINCS LEHETŐSÉGE arra, hogy úgy adja át a karakteres adatot és a dokumentum logikai szerkezetét leíró információkat az alkalmazásnak, ahogy azt normál működés esetén tenné).]

felhasználói kérésre (at user option)

[Definíció: A szabványnak megfelelõ szoftvernek a leírtak szerint LEHET vagy KELL működni (a mondatban szereplõ igétõl függõen), és ha a leírtak szerint is működnek, akkor is lehetõséget KELL biztosítani a felhasználó számára az leírt funkcionalitás esetleges engedélyezésre vagy letiltására.]

érvényességi feltétel (validity constraint)

[Definíció: Olyan szabály, ami az összes érvényes XML dokumentumra vonatkozik. Az érvényességi feltétel megsértése hiba, amit az érvényesítõ XML processzornak felhasználói kérésre jelentenie is KELL.]

jólformáltsági feltétel (well-formedness constraint)

[Definíció: Olyan szabály, ami az összes jólformált XML dokumentumra vonatkozik. A jólformáltsági megkötés megsértése kritikus hiba.]

illeszkedés (match)

[Definíció: (Sztringek vagy nevek illeszkedése:) Két összehasonlított sztringnek vagy névnek azonosnak KELL lennie, hogy illeszkedjenek. Az olyan karakterek, amelyeknek az ISO/IEC 10646 szerint több lehetséges reprezentációjuk van (mint például az olyan karakterek, amelyeknek mind elõre összeállított (precomposed), mind pedig bázisból + diakritikus jelbõl álló formájuk van) csak akkor illeszkednek, ha mindkét sztringben ugyanaz a reprezentációjuk szerepel. Megkülönböztetést teszünk a kis és nagybetûk között. (Sztringek és nyelvtani szabályok illeszkedése:) Egy sztring akkor illeszkedik egy nyelvtani szabályhoz, ha az adott szabály által generált nyelvhez tartozik. (Tartalom és tartalommodellek illeszkedése:) Egy elem akkor illeszkedik a saját deklarációjához, ha megfelel a szabványnak az [VC: Elemérvényesség] feltételben leírtak szerint.]

a kompatibilitás érdekében (for compatibility)

[Definíció: Az XML olyan tulajdonságát leíró mondatot jelölõ megjegyzés, amely tulajdonság kizárólag annak biztosítását szolgálja, hogy az XML kompatibilis maradjon az SGML-lel.]

az interoperabilitás érdekében (for interoperability)

[Definíció: Azokat a nem kötelezõ érvényű ajánlásokat leíró mondatokat jelölõ megjegyzés, amelyek azért kerültek bele a specifikációba, hogy növeljék annak az esélyét, hogy az XML dokumentumokat azok a már létezõ és telepített SGML processzorok is fel tudják dolgozni, amelyek az ISO 8879-hez tartozó WebSGML Adaptation Annex megjelenése elõtt készültek.]

2 Dokumentumok

[Definíció: Egy adatobjektumot XML dokumentumnak nevezünk, ha jólformált ezen specifikáció definíciójának az értelmében. Egy jólformált XML dokumentum egyben érvényes is LEHET, ha kielégít bizonyos további megkötéseket.]

Minden XML dokumentumnak van mind logikai, mind fizikai szerkezete. Fizikailag a dokumentum entitásoknak nevezett egységekből áll. Egy entitás hivatkozHAT más entitásokra, hogy ezáltal a dokumentum részévé tegye a hivatkozott entitásokat is. A dokumentum a gyökérben vagy másnéven a dokumentumentitásban kezdõdik. Logikailag a dokumentum deklarációkból, elemekbõl, megjegyzésekbõl, karakterhivatkozásokból és feldolgozó utasításokból áll, amelyek mindegyikét egy explicit markup jelöli a dokumentumban. A logikai és a fizikai struktúrának helyesen KELL egymásba ágyazva lenni abban az értelemben, ahogy azt a 4.3.2 Jólformált elemzett entitások című részben tárgyaljuk.

2.1 Jólformált XML dokumentumok

[Definíció: Egy szöveges objektumot jólformált XML dokumentumnak nevezünk, ha:]

  1. Teljes egészében illeszkedik a Dokumentum címkéjű szabályra.

  2. Kielégíti a jelen specifikáció összes jólformáltsági feltételét.

  3. Minden egyes elemzett entitás, amire közvetlenül vagy közvetetten hivatkozunk a dokumentumból, jólformált.

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

A document szabályra történő illeszkedés magában foglalja a következőket:

  1. Egy vagy több elemet tartalmaz.

  2. [Definíció: Létezik pontosan egy gyökérnek vagy dokumentumelemnek nevezett elem, aminek egyetlen részét sem tartalmazza egyetlen másik elem sem.] Minden más elem esetén, ha a start-taget egy másik elem tartalmazza, akkor az end-taget is ugyanaz az elem tartalmazza. Egyszerűbben kifejezve, a start- és end-tagek által határolt elemeknek helyesen kell egymásba ágyazva lenni.

[Definíció: Ennek következményeként a dokumentumban a gyökértõl különböző tetszõleges C elemhez létezik egy ettõl különböző P elem, amire teljesül, hogy P tartalmazza a C-t, de nem tartalmaz egyetlen olyan másik elemet sem, ami tartalmazná a C elemet. P-re a C szülőjeként, C-re pedig a P gyermekeként hivatkozunk a továbbiakban.]

2.2 Karakterek

[Definíció: Az elemzett entitások szöveget, karakterek sorozatát tartalmazzák, ami reprezentálhat markupokat és karakteres adatot.] [Definíció: Karakternek a szövegnek az ISO/IEC 10646:2000 [ISO/IEC 10646] által specifikált atomi egységét nevezzük. Megengedett karakterek a tabulátor, a sorvége (carriage return), a sorelemelés (linefeed), valamint a Unicode és az ISO/IEC 10646 által megengedett karakterek. Ezeknek a szabványoknak az A.1 Normatív referenciák részben felsorolt verziói voltak akkor hatályosak, amikor ez a dokumentum készült. Azóta átdolgozások vagy új kiadások révén ezek a szabványok új karakterekkel egészülhettek ki. Következésképpen az XML processzoroknak el KELL fogadniuk minden karaktert, ami a Char számára megadott tartományba esik. ]

Karaktertartomány
[2]    Char    ::=    #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF] /* tetszőleges Unicode karakter, kivéve a helyettesítõ (surrogate) blokkokat, az FFFE-t és az FFFF-t. */

Az a mechanizmus, amivel a karakterkódokat bitmintákra kódoljuk, entitásonként különbözõ LEHET. Minden XML processzornak el KELL fogadnia a Unicode 3.1 [Unicode3] UTF-8 és UTF-16 kódolásait. Késõbb tárgyaljuk a 4.3.3 Karakterkódolás az entitásokban részben azt a mechanizmust, ami jelzi, hogy az UTF-8 és UTF-16 közül melyik van használatban, és ami ezektõl eltérõ kódolások használatát is lehetővé teszi.

Megjegyzés:

A dokumentumok íróinak tanácsosabb kerülni az úgynevezett "kompatibilitási karakterek" használatát. Ezeket a [Unicode] 6.8. alfejezete definiálja. (Lásd még a [Unicode3] 3.6. alfejezetét.) Az alábbi tartományokba eső karakterek használatát szintén tanácsos elkerülni, mivel ezek vagy kontrollkarakterek, vagy pedig definiálatlan Unicode karakterek:

[#x7F-#x84], [#x86-#x9F], [#xFDD0-#xFDDF],
[#1FFFE-#x1FFFF], [#2FFFE-#x2FFFF], [#3FFFE-#x3FFFF],
[#4FFFE-#x4FFFF], [#5FFFE-#x5FFFF], [#6FFFE-#x6FFFF],
[#7FFFE-#x7FFFF], [#8FFFE-#x8FFFF], [#9FFFE-#x9FFFF],
[#AFFFE-#xAFFFF], [#BFFFE-#xBFFFF], [#CFFFE-#xCFFFF],
[#DFFFE-#xDFFFF], [#EFFFE-#xEFFFF], [#FFFFE-#xFFFFF],
[#10FFFE-#x10FFFF].

2.3 Általánosan használt szintaktikai szerkezetek

Ez a szakasz néhány, a leíró nyelvtanunk által gyakran használt szimbólumot definiál.

Az S (white space) egy vagy több szóköz (#x20), sorvége (carriage return), soremelés (line feed) és/vagy tabulátor karakterbõl áll.

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

Megjegyzés:

Az #xD csak azért van jelen a fenti generálószabályban, hogy visszafelé kompatibilisek maradjunk az Első kiadással. Mint ahogy azt a 2.11 A sorvége kezelése részben részeltesen tárgyaljuk is, ha egy ilyen #xD karakter literálisan jelen van az XML dokumentumban, akkor az vagy kitörlődik, vagy pedig #xA karakterrel helyettesítődik, még mielőtt bármilyen más feldolgozási művelet lefutna. Az egyetlen eset, amikor egy #xD karakter illeszkedhet erre a szabályra, az az, amikor egy karakterhivatkozást egy entitás értékét megadó literálon belül használunk.

A karaktereket az egyszerűbb kezelhetõség kedvéért a következõképpen osztályozzuk: betűk, számjegyek és egyéb karakterek. A betűk alfabetikus karakterek, szótagos karakterek vagy ideogrammatikus karakterek lehetnek. Az egyes osztályokban található karakterek teljes definíciója a B Karakterosztályok részben található.

[Definíció: Névnek nevezünk egy tokent, ha betűvel vagy bizonyos megengedett írásjelek valamelyikével kezdõdik, és betűvel, számjeggyel, kötõjellel, aláhúzás karakterrel, kettõsponttal vagy ponttal folytatódik. Az utóbbiakat összefoglaló néven névkaraktereknek hívjuk.] Az "xml" sztringgel kezdõdõ nevek, vagy azok, amelyek olyan sztringgel kezdõdnek, amire az (('X'|'x') ('M'|'m') ('L'|'l')) illeszkedne, fenn vannak tartva arra, hogy ezen specifikáció jelenlegi vagy későbbi verzióiban a szabvány céljaira felhasználhassuk őket.

Megjegyzés:

A Namespaces in XML ajánlás [XML Names] a kettõspont karaktert tartalmazó nevekhez külön jelentést rendel hozzá. Ezért nem tanácsos a kettõspontot az XML nevekben felhasználni, kivéve azt az esetet, ha a névterekhez használjuk őket. Azonban az XML processzoroknak el kell fogadniuk a kettõspontot névkarakterként.

Az Nmtoken (name token - névtoken) névkarakterek tetszõleges kombinációja.

Nevek és tokenek
[4]    NameChar    ::=    Letter | Digit | '.' | '-' | '_' | ':' | CombiningChar | Extender
[5]    Name    ::=    (Letter | '_' | ':') (NameChar)*
[6]    Names    ::=    Name (#x20 Name)*
[7]    Nmtoken    ::=    (NameChar)+
[8]    Nmtokens    ::=    Nmtoken (#x20 Nmtoken)*

Megjegyzés:

A Names és Nmtokens generálószabályokat arra használjuk, hogy definiáljuk, mikor érvényes egy tokenizált attribútumérték, ha már normalizálva van. (Lásd meg az 3.3.1 Attribútumtípusok részt.)

Literális adat bármely idézõjelek közötti sztring, amely nem tartalmazza a sztringet határoló idézõjelet. Literálokat használunk akkor, amikor a belsõ entitások (EntityValue) tartalmát, az attribútumok értékét (AttValue), illetve a külsõ azonosítókat (SystemLiteral) adjuk meg. Vegyük észre, hogy a SystemLiteral-ok a markupok megkeresése nélkül is elemezhetõek, azaz parse-olhatóak.

Literálok
[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] | [-'()+,./:=?;!*#@$_%]

Megjegyzés:

Jóllehet az EntityValue szabály megengedi egy olyan általános entitás definícióját, ami a literálban lévõ egyetlen explicit < karakterbõl áll (pl.: <!ENTITY mylt "<">), igencsak ajánlott ezt a gyakorlatban elkerülni, mivel ha erre az entitásra hivatkozni fogunk, az egy jólformáltsági hibához fog vezetni.

2.4 A karakteres adat és a markup

A szöveg karakteres adat és markup keverékébõl áll. [Definíció: Markupnak nevezzük a start-tageket, az end-tageket, az üreselem-tageket, az entitáshivatkozásokat, a karakterhivatkozásokat, a megjegyzéseket, a CDATA szakaszok elejét és végét jelző karaktersorozatokat, a dokumentum-típusdeklarációkat, a feldolgozó utasításokat, az XML deklarációkat, a szövegdeklarációkat és minden olyan white space-t, ami a dokumentumentitás legfelső szintjén van (azaz minden olyan white space-t, ami a dokumentumelemen kívül van, és amit egyúttal egyetlen más markup sem tartalmaz).]

[Definíció: A markup-okon kívül szöveges részek alkotják a dokumentum karakteres adatát.]

Az és karakternek (&) és a csúcsos balzárójelnek (<) NEM SZABAD literális formában megjelenni, kivéve, ha egy markup határolójeleként kerülnek felhasználásra, vagy ha egy megjegyzésen, feldolgozó utasításon vagy CDATA szakaszon belül vannak. Ha bárhol máshol van szükség rájuk, akkor vagy a numerikus karakterhivatkozások használatával, vagy pedig a "&amp;", illetve "&lt;" sztringekkel KELL helyettesíteni őket. A csúcsos jobbzárójelet (>) reprezentálHATjuk a "&gt;" sztringgel is és a kompatibilitás érdekében helyettesíteni is KELL vagy a "&gt;" sztringgel vagy pedig egy karakterhivatkozással, ha ez a karaktersorozat nem egy CDATA szakasz végét jelöli a szövegben.

Az elemek tartalmi részében karakteres adat minden olyan karaktersorozat, ami nem tartalmazza egyetlen markup kezdõ határolójelét sem, és nem tartalmazza egyetlen CDATA szakasz "]]>" lezáró karaktersorozatát sem. CDATA szakaszban karakteres adat minden karaktersorozat, ami nem tartalmazza a CDATA szakasz "]]>" lezáró karaktersorozatát.

Azért, hogy az attribútumértékek is tartalmazhassanak mind egyszeres, mind pedig dupla idézõjelet, LEHETŐSÉG VAN arra, hogy az aposztrófot vagy másnéven egyszeres idézõjelet (') a "&apos;" sztringgel adjuk meg, és a dupla idézõjelet (") a "&quot;" sztringgel adjuk meg.

Karakteres adat
[14]    CharData    ::=    [^<&]* - ([^<&]* ']]>' [^<&]*)

2.5 Megjegyzések

[Definíció: Megjegyzés bárhol LEHET a dokumentumban, ahol nem tartalmazza egyetlen markup sem. LEHET továbbá megjegyzés a dokumentum-típusdeklaráción belül a nyelvtan által megengedett helyeken. A megjegyzések nem részei a dokumentum karakteres adatának. Az XML processzorok kiolvasHATják az alkalmazások számára a megjegyzések szövegét, de ezt lehetőséget nem kötelezõ támogatniuk. A kompatibilitás érdekében a "--" (két kötõjel) sztringnek NEM SZABAD megjegyzésen belül szereplnie.] A megjegyzéseken belül az XML processzornak NEM SZABAD felismerni a paraméterentitás-hivatkozásokat.

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

Példa a megjegyzésre:

<!-- declarations for <head> & <body> -->

Vegyük észre, hogy a nyelvtan nem engedi meg a ---> végzõdésû megjegyzéseket. A következõ példa nem jólformált.

<!-- B+, B, or B--->

2.6 Feldolgozó utasítások

[Definíció: A feldolgozó utasítások, röviden PI-k (az angol eredetiben: Processing Instruction) lehetõvé teszik, hogy a dokumentumok az alkalmazásoknak szóló utasításokat tartalmazzanak.]

Feldolgozó utasítások
[16]    PI    ::=    '<?' PITarget (S (Char* - (Char* '?>' Char*)))? '?>'
[17]    PITarget    ::=    Name - (('X' | 'x') ('M' | 'm') ('L' | 'l'))

A PI nem része a dokumentum karakteres adatának, de át KELL adni az alkalmazásnak. A PI a cél (PITarget) megadásával kezdõdik, ami azt az alkalmazást azonosítja, aminek az utasítás szól. Az "XML", "xml", stb. nevek fenn vannak tartva arra, hogy ezen specifikáció jelenlegi vagy késõbbi verzióiban a szabvány céljaira felhasználhassuk őket. Az XML Jelölés (Notation) mechanizmusát LEHET használni a PI célok formális deklarációjához. A feldolgozó utasításokon belül az XML processzornak NEM SZABAD felismerni a paraméterentitás-hivatkozásokat.

2.7 CDATA szakaszok

[Definíció: CDATA szakasz bárhol LEHET, ahol karakteres adat lehet. Arra használjuk õket, hogy azokat a szövegblokkokat helyettesítsük velük, amelyek olyan karakereket is tartalmaznak, amelyeket egyébként markupként ismerne fel az XML processzor. A CDATA szakaszok a "<![CDATA[" sztringgel kezdõdnek és a "]]>" sztringgel végzõdnek:]

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

CDATA szakaszon belül csak a CDEnd sztringet ismerjük fel markupként, így tehát a csúcsos balzárójel és az és jel is elõfordulhat literális formájában. Nem kell (és nem is lehet) helyettesíteni õket az "&lt;" és az "&amp;" használatával. CDATA szakaszokat nem lehet egymásba ágyazni.

Az alábbi példa olyan CDATA szakaszt mutat be, amelyben a "<greeting>"-et és a "</greeting>"-et az XML processzor karakteres adatként ismeri fel és nem markupként:

<![CDATA[<greeting>Hello, world!</greeting>]]> 

2.8 Prológus és dokumentumtípus-deklaráció

[Definíció: Az XML dokumentumokat egy XML deklarációval AJÁNLOTT kezdeni, ami meghatározza a használt XML verzióját.] A következõ példa egy teljes XML dokumentum, ami jólformált, de nem érvényes:

<?xml version="1.0"?>
<greeting>Hello, world!</greeting> 

de ez a példa is helyes:

<greeting>Hello, world!</greeting>

A markup funkciója az XML dokumentumban az, hogy leírja a dokumentum tárolási struktúráját és logikai szerkezetét, és hogy az attribútumnév-attribútumérték párokat hozzárendelje a dokumentum logikai szerkezeteihez. Az XML biztosít egy mechanizmust, az úgynevezett dokumentumtípus-deklarációt, ami arra szolgál, hogy a logikai szerkezetre vonatkozóan megszorításokatt tehessünk, és ami támogatja az elõredefiniált tárolási egységek használatát. [Definíció: Azt mondjuk, hogy az XML dokumentum érvényes, ha hozzá van rendelve egy dokumentumtípus-deklaráció, és ha a dokumentum megfelel az abban megfogalmazott megszorításoknak.]

A dokumentumtípus-deklarációnak a dokumentumban még az elsõ elem elõtt KELL lennie.

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

[Definíció: Az XML dokumentumtípus-deklarációja olyan markupdeklarációkat tartalmaz, illetve olyan markupdeklarációkra hivatkozik, amelyek összességében egy dokumentumosztály nyelvtanát határozzák meg. Ezt a nyelvtant dokumentumtípus-definíciónak vagy DTD-nek (Document Type Definition) nevezzük. A dokumentumtípus-deklaráció hivatkozhat egy markupdeklarációkat tartalmazó külsõ részhalmazra (ami a külsõ entitás egy speciális fajtája), vagy közvetlenül egy belsõ részhalmazban is tartalmazhatja a markupdeklarációkat, illete ezzel a két lehetõséggel egyszerre is élhet. A dokumentum DTD-je ezen részhalmazok egyesítésébõl áll.]

[Definíció: Markupdeklarációnak nevezzük az elemtípus-deklarációkat, az attribútumlista-deklarációkat, az entitás-deklarációkat és a jelölésmód-deklarációkat.] Ezeket a deklarációkat részben vagy egészben tartalmazHATja paraméterentitás is abban a formában, ahogy azt a jólformáltsági és érvényességi megkötések alább leírják. További információkért lásd a 4. Fizikai struktúrák részt.

Dokumentumtípus-definíció
[28]    doctypedecl    ::=    '<!DOCTYPE' S Name (S ExternalID)? S? ('[' intSubset ']' S?)? '>' [VC: A root elemtípusa]
[WFC: Külsõ részhalmaz]
[28a]    DeclSep    ::=    PEReference | S [WFC: PE deklarációk között]
[28b]    intSubset    ::=    (markupdecl | DeclSep)*
[29]    markupdecl    ::=    elementdecl | AttlistDecl | EntityDecl | NotationDecl | PI | Comment [VC: Helyes deklaráció/PE egymásbaágyazás]
[WFC: PE-k a belsõ részhalmazban]

Vegyük észre, hogy lehet olyan jólformált dokumentumot konstruálni, ami tartalmaz doctypedecl deklarációt, de nem hivatkozik külsõ részhalmazra és nem tartalmaz belsõ részhalmazt sem.

A markupdeklarációk részben vagy egészben felépülHETnek a paraméterentitások behelyettesítendõ szövegrészébõl is. A specifikációban késõbb következõ nyelvtani szabályok az egyes nemterminálisokra (elementdecl, AttlistDecl, stb.) a deklarációkat azután írják le, hogy a paraméterentitásokat behelyettesítettük.

A paraméterentitás-hivatkozásokat az XML processzor bárhol felismeri a DTD-ben (a belsõ és a külsõ részhalmazban és a külsõ paraméterentitásokban egyaránt), kivételt képeznek ezalól a literálokban, feldolgozó utasításokban, megjegyzésekben és a figyelmen kívül hagyott feltételes szakaszokon belül előforduló parametétentitás-hivatkozások (lásd 3.4 Feltételes szakaszok). Az entitásértékeket megadó literálokban is felismerjük őket. A belsõ részhalmazban a paraméterentitások használata az alábbiakban leírtaknak megfelelõen van korlátozva.

Érvényességi feltétel: Helyes deklaráció/PE egymásbaágyazás

A paraméterentitás behelyettesítendõ szövegrészének a markupdeklarációkkal helyesen KELL egymásba ágyazva lenni. Ez azt jelenti, hogy ha a markupdeklaráció (lásd markupdecl fent) elsõ vagy utolsó karakterét tartalmazza a paraméterentitás-hivatkozás helyére behelyettesítendõ szövegrész, akkor mind a kettõt tartalmaznia KELL ugyanannak a szövegrésznek.

Jólformáltsági feltétel: PE-k a belsõ részhalmazban

A belsõ DTD részhalmazban paraméterentitás-hivatkozások NEM fordulHATnak elő markupdeklarációkon belül, hanem csak ott fordulHATnak elõ, ahol markupdeklarációk is lehetnek. (Ez a feltétel nem vonatkozik azokra a hivatkozásokra, amelyek külsõ paraméterentitásokban vannak, és nem vonatkozik a külsõ részhalmazra.)

Jólformáltsági feltétel: PE deklarációk között

A DeclSep szabályban lévõ paraméterentitás-hivatkozás helyére behelyettesítendõ szövegrésznek illeszkedie KELL az extSubsetDecl szabályra.

A belsõ részhalmazhoz hasonlóan a külsõ részhalmaznak és a DeclSep szabályban hivatkozott külsõ paraméterentitásoknak olyan típusú teljes markupdeklarációk sorozatából KELL állnia, amely típusokat a markupdecl nemterminális szimbólum megenged. Ezek között a markupdeklarációk között white space-ek és paraméterentitás-hivatkozások is elõfordulhatnak. Azonban a külsõ részhalmaz vagy az ilyen külsõ paraméterentitások tartalmának egy részét feltételesen figyelmen kívül is LEHET hagyni a feltételes szakaszok konstrukcióját használva. Ugyanez nem megengedett a belsõ részhalmazban, de megengedett a belső részhalmazból hivatkozott külső paraméterentitásokban.

Külső részhalmaz
[30]    extSubset    ::=    TextDecl? extSubsetDecl
[31]    extSubsetDecl    ::=    ( markupdecl | conditionalSect | DeclSep)*

A külsõ részhalmaz és a külsõ paraméterentitások abban is különböznek a belsõ részhalmaztól, hogy ezekben a paraméterentitás-hivatkozások a markupdeklarációkon belül is megengedettek, nem csak a markupdeklarációk között.

Példa dokumentumtípus-deklarációval rendelkezõ XML dokumentumra:

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

A "hello.dtd" rendszerazonosító a dokumentum számára megadott DTD címét (URI hivatkozását) adja meg.

A deklarációk megadhatók lokálisan is, mint ebben a példában is:

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

Ha mind a külsõ, mind pedig a belsõ részhalmazt használjuk, akkor úgy KELL tekintenünk, hogy a belsõ részhalmaz korábban fordul elõ a dokumentumban, mint a külsõ. Ennek az a hatása, hogy az entitás- és attribútumlista-deklarációk a belsõ részhalmazban elsőbbséget élveznek a külsõ részhalmazban elõfordulókkal szemben.

2.9 Standalone dokumentum deklarációja

A markupdeklarációk kihatással lehetnek a dokumentum tartalmára, amikor az XML processzor az alkalmazásnak átadja õket. Jó példa erre az attribútumok alapértelmezett értéke vagy az entitásdeklarációk. A standalone dokumentum deklarációja, amit az XML deklaráció komponenseként LEHET megadni, azt jelzi, hogy vannak-e ilyen deklarációk a dokumentumentitáson kívül vagy a paraméterentitásokban. [Definíció: Külsõ markupdeklarációnak nevezzük a külsõ részhalmazban és a (külsõ vagy belsõ) paraméterentitásokban elõforduló markupdeklarációkat. (A belsõ paraméterentitásokban előforduló markupdeklarációkat azért tekintjük külső markupdeklarációknak, mert a nem érvényesítõ XML processzoroknak nem kell beolvasni õket.)]

Standalone dokumentum deklarációja
[32]    SDDecl    ::=    S 'standalone' Eq (("'" ('yes' | 'no') "'") | ('"' ('yes' | 'no') '"')) [VC: Standalone dokumentum deklarációja]

A standalone dokumentum deklarációjában a "yes" érték jelzi azt, hogy nincsenek olyan külső markupdeklarációk a dokumentumban, amelyek befolyásolnák az XML processzor által az alkalmazásnak átadott információt. A "no" érték jelzi azt, hogy vannak, illetve lehetnek ilyen külső markupdeklarációk a dokumentumban. Vegyük észre, hogy a standalone dokument deklarációja csak a külső deklarációk előfordulását jelzi. Azt, hogy a dokumentumban vannak-e külső entitásokra történő hivatkozások, nem befolyásolja a dokumentum standalone státuszát, ha ezeket az entitásokat a dokumentumon belül deklaráltuk.

Ha nincsenek külső markupdeklarációk a dokumentumban, akkor a standalone dokument deklarációjának nincs értelme. Ha vannak külső markupdeklarációk a dokumentumban, de nincs benne deklarálva, hogy standalone dokumentumról van-e szó, akkor a "no" értéket feltételezzük.

Minden olyan dokumentumot, amire a standalone="no" teljesül, lehetséges standalone dokumentummá konvertálni algoritmus segítségével. Ez ajánlott is bizonyos hálózati alkalmazások esetében.

Érvényességi feltétel: Standalone dokumentum deklarációja

A standalone dokumentum deklalációjában a "no" értéknek KELL szerepni, ha van olyan külső markupdeklaráció a dokumentumban, ami tartalmazza az alábbi deklarációk valamelyikét:

  • alapértelmezett értékekkel rendelkező attribútumok, ha azok az elemek, amelyekre ezek az attribútumok vonatkoznak, úgy szerepelhetnek a dokumentumban, hogy ezekhez attribútumokhoz nincs érték meghatározva, vagy

  • entitások (eltekintve a amp, lt, gt, apos, quot entitásoktól), ha ezekre az entitásokra történő hivatkozások előfordulnak a dokumentumban, vagy

  • tokenizált típusú attribútumok olyan esetekben, amikor az attribútum olyan értéket vesz fel a dokumentumban, ami a normalizálás során olyan értéket kap, ami különbözik attól az értéktől, amit akkor kapna, ha ez a deklaráció nem szerepelne a dokumentumban, vagy

  • tartalmi résszel rendelkező elemtípusok, ha az ilyen típusú példányok valamelyikében white space közvetlenül előfordul

Példa standalone dokumentum deklarációját tartalmazó XML deklarációra:

<?xml version="1.0" standalone='yes'?>

2.10 A white space-ek kezelése

Az XML dokumentumok szerkeszése közben sokszor célszerű a jobb olvashatóság kedvéért "white space"-eket (szóközöket, tabulátorokat és üres sorokat) használni a markupok elkülönítésére. Az ilyen white space-eket általában nem akarjuk a dokumentum kiszállított verziójában is megtartani. Másrészrõl a a "jelentõsséggel bíró" white space-ek is általánosak, például versekben vagy forráskódokban, ezeket pedig meg kellene õrizni a kiszállított verzióban is.

Az XML processzornak mindig át KELL adnia az alkalmazásnak a dokumentumban található összes olyan karaktert, ami nem képezi egy markup részét. Az érvényesítõ XML processzoroknak ezen felül az alkalmazást tájékoztatniuk KELL arról, hogy ezen karakterek közül melyek azok, amik egy elem tartalmi részében található white space-re illeszkednek.

Az xml:space nevű speciális attribútumot LEHET arra használni, hogy hozzárendelve egy elemhez jelezzük azt a szándékot, hogy abban az elemben a white space-eket meg kellene õrizniük az alkalmazásoknak. Érvényes dokumentumok esetén a többi attribútumhoz hasonlóan ezt az attribútumot is deklarálnunk KELL, ha használni akarjuk. Amikor deklaráljuk, akkor egy olyan felsorolás típusként KELL megadnunk, ami a "default" vagy "preserve" értékeket veheti fel. Például:

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

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

A "default" érték azt jelzi, hogy az alkalmazás által biztosított alapértelmezett white space feldolgozási mód megfelelő ezen elem számára. A "preserve" azt a szándékot jelzi, hogy az alkalmazásoknak meg kell őrizniük az összes white space-t. Ez a deklaráció az összes olyan elemre vonatkozik, ami azon az elemen belül található, amire a deklarációt tettük, kivéve ha ezt az xml:space attribútum egy másik példányával felüldefiniáljuk. Jelen specifikáció nem határoz meg semmilyen jelentést azokra az esetekre, amikor az xml:space a "default"-tól és "preserve"-től eltérő értéket kap. Ha más értéket adunk meg, akkor azt hibának tekintjük. Az XML processzornak jelentHETik a hibát vagy az attribútumspecifikációt figyelmen kívül hagyva vagy a (hibás) értéket az alkalmazásnak lejelentve kezelHETik a hibát. Az alkalmazások figyelmen kívül hagyhatják vagy visszautasíthatják a hibás értékeket.

Úgy tekintjük, hogy a dokumentumok root eleme nem jelzi, hogy az alkalmazásoknak hogyan kellene kezelni a white space-eket, eltekitve azoktól az esetektől, amikor a root elem meghatározza az értékét ennek az attribútumnak vagy amikor az attribútumot alapértelmezett értékkel együtt deklaráltuk.

2.11 A sorvége jel kezelése

Az XML elemzett entitásai gyakran olyan fájlokban kerülnek letárolásra, amelyek a könnyebb szerkeszthetőség kedvéért sorokra vannak tördelve. Ezeket a sorokat leggyakrabban a sorvége/CARRIAGE RETURN (#xD) és soremelés/LINE FEED (#xA) karakterek valamilyen kombinációja választja el egymástól.

Azért, hogy az alkalmazások feladatát egyszerűbbé tegyük, az XML processzor által az alkalmazásnak átadott karaktereknek olyanoknak KELL lenniük, mintha az elemzés előtt az XML processzor normalizálta volna a bemeneten az összes sortörést a külső elemzett entitásokban (ideértve a dokumentumentitást is), mégpedig úgy, hogy a kétkarakteres #xD #xA sorozatokat és azokat az önmagukban álló #xD karaktereket, amelyek után nem áll #xA, egyaránt egyetlen #xA karakterre változtatta volna.

2.12 A nyelv azonosítása

A dokumentumfeldolgozásban gyakran hasznos, ha azonosítjuk azt a természetes vagy formális nyelvet, amelyen a dokumentum tartalma íródott. Az xml:lang nevű speciális attribútumot LEHET a dokumentumokba beilleszteni, ha meg akarjuk határozni, hogy az XML dokumentum valamely eleme milyen nyelven íródott részt tartalmaz, illetve, hogy ezen elemhez rendelt attribútumok értéke milyen nyelven íródott. Érvényes dokumentumokban, mint minden más attribútumot, ezt az attribútumot is deklarálnunk KELL, ha használni akarjuk. Az attribútum értékei az [IETF RFC 3066], Tags for the Identification of Languages, illetve ezen dokumentum újabb verziói által definiált nyelvazonosítók, illetve ezeken kívül még az üres sztring is megadHATó.

(A 33-tól 38-ig terjedő nyelvtani szabályokat törölték a specifikációból.)

Például:

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

Az xml:lang által deklarált nyelv az összes olyan elemre és attribútumra vonatkozik, ami azon az elemen belül található, amire a deklarációt tettük, kivéve ha ezt az xml:lang attribútum egy másik példányával felüldefiniáljuk egy olyan elemen, ami az adott elemen belül található. Speciális esetben egy B elemen az xml:lang üres értékét használjuk arra, hogy úgy definiáljunk felül egy a B elemet tartalmazó A elemen tett xml:lang specifikációt, hogy közben ne adjunk meg másik nyelvet. Ekkor a B elemen belül úgy tekintjük, mintha nem lenne a használt nyelvre vonatkozó információ megadva, pontosan úgy, mintha nem lenne xml:lang megadva sem a B elem, sem pedig a B elem ősein.

Megjegyzés:

A használt nyelvre vonatkozó információt a használt átviteli protokoll (pl.: a HTTP vagy a MIME) is megadhat. Ilyen esetekben az XML alkalmazások használhatják ezt az információt is, de úgy kell tekinteni, hogy az xml:lang által megadott lokálisabb információ ezt felüldefiniálja.

Az xml:lang legegyszerűbb deklarációja az alábbi

xml:lang CDATA #IMPLIED

formában adható meg, de megadHATóak specifikus alapértelmezett értékek is, ha szükség van rájuk. Egy angol diákok számára készült verseskötet esetében, ami francia verseket (poem attribútum) tartalmaz angolul írt glosszákkal (gloss attribútum) és megjegyzésekkel (note attribútum), az xml:lang attribútum például a következőképpen deklarálható:

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

3 Logikai struktúrák

[Definíció: Minden XML dokumentum egy vagy több elemet tartalmaz. Ezek mindegyikét vagy start-tagek és end-tagek határolják, vagy pedig, amennyiben üres elemről van szó, egy üreselem-tag határolja. Minden elemnek névvel azonosított típusa van, amit időnként "generikus azonosító"-nak is (GI - generic identifier) hívunk, és minden elem tartalmazHAT egy vagy több attribútumspecifikációt is.] Minden attribútumspecifikációnak van neve és értéke.

Elem
[39]    element    ::=    EmptyElemTag
| STag content ETag [WFC: Az elemtípus illeszkedése]
[VC: Az elem érvényessége]

Jelen specifikáció nem tesz megszorításokat a szemantikára vonatkozóan, a használatra vonatkozóan vagy (a szintaxison túlmenően) az elemtípusok és attribútumok nevére vonatkozólag, eltekintve attól, hogy az (('X'|'x')('M'|'m')('L'|'l')) kezdetű nevek fenn vannak tartva arra, hogy ezen specifikáció jelenlegi vagy későbbi verzióiban a szabvány céljaira felhasználhassuk őket.

Jólformáltsági feltétel: Az elemtípus illeszkedése

Az elem end-tagjében levő Name névnek illeszkednie KELL az elem start-tagjében szereplő elemtípusra.

Érvényességi feltétel: Az elem érvényessége

Egy elem akkor érvényes, ha van olyan deklaráció, ami illeszkedik az elementdecl szabályra, és ahol a Name név illeszkedik az elemtípusra, továbbá a következők egyike teljesül:

  1. A deklaráció illeszkedik az EMPTY sztringre és az elemnek nincs tartalmi része (beleértve azt is, hogy nem tartalmaz entitáshivatkozásokat, megjegyzéseket, PI-ket vagy white space-eket sem).

  2. A deklaráció illeszkedik a children szabályra és a leszármazott elemek sorozata a tartalommodellben lévő reguláris kifejezés által generált nyelvhez tartozik úgy, hogy a start-tag és az első leszármazott elem között, az egyes leszármazott elemek között, illetve az utolsó leszármazott elem és az end-tag között opcionálisan lehetnek még white space-ek, megjegyzések és PI-k (azaz a [27] Misc szabályra illeszkedő markupok). Megjegyezzük, hogy azok CDATA szakaszok, amelyek csak white spaceket tartalmaznak, és az olyan entitásokra történő hivatkozások, amelyeknek a behelyettesítendő szövegrésze a karakterhivatkozások feloldása után végül white space-ekből áll, nem illeszkednek az S nemterminálisra, és ennélfogva nem szerepelhetnek a fent említett a helyeken. Azonban egy olyan belső entitásra való hivatkozás, aminek a literális értéke csupa olyan karakterhivatkozásból áll, ami white-space-szel fog helyettesítődni, illeszkedik az S szabályra, mivel a neki megfelelő behelyettesítendő szövegrész a karakterhivatkozások feloldása során előálló white space.

  3. A deklaráció illeszkedik a Mixed szabályra és a tartalmi rész (miután az entitáshivatkozásokat a megfelelő behelyettesítendő szövegrészekkel kicseréltük) karakteres adatból, megjegyzésekből, PI-kből és olyan leszármazott elemekből áll, ahol a leszármazott elemek típusa illeszkedik a tartalommodellben megadott nevekre.

  4. A deklaráció illeszkedik az ANY sztringre és a tartalmi rész (miután az entitáshivatkozásokat a megfelelő behelyettesítendő szövegrészekkel kicseréltük) karakteres adatból és olyan leszármazott elemekből áll, amelyeknek a típusát már deklaráltuk.

3.1 Start-tagek, end-tagek és üreselem-tagek

[Definíció: Minden nemüres XML elem kezdetét egy start-tag jelöli.]

Start-tag
[40]    STag    ::=    '<' Name (S Attribute)* S? '>' [WFC: Egyedi attribútum-specifikáció]
[41]    Attribute    ::=    Name Eq AttValue [VC: Az attribútumértékek típusa]
[WFC: Nem lehet külső entitásra hivatkozni]
[WFC: Nem lehet < az attribútumértékekben]

A start-tagekben és end-tagekban szereplő Name név adja meg az elem típusát. [Definíció: A Name-AttValue párokra az elem attribútum-specifikációiként hivatkozunk.], [Definíció: Ezekben a párokban Name részt attribútumnévnek] és [Definíció: az AttValue tartalmát (azaz a ' vagy " határolókjelek közé eső szöveget) attribútumértéknek nevezzük.] Megjegyezzük, hogy az attribútum-specifikációk sorrendje a start-tagben, illetve az üreselem-tagben nem lényeges.

Példa start-tagre:

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

[Definíció: A start-taggel kezdődő elemek végét egy end-taggel KELL jelölni. Az end-tagnek azt a nevet (Name) kell tartalmaznia, ami a start-tagben az adott elem elemtípusát meghatározta:]

End-tag
[42]    ETag    ::=    '</' Name S? '>'

Példa end-tagre:

</termdef>

[Definíció: A start-tag és az end-tag között lévő szöveget az elem tartalmának nevezzük (vagy másképpen: azt mondjuk, hogy az eleme a start-tagja és az end-tagja közötti szöveget tartalmazza):]

Az elem tartalma
[43]    content    ::=    CharData? ((element | Reference | CDSect | PI | Comment) CharData?)*

[Definíció: Azokat az elemeket, amelyeknek nincs tartalma, üres elemeknek nevezzük.] Az üres elemet kétféleképpen adhatjuk meg: vagy egy olyan start-taggel, ami után azonnal egy end-tag áll, vagy pedig egy üreselem-taggel. [Definíció: Az üreselem-taget a következő formában adjuk meg:]

Az üreselem-tag
[44]    EmptyElemTag    ::=    '<' Name (S Attribute)* S? '/>' [WFC: Egyedi attribútumspecifikáció]

Üreselem-taget minden olyan esetben LEHET használni, amikor egy elemnek nincs tartalma, függetlenül attól, hogy az adott elemet az EMPTY kulcsszóval deklaráltuk vagy sem. Az interoperabilitás érdekében az üreselem-taget akkor és csak akkor AJÁNLOTT használni, amikor az adott elemet EMPTY kulcsszóval üresnek deklaráltuk.

Példák üres elemekre:

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

3.2 Elemtípus-deklarációk

Az XML dokumentumokban lévő elemek struktúrájára vonatkozóan megszorításokat LEHET tenni úgy, hogy deklaráljuk az elemtípusokat és az attribútumlistákat. Ezeket a megszorításokat azután a dokumentum érvényességének a meghatározásakor használhatjuk fel. Az elemtípus deklarációjakor az elem tartalmára teszünk megszorításokat.

Az elemtípus-deklarációk gyakran megszorításokat tesznek arra vonatkozóan is, hogy az adott elem leszármazottjaként mely elemek fordulhatnak elő. Felhasználói kérésre az XML processzor figyelmeztetést küldHET, ha a deklaráció olyan elemtípusra hivatkozik, ami még nem volt deklarálva, de ez nem számít hibának.

[Definíció: Az elemtípus-deklarációt a következő formában adjuk meg:]

Elemtípus-deklaráció
[45]    elementdecl    ::=    '<!ELEMENT' S Name S contentspec S? '>' [VC: Egyedi elemtípus-deklaráció]
[46]    contentspec    ::=    'EMPTY' | 'ANY' | Mixed | children

ahol a Name név a deklarálandó elemtípust adja meg.

Példák elemtípus-deklarációkra:

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

3.2.1 Elem-tartalom

[Definíció: Akkor mondjuk, hogy az elemtípusnak elem-tartalma van, amikor az ilyen típusú elemeknek leszármazott elemeket és kizárólag leszármazott elemeket KELL tartalmazniuk (azaz nem karakteres adatot). A leszármazott elemeket között opcionálisan white space-ek (azaz az S nemterminálisra illeszkedő karakterek) is lehetnek elválasztó karakterekként.] [Definíció: Ebben az esetben a megszorítás tartalmazza a tartalom-modellt. A tartalom-modell egy egyszerű nyelvtan, ami meghatározza, hogy milyen elemek fordulhatnak elő leszármazott elemekként és ezek milyen sorrendben követhetik egymást.] Ez a nyelvtan az úgynevezett tartalom-részekből, azaz az angol terminológia alapján cp-kből (content particles) épül fel. A cp-k felépülhetnek nevekből, alternatív tartalom-részek listájából (choice) vagy tartalom-részek szekvenciális listájából (sequence):

Az elemek tartalom-modellje
[47]    children    ::=    (choice | seq) ('?' | '*' | '+')?
[48]    cp    ::=    (Name | choice | seq) ('?' | '*' | '+')?
[49]    choice    ::=    '(' S? cp ( S? '|' S? cp )+ S? ')' [VC: Helyes csoport/PE egymásbaágyazás]
[50]    seq    ::=    '(' S? cp ( S? ',' S? cp )* S? ')' [VC: Helyes csoport/PE egymásbaágyazás]

ahol minden Name név annak az elemnek a típusa, ami az adott elem leszármazottja LEHET. Az adott elem tartalmazHATja a választható tartalom-részek listájában (choice list) szereplő bármely tartalom-részt azon a helyen, ahol a választható tartalom-részek listája a nyelvtanban szerepelt. A tartalom-részek szekvenciális listájában (seq) szereplő minden tartalom-részt tartalmaznia KELL az adott elemnek, méghozzá a listában megadott sorrendben. A név vagy a lista után opcionálisan még megadott karakter határozza meg, hogy az elemek vagy a listában lévő tartalom-részek egyszer vagy egynél többször (+) fordulnak elő, nullaszor vagy többször (*) fordulnak elő, illetve nullaszor vagy egyszer (?) fordulnak elő. Ha nincs ilyen operátor megadva, akkor az azt jelenti, hogy az elemnek vagy tartalom-résznek pontosan egyszer KELL előfordulnia. Ez a szintaxis, illetve a jelentése pontosan megegyezik a jelen specifikáció nyelvtani szabályainak megadásakor használtakkal.

Az elemek tartalma akkor és csak akkor illeszkedik egy tartalom-modellre, ha a tartalom-modellben be lehet járni egy olyan utat, ami nem sérti meg a szekvenciális tartalom-részek listái, választható tartalom-részek listái és az ismétlésre vonatkozó operátorok által meghatározott szabályokat, és ahol az elem tartalmában minden elem illeszkedik a tartalom-modell egy elemtípusára. A kompatibilitás érdekében hibának számít, ha a tartalom-modell lehetővé teszi, hogy egy elem a tartalom-modellben lévő elemtípusok valamelyikének egynél több előfordulására is illeszkedjen. Erről további információkért lásd a E Determinisztikus tartalom-modellek részt.

Érvényességi feltétel: Helyes csoport/PE egymásbaágyazás

A paraméterentitások behelyettesítendő szövegrészének helyesen KELL egymásba ágyazva lenni a zárójelezett csoportokkal. Azaz mondjuk, ha egy paraméterentitás behelyettesítendő szövegrésze tartalmaz egy choice, seq, vagy Mixed szabályban lévő nyitó vagy lezáró zárójelet, akkor mindkettőt tartalmaznia KELL ugyanannak a behelyettesítendő szövegrésznek.

Az interoperabilitás érdekében, ha egy paraméterentitás-hivatkozás szerepel egy choice, seq, vagy Mixed szabályban, akkor AJÁNLOTT, hogy ennek a behelyettesítendő szövegrésze legalább egy nemüres karaktert tartalmazzon, és AJÁNLOTT, hogy a behelyettesítendő szövegrész első nemüres karaktere, illetve utolsó nemüres karaktere ne legyen connector karakter (| vagy ,).

Példák elemek tartalom-modelljére:

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

3.3 Attribútumlista-deklarációk

Az attribútumokat arra használjuk, hogy az elemekhez név-érték párokat rendeljük hozzá. Az attribútumspecifikációk NEM szerepelHETnek a start-tageken, illetve az üreselem-tageken kívül, ezért azok a nyelvtani szabályok, amelyek illeszkednek rájuk a 3.1 Start-tagek, end-tagek és üreselem-tagek részben találhatóak. Az attribútumlista-deklarációkat arra LEHET használni, hogy:

  • definiáljuk azokat az attribútumokat, amelyek egy adott elemtípushoz tartoznak,

  • megszorításokat tegyünk ezeknek az attribútumoknak a típusára vonatkozóan,

  • illetve, hogy alapértelmezett értékeket adjunk meg ezekhez az attribútumokhoz

[Definíció: Az attribútumlista-deklarációk meghatározzák az adott elemtípushoz hozzárendelt attribútumok nevét, adattípusát és alapértelmezett értékét (ha van alapértelmezett értékük):]

Attribútumlista-deklaráció
[52]    AttlistDecl    ::=    '<!ATTLIST' S Name AttDef* S? '>'
[53]    AttDef    ::=    S Name S AttType S DefaultDecl

A Name név az AttlistDecl szabályban az elem típusa. Felhasználói kérésre az XML processzor figyelmeztetést küldHET, ha olyan elemtípusnak deklaráljuk az attribútumait, ami nincs is deklarálva, de ez nem számít hibának. A Name név az AttDef szabályban az attribútum neve.

Ha egy adott elemtípushoz egynél több AttlistDecl attribútumlista-deklarációt adunk meg, akkor ezeknek a tartalma össze lesz fésülve. Ha egy adott elemtípus valamely attribútumához egynél több definíciót adunk meg, akkor az első deklaráció lesz érvényes az adott attribútumra és az összes több figyelmen kívül lesz hagyva. Az interoperabilitás érdekében a DTD-k írásakor LEHETŐSÉG VAN úgy megadni a deklarációkat, hogy legfeljebb egy attribútumlista-deklarációt adunk meg egy adott elemtípushoz, legfeljebb egy attribútumdefiníciót adunk meg egy adott, az attribútumlista-deklarációban szereplő attribútumnévhez, és legalább egy attribútumdefiníciót adunk meg minden attribútumlista-deklarációban. Szintén az interoperabilitás érdekében az XML processzorok felhasználói kérésre figyelmeztetést küldHETnek, ha egynél több attribútumlista-deklaráció van megadva egy adott elemtípushoz vagy egynél több attribútumdefiníció van megadva egy adott attribútumhoz, de ezek nem számítanak hibának.

3.3.1 Attribútumtípusok

Az XML három fajta attribútumtípust támogat: sztringtípust, tokenizált típusokat és felsorolás típusokat. A sztringtípus bármilyen literális sztringet tartalmazhat értékként. A tokenizált típusokra különböző lexikális és szemantikus megszorításokat lehet tenni. A nyelvtan által említett érvényességi feltételeket azután kell alkalmazni, hogy az attribútumértékeket normalizáltuk a 3.3.3 Attribútumérték-normalizálás részben leírtaknak megfelelően.

Attribútumtípusok
[54]    AttType    ::=    StringType | TokenizedType | EnumeratedType
[55]    StringType    ::=    'CDATA'
[56]    TokenizedType    ::=    'ID' [VC: ID]
[VC: Elemtípusonként egy ID]
[VC: ID attribútum alapértelmezett értéke]
| 'IDREF' [VC: IDREF]
| 'IDREFS' [VC: IDREF]
| 'ENTITY' [VC: Entitásnév]
| 'ENTITIES' [VC: Entitásnév]
| 'NMTOKEN' [VC: Név token]
| 'NMTOKENS' [VC: Név token]

Érvényességi feltétel: ID

Az ID típusú értékeknek illeszkedniük KELL a Name szabályra. A neveknek NEM SZABAD egynél többször előfordulniuk egy XML dokumentumon belül ID típusú értékként, azaz az ID értékeknek egyértelműen KELL azonosítaniuk azokat az elemeket, amelyekben előfordulnak.

Érvényességi feltétel: IDREF

Az IDREF típusú értékeknek illeszkedniük KELL a Name szabályra, és az IDREFS típusú értékeknek illeszkedniük KELL a Names szabályra, valamint minden Name névnek illeszkednie KELL az XML dokumentumban valamelyik elem ID attribútumának az értékére, azaz az IDREF értékeknek illeszkedniük KELL valamelyik ID attribútum értékére.

Érvényességi feltétel: Entitásnév

Az ENTITY típusú értékeknek illeszkedniük KELL a Name szabályra, és az ENTITIES típusú értékeknek illeszkedniük KELL a Names szabályra, valamint minden Name névnek illeszkednie KELL egy, a DTD-ben deklarált elemzés nélküli entitás nevére.

Érvényességi feltétel: Név token

Az NMTOKEN típusú értékeknek illeszkedniük KELL az Nmtoken szabályra, és az NMTOKENS típusú értékeknek illeszkedniük KELL az Nmtokens szabályra.

[Definíció: A felsorolás típusú attribútumoknak a deklarációjukban megadott értékek listájából KELL egy értéket felvenniük]. Kétfajta felsorolás típus létezik:

Felsorolás típusú attribútumtípusok
[57]    EnumeratedType    ::=    NotationType | Enumeration
[58]    NotationType    ::=    'NOTATION' S '(' S? Name (S? '|' S? Name)* S? ')' [VC: Jelölésmód típusú attribútumok]
[VC: Elemtípusonként egy jelölésmód]
[VC: Üres elemen nem lehet jelölésmód]
[VC: Duplikált tokenek nem megengedettek]
[59]    Enumeration    ::=    '(' S? Nmtoken (S? '|' S? Nmtoken)* S? ')' [VC: Felsorolás]
[VC: Duplikált tokenek nem megengedettek]

A NOTATION attribútumok azonosítják a jelölésmódokat, amiket arra használunk, hogy fel tudjuk dolgozni, értelmezni tudjuk azokat az elemeket, amelyekhez a NOTATION attribútum meg van adva. A jelölésmódokat a DTD-ben a hozzájuk rendelt system és/vagy publikus azonosítókkal deklaráljuk.

Érvényességi feltétel: Üres elemen nem lehet jelölésmód

A kompatibilitás érdekében NOTATION típusú attribútumot NEM SZABAD olyan elemen deklarálni, amit EMPTY-nek, azaz üresnek deklaráltunk.

Érvényességi feltétel: Duplikált tokenek nem megengedettek

Egy adott NotationType attribútumdeklarációban a jelölésmód-neveknek mind különbözőeknek KELL lenniük. Hasonló módon egy adott Enumeration attribútumdeklarációban az NmToken neveknek mind különbözőeknek KELL lenniük.

Az interoperabilitás érdekében ugyanannak az Nmtoken-nek NEM AJÁNLOTT egynél többször előfordulni egy adott elemtípus felsorolás típusú attribútumtípusaiban.

3.3.2 Attribútumok alapértelmezett értékei

Az attribútumdeklarációk meghatározzák azt is, hogy egy attribútum KÖTELEZŐ attribútum-e, és hogy ha nem kötelező megadni, akkor az XML processzoroknak mit kell csinálni abban az esetben, ha az adott attribútum nem szerepel a dokumentumban.

Attribútumok alapértelmezett értékei
[60]    DefaultDecl    ::=    '#REQUIRED' | '#IMPLIED'
| (('#FIXED' S)? AttValue) [VC: Kötelező attribútum]
[VC: Az attribútumok alapértelmezett értéke szintaktikailag helyes legyen]
[WFC: Nem lehet < az attribútumértékekben]
[VC: Fixed attribútum alapértelmezése]

Az attribútumdeklarációkban a #REQUIRED kulcsszó azt jelenti, hogy az attribútumot mindig meg KELL adni, az #IMPLIED kulcsszó pedig azt, hogy az attribútumhoz nem adunk meg alapértelmezett értéket. [Definíció: Ha a deklarációban sem a #REQUIRED, sem pedig az #IMPLIED kulcsszó nem szerepel, akkor az AttValue érték tartalmazza a deklarált alapértelmezett értéket. A #FIXED kulcsszó használata azt vonja maga után, hogy az attribútum értékének mindig meg KELL egyezni az alapértelmezett értékkel. Ha az XML processzor olyan elemet talál, amihez nem adtunk meg egy olyan attribútumot, amihez ugyanakkor beolvastuk az alapértelmezett érték deklarációját, akkor az XML processzornak értesítenie KELL az alkalmazást erről az attribútumról megadva egyúttal a deklarált alapértelmezett értéket is.]

Példák attribútumlista-deklarációkra:

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

3.3.3 Attribútumérték-normalizálás

Az XML processzornak normalizálnia KELL az attribútumértékeket még mielőtt az attribútumok értékét átadná az alkalmazásnak vagy azok érvényességét ellenőrizné. A normalizálást vagy az alábbi algoritmus végrehajtásával kell elvégeznie, vagy pedig bármely olyan egyéb módon, ami garantálja, hogy az alkalmazásnak átadott érték ugyanaz lesz, mint amit az alábbi algoritmus állított volna elő.

  1. Minden sortörést #xA karakterré KELL normalizálni a bemeneten a 2.11 A sorvége jel kezelése részben leírtaknak megfelelően, tehát az algoritmus további része az így normalizált szöveget kapja inputként.

  2. Kezdjük az algoritmust az üres sztringből álló normalizált értékkel.

  3. Minden karakteren, entitáshivatkozáson vagy karakterhivatkozáson, ami a nem normalizált attribútumértékben található az elsőtől az utolsóig haladva végezzük el a következőket:

    • Karakterhivatkozások esetén adjuk hozzá a hivatkozott karaktert a normalizált értékhez utolsó karakterként.

    • Entitáshivatkozások esetén rekurzív módon alkalmazzuk jelen algoritmus 3. lépését az adott entitás behelyettesítendő szövegrészére.

    • White space karakterek (#x20, #xD, #xA, #x9) esetén adjuk hozzá a szóköz karaktert (#x20) a normalizált értékhez utolsó karakterként.

    • Bármilyen más karakter esetén adjuk hozzá a karaktert a normalizált értékhez utolsó karakterként.

Ha az attribútumtípus nem CDATA, akkor az XML processzornak a normalizált attribútumértéken további módosításokat KELL végrehajtania levágva az érték elején és végén esetlegesen előforduló szóköz (#x20) karaktereket és az egymás után álló szóközök sorozát mindenhol egyetlen szóköz (#x20) karakterrel helyettesítve.

Vegyük észre, hogy ha a nem normalizált attribútumérték olyan karakterhivatkozást tartalmaz, ami egy, a szóköztől (#x20) különböző white space karakterre hivatkozik, akkor a normalizált érték magát a hivatkozott karaktert (#xD, #xA vagy #x9 karaktert) fogja tartalmazni. Ez eltér attól az esettől, amikor a nem normalizált érték közvetlenül egy white space karaktert tartalmaz (tehát nem hivatkozást egy white space karakterre), amikoris a white space karakter egy szóközzel (#x20) lesz helyettesítve a normalizált értékben, és szintén eltér attól az esettől, amikor a nem normalizált érték egy entitáshivatkozást tartalmaz, amelynek a behelyettesítendő szövegrésze tartalmazza a white space karaktert, hiszen ez utóbbi esetben a rekurzív feldolgozás miatt a white space karakter megint csak szóközzel (#x20) lesz helyettesítve a normalizált értékben.

Azoknak a processzoroknak, amelyek nem ellenőrzik az adat érvényességét, minden olyan attribútumot, amihez nem olvastak be deklarációt, úgy AJÁNLOTT kezelni, mintha CDATA-ként lettek volna deklarálva.

Hibának számít, ha egy attribútumérték olyan entitásra történő hivatkozást tartalmaz, amihez nem olvasott be korábban deklarációt.

Példák attribútumnormalizálásra. Legyen adva a következő deklarációk:

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

az alábbi táblázat bal szélső oszlopában található attribútumspecifikációk esetén a középső oszlopban lévő karaktersorozatokat kapjuk a normalizálás után, ha az a attribútumot NMTOKENS-ként deklaráljuk, és a jobb szélső oszlopban lévő karaktersorozatokat kapjuk a normalizálás után, ha az a attribútumot CDATA-ként deklaráljuk.

Attribútumspecifikáció NMTOKENS-ként CDATA-ként
a="

xyz"
x y z
#x20 #x20 x y z
a="&d;&d;A&a;&#x20;&a;B&da;"
A #x20 B
#x20 #x20 A #x20 #x20 #x20 B #x20 #x20
a=
"&#xd;&#xd;A&#xa;&#xa;B&#xd;&#xa;"
#xD #xD A #xA #xA B #xD #xA
#xD #xD A #xA #xA B #xD #xA

Vegyük észre, hogy az utolsó példa nem eredményez érvényes XML dokumentumot (de ugyanakkor jólformált), ha az a attribútumot NMTOKENS-ként deklaráljuk.

3.4 Feltételes szakaszok

[Definíció: Feltételes szakaszoknak nevezzük a dokumentumtípus-deklaráció külső részhalmazának, illetve a külső paraméterentitásoknak azon részeit, amelyeket a feltételes szakaszban található kulcsszótól függően vagy hozzáadunk a DTD struktúrájához, vagy pedig kihagyunk abból.]

Feltételes szakaszok
[61]    conditionalSect    ::=    includeSect | ignoreSect
[62]    includeSect    ::=    '<![' S? 'INCLUDE' S? '[' extSubsetDecl ']]>' [VC: Helyes feltételes szakasz/PE egymásbaágyazás]
[63]    ignoreSect    ::=    '<![' S? 'IGNORE' S? '[' ignoreSectContents* ']]>' [VC: Helyes feltételes szakasz/PE egymásbaágyazás]
[64]    ignoreSectContents    ::=    Ignore ('<![' ignoreSectContents ']]>' Ignore)*
[65]    Ignore    ::=    Char* - (Char* ('<![' | ']]>') Char*)

A DTD belső és külső részhalmazához hasonlóan a feltételes szakaszok is tartalmazhatnak egy vagy több teljes deklarációt, megjegyzést, feldolgozó utasítást vagy további beágyazott feltételes szakaszokat, és ezen részek között white space-ek is lehetnek.

Ha a feltételes szakaszban az INCLUDE kulcsszó található, akkor a feltételes szakasz tartalmát a DTD részének KELL tekinteni. Ha a feltételes szakaszban az IGNORE kulcsszó található, akkor a feltételes szakasz tartalmát úgy KELL tekinteni, hogy az logikailag nem képezi a DTD részét. Ha egy INCLUDE kulcsszót tartalmazó feltételes szakasz egy nagyobb feltételes szakaszon belül fordul elő, ami viszont az IGNORE kulcsszót tartalmazza, akkor mind a belső, mind a külső feltételes szakaszt figyelmen kívül KELL hagyni. A figyelmen kívül hagyott feltételes szakaszok tartalmát úgy KELL értelmezni, hogy a kulcsszót után álló "[" karaktertől kezdődően minden karaktert figyelmen kívül hagyunk, kivéve a feltételes szakaszok kezdő "<![" és lezáró "]]>" karaktersorozatait, amíg a feltételes szakasz végét meg nem találjuk. Ezen értelmezés során a paraméterentitásokra történő hivatkozásokat NEM SZABAD felismerni.

Ha a feltételes szakasz kulcsszava egy paraméterentitásra történő hivatkozás, akkor a paraméterentitást még azelőtt helyettesíteni KELL a neki megfelelő tartalommal, mielőtt a processzor eldöntené, hogy a feltételes szakaszt figyelmen kívül hagyja-e vagy sem.

Példa:

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

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

4 Fizikai struktúrák

[Definíció: Az XML dokumentumok egy vagy több tárolási egységből állhatnak, amiket entitásoknak hívunk. Minden entitásnak van tartalma, és (a dokumentumentitást és a DTD külső részhalmazát kivéve) minden entitást nevével azonosítunk.] Minden XML dokumentumnak van pontosan egy entitása, amit dokumentumentitásnak hívunk. A dokumentumentitás szolgál a XML dokumentum kiindulási pontjaként az XML processzor számára és önmagában is tartalmazhatja a teljes dokumentumot.

Az entitások lehetnek elemzettek vagy elemzés nélküliek. [Definíció: Az elemzett entitás tartalmát az elemzett entitás behelyettesítendő szövegrészének hívjuk. Ezt a szövegrészt a dokumentum részének tekintjük.]

[Definíció: Az elemzés nélküli entitások olyan források, amelyek tartalma lehet szövegrész is és lehet nem szöveges tartalom is. Amennyiben szövegrész, akkor sem kell, hogy XML legyen. Minden elemzés nélküli entitáshoz hozzá van rendelve egy jelölésmód, amit a nevével adunk meg. Azon túlmenően, hogy az XML processzoroknak az entitások nevét és a jelölésmód nevét az alkalmazás számára elérhetővé kell tenniük, az XML nem tesz semmilyen megszorítást az elemzés nélküli entitások tartalmára vonatkozóan.]

Az elemzett entitásokra a nevükkel hivatkozunk entitás-hivatkozásokat használatával. Az elemzés nélküli entitásokra szintén a nevükkel hivatkozunk, de az ENTITY és ENTITIES attribútumok értékében megadva őket.

[Definíció: Általános entitásoknak nevezzük azokat az entitásokat, amelyeket a dokumentum tartalmi részén belül használunk. Jelen specifikációban az általános entitásokra időnként a jelző nélküli entitás kifejezéssel is hivatkozunk, ha ez nem vezet félreértéshez.] [Definíció: Paraméter-entitásoknak nevezzük azokat az elemzett entitásokat, amelyeket a DTD-n belül használunk.] Erre a két különböző entitástípusra eltérő formában hivatkozunk, és különböző szövegkörnyezetben ismerjük fel őket. Ezenfelül különböző névterekhez tartoznak, azaz ha egy paraméterentitásnak és egy általános entitásnak ugyanaz a neve, az megengedett, és ekkor két különböző entitásról van szó.

4.1 Karakterhivatkozások és entitáshivatkozások

[Definíció: A karakterhivatkozások az ISO/IEC 10646 karakterkészlet egy megadott karakterére hivatkoznak. Például olyan esetekben, amikor az adott karakter közvetlenül nem elérhető a rendelkezésre álló beviteli eszközökön keresztül.]

Karakterhivatkozás
[66]    CharRef    ::=    '&#' [0-9]+ ';'
| '&#x' [0-9a-fA-F]+ ';' [WFC: Megengedett karakter]

Ha a karakterhivatkozás "&#x" karakterekkel kezdődik, akkor a lezáró ; karakterig következő számjegyek és betűk a karakter ISO/IEC 10646 szerinti kódjának a hexadecimális számrendszerbeli ábrázolását adják meg. Ha a karakterhivatkozás csak "&#" karakterekkel kezdődik, akkor a lezáró ; karakterig következő számjegyek a karakter kódjának decimális ábrázolását adják meg.

[Definíció: Az entitáshivatkozások egy névvel rendelkező entitás tartalmára hivatkoznak.] [Definíció: Azok a hivatkozások, amelyek elemzett általános entitásokra hivatkoznak az és (&) karaktert és a pontosvesszőt (;) használják a hivatkozás kezdetének, illetve végének a jelzésére.] [Definíció: A paraméterentitás-hivatkozások a százalékjelet (%) és a pontosvesszőt (;) használják a hivatkozás kezdetének és végének a jelzésére.]

Entitáshivatkozás
[67]    Reference    ::=    EntityRef | CharRef
[68]    EntityRef    ::=    '&' Name ';' [WFC: Deklarált entitás]
[VC: Deklarált entitás]
[WFC: Elemzett entitás]
[WFC: Rekurzió nem megengedett]
[69]    PEReference    ::=    '%' Name ';' [VC: Deklarált entitás]
[WFC: Rekurzió nem megengedett]
[WFC: DTD-ben legyen]

Jólformáltsági feltétel: Deklarált entitás

A DTD-vel nem rendelkező dokumentumokban, illetve az olyan csak belső DTD részhalmazzal rendelkező dokumentumokban, amelyek nem tartalmaznak paraméterentitás-hivatkozásokat, továbbá a "standalone='yes'" jelzésű dokumentumokban azon entitáshivatkozás esetében, amelyek nem a külső részhalmazon belül vagy paraméterentitáson belül találhatóak, az entitáshivatkozásban megadott Name névnek illeszkednie KELL egy olyan entitásdeklarációban megadott névre, ami szintén nem a külső részhalmazon belül vagy paraméterentitáson belül található, kivéve, hogy a jólformált dokumentumoknak nem szükséges deklarálniuk a következő entitásokat: amp, lt, gt, apos, quot. Az általános entitások deklarációjának meg KELL előznie minden olyan, az adott entitásra történő hivatkozást, ami egy attribútumlista-deklaráció alapértelmezett értéket megadó részében fordul elő.

Vegyük észre, hogy az érvényességet nem ellenőrző processzoroknak nem kötelező beolvasni és feldolgozni a paraméterentitásokban, illetve a külső részhalmazban található entitásdeklarációkat. Az ilyen dokumentumok esetén az a szabály, hogy az entitást deklarálni kell, csak akkor számít jólformáltsági feltételnek, ha standalone='yes' deklarációja volt.

Érvényességi feltétel: Deklarált entitás

Külső részhalmazzal vagy külső paraméterentitásokkal rendelkező "standalone='no'" deklarációjú dokumentumok esetén az entitáshivatkozásban megadott Name névnek illeszkednie KELL az entitásdeklarációban megadott névre. Az interoperabilitás érdekében az érvényes dokumentumoknak AJÁNLOTT deklarálni az amp, lt, gt, apos, quot entitásokat is, méghozzá abban a formában, ahogy a 4.6 Előredefiniált entitások részben meg vannak adva. A paraméterentitás deklarációjának meg KELL előznie a paraméterentitásra történő hivatkozást. Hasonlóképpen, az általános entitás deklarációjának meg KELL előznie minden olyan attribútumlista-deklarációt, ami olyan alapértelmezett értéket tartalmaz, ami közvetlen vagy közvetett módon az adott általános entitásra hivatkozik.

Jólformáltsági feltétel: Elemzett entitás

Az entitáshivatkozásoknak NEM SZABAD nem elemzett entitás nevét tartalmazniuk. Nem elemzett entitásokra csak ENTITY vagy ENTITIES típusú attribútumok értékeként hivatkozhatunk.

Példák karakterhivatkozásokra és entitáshivatkozásokra:

Type <key>less-than</key> (&#x3C;) to save options.
This document was prepared on &docdate; and
is classified &security-level;.

Példa paraméterentitás-hivatkozásra:

<!-- declare the parameter entity "ISOLat2"... -->
<!ENTITY % ISOLat2
         SYSTEM "http://www.xml.com/iso/isolat2-xml.entities" >
<!-- ... now reference it. -->
%ISOLat2;

4.2 Entitásdeklarációk

[Definíció: Az entitásokat a következőképpen deklaráljuk:]

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

A Name név azonosítja az entitást az entitáshivatkozásban vagy elemzés nélküli entitás esetén az ENTITY vagy ENTITIES attribútumok értékében. Ha ugyanazt az entitást egynél többször deklaráljuk, akkor az elsőnek beolvasott deklarációt tekintjük érvényesnek. Felhasználói kérésre az XML processzor figyelmeztetést küldHET, ha egy entitás egynél többször van deklarálva.

4.2.1 Belső entitások

[Definíció: Ha az entitásdefiníció egy EntityValue-ból áll, akkor a definiált entitást belső entitásnak nevezzük. Ekkor nincs szó külön fizikai tárolási egységről, és az entitás tartalmát magában a deklarációban van megadva.] Megjegyezzük, hogy a literális entitásértékben található entitáshivatkozások és karakterhivatkozások esetén a helyes behelyettesítendő szövegrész előállításához szükség lehet néhány feldolgozási lépésre is: erről lásd még a 4.5 A belső entitások behelyettesítendő szövegrészének az előállítása részt.

A belső entitások elemzett entitások.

Példa belső entitás deklarációjára:

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

4.2.2 Külső entitások

[Definíció: A belső entitásoktól eltérő entitásokat külső entitásnak nevezzük, és a következőképpen deklaráljuk őket:]

Külső entitás deklarációja
[75]    ExternalID    ::=    'SYSTEM' S SystemLiteral
| 'PUBLIC' S PubidLiteral S SystemLiteral
[76]    NDataDecl    ::=    S 'NDATA' S Name [VC: Deklarált jelölésmód]

Ha az NDataDecl szabályt alkalmazzuk, akkor általános elemzés nélküli entitásról beszélünk; egyébként pedig elemzett entitásról van szó.

Érvényességi feltétel: Deklarált jelölésmód

A Name névnek illeszkednie KELL egy deklarált jelölésmód nevére.

[Definíció: A SystemLiteral-t az entitás rendszerazonosítójának nevezzük. A rendszerazonosító arra szolgál, hogy URI hivatkozássá alakítsuk át annak az eljárásnak a részeként, amikor azért hivatkozunk rá valahol, hogy az XML processzor számára elérhetővé tegyük azt az információt, ami az entitás behelyettesítendő szövegrészének a létrehozásához szükséges. (Az URI hivatkozást az [IETF RFC 2396]-ben van definiálja, illetve ezt a definíciót az [IETF RFC 2732] aktualizálta.)] Hibának számít, ha egy fragment-azonosító (azaz # karakterrel kezdődő azonosító) a rendszerazonosító részét képezi. Ha a jelen specifikáció hatókörén kívül eső egyéb információforrás (például egy speciális XML elemtípus, amit egy külön DTD definiál vagy egy külön alkalmazás-specifikáció által definált feldolgozó utasítás) másképp nem definiálja, akkor a relatív URI-k annak az erőforrásnak a helyéhez képest relatívak, amiben az entitásdeklaráció található. Ezt úgy határozzuk meg, hogy az a külső entitás legyen, ami a deklarációt kezdő '<' karaktert tartalmazza akkor, amikor a deklarációt éppen parse-oljuk. Ezért tehát az URI relatív lehet a dokumentumentitáshoz képest, a külső DTD részhalmazt tartalmazó entitáshoz képest vagy más külső paraméterentitáshoz képest is. Amikor megpróbáljuk beolvasni URI által azonosított erőforrásokat, akkor ezek az olvasási kérések továbbítódHATnak a parser szintjére (például egy entitás feloldásakor) vagy az alatti szintre is (a protokoll szintjére, például egy HTTP Location: header segítségével). Ha a jelen specifikáció hatókörén kívül eső más információforrás hiányában az erőforrás számára a bázis URI mindig az éppen visszaadott erőforrás URI-ja. Más szavakkal, annak az erőforrásnak az URI-ja, ami az összes hivatkozás feloldása után beolvasásra került.

A rendszerazonosítók (illetve az egyéb URI hivatkozások céljára használt XML stringek) tartalmazHATnak olyan karaktereket is, amiket az [IETF RFC 2396] és az [IETF RFC 2732] szerint helyettesíteni kell más karakterekkel, mielőtt az URI-t a hivatkozott erőforrás beolvasására használnánk. Az ilyen lecserélendő karakterek a vezérlő karakterek az #x0-tól az #x1F-ig és az #x7F (amelyek legtöbbje nem is szerepelhet az XML-ben), a #x20 szóköz, az '<' #x3C, '>' #x3E és '"' #x22 elválasztó karakterek, az '{' #x7B, '}' #x7D, '|' #x7C, '\' #x5C, '^' #x5E és '`' #x60 unwise karakterek , valamint minden karakter #x7F felett. Mivel ez a behelyettesítés nem mindig teljesen visszafordítható eljárás, ezért akkor KELL elvégezni, amikor minden kétséget kizáróan szükség van rá, és amennyire csak lehetséges a legutolsó lépésként kell végrehajtani a feldolgozás során. Speciálisan NEM SZABAD a behelyettesítést elvégezni sem a relatív URI abszolút URI-ra történő konverziójakor, sem pedig akkor, amikor az URI hivatkozást átadjuk annak az eljárásnak vagy szoftverkomponensnek, ami a hivatkozás feloldásáért felel. Amikor a behelyettesítés megtörténik, akkor a következőképpen KELL végrehajtani:

  1. Minden karaktert, ami lecserélésre kerül UTF-8-ban [Unicode3] ábrázolunk egy vagy több bájttal leírva.

  2. Az így előállított bájtokat az URI behelyettesítési mechanizmusát használva átalakítunk (azaz %HH alakra konvertáljuk őket, ahol HH a bájtérték hexadecimális formában megadva).

  3. Az eredeti karaktert az így előálló karaktersorozattal helyettesítjük.

[Definíció: A rendszerazonosítókon kívül a külső azonosítók tartalmazHATnak publikus azonosítókat is.] Amikor egy XML processzor megpróbál hozzáférni az entitás tartalmához, akkor használhatja a publikus azonosítót és a rendszerazonosítót is, illetve ezek bármilyen kombinációját. HasználHAT továbbá bármilyen további jelen specifikáció hatókörén kívül eső információt is, hogy egy alternatív URI hivatkozást hozzon létre. Ha a processzor nem tud ilymódon URI hivatkozást létrehozni, akkor a rendszerazonosítóban megadott URI hivatkozást KELL használnia. Mielőtt megpróbálnánk alkalmazni a nyilvános azonosítót, a benne található minden white space sorozatot egyetlen szóköz (#x20) karakterrel KELL helyettesíteni és az azonosító elején és végén található esetleges white space-eket törölni KELL.

Példák külső entitások deklarációjára:

<!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 Elemzett entitások

4.3.2 Jólformált elemzett entitások

A dokumentumentitás akkor jólformált, ha illeszkedik a document címkéjű szabályra. Egy általános külső elemzett entitás akkor jólformált, ha illeszkedik a extParsedEnt címkéjű szabályra. Minden külső paraméterentitás definíció szerint jólformált.

Jólformált külső elemzett entitás
[78]    extParsedEnt    ::=    TextDecl? content

Egy belső általános elemzett entitás akkor jólformált, ha a behelyettesítendő szövegrésze illeszkedik content címkéjű szabályra. Minden belső paraméterentitás definíció szerint jólformált.

Az általános entitásoknál megkövetelt jólformáltság következményeként az XML dokumentumban található logikai és fizikai struktúrák helyesen vannak egymásba ágyazva. Egyetlen start-tag, end-tag, üreselem-tag, elem, megjegyzés, feldolgozó utasítás, karakterhivatkozás vagy entitáshivatkozás sem kezdődhet az egyik entitásban és fejeződhet be egy másikban.

4.3.3 Karakterkódolás az entitásokban

Egy XML dokumentum minden egyes külső elemzett entitása különböző karakterkódolást használHAT a karaktereihez. Minden XML processzornak képesnek KELL lennie mind az UTF-8, mind pedig az UTF-16 karakterkódolások használatával írt entitások beolvasasára. A jelen specifikációban használt "UTF-8" és "UTF-16" kifejezések nem vonatkoznak semmilyen más karakterkódolásra, még ha az adott kódolás vagy annak neve nagyon hasonló is az UTF-8-hoz vagy az UTF-16-hoz.

Az UTF-16-ban írt entitásoknak Byte Order Mark-kal KELL kezdődniük, illetve az UTF-8-ban írt entitások is kezdődHETnek Byte Order Mark megadásával. A Byte Order Mark leírása az [ISO/IEC 10646:2000] H függelékében, a [Unicode] 2.4 szakaszában, illetve a [Unicode3] 2.7 szakaszában (a ZERO WIDTH NO-BREAK SPACE karakter, #xFEFF) található meg. Ez egy olyan kódolási jelzés, ami része sem az XML dokumentum markupjának, sem pedig a karakteres adatának. Az XML processzoroknak képesnek KELL lenniük arra, hogy ennek a karakternek a segítségével meg tudják különböztetni egymástól az UTF-8-ban, illetve az UTF-16-ban kódolt dokumentumokat.

Jóllehet az XML processzoroknak csak az UTF-8-ban és az UTF-16-ban írt entitásokat kell tudniuk beolvasni, látnivaló, hogy sok más karakterkódolás is használatban van világszerte, és kívánatos lehet, hogy az XML processzorok ezeket is be tudják olvasni és használni tudják őket. Egyéb külső karakterkódolási információ (pl MIME headerek) hiányában azoknak az elemzett entitásoknak, amelyek az UTF-8-tól és az UTF-16-tól eltérő kódolásban vannak megadva, szövegrész-deklarációval (lásd 4.3.1 A szövegrész-deklaráció részt) KELL kezdődniük, ami tartalmazza használt kódolás deklarációját:

Kódolásdeklaráció
[80]    EncodingDecl    ::=    S 'encoding' Eq ('"' EncName '"' | "'" EncName "'" )
[81]    EncName    ::=    [A-Za-z] ([A-Za-z0-9._] | '-')* /* A kódolás neve csak Latin karaktereket tartalmaz */

A dokumentumentitásban a kódolásdeklaráció az XML deklaráció része. Az EncName a használt kódolás neve.

A kódolás-deklarációban az "UTF-8", "UTF-16", "ISO-10646-UCS-2" és "ISO-10646-UCS-4" értékeket AJÁNLOTT használni a Unicode / ISO/IEC 10646 különböző kódolásainak és transzformációinak a megadásához, illetve az "ISO-8859-1", "ISO-8859-2", ... "ISO-8859-n" (ahol n a rész száma) értékeket AJÁNLOTT használni az ISO 8859 megfelelő részeire történő hivatkozáskor és "ISO-2022-JP", "Shift_JIS" és "EUC-JP" értékeket AJÁNLOTT használni a JIS X-0208-1997 különböző kódolási formáinak a megadásakor. AJÁNLOTT továbbá, hogy azokra a karakterkódolásokra, amelyek az Internet Assigned Numbers Authority [IANA-CHARSETS] által regisztrálva vannak, a regisztrált nevükkel hivatkozzunk. A nem regisztrált nevekre egy "x-" prefix használatával AJÁNLOTT hivatkozni. AJÁNLOTT továbbá, hogy az XML processzorok a karakterkódolások nevénél a kisbetűket és a nagybetűket ne különböztessék meg egymástól, illetve hogy vagy IANA által regisztrált névként értelmezzék azokat a karakterkódolásokat, amelyek regisztrálva vannak az IANA-nál az adott névvel, vagy pedig ismeretlenként kezeljék őket. (Természetesen a processzoroknak nem kell támogatniuk az összes IANA által regiszrált kódolást.)

Azoknál az entitásoknál, ahol egyéb külső transzport protokoll (pl. HTTP vagy MIME) által megadott információ nem áll rendelkezésre a kódolásra vonatkozóan, kritikus hibának számít, ha az entitás más kódolással van továbbítva az XML processzornak, mint amit az entitás kódolásdeklarációjában megadtunk, illetve ha nem UTF-8-ban van továbbítva egy olyan entitás, ahol nem adtunk meg sem Byte Order Markot, sem pedig kódolásdeklarációt. Vegyük észre, hogy tekintettel arra, hogy az ASCII az UTF-8 részhalmazát képezi, a szabályos ASCII entitásoknál szigorú értelemben nincs szükség entitásdeklarációra.

A TextDecl a külső entitások legelején kell szerepljen. Kritikus hibának számít, ha ettől eltérő helyen is előfordul.

Kritikus hibának számít, ha egy XML processzor olyan entitással találkozik, aminek a kódolását nem képes feldolgozni. Kritikus hibának számít, ha egy XML entitás esetén meghatároztuk (alapértelmezésként, kódolásdeklaráció használatával vagy más magasabb szintű protokoll segítségével), hogy milyen kódolással van megadva és mégis olyan bájtsorozatot tartalmaz, ami nem megengedett az adott kódolás esetén. Speciálisan kritikus hibának számít, ha egy UTF-8-ban kódolt entitás a Unicode 3.1 [Unicode3] által definiált szabálytalan kódsorozatot tartalmaz. Amennyiben a kódolást nincs magasabb szintű protokollal meghatározva kritikus hibának számít, ha az XML entitás nem tartalmaz kódolásdeklarációt és a tartalma nem érvényes sem UTF-8-ban sem pedig UTF-16-ban.

Példák kódolásdeklarációt tartalmazó szövegrész-deklarációkra:

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

4.4 Az entitások és a hivatkozások kezelése az XML processzorokban

Az alábbi táblázat összefoglalja, hogy milyen szövegkörnyezetben fordulhatnak elő karakter-hivatkozások, entitás-hivatkozások és elemzés nélküli entitásokra történő hivatkozások és minden egyes ilyen esetre megadja, hogy az XML processzoroknak hogyan KELL reagálniuk. A balszélső oszlopban található címkék jelzik a szövegkörnyezetet, amiben az hivatkozást felismerjük:

Hivatkozás content részben

hivatkozás bárhol egy elem start-tagje után és az end-tagje előtt. A content nemterminálisnak felel meg.

Hivatkozás attribútumértékben

hivatkozás vagy egy start-tag attribútumértékében, vagy pedig egy attribútum-deklaráció alapértelmezett értékében. Az AttValue nemterminálisnak felel meg.

Attribútumértékként történő előfordulás

Name név, azaz nem hivatkozás, ami vagy egy ENTITY típusúnak deklarált attribútum értékében van, vagy pedig egy ENTITIES típusúnak deklarált attribútum értékében a szóközzel elválasztott tokenek egyikeként.

Hivatkozás entitásértékben

hivatkozás paraméteres vagy belső entitás literális entitásértékén belül az entitás deklarációjában. Az EntityValue nemterminálisnak felel meg.

Hivatkozás DTD-ben

hivatkozás vagy a DTD belső vagy külső részhalmazában, de az EntityValue, AttValue, PI, Comment, SystemLiteral, PubidLiteral részeken kívül, vagy pedig egy figyelmen kívül hagyott feltételes szakaszban (lásd 3.4 Feltételes szakaszok).

.

Entitástípus Karakter
Paraméteres Belső általános Külső elemzett általános Elemzés nélküli
Hivatkozás content részben Nincs felismerés Behelyettesítés Behelyettesítés érvényesítés esetén Nem megengedett Behelyettesítés
Hivatkozás attribútumértékben Nincs felismerés Behelyettesítés literálban Nem megengedett Nem megengedett Behelyettesítés
Attribútumértékként történő előfordulás Nincs felismerés Nem megengedett Nem megengedett Értesítés Nincs felismerés
Hivatkozás entitásértékben Behelyettesítés literálban Figyelmen kívül hagyás Figyelmen kívül hagyás Hiba Behelyettesítés
Hivatkozás DTD-ben Behelyettesítés PE-ként Nem megengedett Nem megengedett Nem megengedett Nem megengedett

4.4.1 Nincs felismerés

A DTD-n kívül a % karakternek nincsen speciális jelentése, ezért a DTD-ben paraméterentitás-hivatkozásként felismert markupokat a tartalmi részben nem ismeri fel a processzor. Hasonlóképpen az elemzés nélküli entitások neveit sem ismeri fel, ha nem egy előzőleg megfelelően deklarált attribútum értékében fordulnak elő.

4.4.2 Behelyettesítés

[Definíció: Egy entitás akkor kerül behelyettesítésre, amikor a behelyettesítendő szövegrészét a processzor a hivatkozás helyett adja vissza és dolgozza fel a dokumentumnak azon a pontján, ahol a hivatkozást magát felismerte, éppen úgy, mintha a behelyettesítendő szövegrész a dokumentum részét képezte volna.] A behelyettesítendő szövegrész tartalmazHAT mind karakteres adatot, mind pedig markupot, kivéve a paraméterentitásokban előforduló markupokat, és ezeket a szokások módon KELL felismernie a processzornak. (A "AT&amp;T;" sztringet "AT&T;" sztringgé konvertálja a processzor és az így előálló és karaktert már ismeri fel entitáshivatkozás kezdeteként.) Egy karakterhivatkozás akkor behelyettesítésre, amikor a hivatkozás helyett a hivatkozott karaktert dolgozza fel a processzor.

4.4.3 Behelyettesítés érvényesítés esetén

Amikor az XML processzor egy elemzett entitásra történő hivatkozást talál, akkor ahhoz, hogy a dokumentum érvényességét ellenőrizni tudja, be KELL helyettesítse a hivatkozás behelyettesítendő szövegrészét a hivatkozás helyére. Ha külső entitásról van szó és a processzor nem akarja ellenőrizni az XML dokumentum érvényességét, akkor a processzornak nem kötelező behelyettesíteni az entitás behelyettesítendő szövegrészét, de be LEHETŐSÉGE VAN arra, hogy behelyettesítse. Ha egy érvényesítést nem végző processzor a behelyettesítendő szövegrészt nem helyettesíti be, akkor értesítenie KELL az alkalmazást arról, hogy talált egy entitást, amit azonban nem olvasott be.

Ez a szabály azon a felismerésen alapul, hogy az SGML és XML entitás-mechanizmusa által biztosított automatikus behelyettesítés elsősorban azt a célt szolgálta, hogy modularitást biztosítsunk a dokumentum megírása során, de nem feltétlenül alkalmas más alkalmazások számára, például dokumentumokban történő keresésre különösen nem. A keresőknek lehetőségük van arra ha egy külső elemzett entitásra történő hivatkozást találnak, hogy az entitás jelenlétét valamilyen formában grafikusan jelezzék és csak külön kérésre jelenítsék meg őket.

4.4.4 Nem megengedett

Az itt felsorolt esetek nem megengedettek és kritikus hibának számítanak:

  • ha egy elemzés nélküli entitásra történő hivatkozás fordul elő, kivéve ha ez a hivatkozás egy entitásdeklaráció EntityValue részében van.

  • ha a DTD-ben egy karakterhivatkozás vagy egy általános entitásra történő hivatkozás fordul elő, kivéve ha a hivatkozás EntityValue részben vagy AttValue részben fordul elő.

  • ha egy attribútumértékben egy külső entitásra történő hivatkozás fordul elő.

4.4.5 Behelyettesítés literálban

Ha egy attribútumértékben fordul elő entitáshivatkozás vagy literális entitásértékben fordul elő paraméteres entitásra történő hivatkozás, akkor a hivatkozás behelyettesítendő szövegrészét KELL feldolgozni a hivatkozás helyett úgy, mintha ez a szövegrész képezné a dokumentum részét a hivatkozás helyett azon a helyen, ahol a hivatkozást magát megtaláltuk, kivéve, hogy az egyszeres illetve dupla idézőjel karaktereket a behelyettesítendő szövegrészben normál adatkarakterként KELL kezelni és NEM SZABAD a literál végének tekinteni. A következő példa jólformált:

<!ENTITY % YN '"Yes"' >
<!ENTITY WhatHeSaid "He said %YN;" >

Ezzel szemben ez a példa nem jólformált:

<!ENTITY EndAttr "27'" >
<element attribute='a-&EndAttr;>

4.4.6 Értesítés

Ha egy elemzés nélküli entitás neve egy ENTITY vagy ENTITIES típusúnak deklarált attribútum értékében fordul elő tokenként, akkor a dokumentum érvényességét is ellenőrző processzoroknak értesíteniük KELL rendszerszintű és publikus azonosítók által megadott alkalmazást mind az entitásról, mind pedig a hozzárendelt jelölésmódról. (A publikus azonosító megadása opcionális.)

4.4.7 Figyelmen kívül hagyás

Ha egy entitásdeklaráció EntityValue részében egy általános entitásra történő hivatkozás fordul elő, akkor figyelmen kívül KELL hagyni és nem szabad megváltoztatni.

4.4.8 Belyettesítés PE-ként

Pontosan úgy, mint a külső elemzett entitások esetében, a paraméteres entitásokat is csak érvényesítés esetén kell behelyettesíteni. A DTD-ben találunk paraméteres entitásra történő hivatkozást és behelyettesítjük, akkor a behelyettesítendő szövegrésze elejéhez és végéhez is hozzá KELL adni egy-egy szóköz (#x20) karaktert és így kell behelyettesíteni. Ennek az a célja, hogy a paraméteres entitások behelyettesítendő szövegrésze a DTD-ben csak egész számú nyelvtani tokent tartalmazhasson. Ezt a módosítást NEM SZABAD alkalmazni azoknál a paraméteres entitásokra történő hivatkozásoknál, amelyek entitásértékekben fordulnak elő. Ez utóbbiakat a 4.4.5 Behelyettesítés literálban részben tárgyaltuk.

4.4.9 Hiba

Hibának minősül, ha egy elemzés nélküli entitásra történő hivatkozás egy entitásdeklaráció EntityValue részében fordul elő.

4.5 Entitás behelyettesítendő szövegrészének a létrehozása

Az entitások kezelésének a tárgyalásakor hasznos megkülönböztetni az entitás értékének két külünböző formáját. [Definíció: Belső entitások esetén a literális entitásérték az az idézőjeles szövegrész, ami az entitásdeklarációban található és ami a EntityValue nemterminálisnak felel meg.] [Definíció: Külső entitások esetén a literális entitásérték az entitás által tartalmazott szövegrész.] [Definíció: Belső entitások esetén a behelyettesítendő szövegrész az entitás tartalma, miután a karakterhivatkozásokat és a paraméteres entitásokra történő hivatkozásokat behelyettesítettük.] [Definíció: Külső hivatkozások esetén a behelyettesítendő szövegrész az entitás tartalma, miután a szövegdeklarációt levágtuk az elejéről (meghagyva minden esetleg white space-t, ami ezt körülvette), ha volt szövegdeklaráció benne. A karakterhivatkozásokat és a paraméteres entitásokra történő hivatozásokat itt nem helyettesítettük be.]

Abban a formában, ahogy a belső entitások deklarációjában (EntityValue) megtaláljuk őket, a literális entitásértékek még tartalmazHATnak karakter-hivatkozásokat, paraméteres entitásokra történő hivatkozásokat és általános entitásokra történő hivatkozásokat. Az ilyen hivatkozásokat a literális entitásértéknek teljes egészében tartalmaznia KELL, azaz nem tartalmazhatja a hivatkozásnak csak egy részét. A tulajdonképpeni behelyettesítendő szövegrésznek, amit behelyettesítünk (vagy literálban helyettesítünk be) a fent leírtaknak megfelelően, tartalmaznia KELL minden olyan paraméteres entitás behelyettesítendő szövegrészét, amire a literális entitásértékben hivatkozunk, és a karakter-hivatkozások helyén tartalmaznia KELL minden olyan karaktert, amire a literális entitásértékben karakter-hivatkozással hivatkoztunk. Azonban az általános entitásokra történő hivatkozásokat változatlan formában KELL tartalmaznia, anélkül hogy azokat feloldanánk. Például legyenek adottak a következő deklarációk:

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

Ekkor a "book" entitás behelyettesítendő szövegrésze:

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

Ha a "&rights;" általános entitásra történő hivatkozás be lenne helyettesítve, akkor a "&book;" hivatkozásnak vagy a dokumentum tartalmi részében, vagy egy attribútumértékben kellene lennie.

Ezek az egyszerű szabályok igen komplex összefüggésekben lehetnek egymással. A D Entitáshivatkozások és karakterhivatkozások feloldása részben egy bonyolultabb példa részletes tárgyalása is megtalálható.

4.6 Előredefinált entitások

[Definíció: Mind az entitáshivatkozások, mind a karakterhivatkozások használHATóak arra, hogy a csúcsos balzárójelet, az és jelet, illetve az egyéb határolókaraktereket más karakterekkel helyettesítsünk. Erre a célra a következő általános entitások vannak megadva: amp, lt, gt, apos, quot. Azonban használHATunk numerikus karakterhivatkozásokat is, amik azonnal be lesznek helyettesítve, amint a processzor megtalálja őket és karakteres adatként KELL kezelni őket, így például a "&#60;" és "&#38;" numerikus karakterhivatkozások használHATóak a < és & helyettesítésére, ha ezek a karakterek karakteres adatban fordulnak elő.]

Az XML processzoroknak fel KELL ismerniük ezeket az entitásokat függetlenül attól, hogy előzőleg deklarálva voltak vagy sem. Az interoperabilitás érdekében az érvényes XML dokumentumoknak használat előtt AJÁNLOTT deklaráni ezeket az entitásokat is hasonlóan az összes többi entitáshoz. Ha az lt vagy az amp entitásokat deklaráljuk, akkor ezeket olyan belső entitásként KELL deklarálni, amelynek a behelyettesítendő szövegrésze a megfelelő behelyettesítendő karakterre (azaz a kisebb-jelre vagy az és karakterre) vonatkozó karakterhivatkozás. A kétszeres behelyettesítés azért KÖTELEZŐ ezekben az esetekben, hogy a rájuk történő hivatkozások is jólformált dokumentumokat eredményezzenek. Ha az gt, az apos, vagy quot entitásokat deklaráljuk, akkor ezeket olyan belső entitásként KELL deklarálni, amelynek a behelyettesítendő szövegrésze a megfelelő behelyettesítendő karakter (vagy a megfelelő behelyettesítendő karakterre vonatkozó karakterhivatkozás, azonban ebben az esetben a kétszeres hivatkozás OPCiONÁLIS). Példák:

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

4.7 Jelölésmód-deklarációk

[Definíció: A jelölésmód határozza meg az elemzés nélküli entitás formátumának a nevét, illetve azon elemek formátumát, amelyeknek jelölésmód típusú attribútumuk van vagy azt az alkalmazást, amelyhez egy adott feldolgozó utasítás továbbítva lesz.]

[Definíció: A jelölésmód-deklaráció határozza meg a jelölésmód nevét. Ez a név használható fel azután az entitás-deklarációkban és az attribútumlista-deklarációkban, illetve attribútum-specifikációkban. Ezenfelül a jelölésmód-deklaráció meghatároz egy külső azonosítót is a jelölésmód számára, ami lehetővé teszi az XML processzor számára vagy a XML processzor kliensalkalmazásai számára, hogy az adott jelölésmódban megadott adatot feldolgozásához szükséges segédprogramokat megtalálják.]

Jelölésmód-deklaráció
[82]    NotationDecl    ::=    '<!NOTATION' S Name S (ExternalID | PublicID) S? '>' [VC: Egyedi jelölésmód-név]
[83]    PublicID    ::=    'PUBLIC' S PubidLiteral

Érvényességi feltétel: Egyedi jelölésmód-név

Egy adott Name NEM fordulHAT elő egynél több jelölésmód-deklarációban.

Az XML processzoroknak tovább KELL adniuk az alkalmazások számára az összes olyan jelölésmód nevét és külső azonosítóját, ami deklarálva volt és azután hivatkozás történt rá vagy egy attribútum-értékben, attribútum-definícióban vagy entitás-deklarációban. Ezen felül a külső azonosítót feloldHATják egy rendszer-azonosítóra vagy fájlnévre, illetve tetszőleges olyan információra, ami lehetővé teszi az alkalmazás számára, hogy az adott jelölésmóddal megadott adatot feldolgozza. (Azonban nem számít hibának, ha egy XML dokumentum olyan jelölésmódot deklarál, illetve olyan jelölésmódra hivatkozik, amelynek az adott rendszeren, ahol az XML processzor vagy az alkalmazás fut, nem állnak rendelkezésre a jelölésmód feldolgozásához szükséges segédprogramok.)

4.8 Dokumentumentitás

[Definíció: A dokumentumentitás az entitáshierarchia gyökere és kiindulási pontként szolgál az XML processzorok számára.] Jelen specifikáció nem határozza meg, hogy az XML processzorok milyen módon találják a dokumentumentitást. A többi entitástól eltérően a dokumentumentitásnak nincs neve és a processzor input-streamjére kerülhet anélkül is, hogy megadnánk a processzornak valamilyen azonosítóját.

5 Megfelelés a specifikációnak

5.1 Érvényességet ellenőrző és érvényességet nem ellenőrző processzorok

A specifikációnak megfelelő XML processzorok két osztályba sorolhatóak: az érvényességet ellenőrző processzorok és az érvényességet nem ellenőrző processzorok osztályába.

Az érvényességet ellenőrző és az érvényességet nem ellenőrző processzoroknak is jelezniük KELL a specifikáció által előírt jólformáltsági feltételek minden megsértését, ami a dokumentumentitásban vagy bármely más, általuk beolvasott elemzett entitásban előfordul.

[Definíció: Az érvényességet ellenőrző processzoroknak felhasználói kérésre jelezniük KELL minden, a DTD-ben megadott deklarációban leírt feltétel megsértését, illetve ha a jelen specifikációban szereplő érvényességi feltételek valamelyikét nem elégíti ki az XML dokumentum.] Ennek érdekében az érvényességet ellenőrző XML processzoroknek be KELL olvasni és fel KELL dolgozni a teljes DTD-t és minden a dokumentumból hivatkozott külső elemzett entitást.

Az érvényességet nem ellenőrző processzoroknak csak a dokumentumentitást KELL ellenőrizniük, beleértve ebbe a teljes belső DTD részt, és csak a jólformáltságot KELL ellenőriziük. [Definíció: Annak ellenére, hogy az érvényességet nem ellenőrző processzoroknak nem kell ellenőrizni a dokumentum érvényességét, fel KELL dolgozniuk minden deklarációt, amit beolvasnak a belső DTD részből vagy általuk beolvasott paraméterentitásból egészen az első olyan paraméterentitás-hivatkozásig, amit már nem olvasnak be. Azaz fel KELL használniuk az így beolvasott deklarációkban található információt az attribútumértékek normalizálásakor, a belső entitások behelyettesítendő szövegrészének a behelyettesítésekor, illetve az alapértelmezett attribútumértékek meghatározásakor.] Eltekintve attól az esettől, ha standalone="yes", az érvényességet nem ellenőrző XML processzornak NEM SZABAD feldolgozni azokat az entitás-deklarációkat vagy attribútumlista-deklarációkat, amelyeket azután talál meg, hogy már talált egy olyan paraméterentitásra történő hivatkozást, amit nem olvasott be, mivel a be nem olvasott entitás tartalmazhatott olyan deklarációkat, amelyek felírták az eddigieket. standalone="yes" esetén a processzornak fel KELL dolgozni ezeket a deklarációkat is.

Vegyük észre, hogy ha az érvényességet nem ellenőrző processzor egy érvénytelen dokumentumot dolgoz fel, akkor az alkalmazás inkonzisztens információkat kaphat. Például elképzelhető, hogy a dokumentumban vannak olyan részek, amelyek nem teljesítik az egyediségre vonatkozó feltételeket, azaz például egynél több elemnél is előfordul ugyanaz az id, vagy ugyanazzal a névvel többször is deklarálva van több különböző elem vagy jelölésmód is, stb. Ezekben az esetekben az elemzést végző alkalmazás működése definiálatlan abban az értelemben, hogy nem lehet tudni, hogy ezekből az információkból mit továbbít az alkalmazásnak.

5.2 XML processzorok használata

Az érvényességet ellenőrző XML processzorok működése igen nagymértékben előre meghatározható. Be kell olvasniuk a dokumentum egészét és jelenteniük kell a jólformáltsági feltételek és az érvényességi feltételek minden megsértését. Kevesebbet követelünk meg az érvényességet nem ellenőrző processzoroktól: csak a dokumentumentitást kell beolvasniuk, a dokumentum más részeit nem. Ennek a ténynek két következménye is fontos lehet az XML processzorok használó számára:

Annak érdekében, hogy a különböző XML processzorok közötti interoperabilitást minél megbízhatóbbá tegyük, azoknak az alkalmazásoknak, amelyek az érvényességet nem ellenőrző processzorokat használnak, NEM AJÁNLOTT az általuk használt processzor olyan tulajdonságait kihasználni, amelyeket a specifikáció nem követelt meg tőlük. Azoknak az alkalmazásoknak pedig, amelyek a DTD használatára alapulnak, de nem igénylik az érvényesség ellenőrzését (ilyen lehet például az alapértelmezett attribútumok deklarációja és az olyan belső entitások deklarációja, amelyeket külső entitásokban vannak, illetve lehetnek), az érvényességet ellenőrző processzorokat AJÁNLOTT használni.

6 Jelölés

Az XML jelen specifikációban használt formális nyelvtana egy egyszerű Extended Backus-Naur Form (EBNF) jelölés használatával van megadva. A nyelvtan minden egyes szabálya egy szimbólumot definiál a következő formában:

szimbólum ::= kifejezés

A szimbólumokat nagy kezdőbetűvel írjuk, ha a reguláris nyelv kezdőszimbólumairól van szó, egyébként pedig kis kezdőbetűvel. A literális stringeket idézőjelek közé tesszük.

A szabály jobboldalán lévő kifejezésen belül a következő kifejezéseket használjuk a karakterek stringekre történő illesztésekor:

#xN

ahol N hexadecimális egész szám, a kifejezés arra a karakterre illeszkedik amelynek az ISO/IEC 10646 által definiált száma (code point) N. A vezető nullákat a #xN formájú kifejezésekben nem vesszük figyelembe.

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

illeszkedik bármely Char karakterre, amelynek az értéke a megadott határok által definiált zárt intervallumba esik (azaz beleértjük a két szélső értéket is).

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

illeszkedik bármely Char karakterre, amelynek az értéke a felsorolt karakterek között megtalálható. A felsorolások és a zárt intervallumok egyetlen szögletes zárójelpáron belül felváltva is előfordulhatnak.

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

illeszkedik bármely Char karakterre, amelynek az értéke a megadott intervallumon kívül esik.

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

illeszkedik bármely Char karakterre, amelynek az értéke nem fordul elő a megadott karakterek között. A nem megengedett karaktereket megadó felsorolások és zárt intervallumok egyetlen szögletes zárójelpáron belül felváltva is előfordulhatnak.

"string"

illeszkedik bármely olyan stringliterálra, amely illeszkedik a dupla idézőjelek között megadott stringliterálra.

'string'

illeszkedik bármely olyan stringliterálra, amely illeszkedik az egyszeres idézőjelek között megadott stringliterálra.

Komplexebb minták illeszkedéséhez a fentebb megadott szimbólumokat lehet egymássak kombinálni is a következők szerint where A and B represent simple expressions:

(kifejezes)

a kifejezes önálló egység és az alábbi listában leírt módokon lehet belőle összetételeket képezni.

A?

illeszkedik A-ra vagy semmire; azaz A opcionális.

A B

illeszkedik A-ra és az azt követő B-re. Ennek az operációnak magasabb a precedenciája, mint az alternatívák közül történő választásnak, ezért a A B | C D kifejezés megegyezik a (A B) | (C D) kifejezéssel.

A | B

illeszkedik A-ra vagy B-re.

A - B

illeszkedik bármely olyan stringre, ami illeszkedik A-ra, de nem illeszkedik B-re.

A+

illeszkedik az A egy vagy több előfordulására. A konkatenációnak magasabb a precedenciája, mint az alternatívák közül történő választásnak, ezért a A+ | B+ kifejezés megegyezik a (A+) | (B+) kifejezéssel.

A*

illeszkedik az A nulla, egy vagy több előfordulására. A konkatenációnak magasabb a precedenciája, mint az alternatívák közül történő választásnak, ezért a A* | B* kifejezés megegyezik a (A*) | (B*) kifejezéssel.

A generálószabályokban használt további jelölések:

/* ... */

megjegyzés.

[ wfc: ... ]

jólformáltsági feltétel; meghatározza a jólformált dokumentumokra vonatkozó, az adott generálószabályhoz kapcsolódó feltétel nevét.

[ vc: ... ]

érvényességi feltétel; meghatározza az érvényes dokumentumokra vonatkozó, az adott generálószabályhoz kapcsolódó feltétel nevét.

A Hivatkozások

A.1 Normatív hivatkozások

IANA-CHARSETS
(Internet Assigned Numbers Authority) Official Names for Character Sets, ed. Keld Simonsen et al. (Lásd: http://www.iana.org/assignments/character-sets.)
IETF RFC 2119
IETF (Internet Engineering Task Force). RFC 2119: Key words for use in RFCs to Indicate Requirement Levels. Scott Bradner, 1997. (Lásd: http://www.ietf.org/rfc/rfc2119.txt.)
IETF RFC 2396
IETF (Internet Engineering Task Force). RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax. T. Berners-Lee, R. Fielding, L. Masinter. 1998. (Lásd: http://www.ietf.org/rfc/rfc2396.txt.)
IETF RFC 2732
IETF (Internet Engineering Task Force). RFC 2732: Format for Literal IPv6 Addresses in URL's. R. Hinden, B. Carpenter, L. Masinter. 1999. (Lásd: http://www.ietf.org/rfc/rfc2732.txt.)
IETF RFC 3066
IETF (Internet Engineering Task Force). RFC 3066: Tags for the Identification of Languages, ed. H. Alvestrand. 2001. (Lásd: http://www.ietf.org/rfc/rfc3066.txt.)
ISO/IEC 10646
ISO (International Organization for Standardization). ISO/IEC 10646-1:2000. Information technology — Universal Multiple-Octet Coded Character Set (UCS) — Part 1: Architecture and Basic Multilingual Plane és ISO/IEC 10646-2:2001. Information technology — Universal Multiple-Octet Coded Character Set (UCS) — Part 2: Supplementary Planes. Ezeket időről időre kiegészítik, illetve új kiadással helyettesítik vagy újabb részekkel bővítik ki. [Geneva]: International Organization for Standardization. (A legújabb verziót lásd: http://www.iso.ch/.)
ISO/IEC 10646:2000
ISO (International Organization for Standardization). ISO/IEC 10646-1:2000. Information technology — Universal Multiple-Octet Coded Character Set (UCS) — Part 1: Architecture and Basic Multilingual Plane. [Geneva]: International Organization for Standardization, 2000.
Unicode
The Unicode Consortium. The Unicode Standard, Version 2.0. Reading, Mass.: Addison-Wesley Developers Press, 1996.
Unicode3
The Unicode Consortium. The Unicode Standard, Version 3.2, amit a The Unicode Standard, Version 3.0 (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5) definiál és a Unicode Standard Annex #27: Unicode 3.1 (http://www.unicode.org/reports/tr27/) és a Unicode Standard Annex #28: Unicode 3.2 (http://www.unicode.org/reports/tr28/) egészít ki.

A.2 Egyéb hivatkozások

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

B Karakterosztályok

A Unicode szabványban definiált jellemzőknek megfelelően a karaktereket a következőképpen osztályozzuk: bázis (base) karakterek (többek között ezek tartalmazzák a latin ábécé alfabetikus karaktereit), ideografikus karakterek és összetett (combining) karakterek (többek között ez az osztály tartalmazza a legtöbb diacriticát). A számjegyeket (digit) és az extendereket szintén megkülönböztetjük.

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

Az itt definiált karakterosztályok a Unicode 2.0 karakter-adatbázisából a következőképpen származtathatóak:

  • A nevek első karakterének a következő kategóriák egyikébe kell esniük: Ll, Lu, Lo, Lt, Nl.

  • A nevek első karaktertől eltérő karaktereinek a következő kategóriák egyikébe kell esniük: Mc, Me, Mn, Lm, or Nd.

  • A kompatibilitási területre eső karakterek (azaz azok a karakterek, amelyeknek a kódja #xF900-nál nagyobb és #xFFFE-nél kisebb) nem megengedettek az XML nevekben.

  • Azok a karakterek nem megengedettek, amelyeknek betűtípus szerinti vagy kompatibilitási dekompozíciója van (azaz azok a karakterek, amelyek rendelkeznek "compatibility formatting tag"-gel az adatbázis 5. mezőjében -- amit az jelöl, hogy az 5. mező "<" karakterrel kezdődik).

  • A következő karaktereket úgy kezeljük, mint a nevek kezdő karaktereit, ahelyett, hogy normál névkaraktereknek tekintenénk őket, mert a property fájl alfabetikus karakterekként osztályozza őket: [#x02BB-#x02C1], #x0559, #x06E5, #x06E6.

  • A #x20DD-#x20E0 közötti karaktereket (a Unicode 2.0 5.14 szakaszának megfelelően) kizárjuk.

  • A #x00B7 karaktert extenderként osztályozzuk, mert a property lista így azonosítja.

  • A #x0387 karaktert hozzáadjuk a névkarakterekhez, mert a #x00B7 karakter vele kanonikusan ekvivalens.

  • A ':' és '_' karakterek használatát megengedjük nevek első karaktereként.

  • A '-' és '.' karakterek használatát megengedjük névkarakterként.

C XML és SGML (nem normatív)

Az XML-t úgy tervezték meg, hogy az SGML részét képezze, azaz minden XML dokumentumnak meg kell felelnie az SGML dokumentumokkal szemben támasztott követelményeknek is. Az XML és az SGML részletes összehasonlításáról lásd [Clark], illetve ugyanitt találunk információkat azokról a megszorításokról, amelyeket az XML az SGML által elírtakon felül még megkövetel.

D Entitáshivatkozások és karakterhivatkozások feloldása (nem normatív)

Ez a függelék olyan példákat tartalmaz, amelyek azt illusztrálják, hogyan kell a 4.4 Az entitások és a hivatkozások kezelése az XML processzorokban részben specifikált entitáshivatkozásokat és karakterhivatkozásokat felismerni és feloldani.

Ha a DTD a következő deklarációt tartalmazza

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

akkor az XML processzor a karakterhivatkozásokat az entitásdeklaráció elemzésekor fel fogja ismerni a karakterhivatkozásokat és ki fogja értékelni őket, még mielőtt eltárolná a megadott stringet az "example" entitás értékeként:

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

Az "&example;" entitásra történő hivatkozás ezek után azt fogja eredményezni, hogy a szöveg újra elemzésre kerül és ekkor a p elem start-tagjét és end-tagjét is felismeri a processzor, illetve a három, a szövegben szereplő hivatkozást is felismeri és kiértékeli és így a p elemnek a tartalma már tisztán adat lesz, azaz már nem tartalmaz határoló jeleket vagy markupot:

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

A következő, összetettebb példa teljes egészében illusztrálni fogja ezeket a szabályokat és a hatásukat. Ebben a példában a sorszámok csak a hivatkozás megkönnyítése céljából szereplnek, nem részei a példának.

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>

Ez a példa tehát a következőket eredményezi:

E Determinisztikus tartalommodellek (nem normatív)

Amint már a 3.2.1 Elem-tartalom részben is említettük, az elemtípus-deklarációk által megadott tartalommodelleknek determinisztikusaknak kell lenniük. Ez követelmény az SGML-lel való kompatibilitás érdekében került bele a specifikációba. (Az SGML a determinisztikus tartalommodelleket "egyértelmű" tartalommodelleknek nevezi.) Az SGML rendszerek használatával készített XML processzorok a nemdeterminisztikus tartalommodelleket hibás modellekként kezelhetik.

Például a ((b, c) | (b, d)) tartalommodell nemdeterminisztikus, mert ha feltesszük, hogy a tartalom egy b-vel kezdődik, akkor az XML processzor nem tudja eldönteni, hogy ez a b a modellben melyik b-re illeszkedik. Csak akkor tudná eldönteni, ha még egy elemet előre beolvasna a b után. Ebben az esetben a két b-re történő hivatkozást egyetlen hivatkozással lehet helyettesíteni, ami a (b, (c | d)) modellt eredményezné. Most a b egyértelműen illeszkedik a tartalommodellben szereplő egyetlen b elemre, így a processzornak nem kell előre beolvasni a b után következő elemet, hogy eldöntse, melyik illeszkedést alkalmazza, a b beolvasása után pedig vagy a c, vagy pedig a d szintén egyértelműen fog illeszkedni.

Formálisan: a tartalommodellból a szokásos algoritmusok használatával véges automatát lehet konstruálni. Ilyen algoritmust pl. Aho, Sethi, és Ullman [Aho/Ullman] könyvének 3.9 szakaszában találunk a 3.5 pont alatt. A legtöbb ilyen algoritmus úgy működik, hogy a reguláris kifejezés minden pozíciójához (pozició alatt azt értve, hogy a kifejezés olvasásában éppen hol tartunk) meghatározza azon elemek halmazát, amelyek az olvasás során következő elemként előfordulhatnak. Ha egy adott pozícióban a lehetséges következő elemek között egy adott elemtípus neve kétszer is előfordulna, az hibát eredményezne a tartalommodellben és ezért a processzor hibaként jelezhetné az alkalmazásnak.

Vannak olyan algoritmusok, amelyek lehetővé teszik nemdeterminisztikus tartalommodellek ekvivalens determinisztikus tartalommodellekké történő átalakítását, azonban ezek az algoritmusok sem működnek minden nemdetermisztikus esetre. Lásd: Brüggemann-Klein 1991 [Brüggemann-Klein].

F A karakterkódolás automatikus felismerése (nem normatív)

Az XML karakterkódolásának a deklarációja úgy működik, mintha minden entitást megcímkéztünk volna vele, és ez jelzi, hogy az adott entitás milyen karakterkódolást használ. Azonban még mielőtt az XML processzor beolvashatná ezt az információt, már tudnia kellene, hogy ez az információ milyen karakterkódolás használatával van megadva. De ezt pedig csak a beolvasás után tudná meghatározni. Általános esetben ez egy reménytelen helyzet. Azonban az XML esetében mégsem teljesen reménytelen a dolog, mert az XML két értelemben is megszorításokat tesz az általános esethez képest: egyrészről minden implementációról feltételezzük, hogy csak véges számú karakterkódolást ismer, illetve használ, másrészről pedig a karakterkódolás deklarációjának a helye és annak tartalma is meg van határozva, lehetővé téve ezáltal, hogy az entitásokban használt karakterkódolást automatikusan felismerjük. Ezenfelül sokszor egyéb információk is rendelkezésünkre állnak az XML adatstreamjén kívül is. Két esetet lehet megkülönböztetni attól függően, hogy az XML entitáson kívül a processzor még kap-e további (külső) információkat. Tekintsük először azt az esetet, amikor nem kap ilyen információt.

F.1 Felismerés külső kódolási információ használata nélkül

Mivel nem minden olyan XML entitásnak egy XML karakterkódolási deklarációval kell kezdődnie, amihez nem társul külső információ a használt kódolásra vonatkozóan, illetve ami nem UTF-8 vagy UTF-16 használatával van kódolva, és tekintetbe véve, hogy az XML karakterkódolási deklarációja mindig a '<?xml' karakterekkel kezdődik, ezért minden, a specifikációnak megfelelő processzor meg tudja határozna az input első kettő, illetve első négy octetjének a beolvasása után, hogy a következő esetek közül melyik áll fenn. Az alábbi lista tanulmányozásakor segítségünkre lehet, ha tudjuk, hogy UCS-4-ben a '<' karakter "#x0000003C" és a '?' karakter "#x0000003F", illetve, hogy a Byte Order Mark, amit az UTF-16 adatstreamek előírnak "#xFEFF". A ## jelölés helyén tetszőleges byteérték állhat, kivéve a két egymást követő nullát, azaz a ## nem lehet 00.

Byte Order Mark használata esetén:

00 00 FE FF UCS-4, big-endian gép (1234 sorrend)
FF FE 00 00 UCS-4, little-endian gép (4321 sorrend)
00 00 FF FE UCS-4, általában nem használt octet sorrend (2143)
FE FF 00 00 UCS-4, általában nem használt octet sorrend (3412)
FE FF ## ## UTF-16, big-endian
FF FE ## ## UTF-16, little-endian
EF BB BF UTF-8

Byte Order Mark használata nélkül:

00 00 00 3C USC-4 vagy más 32 bites kódolási egységeket használó kódolás, ahol az ASCII karakterek ASCII értékekként vannak elkódolva big-endian (1234) vagy little-endian (4321) sorrendben, vagy az általában nem használt (2143 vagy 3412) bytesorrendekben. A karakterkódolás deklarációját be kell olvasni annak meghatározásához, hogy a lehetséges 32 bites kódolások közül (beleértve az USC-4-et is) melyiket kell alkalmazni.
3C 00 00 00
00 00 3C 00
00 3C 00 00
00 3C 00 3F UTF-16BE, big-endian ISO-10646-UCS-2 vagy más 16 bites kódolási egységeket és big-endian sorrendet használó kódolás, ahol az ASCII karakterek ASCII értékekként vannak elkódolva (a karakterkódolás deklarációját be kell olvasni a konkrét kódolás meghatározásához)
3C 00 3F 00 UTF-16LE, little-endian ISO-10646-UCS-2 vagy más 16 bites kódolási egységeket és little-endian sorrendet használó kódolás, ahol az ASCII karakterek ASCII értékekként vannak elkódolva (a karakterkódolás deklarációját be kell olvasni a konkrét kódolás meghatározásához)
3C 3F 78 6D UTF-8, ISO 646, ASCII, az ISO 8859 bizonyos részei, Shift-JIS, EUC, vagy bármely más 7 bites, 8 bites vagy változó hosszúságú kódolási egységeket használó kódolás, ami garantálja, hogy az ASCII karakterek a szokásos pozíciójukban, bitszélességben és értékben vannak megadva; a konkrét karakterkódolási deklarációt be kell olvasni annak meghatározásához, hogy a fenti esetek közül melyik alkalmazandó, de tekintetbe véve, hogy a fenti kódolások mind ugyanazokat a bitmintákat használják a megfelelő ASCII karakterek kódolására, ezért magát a karakterkódolás deklarációját még a konkrét kódolás ismerete nélkül is be lehet olvasni.
4C 6F A7 94 EBCDIC (bizonyos verziókban; a teljes kódolási deklarációt be kell olvasni annak eldöntéséhez, hogy melyik kódpage-t kell használni.)
Egyéb UTF-8 karakterkódolási deklaráció nélkül vagy pedig a az adatstream rosszul van jelezve (pl. hiányzik a szükséges karakterkódolás-deklaráció), hibás, töredezett vagy valamilyen wrapperbe van csomagolva.

Megjegyzés:

A fenti esetek közül azon esetekben, amikor a karakterkódolás deklarációjának a beolvasására nincs szükség a használt kódolás megállapításához, a 4.3.3 szakasz ettől a ténytől függetlenül megköveteli, hogy ha meg van adva karakterkódolás-deklaráció, akkor azt a processzor beolvassa és leellenőrizze, hogy az ebben megadott név megegyezik-e a használt kódolás nevével. Az is elképzelhető, hogy olyan új karakterkódolás lesz a jövőben kifejlesztve, ami a karakterkódolás-deklaráció beolvasását és használatát ezen esetek valamelyikében mégis szükségessé teszi majd annak ellenére, hogy jelenleg még megállapítható a használt kódolás a deklaráció beolvasása nélkül is.

Az automatikus felismerésnek ezen a szintjén elegendő beolvasni az XML karakterkódolás-deklarációját és kiértékelni, hogy ebben mi a karakterkódolás azonosítója. Az azonosító kiértékelésére azonban még mindenképpen szükség van annak eldöntéséhez, hogy a fenti kódolási osztályokon belül is meg tudjuk határozni, melyik konkrét kódolást kell alkalmazni az adott osztályon belül. (Például, hogy meg tudjuk mondani, hogy a 8859 bizonyos részeit vagy pedig az UTF-8-at kell alkalmazni, vagy hogy meg tudjuk mondani, hogy az EBCDIC melyik kódpage-ét kell használni, stb.)

Mivel a karakterkódolás-deklaráció által használt karakterek csak az ASCII által is biztosított karakterkészletből származhatnak, akárhogy is vannak kódolva, ezért a processzor be tudja olvasni a karakterkódolás-deklarációt, ha már azt meghatározta, hogy a fenti kódolási osztályok közül melyik csoporton belül keresse a konkrét kódolást. Tekintettel arra, hogy a gyakorlatban a széleskörben elterjedt és használt karakterkódolások mind a fenti karakterosztályok valamelyikébe esnek bele, ezért az XML karakterkódolás-deklarációja meglehetősen megbízható módon tudja jelezni számunkra a karakterkódolást még azokban az esetekben is, amikor az operációs rendszer vagy a magasabb szintű átviteli protokoll által biztosított külső információ a karakterkódolásra vonatkozóan nem megbízható. Az UTF-7-hez hasonló karakterkódolásokat azonban, amelyek az ASCII értékkel rendelkező byte-okat más célra is használhatják, elképzelhető, hogy nem sikerül megbízhatóan detektálni.

Miután a processzor felismerte az éppen használatban lévő karakterkódolást, azután már képes az adott kódolásnak megfelelően működni függetlenül attól, hogy ezt külön input rutinok meghívásával oldja meg vagy az input minden karakterére valamilyen konverziós függvényt hív meg.

Hasonlóan bármely más olyan rendszerhezn, ami saját magát azonosítja, az XML karakterkódolás-deklaráció sem fog működni, ha egy szoftver megváltoztatja az entitás karakterkészletét vagy kódolását, de elfelejti ennek megfelelően aktualizálni a karakterkódolás-deklarációt. A karakterkódolást végző rutinokat készítő programozóknak biztosítaniuk kell, hogy az entitás azonosítására használt külső és belső információk pontosak legyenek.

F.2 Külső kódolási információ használata esetén alkalmazandó prioritási sorrend

A másik lehetséges eset, hogy az XML entitáshoz valamilyen kódolási információ is meg van adva. Ez az eset például fájlrendszerek vagy bizonyos hálózati protokollok esetén fordulhat elő. Amikor több információforrás is rendelkezésre áll a használt kódolásra vonatkozóan, akkor egymáshoz viszonyított prioritási sorrendjének a meghatározására, illetve esetleges ellentmondások feloldására alkalmazandó eljárás megadására is szükség van, mégpedig az XML továbbítására használt magasabb szintű protokoll részeként. Részletek erre vonatkozóan a [IETF RFC 3023] dokumentumban, illetve ezen dokumentum esetleges újabb verzióiban találhatóak, mivel ez a dokumentum definiálja a text/xml és a application/xml MIME típusokat, illetve további útmutatót is ad ezek használatára vonatkozóan. Az interoperabilitás érdekében azonban érdemes a következő szabályt betartani.

  • Ha egy XML entitás fájlban található, akkor a Byte-Order Mark-ot és (amennyiben létezik) a karakterkódolás deklarációját használjuk a karakterkódolás meghatározására.

G W3C XML Munkacsoport (nem normatív)

Jelen specifikációt a W3C XML Munkacsoport (Working Group - WG) készítette el és engedélyezte publikálásra. Az, hogy a WG publikálásra alkalmasnak találta a specifikációt nem jelenti azt, hogy minden WG tag az engedélyezés mellett szavazott. Az XML WG jelenlegi és korábbi résztvevői:

  • Jon Bosak, Sun (elnök)
  • James Clark (technikai vezető)
  • Tim Bray, Textuality and Netscape (XML társszerkesztő)
  • Jean Paoli, Microsoft (XML társszerkesztő)
  • C. M. Sperberg-McQueen, U. of Ill. (XML társszerkesztő)
  • Dan Connolly, W3C (W3C kapcsolattartó)
  • Paula Angerstein, Texcel
  • Steve DeRose, INSO
  • Dave Hollander, HP
  • Eliot Kimber, ISOGEN
  • Eve Maler, ArborText
  • Tom Magliery, NCSA
  • Murray Maloney, SoftQuad, Grif SA, Muzmo és Veo Systems
  • MURATA Makoto (FAMILY Given), Fuji Xerox Information Systems
  • Joel Nava, Adobe
  • Conleth O'Connell, Vignette
  • Peter Sharpe, SoftQuad
  • John Tigue, DataChannel

H W3C XML Core Munkacsoport (nem normatív)

Jelen specifikáció harmadik kiadását a W3C XML Core Munkacsoport (Working Group - WG) készítette el. Jelen kiadás publikálásakor a WG-ban részt vettek:

  • Leonid Arbouzov, Sun Microsystems
  • Mary Brady
  • John Cowan
  • John Evdemon, Microsoft
  • Andrew Fang, Arbortext
  • Paul Grosso, Arbortext (társelnök)
  • Arnaud Le Hors, IBM
  • Dmitry Lenkov, Oracle
  • Anjana Manian, Oracle
  • Glenn Marcy, IBM
  • Jonathan Marsh, Microsoft
  • Sandra Martinez, NIST
  • Liam Quin, W3C (személyzeti kapcsolattartó)
  • Lew Shannon
  • Richard Tobin, University of Edinburgh
  • Daniel Veillard
  • Norman Walsh, Sun Microsystems (társelnök)
  • François Yergeau (a harmadik kiadás szerkesztője)

I Megjegyzések a dokumentum elkészítésével kapcsolatban (nem normatív)

Jelen harmadik kiadás az XMLspec DTD, v2.5 egy módosított verziójában készült. Az angol nyelvű verzió XHTML verziói az xmlspec.xsl, diffspec.xsl és REC-xml-3e.xsl XSLT stylesheet-ek kombinációjával készültek.