Det här är en svensk översättning av W3Cs specifikation XML 1.0 (Third Edition) från den 4 februari 2004. Syftet med översättningen är att stödja användningen av XML i Sverige. Arbetet har gjorts inom XML Sweden. Erik Mjöberg har gjort översättningsarbetet, som granskats av Gustaf Liljegren och Jan Östberg.

Översättningen utgår från vår tidigare översättning av Extensible Markup Language (XML) 1.0. Därefter har översättningen uppdaterats med avseende på W3Cs rättningar av XML 1.0 i XML 1.0 Specification Errata och XML 1.0 Second Edition Specification Errata. Några få begrepp och uttryck på svenska har modifierats i samband med detta arbete. Översättningen har därmed bibehållit formateringen från Extensible Markup Language (XML) 1.0, men har updaterats till XHTML.

Observera att endast originaldokumentet på engelska har ett normativt värde. Origialdokumentet finns på http://www.w3.org/TR/2004/REC-xml- 20040204, och denna svenska översättning på http://www.xml.se/xml/REC-xm l-2004-02-04-sv.html. Notera att beteckningssättet i de definitioner som anges med hakparanteser och nummer, t.ex. [1], finns förklarat i avsnittet "6 Beteckningssätt" sist i specifikationen.

Översättningen kan innehålla översättningsfel. Vi har emellertid försökt att vara så trogna det engelska originalet som möjligt och samtidigt försökt att hitta bra svenska ord för nya begrepp. Översättningskommentarer har vi lagt inom hakparanteser ["så här"]. Om vi har velat komplettera den svenska översättningen med originalorden på engelska har vi angett detta i parenteser med citationstecken ("like this"). Synpunkter på den svenska översättningen välkomnas på [email protected]. En lista på uppdateringar av den svenska översättningen finns i filen logg.xml.

Översättningen är upphovsrättsligt skyddad. Copyright © AB XML Sweden. Dokumentet får fritt kopieras om den upphovsrättsliga informationen följer med.

Sammanfattning

Detta dokument är en fullständig beskrivning av Extensible Markup Language (XML), som är en delmängd ("subset") av SGML. Syftet med standarden är att möjliggöra för SGML att användas på webben på samma sätt som nu är möjligt för HTML. XML har utformats för att vara lätt att tillämpa och fungera tillsammans med både SGML och HTML.

Status för detta dokument

Detta avsnitt beskriver statusen för detta dokument då det publicerats. Andra dokument kan övertrumfa detta dokument. En lista på altuella W3C W3C-publikationer och den senaste revisionen av denna tekniska rapport finns i W3C technical reports index på http://www.w3.org/TR/.

Detta dokument är en Rekommendation från W3C. Det har granskats av medlemmar i W3C och och andra intresserade och har ratifierats av W3Cs Director som en W3C-rekommendation. Det är ett stabilt dokument som kan användas som referensmaterial eller citeras som en normativ referens från andra dokument. W3Cs roll är nu att dra uppmärksamhet till specifikationen och att främja en bred användning, något som kommer att förbättra funktionaliteten och utbytet på webben.

Detta dokument specificerar en syntax skapad som en understandard till en existerande, vida använd internationell standard för textbehandling (Standard Generalized Markup Language, ISO 8879:1986(E) i en korrigerad version) för användning på Webben. Det har tagits fram av W3C XML Activity, vars verksamhet återfinns på http://www.w3.org/XML. Den engelska versionen av denna specifikation är den enda normativa versionen. För översättningar av detta dokument, se http://www.w3.org/2003/03/Translations/byTechnology?technology=REC-xml.

Denna tredje upplaga är inte en ny version av XML (först publiserad den 10 februari 1998). För att underlätta för läsare, lyfter den in ändringarna som dikterats av de samlade felen (tillgängliga på http://www.w3.org/XML/xml-19980210-errata) i andra upplagan av XML 1.0, daterad den 6 oktober 2000. Dessutom har uppmärkning införts i viktiga delar av specifikationens beskrivning, för att klargöra när beskrivande nyckelord som MÅSTE, BÖR och KAN används på ett formellt sätt definierat i [IETF RFC 2119]. För att underlätta för läsare, finns även en XHTML-version med färgkodade revisionsangivelser; en version som särskilt anger varje ändring som gjorts på grund av ett fel publicerat i fellistan, tillsammans med en länk till det akutella felet i listan. De flesta av felen i listan är orsaker till förändringar.

En implementeringsrapport återfinns på http://www.w3.org/XML/2003/09/xml10-3e-implementation.html.

Dokumentation av upphovsrättsfrågor som kan vara aktuella för denna rekommendation återfinns på the Working Group's offentliga IPR disclosure sida.

Rapporter om fel i det engelska originalet till detta dokument görs till [email protected]; arkiv finns tillgängliga. Fellistan för denna tredje upplaga återfinns på http://www.w3.org/XML/xml-V10-3e-errata.

En testserie upprätthålls som hjälp för att fastställa konformitet med denna specifikation.

Extensible Markup Language (XML) 1.0

Innehållsförteckning

1 Inledning
    1.1 Ursprung och mål
    1.2 Terminologi
2 Dokument
    2.1 Välformade XML-dokument
    2.2 Tecken
    2.3 Vanliga syntaxkonstruktioner
    2.4 Teckendata och uppmärkning
    2.5 Kommentarer
    2.6 Processinstruktioner
    2.7 CDATA-avsnitt
    2.8 Prolog och dokumenttypsdeklaration
    2.9 Fristående dokumentdeklaration
    2.10 Tomrumshantering
    2.11 Hantering av radbrytning
    2.12 Språkidentifiering
3 Logiska strukturer
    3.1 Starttaggar, sluttaggar och tomelementstaggar
    3.2 Elementtypsdeklarationer
        3.2.1 Elementinnehåll
        3.2.2 Blandat innehåll
    3.3 Attributlist-deklarationer
        3.3.1 Attributtyper
        3.3.2 Ingångsvärden för attribut
        3.3.3 Normalisering av attributvärden
    3.4 Villkorliga urval
4 Fysiska strukturer
    4.1 Tecken- och entitetsanrop
    4.2 Entitetsdeklarationer
        4.2.1 Interna entiteter
        4.2.2 Externa entiteter
    4.3 Analyserade entiteter
        4.3.1 Textdeklarationen
        4.3.2 Välformade, analyserade entiteter
        4.3.3 Teckenkoder i entiteter
    4.4 Bearbetning av entiteter och anrop i en XML-tolk
        4.4.1 Inte accepterad
        4.4.2 Infogad
        4.4.3 Infogat vid validering
        4.4.4 Förbjudet
        4.4.5 Infogad inom anföringstecken
        4.4.6 Underrätta
        4.4.7 Överhoppat
        4.4.8 Infogad som PE
        4.4.9 Fel
    4.5 Konstruktion av ersättningstext för interna entiteter
    4.6 Fördefinierade entiteter
    4.7 Notationsdeklarationer
    4.8 Dokumententitet
5 Konformitet
    5.1 Validerande respektive icke-validerande XML-tolkar
    5.2 Användning av XML-tolkar
6 Beteckningssätt

Bilagor

A Referenser
    A.1 Normativa referenser
    A.2 Andra referenser
B Teckenklasser
C XML och SGML (icke normativt)
D Expansion av entitets- och teckenanrop (icke normativt)
E Deterministiska innehållsmodeller (icke normativt)
F Automatiskt fastställande av teckenuppsättningar (icke normativt)
F.1 Fastställande utan extern teckenkodsinformation
F.2 Prioritieringar i närvaro av extern teckenkodsinformation
G W3Cs arbetsgrupp för XML (icke normativt)
H W3C XML Core Working Group (icke normativt)
I Produktionsuppgifter (icke normativt)

1 Inledning

Extensible Markup Language, förkortat XML, beskriver dels en klass av dataobjekt som kallas XML-dokument och dels beteendet hos dataprogram som bearbetar dem. XML är en begränsad form av SGML, the Standard Generalized Markup Language [ISO 8879]. Genom sin uppbyggnad är XML-dokument även SGML-dokument.

XML-dokument är uppbyggda av lagringsenheter som kallas entiteter, som innehåller endera analyserad ("parsed") eller icke analyserad ("unparsed") data. Analyserad data bygger på tecken ("characters"), av vilka vissa utgör teckendata och vissa utgör uppmärkning. Uppmärkningen är en kodad beskrivning av dokumentets lagringsutformning och logiska struktur. XML erbjuder en mekanism för att införa begränsningar i lagringsutformningen och den logiska strukturen.

[Definition: En mjukvarumodul kallad en XML-tolk ("XML processor") används för att läsa XML-dokument och ge tillgång till deras innehåll och struktur.] [Definition: Det förutsätts att en XML-tolk arbetar under en annan modul kallad applikationen.] Denna specifikation beskriver det beteende som krävs av en XML-tolk med avseende på hur den skall läsa XML-data och vilken information den måste förse applikationen med.

1.1 Ursprung och mål

XML utvecklades av XML Working Group (ursprungligen känd som the SGML Editorial Review Board) som bildades under överinseende av the World Wide Web Consortium (W3C) 1996. Ordförande var Jon Bosak, Sun Microsystems, med aktivt deltagande av en XML Special Interest Group (tidigare känd som the SGML Working Group) som också hade bildats av W3C. Medlemmarna i the XML Working Group finns angivna i en bilaga. Dan Connolly fungerade som kontaktman mellan the XML WG och W3C.

Målen för XMLs utformning är:

1. XML skall bli lätt att använda på Internet.
2. XML skall stödja en bred variation av applikationer.
3. XML skall vara kompatibelt med SGML.
4. Det skall vara lätt att skriva program som bearbetar XML-dokument.
5. Antalet alternativa möjligheter för uppmärkning i XML skall hållas nere till ett absolut minimum, helst noll.
6. XML-dokument bör vara läsbara för det mänskliga ögat och tillräckligt lätta att förstå.
7. XMLs utformning bör snabbt bli klar.
8. XMLs utformning skall vara formell och kortfattad.
9. XML-dokument skall vara lätta att skapa.
10. Förkortningar i XML-uppmärkningen ["på bekostnad av klarhet"] har liten betydelse.

Denna specifikation bidrar, tillsammans med associerade standarder (Unicode och ISO/IEC 10646 för tecken, Internet RFC 3066 för språkidentifieringstaggar, ISO 639 för kodning av namn på språk ochd ISO 3166 for kodning av namn på länder) till den information som behövs för att förstå XML version 1.0 och konstruera dataprogram för att bearbeta XML-dokument.

Denna version av XML-specifikationen får distribueras fritt, om all text och alla hänvisningar förblir intakta.

1.2 Terminologi

Terminologin som används för att beskriva XML-dokument är definierad i denna specifikation. Nyckelorden MÅSTE, FÅR INTE, OBLIGATORISK, SKALL, SKALL INTE, BÖR, BÖR INTE, REKOMMENDERAD, FÅR och VALFRI skall, när de är BETONADE, tolkas som beskrivits i [IETF RFC 2119]. Utöver detta definieras i följande lista de termer som används för att bygga upp definitionerna och för att beskriva aktiviteterna hos en XML-tolk:

fel ("error")

[Definition: Överträdelse av regler i denna specifikation; resultaten är odefinierade. Om inte annat specificeras, är ett underlåtande att observera en regel i denna specifikation angivet med ett av nyckelorden MÅSTE, OBLIGATORISK, FÅR INTE, SKALL och SKALL INTE ett fel. Godkänd mjukvara får leta fram och rapportera fel och får därefter fortsätta sin bearbetning.]

kritiskt fel

[Definition: Ett fel som en godkänd XML-tolk MÅSTE upptäcka och rapportera till applikationen. Efter att ha upptäckt ett kritiskt fel, FÅR XML-tolkn fortsätta att bearbeta data för att finna fler fel och FÅR rapportera sådana fel till applikationen. För att kunna stödja felrättning, FÅR XML-tolkn göra obearbetad data från dokumentet (med teckendata och uppmärkning blandat) tillgänglig för applikationen. När ett kritiskt fel har upptäckts, MÅSTE emellertid XML-tolken upphöra med normal behandling (dvs den FÅR INTE fortsätta att leverera teckendata och information om dokumentets logiska struktur till applikationen på normalt sätt).]

på användarens initiativ ("at user option")

[Definition: Godkänd mjukvara FÅR eller MÅSTE (beroende på det modala hjälpverbet i meningen) bete sig som beskrivet. Om den gör det, MÅSTE den förse användarna med ett medel att möjliggöra eller omöjliggöra det beskrivna beteendet.]

giltighetsbegränsning ("validity constraint")

[Definition: En regel som gäller för alla giltiga XML-dokument. Överträdelser av giltighetsbegränsningar är fel. De MÅSTE på användarens initiativ kunna rapporteras av en validerande ("validating") XML-tolk.]

välutformningsbegränsning ("well-formed constraint")

[Definition: En regel som gäller för alla välformade XML-dokument. Överträdelser av begränsningar för välutformning är kritiska fel.]

överensstämma med ("match")

[Definition: (I strängar eller namn:) Två jämförda strängar eller namn MÅSTE vara identiska. Tecken med flera möjliga sätt att representeras i ISO/IEC 10646 (dvs tecken med både fasta ["ex ö"] och bas+diakritiska former ["ex o+¨"]) överensstämmer bara om de har samma representation i båda strängarna. Ingen kastväxling ["dvs växling mellan stora och små bokstäver"] är tillåten. (För strängar och regler i grammatiken:) En sträng överenstämmer med en grammatisk definition om den hör till det språk som generas av definitionen. (För innehåll och innehållsmodeller:) Ett element överensstämmer med sin deklaration när det överensstämmer med det sätt som beskrivs i "Giltighetsbegränsning: Giltigt element".]

för kompatibilitet ("for compatibility")

[Definition: Anger en mening som beskriver en egenskap hos XML som enbart är inlagd för att säkra att XML blir kompatibelt med SGML.]

för utbyte ("for interoperability")

[Definition: Anger en mening som beskriver en icke-bindande rekommendation inlagd för att öka chanserna för att XML-dokument skall kunna behandlas av de existerande installerade SGML-behandlare som föregick the WebSGML Adaptations Annex (bilaga till SGML).]

2 Dokument

[Definition: Ett dataobjekt är ett XML-dokument om det enligt definitionen i denna specifikation är välutformat ("well-formed"). Ett välutformat XML-dokument FÅR dessutom vara giltigt om det möter vissa ytterligare begränsande krav.]

Varje XML-dokument har såväl en logisk som en fysisk struktur. Fysiskt är dokumentet komponerat av enheter som kallas entiteter. En entitet FÅR anropa andra entiteter för att ta in deras innehåll i dokumentet. Ett dokument börjar med en "rot" eller dokumententitet. Logiskt är dokumentet uppbyggt av deklarationer, element, kommentarer, teckenanrop och processinstruktioner, som alla är utmärkta med explicit uppmärkning i dokumentet. De logiska och fysiska strukturerna MÅSTE noggrant inkapslas ("nest"), vilket beskrivs i "4.3.2 Välformade analyserade entiteter".

2.1 Välformade XML-dokument

[Definition: Ett textobjekt är ett välutformat XML-dokument, om:]

1. det i sin helhet överensstämmer med en beskrivning som benämns dokument,
2. det uppfyller de begränsningar som välutformning anger i denna specifikation och
3. var och en av de analyserade entiteterna som anropas direkt eller indirekt inom dokumentet är välformad.

För att ett dokument skall överensstämma med dokument-beskrivning förutsätts att:

1. Det innehåller ett eller flera element.
2. [Definition: Det finns exakt ett element som kallas roten eller rotelementet, som inte i någon del återkommer i innehållet i något annat element.] För alla andra element gäller att om starttaggen ("start-tag") finns i innehållet i ett annat element skall också sluttaggen ("end-tag") finnas i innehållet i samma element. Enklare uttryckt: Elementen, begränsade av start- och sluttaggar, inkapslas i varandra.

[Definition: Som en följd av detta gäller att för varje icke-rotelement C i dokumentet, finns det ett annat element P i dokumentet så att C finns i innehållet i P, men inte i innehållet i något annat element som finns i innehållet i P. Under dessa villkor är P angivet som parent ["förälder"] till C och C är child ["barn"] till P.]

2.2 Tecken

[Definition: En analyserad entitet innehåller text, en följd av tecken, som kan representera endera uppmärkning eller teckendata.] [Definition: Ett tecken är en minsta textenhet, enligt specifikationen ISO/IEC 10646:2000 [ISO/IEC 10646]. Tillåtna tecken är tabulatorsteg, returmatning, ny rad och de tillåtna tecknen i Unicode och ISO/IEC 10646. De versioner av dessa standarder som citeras i A.1 Normative References var gällande vid tiden då detta dokument förbereddes. Nya tecken får adderas till dessa standarder genom tillägg eller nya upplagor. Följaktligen, MÅSTE XML-tolkar acceptera varje tecken inom intervallet som anges för Char. Användning av "kompatibilitetstecken", som definierats i sektion 6.8 i [Unicode], (se även D21 i avsnitt 3.6 av [Unicode3]), skall motverkas.]

Mekanismen för att omvandla teckenkodsnummer till bitar FÅR variera från entitet till entitet. Alla XML-tolk MÅSTE acceptera UTF-8- och UTF-16-koden i Unicode 3.1. Möjligheterna att deklarera vilken av de två som används eller för att lyfta in andra teckenstandarder kommer att tas upp senare, i "4.3.3 Teckenkoder i entiteter".

[#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 Vanliga syntaxkonstruktioner

Detta avsnitt definierar några ofta använda begrepp i grammatiken.

S (tomrum, "white space") består av ett eller flera blanktecken (#x20), returmatningar, nya rader eller tabulatorsteg.

Tecken är traditionellt uppdelade i bokstäver, siffror och andra tecken. En bokstav består av ett alfabetiskt eller stavelsebaserat bastecken eller av ett bildskriftstecken. Fullständiga definitioner av de specifika tecknen i varje klass finns i "B. Teckenklasser".

[Definition: Ett namn är en datatyp ("token") som börjar med en bokstav eller ett av några få interpunktionstecken och fortsätter med bokstäver, siffror, bindestreck, understrykningstecken, kolon, eller punkter, sammantaget kända som namntecken.] Namn som börjar med strängen "xml" eller med varje annan sträng som överensstämmer med (('X'|'x') ('M'|'m') ('L'|'l')), är reserverade för standardisering i denna och kommande versioner av specifikationen.

En Nmtoken (namntyp, "name token") är en blandning av namntecken ("name characters").

Literal data är en sträng inom anföringstecken som inte innehåller samma anföringstecken som använts för avgränsning av strängen. Literal data används för att specificera innehållet i interna entiteter (EntityValue) ["entitetsvärde"], attributvärden (AttValue) och externa beteckningar (SystemLiteral). Notera att en SystemLiteral kan analyseras utan att söka efter uppmärkning.

2.4 Teckendata och uppmärkning

Text består av blandad teckendata och uppmärkning. [Definition: Uppmärkning har formen av starttaggar, sluttaggar, tomma taggar, entitetsanrop, teckenanrop, kommentarer, skiljetecken för CDATA-avsnitt, dokumenttypsdeklarationer och processinstruktioner, XML-deklarationer, textdeklarationer och varje tomrum som ligger på toppnivå i dokumententiteten (dvs, utanför rotelementet och inte innanför någon annan uppmärkning).]

[Definition: All text som inte är uppmärkning utgör dokumentets teckendata.]

Och-tecknet (&) och mindre-än-tecknet (<) FÅR INTE förekomma i teckenform, utom när de används som skiljetecken för uppmärkning, eller inom en kommentar, en processinstruktion eller ett CDATA-avsnitt. Om de behövs någon annanstans, MÅSTE de vara undantagna genom att antingen använda numeriska teckenanrop eller strängarna "&" eller "<". Större-än-tecknet (>) FÅR representeras av strängen ">" och MÅSTE för kompatibilitet undantas med hjälp av endera ">" eller av ett teckenanrop, när det uppträder i strängen "]]>", i det fall strängen inte anger slutet på ett CDATA-avsnitt.

I innehållet hos element, är teckendata varje teckensträng som inte innehåller ett startskiljetecken i någon uppmärkning och inte innehåller avslutningstecknen för CDATA-avsnitt, "]]>". I ett CDATA-avsnitt är teckendata varje teckensträng som inte innehåller avslutningstecknet för CDATA-avsnitt, "]]>".

För att möjliggöra för attributvärden att innehålla både enkla och dubbla anföringstecken, FÅR apostrofen eller det enkla anföringstecknet (') anges med "'" och citationstecknet eller det dubbla anföringstecknet (") med """.

2.5 Kommentarer

[Definition: Kommentarer FÅR förekomma överallt i ett dokument utanför annan uppmärkning. Dessutom FÅR kommentarer förekomma inom dokumenttypsdeklarationen på platser som tillåts av grammatiken. De är inte någon del av dokumentets teckendata.] En XML-tolk FÅR, men behöver inte, möjliggöra för applikationen att gå igenom texten i kommentarerna. För kompatibilitet FÅR INTE strängen"--" (dubbelt bindestreck) förekomma inom kommentarerna.] Anrop till parameterentiteter FÅR INTE förekomma i kommentarer.

Ett exempel på en kommentar:

Notera att grammatiken inte tillåter en kommentar som slutar med --->. Följande exampel är inte välutformat.

<!-- B+, B, eller B--->

2.6 Processinstruktioner

[Definition: Processinstruktioner (PIer) låter ett dokument innehålla instruktioner för applikationer.]

PIer är inte en del av ett dokuments teckendata, men MÅSTE vidarebefordras till applikationen. PIer inleds med ett mål (PITarget) ["PI-mål"] för att identifiera den applikation som instruktionen riktar sig till. Målnamnen "XML", "xml" osv. är reserverade för standardisering i denna eller i framtida versioner av specifikationen. XML-mekanismen för notation FÅR användas för formella deklarationer av PI-mål. Anrop till parameterentiteter FÅR INTE förekomma i processinstruktioner.

2.7 CDATA-avsnitt

[Definition: CDATA-avsnitt ("CDATA Sections") FÅR förekomma överallt där teckendata förekommer. De används för att gå ur textavsnitt som innehåller tecken som annars skulle betraktas som uppmärkning. CDATA-avsnitt börjar med strängen "<![CDATA[" och slutar med strängen "]]>":]

Inom ett CDATA-avsnitt betraktas endast CDEnd-strängen som uppmärkning, dvs mindre-än-tecken och och-tecken får förekomma i utskriven form. De behöver inte (och kan inte) bli överhoppade genom att använda "<" och "&". CDATA-avsnitt kan inte inkapslas.

Ett exempel på ett CDATA-avsnitt, där "<hälsning>" och "</hälsning>" betraktas som teckendata, inte som uppmärkning:

2.8 Prolog och dokumenttypsdeklaration

[Definition: XML-dokument BÖR börja med en XML-deklaration som specificerar den XML-version som används.] T.ex. det följande är ett fullständigt XML-dokument, välutformat men inte giltigt:

liksom detta:

Uppmärkningens funktion i ett XML-dokument är att beskriva dess lagring och logiska struktur och att knyta namn-/värdepar i attribut till sina logiska strukturer. XML erbjuder en mekanism, dokumenttypsdeklarationen, för att definiera begränsningar i den logiska strukturen och att stödja användningen av fördefinierade lagringsenheter. [Definition: Ett XML-dokument är giltigt om det har en tillhörande dokumenttypsdeklaration och om dokumentet överensstämmer med de begränsningar som har uttryckts i den.]

Dokumenttypsdeklarationen måste ligga före det första elementet i dokumentet.

[Definition: Dokumenttypsdeklarationen i XML innehåller eller pekar på uppmärkningsdeklarationer som bildar en grammatik för en dokumentklass. Denna grammatik är känd som dokumenttypsdefinitionen eller DTDn. Dokumenttypsdeklarationen kan peka på en extern delmängd ("subset", en särskild sorts extern entitet) som innehåller uppmärkningsdeklarationer eller kan innehålla uppmärkningsdeklarationerna direkt i en inre delmängd eller kan innehålla båda. DTDn för ett dokument består av båda delmängdstyperna sammantagna.]

[Definition: En uppmärkningsdeklaration är en elementtypsdeklaration, en attributlist-deklaration, en entitetsdeklaration eller en notationsdeklaration.] Dessa deklarationer FÅR vara sammanhållna i sin helhet eller i delar i parameterentiteter, som beskrivs i välutformnings- och giltighetsbegränsningar nedan. För ytterligare information, se "4. Fysiska strukturer".

Notera att det är möjligt att konstruera ett välutformat dokument, som innehåller en dokumenttypsdeklaration som varken pekar på en extern delmängd eller innehåller någon intern delmängd.

Uppmärkningsdeklarationerna FÅR ha gjorts helt eller delvis i ersättningstexten i parameterentiteterna. De definitioner som förekommer senare i denna specifikation avseende vissa begrepp ("nonterminals") ["vänsterledet i de olika numrerade begreppsdefinitionerna"] (elementdecl, AttlistDecl osv) beskriver deklarationerna efter det att alla parameterentiteterna har blivit infogade.

Parameterentitetsanrop accepteras överallt i DTDn (interna och externa delmängder samt externa parameterentiteter), utom i strängar inom anföringstecken ("literals"), processinstruktioner, kommentarer och innehållet i förbisedda villkorliga avsnitt (se 3.4 Villkorliga avsnitt). De accepteras även i entitetsvärdessträngar ("entity value literals"). Användningen av parameterentiteter i den interna delmängden är begränsad enligt nedan.

Giltighetsbegränsning: Rotelementstyp

Namnet i dokumenttypsdeklarationen MÅSTE överensstämma med elementtypen hos rotelementet.

Giltighetsbegränsning: Riktig deklaration/PE-inkapsling

Ersättningstexten i en parameterentitet MÅSTE vara riktigt inkapslad i uppmärkningsdeklarationerna. Det vill säga att om något av de första tecknen eller det sista tecknet i en uppmärkningsdeklaration (markupdecl ovan) ingår i ersättningstexten för ett parameterentitetsanrop, MÅSTE båda ingå i samma ersättningstext.

Välutformningsbegränsning: PEer i interna delmängder

I den interna delmängden av DTDn FÅR INTE parameterentitetsanrop förekomma inom uppmärkningsdeklarationer; de FÅR dock förekomma där uppmärkningsdeklarationer kan förekomma. (Detta gäller inte för anrop som förekommer i externa parameterentiteter eller den externa delmängden.)

Välutformningsbegränsning: Extern delmängd

Den externa delmängden MÅSTE, om den finns, överensstämma med definitionen för extSubset.

Välutformningsbegränsning: PE mellan deklarationer

Ersättningstext till ett parameterentitetsanrop i en DeclSep MÅSTE överensstämma med definitionen extSubsetDecl.

På samma sätt som den interna delmängden MÅSTE den externa delmängden och alla parameterentiteter som anropas i en DeclSep bestå av en serie av kompletta uppmärkningsdeklarationer av de typer som tillåts av begreppet markupdecl, blandade med tomrum eller parameterentitetsanrop. Emellertid FÅR delar av innehållet i den externa delmängden eller i dessa externa parameterentiteter förbises villkorligt genom att använda en villkorliga avsnitts-konstruktion. Detta är inte tillåtet i den interna delmängden, men är tillåtet i externa parameterentiteter anropade i den interna delmängden.

Den externa delmängden och de externa parametererentiteterna skiljer sig också från den interna delmängden i det att i dessa är parameterentitetsanrop tillåtna inom uppmärkningsdeklarationerna, inte bara mellan uppmärkningsdeklarationerna.

Ett exempel på ett XML-dokument med en dokumenttypsdeklaration:

Systemadressen ("The system identifier") "hallå.dtd" ger URI-anropet till en DTD för dokumentet.

Deklarationerna kan också vara givna lokalt, som i detta exempel:

Om både externa och interna delmängder används, anses den interna delmängden övertrumfa den externa delmängden. Detta har den effekten att entitets- och attributlist-deklarationer i den interna delmängden har företräde framför dem i den externa delmängden.

2.9 Fristående ("standalone") dokumentdeklaration

Uppmärkningsdeklarationer kan ha en negativ inverkan på innehållet i ett dokument som skickas från en XML-tolk till ett applikation. Entitetsdeklarationer och ingångs-("default")värden för attribut är exempel på detta. Den fristående dokumentdeklarationen, som FÅR förekomma som en komponent i XML-deklarationen, ger en signal om huruvida det finns eller inte finns sådana deklarationer som förekommer utanför dokumententiteten eller i parameterentiteter. [Definition: En extern uppmärkningsdeklaration definieras som en uppmärkningsdeklaration som ligger i den externa delmängden eller i en parameterentitet (extern eller intern, den senare inbegripen eftersom icke-validerande XML-tolkar inte skall läsa dem).]

I en fristående dokumentdeklaration anger värdet "yes" att det inte finns några externa uppmärkningsdeklarationer som får en negativ inverkan på den information som skickas från XML-tolk till applikationen. Värdet "no" anger att det finns eller kan finnas några sådana externa uppmärkningsdeklarationer. Notera att den fristående dokumentdeklarationen bara utesluter närvaron av externa deklarationer; närvaron i ett dokument av anrop till externa entiteter, när entiteterna är deklarerade internt, ändrar inte deras fristående status.

Om det inte finns några uppmärkningsdeklarationer, har den fristående dokumentdeklarationen inte någon mening. Om det finns externa uppmärkningsdeklarationer men det inte finns någon fristående dokumentdeklaration, är värdet "no" förutsatt.

Varje XML-dokument för vilket standalone="no" kan konverteras algoritmiskt till ett fristående dokument, vilket kan vara önskvärt för vissa nätverksapplikationer.

Giltighetsbegränsning: Fristående dokumentdeklaration

Den fristående dokumentdeklarationen MÅSTE ha värdet "no" om någon extern uppmärkningsdeklaration innehåller deklarationer av:

• attribut med ingångs-("default")värden, om elementen som dessa attribut hör till förekommer i dokumentet utan specifikationer för värdena hos dessa attribut, eller
• entiteter (andra än amp, lt, gt, apos, quot), om anrop till dessa entiteter förekommer i dokumentet eller
• attribut med namntyper, där attributet uppträder i dokumentet med ett värde så att normalisering kommer att ge ett annat värde än det som skulle ha uppkommit i frånvaron av en deklaration eller
• elementtyper med elementinnehåll, om tomrum förekommer direkt inom något exempel på sådana typer.

Ett exempel på en XML-deklaration med en fristående dokumentdeklaration:

2.10 Tomrumshantering

Vid editering av XML-dokument, är det ofta praktiskt att använda tomrum (blanktecken/"spaces", tabulatorsteg/"tabs" och nya rader/"blank lines) för att dela upp uppmärkningen för bättre läsbarhet. Sådana tomrum är normalt inte avsedda att ingå i den framtagna ("delivered") versionen av dokumentet. Å andra sidan är det vanligt att ha med ett "signifikant" tomrum som bör sparas i den framtagna versionen, till exempel i en dikt eller en källkod.

En XML-tolk MÅSTE alltid vidarebefordra alla tecken i ett dokument som inte är uppmärkning till applikationen. En validerande XML-tolk MÅSTE också underrätta applikationen om vilka av dessa tecken i elementinnehållet som utgör tomrum.

Ett speciellt attribut kallat xml:space FÅR knytas till element för att signalera en avsikt att i det elementet bör tomrum sparas av applikationen. I giltiga dokument, MÅSTE detta attribut, liksom varje annat deklareras om det skall användas. När det deklareras, MÅSTE det anges som uppräkningstyp ("enumerated type") vars värden är ett eller båda av "default" ["ingångsvärde"] och "preserve" ["bibehåll"]. Till exempel:

Värdet "default" signalerar att inställningen av ingångsvärdet för applikationens tomrumshantering är godtagbart för detta element. Värdet "preserve" anger att applikationen skall bibehålla alla tomrum. Denna deklarerade avsikt gäller även för alla element som är inkapslade i det element som har detta värde angivet, om det inte övertrumfats av något annat värde på xml:space-attributet. Denna specifikation ger inte mening åt något värde på xml:space andra än "default" och "preserve". Det är ett fel att specificera andra värden; XML-tolken FÅR rapportera felet eller FÅR fortsätta genom att förbise attributspecifikationen eller genom att rapportera det (felaktiga) värdet till applikationen. Applikationer får förbise eller förkasta felaktiga värden.

Rotelementet i ett dokument anses inte ha signalerat någon avsikt avseende applikationens tomrumshantering, om det inte har ett värde på detta attribut eller attributet har deklarerats med ingångs-("default")värdet.

2.11 Hantering av radbrytning

XML-analyserade entiteter är ofta lagrade i datafiler, som är organiserade i rader för bearbetning. Dessa rader är separerade på ett särskilt sätt genom en kombination av tecknen returmatning (#xD) och ny rad (#xA).

För att underlätta uppgifterna för en applikation, MÅSTE XML-tolken uppträda som om den normaliserade alla radbrytningar i externa analyserade entiteter (inklusive dokumententiteten) vid inmatningen före tolkning genom att översätta både två-teckenföljden #xD #xA och alla #xD, som inte följs av #xA, till ett ensamt #xA-tecken.

2.12 Språkidentifiering

Vid dokumentbearbetning, är det ofta praktiskt att identifiera det naturliga eller formella språk som innehållet är skrivet i. Ett särskilt attribut kallat xml:lang FÅR infogas i dokumentet för att ange vilket språk som används i innehållet och attributvärdena hos alla element i ett XML-dokument. I giltiga dokument MÅSTE detta liksom alla andra attribut deklareras om det används. Dessa attributvärden utgörs av en språkidentifiering enligt definitionen i [IETF RFC 1766], Tags for the Identification of Languages eller dess efterföljare; dessutom FÅR en tom sträng specificeras.

(Definitionerna 33 t.o.m. 38 har tagits bort.)

Exempel:

Den deklarerade avsikten med xml:lang anses gälla alla attribut och innehållet i det element där koden är angiven, om det inte i något inkapslat element har angetts något annat värde på xml:lang-attributet. Särskilt används det tomma värdet på xml:lang på ett element B för att övertrumfa en specifikation av xml:lang på ett omslutande element A, utan att specificera något annat språk. Inom B anses det att det inte finns någon språkkod tillgänglig, precis som om xml:lang inte hade specificerats på B eller någon av dess förfäder ("ancestors").

En enkel deklaration för xml:lang kan se ut så här:

men om det är lämpligt FÅR särskilda ingångs-("default")värden vara givna. I en samling av franska dikter för svenska studenter kan, med glosor och noter på svenska, xml:lang-attributet vara deklarerat så här:

3 Logiska strukturer

[Definition: Varje XML-dokument innehåller ett eller flera element, som är avgränsade av antingen starttaggar ("start-tags") och sluttaggar ("end-tags"), eller för tomma ("empty") element av en tomelementstagg ("empty-element tag"). Varje element har en typ som identifieras med namn, ibland kallad dess generella identifikation ("generic identifier", GI), och FÅR ha en uppsättning med attributspecifikationer.] Varje attributspecifikation har ett namn och ett värde.

Denna specifikation utgör inte någon begränsning av semantiken för, användningen av eller (bortom syntaxen) namnen på elementtyperna och attributen, utom att namn som börjar på (('X'|'x')('M'|'m')('L'|'l')) är reserverade för standardisering i denna eller framtida versioner av specifikationen.

Välutformningsbegränsning: Elementtypsöverensstämmelse

Namnet i ett elements sluttagg MÅSTE överensstämma med elementtypen i starttaggen.

Giltighetsbegränsning: Giltigt element

Ett element är giltigt om det finns en deklaration som överensstämmer med elementdecl ["elementdeklarationen"] där namnet överensstämmer med elementtypen och ett av följande villkor gäller:

1. Deklarationen överensstämmer med EMPTY och elementet har inte något innehåll (inte ens entitetsanrop, kommentarer, processinstruktioner eller tomrum).
2. Deklarationen överensstämmer med children och de ingående child-elementen (efter ersättning av alla entitetsanrop med deras ersättningstext) hör till det språk som skapats av det reguljära uttrycket ("regular expression") i innehållsmodellen ["se begreppsdefinitionerna [47]-[50]"], med tomrum, kommentarer, processinstruktioner (dvs uppmärkning som överensstämmer med definitionen [27]Misc) som möjliga tillval mellan starttaggen och det första child-elementet, mellan child-element eller mellan det sista child-elementet och sluttaggen. Notera att en CDATA-sektion som bara innehåller tomrum eller ett anrop till en entitet vars ersättningstext är teckenanrop som expanderas till tomrum inte överensstämmer med definitionen S och således inte kan förekomma på dessa ställen. Emellertid överensstämmer ett anrop till en intern entitet med ett strängvärde ("literal value") som består av teckenanrop som expanderas till tomrum definitionen S, eftersom dess ersättningstext är tomrum som är resultatet av expansioner av teckenanrop.
3. Deklarationen överensstämmer med mixed och innehållet (efter ersättning av alla entitetsanrop med deras ersättningstext) består av teckendata, kommentarer, processinstruktioner och child-element med elementtyper som överensstämmer med namnen i innehållsmodellen.
4. Deklarationen överensstämmer med ANY och innehållet (efter ersättning av alla entitetsanrop med deras ersättningstext) består av teckendata och child-element vilkas typer har deklarerats.

3.1 Starttaggar, sluttaggar och tomelementstaggar

[Definition: Början på varje XML-element, som inte är ett tomelement, är markerad med en starttagg ("start-tag").]

Namnet i start- och sluttaggarna anger elementets typ. [Definition: Namn-AttValue["attributvärde"]-paren anropas som elementens attributspecifikationer ("attribute specifications")], [Definition: med namnet i varje par anropat som attributnamnet och innehållet i AttValue (texten mellan '- eller "-anföringstecknen) som attributvärdet.] Notera att ordningen för attributspecifikationerna i en starttagg eller tomelementstagg inte är bestämd.

Välutformningsbegränsning: Unik attributspecifikation ("Unique Att Spec")

Ett attributnamn FÅR INTE förekomma mer än en gång i samma starttagg eller tomelementstagg.

Giltighetsbegränsning: Attributvärdestyp ("Attribute Value Type")

Attributet MÅSTE ha blivit deklarerat; värdet MÅSTE vara av samma typ som angetts i deklarationen. (För attributtyper, se "3.3 Attributlist-deklarationer".)

Välutformningsbegränsning: Inga externa entitetsanrop

Attributvärden FÅR INTE innehålla direkta eller indirekta anrop till externa entiteter ["men de får innehålla ett anrop till ett entitetsnamn till en extern icke analyserad entitet"].

Välutformningsbegränsning: Inget <-tecken i attributvärdet

Ersättningstexten för varje entitet som anropats direkt eller indirekt i ett attributvärde FÅR INTE innehålla <.

Ett exempel på en starttagg:

[Definition: Slutet på varje element som börjar med en starttagg MÅSTE märkas upp av en sluttagg. Denna innehåller ett namn som upprepar elementets typ såsom den angetts i starttaggen:]

Ett exempel på en sluttagg:

[Definition: Texten mellan starttaggen och sluttaggen kallas elementets innehåll:]

[Definition: Ett element utan innehåll kallas tomt.] Ett tomt element representeras antingen av en starttagg omedelbart följd av en sluttagg eller av en tomelementstagg. [Definition: En tomelementstagg har en speciell form:]

Tomelementstaggar FÅR användas för alla element som inte har något innehåll, vare sig de är deklarerade som EMPTY eller inte. För utbyte ("interoperability") BÖR tomelementstaggen användas och BÖR bara användas för element som är deklarerade som EMPTY.

Exempel på tomelement:

3.2 Elementtypsdeklarationer

I ett XML-dokument FÅR element-strukturen begränsas med hjälp av deklarationer av elementtyp och attributlistor i syfte att testa giltigheten. En elementtypsdeklaration begränsar elementets innehåll.

Elementtypsdeklarationer begränsar ofta vilka elementtyper som kan förekomma som children ["barn"] till elementet. På användarens initiativ, FÅR en XML-tolk utfärda en varning när en deklaration nämner en elementtyp som inte är deklarerad, men det är inte ett fel.

[Definition: En elementtypsdeklaration antar formen:]

där namnet betecknar den deklarerade elementtypen.

Giltighetsbegränsning: Unik elementtypsdeklaration

En elementtyp FÅR INTE deklareras mer än en gång.

Exempel på elementtypsdeklarationer:

3.2.1 Elementinnehåll

[Definition: En elementtyp har elementinnehåll när en sådan typ av element MÅSTE innehålla enbart child-element (ingen teckendata), som kan, men inte behöver vara åtskilda med tomrum (tecken som överensstämmer med begreppet S).] [Definition: I detta fall, innefattar begränsningen en innehållsmodell, en enkel grammatik som styr tillåtna child-elementtyper och den ordning de får förekomma i.] Grammatiken är byggd på innehållsdelar ("content particles") (cps), som består av namn samt urvalslistor ("choice lists") eller sekvenslistor ("sequence lists") med innehållsdelar:

där varje namn är den elementtyp som FÅR förekommer som child. Varje innehållsdel i en urvalslista FÅR förekomma i elementinnehållet på det ställe där urvalslistan förekommer i grammatiken. Innehållsdelar i en sekvenslista MÅSTE var och en förekomma i elementinnehållet i den ordning som angetts i listan. Det tecken som kan följa ett namn eller en lista som tillval styr hur elementet eller innehållsdelarna i listan får förekomma; en eller flera (+); ingen, en eller flera (*) eller ingen eller en gång (?). Frånvaron av en sådant tecken innebär att elementet eller innehållsdelen bara får förekomma exakt en gång. Denna syntax och innebörd är identisk för de innehållsdelar som används i begreppsdefinitionerna i denna specifikation.

Innehållet i ett element överensstämmer med en innehållsmodell om och endast om det är möjligt att finna en gång ("path") genom innehållsmodellen, som följer sekvens, urval och förekomsttecken samt stämmer av varje element i innehållet mot en elementtyp i innehållsmodellen. För kompatibilitet är det ett fel om innehållsmodellen tillåter ett element att överensstämma med fler än en förekomst av en elementtyp i innehållsmodellen. För mer information, se "E. Deterministiska innehållsmodeller".

Giltighetsbegränsning: Riktig grupp/PE-inkapsling

Ersättningstexten för en parameterentitet MÅSTE vara riktigt inkapslad i parentesförsedda grupper. Dvs om någon av start- eller slutparentesen i ett urvals-, en sekvens- eller en blandad ("mixed") konstruktion är inkapslad i ersättningstexten för en parameterentitet, MÅSTE även den andra parentesen vara inkapslad i samma ersättningstext. Om ett parameterentitetsanrop förekommer i ett urval, en sekvens eller en blandad konstruktion, BÖR för utbyte dess ersättningstext innnehålla minst ett tecken som inte är tomrumstecken och varken det första eller det sista tecknet som inte är tomrum i ersättningstexten BÖR vara ett bindetecken ("connector") (| eller ,).

Exempel på elementinnehållsmodeller:

3.2.2 Blandat innehåll

[Definition: En elementtyp har blandat innehåll när element av denna typ FÅR innehålla teckendata, valfritt ("optionally") blandat med child-element.] I detta fall FÅR child-elementtyperna vara begränsade, men inte deras ordning eller deras antal:

där namnen anger de elementtyper som får förekomma som children. Nyckelordet PCDATA härrör historiskt från termen "parsed character data" ["analyserad teckendata"].

Giltighetsbegränsning: Inga dubbla typer

Samma namn FÅR INTE förekomma fler än en gång i en deklaration av blandat innehåll.

Exempel på deklarationer av blandat innehåll:

3.3 Attributlist-deklarationer ("Attribute-List Declarations")

Attribut används för att knyta namn/värde-par till element. Attributspecifikationer FÅR INTE förekomma utanför starttaggar och tomelementstaggar. Begreppsdefinitionerna som används för att identifiera dem finns således i avsnitt "3.1". Attributlist-deklarationer FÅR användas:

• För att definiera den uppsättning av attribut som tillhör en angiven elementtyp.
• För att skapa typbegränsningar för dessa attribut.
• För att förse attribut med ingångsvärden ("default values").

[Definition: Attributlist-deklarationer anger namnet, datatypen och ingångsvärdet (om det finns något) för varje attribut som är knutet till en angiven elementtyp:]

Namnet i AttlistDecl-regeln [52] är namnet på elementtypen. På användarens initiativ FÅR en XML-tolk utfärda en varning om attribut deklareras för en elementtyp som i sig inte är deklarerad, men detta är inte ett fel. Namnet i AttDef-regeln (53) är attributnamnet.

När fler än en AttlistDecl är föreskriven för en angiven elementtyp, slås innehållet i alla föreskrivna deklarationer samman. När fler än en definition finns för samma attribut för en angiven elementtyp, är den första deklarationen bindande och de senare deklarationerna förkastade. För utbyte FÅR författare av DTDer föreskriva deklaration av maximalt ett attribut för en angiven elementtyp, maximalt en attributdefinition för ett angivet attributnamn i en attributlist-deklaration och åtminstone en attributdefinition i varje deklaration av en attributlista. För utbyte FÅR en XML-tolk på användarens initiativ utfärda en varning när fler än en attributlist-deklaration är föreskriven för en angiven elementtyp, eller fler än en attributdefinition är föreskriven för ett angivet attribut, men detta är inte ett fel.

3.3.1 Attributtyper

XML har tre sorters attributtyper: en strängtyp, ett antal datatyper av namn-typ ("tokenized types") och uppräkningstyper. Strängtypen kan ha alla sorters literal data som värde; de olika datatyperna har varierande lexikala och semantiska begränsningar. Giltighetsbegränsningarna som angetts i grammatiken tillämpas efter det att attributvärdet har normaliserats enligt avsnitt 3.3.3 Normalisering av attributvärden.

Giltighetsbegränsning: ID

Värdetypen ID MÅSTE överensstämma med namn-definitionen. Ett namn FÅR INTE förekomma mer än en gång i ett XML-dokument som ett värde av denna typ; dvs ID-värden MÅSTE på ett unikt sätt identifiera de element som bär dem.

Giltighetsbegränsning: En ID per elementtyp

En elementtyp FÅR INTE ha fler än ett ID-attribut.

Giltighetsbegränsning: Ingångsvärde för ID-attribut

Ett ID-attribut MÅSTE ha #IMPLIED eller #REQUIRED som deklarerat ingångsvärde.

Giltighetsbegränsning: IDREF

Värdetypen IDREF MÅSTE överensstämma med Namn-definitionen [5] och värdetypen IDREFS MÅSTE överensstämma med Namn [6, "flera namn"]; varje Namn [5] MÅSTE överensstämma med värdet på ett ID-attribut i något element i XML-dokumentet; dvs IDREF-värden MÅSTE överensstämma med värdet på något ID-attribut.

Giltighetsbegränsning: Entitetsnamn

Värdetypen ENTITY MÅSTE överensstämma med Namn-definitionen [5], värdetypen ENTITIES MÅSTE överensstämma med Namn [6, "flera namn"]; varje Namn MÅSTE överensstämma med namnet på en icke analyserad entitet deklarerad i DTDn.

Giltighetsbegränsning: Namntyp

Värdetypen NMTOKEN MÅSTE överensstämma med namntyps-definitionen; värdetypen NMTOKENS MÅSTE överensstämma med namntyper.

[Definition: Uppräkningsattribut MÅSTE anta ett av värdena i en lista av värden angivna i deklarationen.] Det finns två sorters uppräkningstyper:

Ett notations-attribut identifierar en notation, deklarerad i DTDn med anknutna system- och/eller allmänna adresser, vilka används för att tolka det element som attributen är knutet till.

Giltighetsbegränsning: Notationsattribut

Värden av denna typ MÅSTE överensstämma med ett av notations-namnen som finns i deklarationen. Alla notationsnamn i deklarationen MÅSTE deklareras.

Giltighetsbegränsning: En notation per elementtyp

En elementtyp FÅR INTE ha mer än ett notationsattribut.

Giltighetsbegränsning: Ingen notation på tomelement

För kompatibilitet FÅR INTE ett attribut av typen NOTATION deklareras på ett element, som deklarerats som EMPTY.

Giltighetsbegränsning: Inga dubbla datatyper av namn-typ ("tokens")

Notationsnamn i en Notationsattribut-sdeklaration, såväl som NmToken-typer i en Uppräkningsattribut-sdeklaration, MÅSTE all vara urskiljbara ["unika"].

Giltighetsbegränsning: Uppräkning

Värden av denna typ MÅSTE överensstämma med en av namntyps-typerna ("Nmtoken tokens") i deklarationen.

För utbyte gäller att samma namntyp BÖR INTE förekomma mer än en gång i uppräkningsattributtyperna för en elementtyp.

3.3.2 Ingångsvärden för attribut ("Attribute Defaults")

En attributdeklaration ger information om huruvida attributets närvaro krävs och om inte, hur en XML-tolk förväntas reagera om ett deklarerat attribut inte finns i ett dokument.

#REQUIRED i en attributdeklaration betyder att attributet alltid MÅSTE anges, #IMPLIED att ett ingångsvärde saknas. [Definition: Om deklarationen varken anger #REQUIRED eller #IMPLIED innehåller attributvärdet det deklarerade ingångsvärdet ("default value"). Nyckelordet #FIXED ["låst"] anger då att attributet alltid MÅSTE anta ingångsvärdet. När en XML-tolk möter ett element utan en attributspecifikation, för vilken den läst deklarationen för ingångsvärdet, MÅSTE den rapportera attributet med det deklarerade ingångsvärdet till applikationen.]

Giltighetsbegränsning: Obligatoriskt attribut

Om ingångsdeklarationen har nyckelordet #REQUIRED ["obligatorisk"] MÅSTE attributet specificeras för alla element med den angivna attributtypen i attributlist-deklarationen.

Giltighetsbegränsning: Syntaktiskt korrekt ingångsvärde för attribut

Det deklarerade ingångsvärdet MÅSTE möta de syntaktiska begränsningarna för den deklarerade attributtypen.

Notera att enbart de syntaktiska begränsningningarna för datatypen krävs här; andra begränsningar (t.ex. att värdet skall vara namnet på en deklarerad icke analyserad entitet för ett attribut av typen ENTITY) kan komma att beaktas om det deklarerade ingångsvärdet verkligen används (t.ex. ett element utan en specifikation för detta attribut uppträder).

Giltighetsbegränsning: Låst ingångsvärde för attribut

Om ett attribut har ett ingångsvärde deklarerat tillsammans med nyckelordet #FIXED, MÅSTE exempel på attributet överensstämma med ingångsvärdet.

Exempel på attributlist-deklarationer:

3.3.3 Normalisering av attributvärden

Innan ett attributvärde skickas till applikationen eller analyseras med avseende på giltighet, MÅSTE XML-tolken normalisera attributvärdet genom att tillämpa nedanstående algoritm eller någon annan metod så att värdet som skickas till applikationen är samma som det som genereras av algoritmen.

1. Alla radbrytningar MÅSTE normaliseras till #xA som beskrivits i 2.11 Hantering av radbrytning, så att resten av algoritmen arbetar med text som är normaliserad på detta sätt.
2. Börja med ett normaliserat värde som består av en tom sträng.
3. För varje, tecken, entitets- eller teckenanrop i det icke normaliserade attributvärdet med början med det första och sedan med fortsättning till det sista, gör följande:
   • För ett teckenanrop; hämta det anropade tecknet till det normaliserade värdet.
   • För ett entitetsanrop; tillämpa rekursivt steg 3 på denna algoritm på ersättningstexten för entiteten.
   • För tomrumstecken (#x20, #xD, #xA, #x9); hämta ett blanktecken #x20 som normaliseringsvärde.
   • För övriga tecken; hämta tecknet för det normaliserade värdet.

Om attributtypen inte är CDATA, MÅSTE XML-tolken bearbeta det normaliserade attributvärdet ytterligare genom att ta bort inledande och avslutande blanktecken (#x20) och genom att ersätta sekvenser av blanktecken (#x20) med ett blanktecken (#x20).

Notera att om det icke normaliserade attributvärdet innehåller ett teckenanrop till ett annat tomrumstecken än blanktecken (#x20), innehåller det normaliserade värdet det anropade tecknet i sig (#xD, #xA or #x9). Detta kontrasterar mot fallet där det icke normaliserade värdet innehåller ett tomrumstecken (inte ett anrop), som ersätts med ett blanktecken (#x20) i det normaliserade värdet och kontrasterar även mot fallet där det icke normaliserade värdet innehåller ett entitetsanrop vars ersättningstext innehåller ett tomrumstecken, som bearbetas rekursivt och ersätter tomrumstecknet med ett blanktecken (#x20) i det normaliserade värdet.

Alla attribut som inte har någon inläst deklaration BÖR av en icke-validerande XML-tolk behandlas som om de vore deklarerade som CDATA.

Här följer exampel på attributnormalisering. Med följande deklarationer givna:

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

normaliseras attributspecifikationerna i den vänstra kolumnen nedan till teckenföljderna i mittenkolumnen om attributet a deklareras som NMTOKENS och till dem i de högra kolumnernas om a deklareras som CDATA.

Notera att det sista exemplet inte är giltigt (men välutformat) om a är deklarerat som typen NMTOKENS.

3.4 Villkorliga avsnitt

[Definition: Villkorliga avsnitt är delar av dokumenttypsdeklarationens externa delmängd eller av av externa parameterentiteter vilka ingår i eller har uteslutits ur DTDns logiska struktur baserat på nyckelordet som styr dem.]

Giltighetsbegränsning: Riktigt villkorligt avsnitt/PE-inkapsling

Om något av "<![", "[", eller "]]>" i ett villkorligt avsnitt ligger i ersättningstexten för ett parameterentitetsanrop, MÅSTE de alla ligga i samma ersättningstext.

Villkorliga avsnitt kan liksom interna och externa DTD-delmängder innehålla en eller flera kompletta deklarationer, kommentarer, processinstruktioner eller inkapslade villkorliga avsnitt blandade med tomrum.

Om nyckelordet för det villkorliga avsnittet är INCLUDE, är innehållet i det villkorliga avsnittet en del av DTDn. Om nyckelordet för det villkorliga avsnittet är IGNORE, är innehållet i det villkorliga avsnittet inte en logisk del av DTDn. Om ett villkorligt avsnitt med nyckelordet INCLUDE förekommer inom ett större villkorligt avsnitt med nyckelordet IGNORE, förkastas både det yttre och det inre villkorliga avsnittet. Innehållet i ett förbisett villkorligt avsnitt kontrolleras genom att förbise alla tecken efter "[" som kommer efter nyckelordet, utom villkorliga avsnitt som börjar med "<![" och slutar med "]]>", tills det överensstämmande villkorliga avsnittets slut är funnet. Parameterentitetsanrop är inte accepterade i denna process.

Om nyckelordet för det villkorliga avsnittet är ett parameterentitetsanrop, MÅSTE parameterentiteten ersättas med sitt innehåll innan XML-tolken bestämmer om den skall lyfta in eller förkasta det villkorliga avsnittet.

Ett exempel:

4 Fysiska strukturer

[Definition: Ett XML-dokument kan bestå av en eller flera lagringsenheter. Dessa kallas entiteter; de har alla innehåll och är alla (utom dokumententiteten, se den externa DTD-delmängden) identifierade genom entitetsnamn. ] Varje XML-dokument har en entitet kallad dokumententiteten, som tjänar som startpunkten för XML-tolken och kan innehålla hela dokumentet.

Entiteter kan vara endera analyserade eller icke analyserade. [Definition: En analyserad entitets innehåll refereras till genom sin ersättningstext. Denna text anses som en integrerad del av dokumentet.]

[Definition: En icke analyserad entitet är en resurs vars innehåll kan men inte behöver vara text och är den text behöver den inte vara XML. Varje icke analyserad entitet har en associerad notation, som identifieras av namnet. Utöver kravet att en XML-tolk gör identifieringarna av entiteter och notationer tillgängliga för applikationen, lägger XML inte några begränsningar på innehållet i icke analyserade entiteter.]

Analyserade entiteter anropas med namn genom entitetsanrop. Icke analyserade entiteter anropas med namn, givna i värdet på ENTITY- eller ENTITIES-attribut.

[Definition: Generella entiteter är entiteter för användning inom dokumentinnehållet. I denna specifikation är generella entiteter ibland refererade till med den icke kvalificerande termen entitet när det inte leder till någon tveksamhet.] [Definition: Parameterentiteter är analyserade entiteter för användning inom DTDn.] Dessa två typer av entiteter använder olika former av anrop och är tillämpbara i olika sammanhang. Dessutom tar de olika namnrymder i anspråk; en parameterentitet och en generell entitet med samma namn är två åtskilda entiteter.

4.1 Tecken- och entitetsanrop

[Definition: Ett teckenanrop refererar till ett särskilt tecken i teckenuppsättningen ISO/IEC 10646, t.ex. till ett tecken som inte går att få fram direkt från tillgängliga inmatningsverktyg.]

Välutformningsbegränsning: Giltigt tecken

Vid användning av teckenanrop MÅSTE det anropade tecknet överensstämma med en definition av Char ["tecken"].

Om teckenanropet börjar med "&#x", utgör siffrorna och bokstäverna fram till det avslutande ; en hexadecimal representation av tecknets kodnummer i ISO/IEC 10646. Om det enbart börjar med "&#", utgör siffrorna fram till det avslutande ; en decimal representation av tecknets kodnummer.

[Definition: Ett entitetsanrop refererar till innehållet i en namngiven entitet.] [Definition: Anrop till analyserade generella entiteter använder och-tecken (&) och semikolon (;) som skiljetecken.] [Definition: Parameterentitetsanrop använder procenttecken (%) och semikolon (;) som skiljetecken.]

Välutformningsbegränsning: Deklarerad entitet

I ett dokument utan någon DTD, ett dokument med enbart en intern DTD-delmängd som inte innehåller något parameterentitetsanrop eller ett dokument med "standalone='yes'", MÅSTE för ett entitetsanrop som inte förekommer i den externa delmängden eller en parameterentitet namnet i entitetsanropet överensstämma med det i en entitetsdeklaration, som inte förekommer i den externa delmängden eller en parameterentitet, med det undantaget att välformade dokument inte behöver deklarera någon av följande entiteter: amp, lt, gt, apos, quot. Deklarationen av en generell entitet MÅSTE föregå varje anrop till den i form av ett ingångsvärde i en attributlist-deklaration.

Notera att om entiteter är deklarerade i parameterentiteter eller i den externa delmängden, behöver inte ("are not obligated to") icke-validerande XML-tolkar läsa och bearbeta deras deklarationer. För sådana dokument gäller regeln att en entitet måste vara deklarerad bara som en välutformningsbegränsning om standalone='yes'.

Giltighetsbegränsning: Deklarerad entitet

I ett dokument med en extern delmängd eller externa parameterentiteter med "standalone='no'", MÅSTE det angivna namnet i entitetsanropet överensstämma med det i en entitetsdeklaration. För utbyte BÖR giltiga dokument deklarera entiteterna amp, lt, gt, apos, quot, i den form som specificerats i "4.6 Fördefinierade entiteter". Deklarationen av en parameterentitet MÅSTE föregå varje anrop till den. På samma sätt MÅSTE deklarationen av en generell entitet föregå varje direkt eller indirekt anrop till den i form av ett ingångsvärde i en attributlist-deklaration.

Välutformningsbegränsning: Analyserad entitet

Ett entitetsanrop FÅR INTE innehålla namnet på en icke analyserad entitet. Icke analyserade entiteter får endast anropas i attributvärden som deklarerats som ENTITY eller ENTITIES.

Välutformningsbegränsning: Ingen rekursivitet

En analyserad entitet FÅR INTE innehålla ett rekursivt anrop till sig själv, vare sig direkt eller indirekt.

Välutformningsbegränsning: I DTDn

Parameterentitetsanrop FÅR INTE förekomma utanför DTDn.

Exempel på tecken- och entitetsanrop:

Exempel på ett parameterentitetsanrop:

4.2 Entitetsdeklarationer

[Definition: Entiteter deklareras som följer:]

Namnet identifierar entiteten i ett entitetsanrop eller, om det gäller en icke analyserad entitet, i värdet på ett ENTITY- eller ENTITIES-attribut. Om samma entitet deklareras fler än en gång är den först påträffade deklarationen bindande. På användarens initiativ FÅR en XML-tolk utfärda en varning om entiteter är deklarerade flera gånger.

4.2.1 Interna entiteter

[Definition: Om entitetsdefinitionen är ett entitetsvärde, kallas den definierade entiteten en intern entitet. Det finns inget separat fysiskt lagringsobjekt och entitetens innehåll är givet i deklarationen.] Notera att viss behandling av entitets- och teckenanrop i the literal entity value ["en sträng avgränsad av anföringstecken"] kan krävas för att skapa korrekt ersättningstext: se "4.5 Konstruktion av ersättningstext för interna entiteter".

En intern entitet är en analyserad entitet.

Exempel på en intern entitetsdeklaration:

4.2.2 Externa entiteter

[Definition: Om en entitet inte är intern, är det en extern entitet, som deklareras enligt följande:]

Om NDataDecl föreligger, handlar det om en generell icke analyserad entitet, annars är det en analyserad entitet.

Giltighetsbegränsning: Deklarerad notation

Namnet MÅSTE överensstämma med det deklarerade namnet på en notation.

[Definition: SystemLiteral kallas entitetens systemadress. Det är tänkt att konverteras till ett URI-anrop (definierat i [IETF RFC 2396], uppdaterat av [IETF RFC 2732]), som en del i processen att ge åtkomst ("dereference") för att få indata till en XML-tolk för att konstruera entitetens ersättningstext.] Det är ett fel om en fragmentidentifikation (som börjar med ett hash-tecken #) ingår som en del i en systemadress. Om inte annat anges genom information utanför omfattningen av denna specifikation (t.ex. en speciell XML-elementtyp definierad av en särskild DTD eller en processinstruktion definierad av en särskild applikationsspecifikation), är relativa URIer relativa i förhållande till läget på den resurs där entitetsdeklarationen finns. Detta definieras vara den externa entitet som innehåller det '<' som inleder deklarationen, i det ögonblicket den analyseras som en deklaration. En URI kan således vara relativ i förhållande till dokumententiteten, till entiteten som innehåller den externa DTD-delmängden eller till någon annan extern parameterentitet. Försök att bearbeta den resurs som identifierats av en URI FÅR omdirigeras på analysnivå (t.ex. i en entitetsupplösare ("entity resolver")) eller under (på protokollnivå, t.ex. via ett HTTP-Location:- huvud). I frånvaron av ytterligare information inom resursen, utanför omfattningen av denna specifikation, är bas-URIn ("the base URI") hos en resurs alltid URIn för den aktuella resursen som skickas tillbaka. Med andra ord är det URIn hos resursen bearbetad efter att alla omdirigeringar har gjorts.

Systemadresser (och andra XML-strängar avsedda att användas som URI-anrop) FÅR innehålla tecken som enligt [IETF RFC 2396] och [IETF RFC 2732], måste undvikas innan en URI kan användas för att bearbeta den anropade resursen. Tecknen som skall undvikas är kontrolltecknen #x0 till #x1F och #x7F (av vilka de flesta inte kan finnas i XML), blanktecken (#x20), uppmärkningstecken '<', #x3C, '>' #x3E och '"' #x22, de okloka tecknen '{' #x7B, '}' #x7D, '|' #x7C, '\' #x5C, '^' #x5E och '`' #x60, liksom alla tecken över #x7F. Eftersom undvikande inte alltid är en helt reversibel process, MÅSTE det utföras bara när det är absolut nödvändigt och så sent som möjligt i processkedjan. Särskilt gäller att varken processen att konvertera en relativ URI till en absolut eller processen att skicka ett URI-anrop till en process eller en mjukvarukomponent ansvarig för att ge åtkomst till den BÖR utlösa undvikande. När undvikande förekommer, MÅSTE det utföras enligt följande:

1. Varje tecken som skall undvikas är representerat i UTF-8 [Unicode3] som en eller flera bytes.
2. Resulterande bytes undviks genom URI-undvikningsmekanismen ("the URI escaping mechanism") (dvs konverteras till %HH, där HH är den hexadecimala representationen av bytevärdet).
3. Det ursprungliga tecknet ersätts av den resulterande teckenföljden.

[Definition: Som tillägg till en systemadress FÅR en extern adress innehålla en allmän adress.] En XML-tolk som försöker att tolka en entitets innehåll FÅR använda alla kombinationer av allmänna adresser och systemadresser såväl som ytterligare information utanför omfattningen av dennna specifikation för att försöka att skapa ett alternativt URI-anrop. Om XML-tolken inte kan göra det, MÅSTE den använda URI-anropet såsom det har specificerats i innehållet mellan anföringstecknen i systemcitatet. Innan en test av överensstämmelse görs, MÅSTE alla tomrumssträngar i en allmän adress normaliseras till ett blanktecken (#x20) samt inledande och avslutande tomrum tas bort.

Exempel på externa entitetsdeklarationer:

4.3 Analyserade entiteter

4.3.1 Textdeklarationen

Externa analyserade entiteter BÖR var och en börja med en textdeklaration.

Textdeklarationen MÅSTE skrivas ut explicit, inte anges som anrop till en analyserad entitet. I en extern analyserad entitet FÅR INTE en textdeklaration förekomma på annan plats än i början på entiteten. Textdeklarationen i en extern analyserad entitet anses inte som en del dess ersättningstext.

4.3.2 Välformade analyserade entiteter

Dokumententiteten är välformad om den överensstämmer med en dokument-definition. En extern generell analyserad entitet är välformad om den överensstämmer med definitionen av en extParsedEnt ["se nedan"]. Alla externa parameterentiteter är välformade per definition.

En intern generell analyserad entitet är välformad om dess ersättningstext överensstämmer med definitionen av innehåll. Alla interna parameterentiteter är välformade per definition.

En konsekvens av välutformning i generella entiteter är att den logiska och fysiska strukturen i ett XML-dokument är korrekt inkapslade; ingen starttagg, sluttagg, tomelementstagg, inget element, ingen kommentar, processinstruktion, teckenanrop eller entitetsanrop kan börja i en entitet och sluta i en annan.

4.3.3 Teckenkoder i entiteter

Varje extern analyserad entitet i ett XML-dokument FÅR använda olika koder för sina tecken. Alla XML-tolkar MÅSTE kunna läsa entiteter i både UTF-8 och UTF-16. Termerna "UTF-8" och "UTF-16" i denna specifikation är inte kopplade till teckenuppsättningar med utvidgningar, även om teckenuppsättningarna eller deras utvidgningar i mycket liknar UTF-8 eller UTF-16

Entiteter kodade i UTF-16 MÅSTE och entititeter i UTF-8 FÅR börja med den byteordningsmärkning ("Byte Order Mark") som är beskriven i Bilaga H i [ISO/IEC 10646:2000], avsnitt 2.4 i [Unicode] och avsnitt 2.7 i [Unicode3] (the ZERO WIDTH NO-BREAK SPACE character, #xFEFF). Detta är en kodsignatur, inte en del av vare sig uppmärkning eller teckendata i XML-dokumentet. XML-tolkar MÅSTE kunna använda detta tecken för att skilja mellan UTF-8- och UTF-16-kodade dokument.

Även om det bara krävs av en XML-tolk att den skall kunna läsa entiteter i UTF-8- och UTF-16-kodning, är det erkänt att andra teckenuppsättningar används runt om i världen och det kan bli önskvärt för XML-tolkar att kunna läsa entiteter som även använder sådana. I frånvaron av en extern teckenkodsinformation (som t.ex. MIME-huvuden) MÅSTE analyserade entiteter som lagras i en annan teckenkod än UTF-8 eller UTF-16 börja med en textdeklaration (se 4.3.1 Textdeklarationen) som innehåller en teckenkodsdeklaration:

I dokumententiteten är teckenkodsdeklarationen en del av XML-deklarationen. EncName ["Teckenkodsnamnet"] är namnet på den teckenuppsättning som används.

I en teckenkodsdeklaration BÖR värdena "UTF-8", "UTF-16", "ISO-10646-UCS-2" och "ISO-10646-UCS-4" användas för de olika teckenkoderna och transformationerna av Unicode /ISO/IEC 10646, värdena "ISO-8859-1", "ISO-8859-2", ... "ISO-8859-n" (där n är delnumret) BÖR användas för de aktuella delarna av ISO 8859 samt värdena "ISO-2022-JP", "Shift_JIS" och "EUC-JP" BÖR användas för de olika formerna för teckenkodning i JIS X-0208-1997. XML-tolkar får stödja andra teckenkoder. Det REKOMMENDERAS att teckenkoder förutom de nyss nämnda är registrerade (som charsets ["teckenuppsättningar"]) hos the Internet Assigned Numbers Autority [IANA-CHARSETS], skall anropas med sina registrerade namn. Andra teckenkoder BÖR använda namn som börjar med ett "x-"prefix. XML-tolkar BÖR kunna kontrollera teckenkoder oberoende av kast ["versaler eller gemener"] och BÖR endera kunna tolka ett IANA-registerat namn som den registerade teckenkoden hos IANA för det namnet eller behandla det som okänt (processorer måste naturligtvis inte stödja alla IANA-registerade teckenkoder).

I frånvaron av information från ett externt överföringsprotokoll (t.ex. HTTP eller MIME), är det ett kritiskt fel för en entitet som innehåller en teckenkodsdeklaration att presenteras för XML-tolken i en annan teckenkod än den som är angiven i deklarationen. Det är också ett fel för en entitet som varken börjar med en byteordningsmärkning ("Byte Order Mark") eller en teckenkodsdeklaration att använda någon annan teckenkod än UTF-8. Notera att eftersom ASCII är en delmängd av UTF-8, behöver normala ASCII-entiteter strikt sett inte en teckenkodsdeklaration.

Det är ett kritiskt fel om en extern textdeklaration förekommer någon annanstans än i början av en extern entitet.

Det är ett kritiskt fel när en XML-tolk möter en entitet med en teckenkod som den inte kan bearbeta. Det är ett kritiskt fel om en XML-entitet är bestämd (via ingångsvärde, teckenkodsdeklaration eller högnivåprotokoll) att vara i en viss teckenkod men innehåller byte-följder som inte är giltiga i den teckenkoden. I synnerhet är det ett kritiskt fel om en entitet kodad i UTF-8 innehåller några oregelbundna kodenhetsföljder, som defierats i Unicode 3.1 [Unicode3]. Om inte någon teckenkod är bestämd av ett högnivåprotokoll, är det också ett kritiskt fel om en XML-entitet inte innehåller någon teckenkodsdeklaration och dess innehåll inte är giltig UTF-8 eller UTF-16.

Exempel på textdeklarationer med teckenkodsdeklarationer:

4.4 Bearbetning av entiteter och anrop i en XML-tolk

Tabellen nedan summerar det sammanhang som teckenanrop, entitetsanrop och anrop av icke analyserade entiteter kan förekomma i och det OBLIGATORISKA beteendet hos en XML-tolk i respektive fall. Uttrycken i den vänstra kolumnen beskriver sammanhanget:

Anrop i innehåll

som ett anrop var som helst efter starttaggen och före sluttaggen i ett element; motsvarar begreppet innehåll.

Anrop i attributvärde

som ett anrop inom endera ett attributvärde i en starttagg eller ett ingångsvärde i en attributdeklaration; motsvarar begreppet attributvärde.

Finns som attributvärde

som ett namn - inte ett anrop - i endera ett attributvärde som har deklarerats som typen ENTITY eller som en av de datatyper i attributvärdet som åtskiljs med tomrum och som har deklarerats som typen ENTITIES.

Anrop i entitetsvärde

som ett anrop inom en parameter- eller en intern entitets entitetsvärdet inom anföringstecken i entitetsdeklarationen; motsvarar begreppet entitetsvärde.

Anrop i DTD

som ett anrop inom endera den interna eller den externa delmängden i DTDn, men utanför ett entitetsvärde, attributvärde, PI, kommentar, systemadress, allmän adress eller innehållet i ett förbisett villkorligt avsnitt (se 3.4 Villkorliga avsnitt).

4.4.1 Inte accepterat

Utanför DTDn har %-tecknet ingen särskild betydelse. Det som är ett parameterentitetsanrop i DTDn är således inte accepterat som uppmärkning i innehållet. På samma sätt är namn på icke analyserade entiteter inte accepterade, utom när de förekommer i värdet på ett korrekt deklarerat attribut ["deklarerat som ENTITY eller ENTITIES"].

4.4.2 Infogat

[Definition: En entitet är infogad när dess ersättningstext är återfunnen och bearbetad i stället för själva anropet som om den vore del av dokumentet på det ställe där anropet låg.] Ersättningstexten FÅR innehålla både teckendata och (utom för parameterentiteter) uppmärkning, som MÅSTE accepteras på vanligt sätt. (Strängen "AT&T;" expanderas till "AT&T;" och det återstående och-tecknet blir inte tolkat som ett skiljetecken för ett entitetsanrop.) Ett teckenanrop är infogat när det avsedda tecknet har placerats på platsen för själva anropet.

4.4.3 Infogat vid validering

När en XML-tolk accepterar ett anrop till en analyserad entitet, MÅSTE den, för att validera dokumentet, infoga entitetens ersättningstext. Om entiteten är extern och XML-tolken inte försöker validera XML-dokumentet, FÅR XML-tolken, men behöver inte, infoga entitetens ersättningstext. Om en icke-validerande XML-tolk underlåter att infoga ersättningstexten, MÅSTE den underrätta applikationen att den accepterade, men inte läste entiteten.

Denna regel är baserad på konstaterandet att den automatiska infogningen som SGMLs och XMLs entitetsmekanismer erbjuder för att i första hand stödja moduluppbyggt författande, inte nödvändigtvis är lämplig för andra applikationer - särskilt inte dokumentläsning ("-browsing"). En läsare som till exempel stöter på ett anrop till en extern analyserad entitet kan välja att erbjuda en visuell indikation på entitetens närvaro och hämta den för att endast visa på uppmaning.

4.4.4 Förbjudet

Följande är förbjudet och utgör kritiska fel:

• förekomsten av ett anrop till en icke analyserad entitet ["icke analyserade entiteter anropas med entitetsnamn"], utom i entitetsvärdet i en entitetsdeklaration.
• förekomsten av ett anrop till en teckenentitet eller en generell entitet i DTDn utom inom ett entitetsvärde eller attributvärde.
• ett anrop till en extern entitet i ett attributvärde ["som således inte är deklarerat som ENTITY eller ENTITIES"].

4.4.5 Infogat inom anföringstecken

När ett entitetsanrop förekommer i ett attributvärde, eller ett parameterentitetsanrop förekommer i ett entitetsvärde innanför anföringstecken, behandlas deras ersättningstext i stället för själva anropet som om de vore del av dokumentet på det ställe där anropet låg, utom att ett enkelt eller dubbelt anföringstecken i ersättningstexten alltid behandlas som normala datatecken och inte avslutar texten inom anföringstecknen. Till exempel är detta välutformat:

medan detta inte är:

4.4.6 Underrätta

När namnet på en icke analyserad entitet förekommer som en datatyp i värdet på ett attribut med den deklarerade typen ENTITY eller ENTITIES, MÅSTE en validerande XML-tolk underrätta applikationen för systemadressen eller den allmänna adressen (om det finns någon) om både entiteten och dess anknutna notation.

4.4.7 Överhoppat ("Bypassed")

När ett anrop till en generell entitet förekommer i entitetsvärdet i en entitetsdeklaration, blir det överhoppat och lämnat som den är.

4.4.8 Infogat som PE

Precis som med externa analyserade entiteter behöver parameterentiteter bara bli infogade vid validering. När ett parameterentitetsanrop är accepterat i DTDn och infogat, blir dess ersättningstext utökad med tillägg av ett inledande och ett avslutande blanktecken (#x20). Syftet är att begränsa ersättningstexten i parameterentiteter till att innehålla ett låst antal grammatiska begrepp i DTDn. Detta beteende är inte kopplat till parameterentitetsanrop inom entitetsvärden; dessa beskrivs i 4.4.5 Infogat inom anföringstecken.

4.4.9 Fel

Det är ett fel för ett anrop till en icke analyserad entitet att uppträda i entitetsvärdet i en entitetsdeklaration.

4.5 Konstruktion av ersättningstext för interna entiteter

Vid diskussionen om behandlingen av entiteter, är det lämpligt att urskilja två former av entitetsvärden. [Definition: För en intern entitet är entitetsvärdet inom anföringstecken den citerade strängen i entitetsdeklarationen motsvarande begreppet entitetsvärde.] [Definition: För en extern entitet, är literal entity value den exakta text som ligger i entiteten.] [Definition: För en extern entitet är ersättningstexten innehållet i entiteten när man har tagit bort textdeklarationen, om det finns någon (och lämnat kvar omgivande tomrum), men utan ersättning av teckenanrop och parameterentitetsanrop.]

På det sätt som entitetsvärdet inom anföringstecken är angivet i en intern entitetsdeklaration (entitetsvärde) FÅR det innehålla tecken-, parameterentiteter och generella entitetsanrop. Sådana anrop MÅSTE helt inkapslas i entitetsvärdet inom anföringstecknen. Den faktiska ersättningstexten som är infogad (eller infogad inom anföringstecken) på ovan angivet sätt, MÅSTE innehålla ersättningstexten från varje anropad parameterentitet och MÅSTE innehålla det anropade tecknet i stället för varje teckenanrop i entitetsvärdet inom anföringstecken. Emellertid MÅSTE generella entitetsanrop bli lämnade som de är, oexpanderade. Till exempel med följande deklarationer givna:

blir ersättningstexten för entiteten "book":

Om anropet till den generella entiteten "&rights;" skulle ha expanderats bör anropet "&book;" förekomma i dokumentets innehåll eller i ett attributvärde.

Dessa enkla regler kan få en komplex växelverkan. För en detaljerad diskussion om ett svårt exempel, se "D. Expansion av entitets- och teckenanrop".

4.6 Fördefinierade entiteter

[Definition: Entitets- och teckenanrop FÅR både användas för att undvika mindre-än-tecknet, och-tecknet och andra skiljetecken. En uppsättning av generella entiteter (amp, lt, gt, apos, quot) har specificerats för detta ändamål. Numeriska teckenanrop FÅR också användas; de blir omedelbart expanderade när de har accepterats och MÅSTE behandlas som teckendata. De numeriska teckenanropen "<" och "&" FÅR således användas för att undvika < och & när de uppträder i teckendata.]

Alla XML-tolkar MÅSTE acceptera dessa entiteter, oberoende av om de är deklarerade eller inte. För utbyte BÖR ett giltigt XML-dokument deklarera dessa entiteter precis som alla andra entiteter innan de används. Om entiteterna lt eller amp är deklarerade, MÅSTE de vara deklarerade som interna entiteter vilkas ersättningstext är ett teckenanrop till respektive tecken (mindre-än- och och-tecken) som undantas; det dubbla undantaget krävs för dessa entiteter så att anrop till dem ger ett välutformat resultat. Om entiteterna gt, apos eller quot deklareras, MÅSTE de deklareras som interna entiteter vilkas ersättningstext är det enstaka tecken som undantas (eller ett teckenanrop till det tecknet; det dubbla undantaget är här onödigt men harmlöst). Till exempel:

4.7 Notationsdeklarationer

[Definition: Notationer identifierar med namn formatet på icke analyserade entiteter, formatet på element som bär ett notationsattribut eller den applikation som en processinstruktion anropar.]

[Definition: Notationsdeklarationer anger ett namn på notationen för användning i entitets- och attribut-listdeklarationer och i attributspecifikationer samt en extern adress för den notation som får tillåta en XML-tolk eller dess klientapplikation att lokalisera en hjälpapplikation som kan bearbeta data i den angivna notationen.]

Giltighetsbegränsning: Unikt notationsnamn

Ett angivet namn FÅR INTE deklareras i mer än en notationsdeklaration.

XML-tolkar MÅSTE förse applikationer med namnet och de externa adresserna för alla notationer som deklarerats och som anropats i ett attributvärde, en attributdefinition eller en entitetsdeklaration. De FÅR dessutom lösa upp den externa adressen till en systemadress, ett filnamn eller annan information som är nödvändig för att tillåta applikationen att kalla på en behandlare av data i den beskrivna notationen. (Det är emellertid inte ett fel för XML-dokument att deklarera och anropa notationer för vilka notationsspecifika applikationer inte är tillgängliga inom det system där XML-tolken eller applikationen arbetar.)

4.8 Dokumententitet

[Definition: Dokumententiteten tjänar som rot för entitetsträdet och en startpunkt för en XML-tolk]. Denna specifikation specificerar inte hur dokumententiteten skall lokaliseras av en XML-tolk. I motsats till andra entiteter har dokumententiteten inget namn och kan mycket väl förekomma i inmatningsflödet hos en XML-tolk utan någon identifikation alls.

5 Konformitet

5.1 Validerande respektive icke-validerande XML-tolkar

Konforma XML-tolkar delar upp sig i två klasser; validerande respektive icke-validerande.

Såväl validerande som icke-validerande XML-tolkar MÅSTE rapportera överträdelser av välutformningsbegränsningar enligt denna specifikation från innehållet i dokumententiteten och alla andra analyserade entiteter som de läser.

[Definition: Validerande XML-tolkar MÅSTE på användarens initiativ kunna rapportera överträdelser av de begränsningar som uttryckts av deklarationerna i DTDn och varje icke uppfylld giltighetsbegränsning som angetts i denna specifikation.] För att uppnå det MÅSTE validerande XML-tolkar läsa och bearbeta hela DTDn och alla externa analyserade entiteter som anropats i dokumentet.

Icke-validerande XML-tolkar behöver bara analysera dokumententiteten, inklusive hela den interna DTD-delmängden med avseende på välutformning. [Definition: Eftersom de inte behöver analysera dokumentet med avseende på giltighet, är det OBLIGATORISKT för dem att bearbeta alla deklarationer de läser i den interna DTD-delmängden och i alla parameterentiter som de läser ända fram till det första anropet till en parameterentitet som de inte läser. Dvs de MÅSTE använda informationen i dessa deklarationer för att normalisera attributvärdena, infoga ersättningstexten för interna entiteter och förse attributen med ingångsvärden.] Med undantag för när standalone="yes", FÅR de INTE bearbeta entitetsdeklarationer eller attributlist-deklarationer som de möter efter ett anrop till en parameterentitet som inte är läst, eftersom entiteten kan ha innehållit övertrumfande deklarationer; när standalone="yes" MÅSTE XML-tolkar bearbeta dessa deklarationer.

Notera att när ogiltiga dokument bearbetas med en icke-validerande XML-tolk blir applikationen inte matad med konsistent information. T.ex. kan åtskilliga krav på unikhet inom dokumentet inte mötas, inklusive fler än ett element med samma id, dubbla deklarationer av element eller notationer med samma namn etc. I dessa fall blir beteendet hos tolken odefinierat med avseende på rapportering av sådan information till applikationen.

5.2 Användning av XML-tolkar

Beteendet hos en validerande XML-tolk är högst förutsägbart; den måste läsa varje del av ett dokument och rapportera alla välutformnings- och giltighetsöverträdelser. Mindre krävs av en icke-validerande XML-tolk; den behöver inte läsa någon annan del av dokumentet än dokumententiteten. Detta har två konsekvenser som kan vara viktiga för användare av XML-tolk:

• Vissa välutformningsfel, i synnerhet de som kräver inläsning av externa entiteter, kanske undgår att bli upptäckta av en icke-validerande XML-tolk. Exempel på detta inbegriper såväl begränsningar kallade deklarerad entitet, analyserad entitet och ingen rekursivitet som vissa av de fall som beskrivits som förbjudna i "4.4 Bearbetning av entiteter och anrop i en XML-tolk".
• Informationen som förmedlas av XML-tolken till applikationen kan variera, beroende på om XML-tolken läser parameter- och externa entiteter. T.ex. kanske en icke-validerande XML-tolk undgår att normalisera attributvärden, att infoga ersättningstexten för interna entiteter eller att ange ingångsvärden för attribut för avsnitt där det är avhängigt om den har läst deklarationer i parameter- eller externa entiteter.

För maximal tillförlitlighet i samarbetet mellan olika XML-tolkar BÖR applikationer som använder icke-validerande XML-tolkar INTE bygga på beteenden som inte krävs av sådana verktyg. Applikationer som kräver DTD-egenskaper som inte är knutna till validering, som användningen av deklaration av ingångsvärden för t.ex. attribut och interna entiteter, vilka förekommer eller kan förekomma i externa entiteter, BÖR använda validerande XML-tolkar.

6 Beteckningssätt

Den formella grammatiken i XML är given i denna specifikation genom en enkel användning av beteckningssättet Extended Backus-Naur Form (EBNF). Varje regel i grammatiken definierar ett begrepp i formen:

Begrepp är skrivna med en inledande versal om de är inledande symboler för ett reguljärt språk, annars med en inledande gemen ["liten bokstav"]. Innehållet i "literal strings" är placerat mellan anföringstecken.

Inom uttrycket som anges på högersidan av en regel används följande uttryck för att kontrollera överensstämmelse med strängar som innehåller ett eller flera tecken:

#xN

där N är ett hexadecimalt heltal; uttrycket ansluter till tecknet vars nummer (kodnummer) i ISO/IEC 10646 är N. Antalet inledande nollor i #xN-formen har ingen betydelse.

[-'()+,./:=?;!*#@$_%]

överensstämmer med något av de angivna tecknen.

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

överensstämmer något tecken med ett värde inom och inklusive det angivna intervallet/en.

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

överensstämmer med alla tecken med ett värde utanför det angivna intervallet.

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

överensstämmer med alla tecken med ett värde som inte är bland de angivna tecknen. Uppräkningar och intervall av förbjudna värden kan blandas inom en hakparentes.

"string"

överensstämmer med en "literal string" som överensstämmer med det som anges innanför citationstecknen.

'string'

överensstämmer med en "literal string" som överensstämmer med det som anges innanför apostroftecknen.

Dessa begrepp kan vara kombinerade för att överensstämma med mer komplexa mönster som nedan, där A och B representerar enkla uttryck:

(uttryck)

uttryck behandlas som en enhet och kan kombineras som beskrivs i denna lista.

A?

överensstämmer med A eller ingenting; valfritt A.

A B

överensstämmer med A följt av B. Denna operator har företräde framför alternering så att A B | C D är identisk med (A B) | (C D).

A | B

överensstämmer med A eller B.

A - B

överensstämmer med varje sträng som överensstämmer med A men inte överensstämmer med B.

A+

överensstämmer med en eller flera förekomster av A. Konkatenering har företräde framför alternering, så att A+ | B+ är identiskt med (A+) | (B+).

A*

överensstämmer med ingen, en eller flera förekomster av A. Konkatenering har företräde framför alternering, så att A* | B* är identiskt med (A*) | (B*).

Andra beteckningssätt som används i definitionerna är:

/* ... */

kommentar.

[ wfc: ... ]

välutformningsbegränsning ("well-formedness constraint"); detta identifierar namnet på en begränsning för välformade dokument anknuten till en definition.

[ vc: ... ]

giltighetsbegränsning ("validity constraint"); detta identifierar namnet på en begränsning för giltiga dokument anknuten till en definition.

Bilagor

A Referenser

A.1 Normativa referenser

IANA-CHARSETS

(Internet Assigned Numbers Authority) Official Names for Character Sets, ed. Keld Simonsen m.fl. Se http://www.iana.org/assignments/character-sets.

IETF RFC 1766

IETF (Internet Engineering Task Force). RFC 1766: Tags for the Identification of Languages, ed. H. Alvestrand. 1995. (Se http://www.ietf.org/rfc/rfc1766.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. (Se 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. (Se 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. (Se 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 and ISO/IEC 10646-2:2001. Information technology -- Universal Multiple-Octet Coded Character Set (UCS) -- Part 2: Supplementary Planes, liksom, från tid till annan, tillagd med, ersatt av en ny upplaga eller utökad med tillägg av nya delar. [Geneva]: International Organization for Standardization. (Se http://www.iso.ch/ för den senaste versionen.)

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, defined by: The Unicode Standard, Version 3.0 (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), liksom tillägget Unicode Standard Annex #27: Unicode 3.1 (http://www.unicode.org/reports/tr27/) och the Unicode Standard Annex #28: Unicode 3.2 (http://www.unicode.org/reports/tr28/)

A.2 Andra referenser

Aho/Ullman

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

Berners-Lee m.fl.

Berners-Lee, T., R. Fielding och L. Masinter. Uniform Resource Identifiers (URI): Generic Syntax and Semantics. 1997. (Pågående arbete; se uppdateringar till RFC1738.)

Brüggemann-Klein

Brüggemann-Klein, Anne. Formal Models in Document Processing. Habilitationsschrift. Matematikfakulteten vid Freiburgs universitet, 1993. (Se ftp://ftp.informatik.uni-freiburg.de/documents/papers/brueggem/habil.ps.)

Brüggemann-Klein och Wood

Brüggemann-Klein, Anne och Derick Wood. Deterministic Regular Languages. Universität Freiburg, Institut für Informatik, Bericht 38, Oktober 1991. Utvecklad artikel i A. Finkel, M. Jantzen, Hrsg., STACS 1992, S. 173-184. Springer-Verlag, Berlin 1992. Föreläsningsnoter i Computer Science 577. Full version med titeln One-Unambiguous Regular Languages i Information and Computation 140 (2): 229-253, February 1998.

Clark

James Clark. Comparison of SGML and XML. Se http://www.w3.org/TR/NOTE-sgml-xml-971215.

IANA-LANGCODES

(Internet Assigned Numbers Authority) Registry of Language Tags, ed. Keld Simonsen m.fl. (Se http://www.iana.org/assignments/language-tags.)

IETF RFC 2141

IETF (Internet Engineering Task Force). RFC 2141: URN Syntax, ed. R. Moats. 1997. (Se 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. (See 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. (Se http://www.ietf.org/rfc/rfc2781.txt.)

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). First edition -- 1986-10-15. [Geneva]: International Organization for Standardization, 1986.

ISO/IEC 10744

ISO (International Organization for Standardization). ISO/IEC 10744-1992 (E). Information technology -- Hypermedia/Time-based Structuring Language (HyTime). [Geneva]: International Organization for Standardization, 1992. Extended Facilities Annexe. [Geneva]: International Organization for Standardization, 1996.

WEBSGML

ISO (International Organization for Standardization). ISO 8879:1986 TC2. Information technology -- Document Description and Processing Languages. [Geneva]: International Organization for Standardization, 1998. (Se http://www.sgmlsource.com/8879rev/n0029.htm.)

XML Names

Tim Bray, Dave Hollander, and Andrew Layman, editors. Namespaces in XML. Textuality, Hewlett-Packard, and Microsoft. World Wide Web Consortium, 1999. (Se http://www.w3.org/TR/REC-xml-names/.)

B Teckenklasser

Med beaktande av de i Unicode-standarden definierade egenskaperna klassas tecken som bastecken (bl.a. innehåller dessa de alfabetiska tecknen i det latinska alfabetet), bildskriftstecken och kombinationstecken (bl.a. innehåller denna klass de flesta diakritiska tecknen ["accenter, ö-prickar osv"]). Siffror och skiljetecken är också representerade.

De teckenklasser som definierats här kan härledas från Unicodes teckendatabas enligt nedan:

• Inledningstecken på namn måste utgöras av en av kategorierna Ll, Lu, Lo, Lt, Nl.
• Namntecken utom inledningstecken måste utgöras av en av kategorierna Mc, Me, Mn, Lm eller Nd.
• Tecken inom kompatibilitetsområdet (compatibility area, dvs. med teckenkod större än #xF900 och mindre än #xFFFE) är inte tillåtna i XML-namn.
• Tecken som har en font eller kompatibilitetsupplösning (compatibility decomposition, dvs. de med en utformningstagg för kompatibilitet ("compatibility formatting tag" i fält 5 i databasen - markerade i fält 5 med ett inledande "<") är inte tillåtna.
• Följande tecken behandlas snarare som inledningstecken på namn än namntecken, därför att egenskapsfilen ("the property file") klassar dem som alfabetiska: [#x02BB-#x02C1], #x0559, #x06E5, #x06E6.
• Tecknen #x20DD-#x20E0 är uteslutna (i enlighet med Unicode 2.0, avsnitt 5.14).
• Tecknet #x00B7 klassas som ett skiljetecken, för att egenskapslistan identifierar det på det sättet.
• Tecknet #x0387 adderas som ett namntecken, därför att #x00B7 är dess kanoniska motsvarighet.
• Tecknen ':' och '_' är tillåtna som inledningstecken på namn.
• Tecknen '-' och '.' är tillåtna som namntecken.

C XML och SGML (icke normativt)

XML är utformat som en delmängd av SGML på så sätt att varje XML-dokument också bör vara ett godkänt ("conforming") SGML-dokument. För en detaljerad jämförelse av de ytterligare begränsningar som XML ger för dokument utöver de som finns i SGML, se [Clark].

D Expansion av entitets- och teckenanrop (icke normativt)

Denna bilaga innehåller några exempel som illustrerar en följd av identifieringar och expansioner av entitets- och teckenanrop, som har specificerats i "4.4 Bearbetning av entiteter och anrop i en XML-tolk".

Om DTDn innehåller deklarationen

kommer XML-tolken att acceptera teckenanropen när den tolkar entitetsdeklarationen och lösa upp dem innan den lagrar följande sträng som värde på entiteten "exempel":

Ett anrop i dokumentet till "&exempel;" kommer att göra att text analyseras på nytt, varvid start- och slut-taggarna i elementet "p" kommer att accepteras och de tre anropen accepteras och expanderas, vilket resulterar i ett "p"-element med följande innehåll (allt är data - inte skiljetecken eller uppmärkning):

Ett mer komplext exempel illustrerar reglerna och deras konsekvenser fullt ut. I följande exempel är radnumren enbart till för referens.

Detta producerar följande:

• på rad 4; referensen till tecken 37 expanderas omedelbart och parameterentiteten "xx" lagras i begreppstabellen med värdet "%zz;". Eftersom ersättningstexten inte blir återläst, accepteras inte anropet till parameterentiteten "zz". (Och det skulle vara ett fel om den accepterades, eftersom "zz" inte är deklarerad än.)
• på rad 5; teckenanropet "<" expanderas omedelbart och parameterentiteten "zz" lagras med ersättningstexten "<!ENTITY knepig "fel-benägen" >", som är en välformad entitetsdeklaration.
• på rad 6; referensen till "xx" accepteras och ersättningstexten för "xx" (nämligen "%zz;") analyseras. Anropet till "zz" accepteras i sin tur och dess ersättningstext ("<!ENTITY knepig "fel-benägen" >") analyseras. Den generella entiteten "knepig" har nu blivit deklarerad med ersättningstexten "fel-benägen".
• på rad 8; anropet till den generella entiteten "knepig" accepteras och den blir expanderad, så att det fulla innehållet i "test"-elementet blir den självbeskrivande (och ogrammatiska) strängen Detta prov visar en fel-benägen metod.

E Deterministiska innehållsmodeller (icke normativt)

Som angetts i 3.2.1 Elementinnehåll, krävs det att innehållsmodeller i elementtypsdeklarationer är deterministiska. Detta krav gäller för kompatibilitet med SGML (som kallar deterministiska innehållsmodeller "otvetydiga") ("unambiguous"); XML-tolkar som byggts för att använda SGML-system kan signalera en icke deterministisk innehållsmodell som fel.

T.ex. är innehållsmodellen ((b, c) | (b, d)) icke deterministisk, därför att givet ett inledande b kan inte XML-tolken avgöra vilket b i modellen som stämmer överens utan att titta i förväg för att se vilket element som följer efter b. I detta fall kan de två anropen till b reduceras till ett enda anrop, vilket ger modellen följande utseende (b, (c | d)). Ett inledande b överensstämmer nu tydligt bara med ett enda namn i innehållsmodellen. XML-tolken behöver inte titta i förväg för att se vad som följer; endera c eller d kommer att accepteras.

Mer formellt sett: en ändlig nivå-robot ("state automaton") kan skapas ur en innehållsmodell med användning av standardalgoritmer, t.ex. algoritm 3.5 i avsnitt 3.9 av Aho, Sethi och Ullman [Aho/Ullman]. I många sådana algoritmer skapas en tilläggsuppsättning för varje position i det reguljära uttrycket (dvs. för varje löv-nivå i syntaxträdet för det reguljära uttrycket). Om någon position har en tilläggsuppsättning i vilken mer än en åtföljande position har samma elementtypsnamn, är innehållsmodellen felaktig och får anges som ett fel.

Det finns algoritmer som tillåter att många, men inte alla, icke deterministiska innehållsmodeller får reduceras automatiskt till ekvivalenta deterministiska modeller; se Brüggemann-Klein 1991 [Brüggemann-Klein].

F Automatiskt fastställande av teckenuppsättningar (icke normativt)

XMLs teckenkodsdeklaration fungerar som en intern etikett på varje entitet, som anger vilken teckenuppsättning som används. Innan en XML-tolk emellertid kan läsa den interna etiketten, måste den uppenbarligen veta vilken teckenuppsättning som används - vilket är vad den interna etiketten försöker att ange. I det generella fallet är detta en hopplös situation. I XML är det emellertid inte helt hopplöst på grund av att XML begränsar det generella fallet på två sätt: varje tillämpning antas stödja bara en begränsad uppsättning teckenkoder och XMLs teckenkodsdeklaration är begränsad i position och innehåll för att kunna göra det möjligt att automatiskt fastställa den teckenuppsättning som används i varje entitet i normala fall. I många fall finns också andra källor för information tillgänglig utöver själva XML-dataflödet. Två fall kan urskiljas beroende på om XML-entiteten är presenterad för XML-tolken utan eller med någon åtföljande (extern) information. Vi betraktar det första fallet först.

F.1 Fastställande utan extern teckenkodsinformation

Eftersom varje XML-entitet som inte är åtföljd av en extern teckenuppsättningsinformation och som inte är i UTF-8- eller i UTF-16-format måste börja med en teckenkodsdeklaration i XML, i vilken de första tecknen måste vara '<?xml', kan varje godkänd XML-tolk efter två till fyra inmatade oktetter fastställa vilket av de åtföljande alternativen som gäller. När den läser denna lista, kan den ha hjälp av att veta att i UCS-4 motsvaras '<' av "#x0000003C" och '?' av "#x0000003F" samt byteordningsmärkningen som krävs för UTF-16-dataflöden är "#xFEFF". Notationen ## används för att utesluta alla bytevärden utom att två ## i rad inte kan vara 00.

Med ett byteordningsmärke:

Med ett byteordningsmärke:

Denna nivå av automatiskt fastställande är tillräcklig för att läsa teckenkodsdeklarationen i XML och tolka teckenuppsättningsidentifierare, som fortfarande är nödvändig för att urskilja de individuella medlemmarna i varje familj av kodningar (t.ex. att skilja UTF-8 från 8859 och delarna av 8859 från varandra eller att urskilja den specifika kodsidan i EBCDIC som används osv).

Eftersom innehållet i teckenkodsdeklarationen är begränsad till ASCII-tecknens repertoar (emellertid kodad), kan en XML-tolk tillförlitligt läsa hela teckenkodsdeklarationen så fort den har fastställt vilken kodfamilj som används. Eftersom i praktiken alla brett använda teckenkoder hamnar i en av kategorierna ovan, medger teckenkodsdeklarationen i XML en godtagbart tillförlitlig beskrivning av teckenuppsättningar, även då externa informationskällor på nivån för operativsystem eller överföringsprotokoll inte är tillförlitliga. Teckenkoder som UTF-7, som gör överladdad ("overloaded") användning av ASCII kan misslyckas med ett tillförlitligt fastställande.

När väl XML-tolken har fastställt den använda teckenuppsättningen, kan den agera på förväntat sätt genom att endera infoga en separat inmatningsrutin för varje alternativ eller kalla på själva konverteringsfunktionen för varje inmatat tecken.

Liksom varje egendefinierat system kommer teckenkodsdeklarationen i XML inte att fungera om varje mjukvara byter entitetens teckenuppsättning eller -kod utan att uppdatera teckenkodsdeklarationen. De som tillämpar teckenkodsrutiner bör vara försiktiga för att säkra tillförlitligheten i den interna och externa information som används för att beskriva entiteten.

F.2 Prioritieringar i närvaro av extern teckenkodsinformation

Det andra möjliga fallet uppkommer när XML-entiteten är åtföljd av teckenkodsinformation, som i vissa filsystem och nätverksprotokoll. När flera informationskällor är tillgängliga, bör deras inbördes prioritet och den angivna metoden för att lösa konflikter specificeras som en del av det högnivå-protokoll ("higher-level protocol") som används för XML. Referera, om möjligt till [IETF RFC 3023] eller dess efterföljare, som definierar text/xml- och application/xml-MIME-typerna och ger viss praktisk ledning. Av utbytesskäl är emellertid följande regler rekommenderade.

• Om en XML-entitet ligger i en fil, används byteordningsmärkningen samt teckenkodsdeklarationen (om den finns) för att bestämma teckenuppsättningen.

G W3Cs arbetsgrupp för XML ("W3C XML Working Group") (icke normativt)

Denna specifikation togs fram och godkändes för publicering av W3Cs arbetsgrupp för XML (WG). WGs godkännande av denna specifikation innebär inte nödvändigtvis att alla WG-medlemmar röstade för dess godkännande. De aktuella och tidigare medlemmarna av XML WG är:

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

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

H W3C XML Core Working Group (icke normativt)

Den andra upplagan av denna specifikation bereddes av the W3C XML Core Working Group (WG). Medlemmarna i arbetsgruppen vid tiden för publiceringen av denna upplaga var:

• Paula Angerstein, Vignette
• Daniel Austin, Ask Jeeves
• Tim Boland
• Allen Brown, Microsoft
• Dan Connolly, W3C (Staff Contact)
• John Cowan, Reuters Limited
• John Evdemon, XMLSolutions Corporation
• Paul Grosso, Arbortext (Co-Chair)
• Arnaud Le Hors, IBM (Co-Chair)
• Eve Maler, Sun Microsystems (Second Edition Editor)
• Jonathan Marsh, Microsoft
• MURATA Makoto (FAMILY Given), IBM
• Mark Needleman, Data Research Associates
• David Orchard, Jamcracker
• Lew Shannon, NCR
• Richard Tobin, University of Edinburgh
• Daniel Veillard, W3C
• Dan Vint, Lexica
• Norman Walsh, Sun Microsystems
• François Yergeau, Alis Technologies (Errata List Editor)
• Kongyi Zhou, Oracle