[This local archive copy is from the official and canonical URL, http://www.xml.se/xml/REC-xml-19980210-sv.html; please refer to the canonical source document if possible.]

Extensible Markup Language (XML) 1.0

REC-xml-19980210-sv

Extensible Markup Language (XML) 1.0

W3C-rekommendation 1998-02-10

Denna version:

http://www.w3.org/TR/1998/REC-xml-19980210

http://www.w3.org/TR/1998/REC-xml-19980210.xml

http://www.w3.org/TR/1998/REC-xml-19980210.html

http://www.w3.org/TR/1998/REC-xml-19980210.pdf

http://www.w3.org/TR/1998/REC-xml-19980210.ps

Senaste version:

http://www.w3.org/TR/REC-xml

Tidigare version:

http://www.w3.org/TR/PR-xml-971208

Redaktion:

Tim Bray (Textuality och Netscape) <tbray@textuality.com>

Jean Paoli (Microsoft) <jeanpa@microsoft.com>

C. M. Sperberg-McQueen (University of Illinois at Chicago) <cmsmcq@uic.edu>

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 dokument 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. W3C:s 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. En lista på aktuella W3C-rekommendationer och andra tekniska dokument finns på http://www.w3.org/TR.

Denna specifikation använder termen URI, som definierats av [Berners-Lee m.fl.] och som är under utveckling och förväntas uppdatera [IETF RFC1738] och [IETF RFC1808].

En lista på kända fel i denna specifikation finns tillgängliga på http://www.w3.org/XML/xml-19980210-errata.

Rapporter om fel i det engelska originalet till detta dokument görs till xml-editor@w3.org.

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älutformade 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 entitetsreferenser
    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älutformade, analyserade entiteter
        4.3.3 Teckenkoder i entiteter
    4.4 Bearbetning av entiteter och referenser i en XML-behandlare
        4.4.1 Inte accepterad
        4.4.2 Infogad
        4.4.3 Infogad vid giltighetstest
        4.4.4 Förbjudet
        4.4.5 Infogad inom anföringstecken
        4.4.6 Underrätta
        4.4.7 Överhoppad
        4.4.8 Infogad som PE
    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 XML-behandlare som testar respektive inte testar giltighet
    5.2 Användning av XML-behandlare
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 teckenreferenser (icke normativt)
E. Deterministiska innehållsmodeller (icke normativt)
F. Automatiskt fastställande av teckenuppsättningar (icke normativt)
G. W3Cs arbetsgrupp för XML (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.

En mjukvarumodul kallad en XML-behandlare ("XML processor") används för att läsa XML-dokument och ge tillgång till deras innehåll och struktur. Det förutsätts att en XML-behandlare arbetar under en annan modul kallad applikationen. Denna specifikation beskriver det beteende som krävs av en XML-behandlare 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 ska 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 ska hållas nere till ett absolut minimum, helst noll.
6. XML-dokument ska vara läsbara för det mänskliga ögat och tillräckligt lätta att förstå.
7. XMLs utformning skall 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 1766 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. I följande lista definieras de termer som används för att bygga upp definitionerna och för att beskriva aktiviteterna hos en XML-behandlare:

får ("may")

Godkända dokument och XML-behandlare kan men behöver inte uppträda som beskrivet.

måste ("must")

Godkända dokument och XML-behandlare måste uppträda som beskrivet; annars är de felaktiga

fel ("error")

Överträdelse av regler i denna specifikation; resultaten är odefinierade. Godkänd mjukvara får leta fram och rapportera fel och får därefter fortsätta sin bearbetning.

kritiskt fel ("fatal error")

Ett fel som en godkänd XML-behandlare måste upptäcka och rapportera till applikationen. Efter att ha upptäckt ett kritiskt fel, får XML-behandlaren 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-behandlaren 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-behandlaren 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).

användartillval ("at user option")

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

En regel som gäller för alla giltiga XML-dokument. Överträdelser av giltighetsbegränsningar är fel. De måste som användartillval kunna rapporteras av en XML-behandlare som utför giltighetskontroll ("validating").

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

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

överensstämma med ("match")

• (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. Som användartillval får XML-behandlare normalisera sådana tecken till någon kanonisk form. 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änsningen "giltigt element".

för kompatibilitet ("for compatibility")

En egenskap hos XML som enbart är inlagd för att säkra att XML blir kompatibelt med SGML.

för utbyte ("for interoperability")

En icke-bindande rekommendation inlagd för att öka chanserna för att XML-dokument ska kunna behandlas av de existerande installerade SGML-behandlare som föregick the WebSGML Adaptations Annex (bilaga till SGML).

2. Dokument

Ett dataobjekt är ett XML-dokument om det enligt definitionen i denna specifikation är välutformat ("wellformed"). Ett välutformat XML-dokument kan 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, teckenreferenser 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älutformade analyserade entiteter".

2.1 Välutformade XML-dokument

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älutformad.

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

1. Det innehåller ett eller flera element.
2. Det finns exakt ett element som kallas roten eller dokumentelementet, som inte i någon del får återkomma 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.

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

En analyserad entitet innehåller text, en följd av tecken, som kan representera endera uppmärkning eller teckendata. Ett tecken är en minsta textenhet, enligt specifikationen ISO/IEC 10646 [ISO/IEC 10646]. Tillåtna tecken är tabulatorsteg, returmatning, ny rad och de grafiska tecknen i Unicode och ISO/IEC 10646 samt ytterligare några tecken som innefattas i begreppet [2] Char. Användning av "kompatibilitetstecken", som definierats i sektion 6.8 i [Unicode], skall motverkas.

Mekanismen för att omvandla teckenkodsnummer till bitar kan variera från entitet till entitet. Alla XML-behandlare måste acceptera UTF-8- och UTF-16-koden i ISO/IEC 10646. 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".

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), returmatning, ny rad eller tabulatorsteg.

Tecken är traditionellt uppdelade i bokstäver, siffror och andra tecken. Bokstäver består av ett alfabetiskt eller stavelsebaserat tecken möjligen följt av ett eller flera kombinationstecken eller av ett bildskriftstecken. Fullständiga definitioner av de specifika tecknen i varje klass finns i "B. Teckenklasser".

Ett namn är en symbol ("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 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.

Notera: Tecknet kolon inom XML-namn är reserverat för experiment med namnrymder. Deras betydelse avses bli standardiserad inom en nära framtid, då de dokument som använder kolon i experimentsyfte kanske kommer att behöva uppdateras. (Det finns ingen garanti för att man kommer att anta en namnrymdsmekanism för XML med kolon som namnrymdsskiljetecken.) I praktiken betyder det att författare inte bör använda kolon i XML-namn utom i experiment med namnrymd, men att XML-behandlare bör acceptera kolon som ett namntecken.

En Nmtoken (namnsymbol, "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. Uppmärkning har formen av starttaggar, sluttaggar, tomma taggar, entitetsreferenser, teckenreferenser, kommentarer, skiljetecken för CDATA-avsnitt, dokumenttypsdeklarationer och processinstruktioner.

All text som inte är uppmärkning utgör dokumentets teckendata.

Och-tecknet (&) och mindre-än-tecknet (<) får, om de används som skiljetecken för uppmärkning, inom en kommentar, en processinstruktion eller ett CDATA-avsnitt, endast förekomma i teckenform. De är också tillåtna inom entitetsvärdet i en intern entitetsdeklaration; se "4.3.2 Välutformade analyserade entiteter". Om de behövs någon annanstans, måste de vara undantagna genom att antingen använda numeriska teckenreferenser 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 ">" eller av en teckenreferens, när den 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. 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, kan apostrofen eller det enkla anföringstecknet (') anges med "'" och citationstecknet eller det dubbla anföringstecknet (") med """.

2.5 Kommentarer

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-behandlare får, men behöver inte, möjliggöra för applikationen att gå igenom texten i kommentarerna. För kompatibilitet får strängen"--" (dubbel-bindestreck) inte förekomma inom kommentarerna.

Ett exempel på en kommentar:

2.6 Processinstruktioner

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 PImål.

2.7 CDATA-avsnitt

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

XML-dokument får, och skall, börja med en XML-deklaration som specificerar den XML-version som används. Här följer exempel på två fullständiga XML-dokument, välutformade men inte giltiga:

Versionsnummer "1.0" används för att ange överensstämmelse med denna version av specifikationen. Det är ett fel att i ett dokument använda värdet "1.0" om det inte överensstämmer med denna version av specifikationen. Det är the XML Working Group:s avsikt att ge senare versioner av denna specifikation andra nummer än "1.0", men denna avsikt anger inte ett löfte att producera några framtida versioner av XML, inte heller att använda en särskild nummerserie, om någon ny version skapas. Eftersom framtida versioner inte kan uteslutas, är denna konstruktion gjord som ett medel för att tillåta möjligheten av en automatisk versionshantering, om det skulle bli nödvändigt. XML-behandlare får signalera ett fel om de tar emot dokument med versioner angivna som de inte stödjer.

Uppmärkningens funktion i ett XML-dokument är att beskriva dess lagring och logiska struktur och att knyta attributvärde-par 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. 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.

Dokumenttypsdeklarationen i XML innehåller eller pekar på uppmärkningsdeklarationer som bildar en grammatik för en dokumentklass. Denna grammatik är känd som dokumenttypdefinitionen 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.

En uppmärkningsdeklaration är en elementtypsdeklaration, en attributlist-deklaration, en entitetsdeklaration eller en notationsdeklaration. Dessa deklarationer kan 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".

Uppmärkningsdeklarationerna kan 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.

Giltighetsbegränsning: Rotelementtyp

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 en parameterentitetsreferens, 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 parameterentitetsreferenser förekomma bara där uppmärkningsdeklarationer får förekomma, dock inte inom uppmärkningsdeklarationerna. (Detta gäller inte för referenser som förekommer i externa parameterentiteter eller den externa delmängden.)

På samma sätt som interna delmängder måste de externa delmängderna och varje extern parameterentitet som anropas i DTDn bestå av en serie av kompletta uppmärkningsdeklarationer av de typer som tillåts av begreppet markupdecl, blandade med tomrum eller parameterentitetsreferenser. Emellertid kan delar av innehållet i den externa delmängden eller i de externa parameterentiteterna villkorligt få förbises genom att använda en villkorsavsnitts-konstruktion. Detta är inte tillåtet i den interna delmängden. Den externa delmängden och varje extern parameterentitet som åberopas i DTDn måste överensstämma med begreppet extPE. Se 4.3.2 Välutformade analyserade entiteter.

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

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

Systemidentifikationen "hallå.dtd" ger URIn 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-behandlare till ett applikation. Entitetsdeklarationer och ingångs-("default")värden för attribut är exempel på detta. Den fristående dokumentdeklarationen, som kan 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.

I en fristående dokumentdeklaration anger värdet "yes" att det inte finns några uppmärkningsdeklarationer utanför dokumententiteten (varken i DTDns externa delmängd eller i en extern parameterentitet som är anropad av den interna delmängden) vilket får en negativ inverkan på den information som skickas från XML-behandlaren 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 referenser 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örutatt.

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 referenser till dessa entiteter förekommer i dokumentet eller
• attribut med värden som underkastas normalisering, där attributet förekommer i dokumentet med ett värde som byts ut som resultat av normalisering 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", enligt begreppet S i denna specifikation) 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 versionen av dokumentet. Å andra sidan är det vanligt att ha med ett "signifikant" tomrum som ska sparas i den framtagna ("delivered") versionen, till exempel i en dikt eller en källkod.

En XML-behandlare måste alltid vidarebefordra alla tecken i ett dokument som inte är uppmärkning till applikationen. En analyserande XML-behandlare 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 ska 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 enda möjliga värden är "default" ["ingångsvärde"] eller "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 ska 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 i det inkapslade elementet har angivits något annat värde på xml:space-attributet.

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 för en applikation får en XML-behandlare, om en extern analyserad entitet eller entitetsvärdet i en intern analyserad entitet innehåller endera de två tecknen "#xD#xA" eller det fristående tecknet #xD, endast skicka tecknet #xA till applikationen. (Detta sätt att arbeta kan vid inläsning av data lämpligen utföras genom att normalisera alla radbrytningar till #xA, före analysering.)

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

Langcode är en av följande:

• en tvåbokstavs-språkkod definierad i [ISO 639], "Codes for the representation of names of languages"
• en språkidentifiering registrerad hos the Internet Assigned Numbers Authority [IANA]; dessa börjar med förstavelsen "i-" (eller "I-")
• en språkidentifiering anvisad av användaren eller överenskommen mellan parter för privat bruk. Dessa koder måste börja med förstavelsen "x-" eller "X-" för att förhindra konflikt med namn som senare har standardiserats eller registrerats hos IANA.

Det får finnas ett godtyckligt antal subkod-segment. Om det första subkodsegmentet finns och subkoden består av två bokstäver, måste det vara en landskod från [ISO 3166], "Codes for the representation of names of countries." Om den första subkoden består av fler än två bokstäver, måste det vara en subkod registrerad hos [IANA] för språket i fråga, om inte Langcode börjar med förstavelsen "x-" eller "X-".

Det är brukligt att ange språkkoden i gemener och landskoden (om den finns) i versaler. Notera att dessa värden - till skillnad från namn i XML-dokument - är oberoende av kast ["om de är versaler eller gemener"].

Exempel:

Den deklarerade avsikten med xml:lang avses gälla alla attribut och innehållet i de 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.

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

men om det är lämpligt kan 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

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 kan 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.
2. Deklarationen överensstämmer med children och de ingående child-elementen hör till det språk som skapats av uttrycket i innehållsmodellen ["se begreppsdefinitionerna (47)-(50)"], med tomrum som möjligt tillval (tecken som överensstämmer med begreppet S) mellan varje par av child-element.
3. Deklarationen överensstämmer med mixed och innehållet består av teckendata och child-element med elementtyper som överensstämmer med namnen i innehållsmodellen.
4. Deklarationen överensstämmer med ANY och elementtyperna för alla child-element har deklarerats.

3.1 Starttaggar, sluttaggar och tomelementstaggar

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. Namn-AttValue["attributvärde"]-paren åberopas som elementens attributspecifikationer ("attribute specifications"), med namnet i varje par åberopat som attributnamnet och innehållet i AttValue (texten mellan '- eller "-anföringstecknen) som attributvärdet.

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

Inget attributnamn får förekomma mer än en gång i samma starttagg eller tomelementstagg.

Giltighetsbegränsning: Typ av attributvärde ("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 entitetsreferenser

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

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

Ersättningstexten för varje entitet som åberopats direkt eller indirekt i ett attributvärde (förutom "<") får inte innehålla <.

Ett exempel på en starttagg:

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:

Texten mellan starttaggen och sluttaggen kallas elementets innehåll:

Om ett element är tomt, måste det antingen representeras av en starttagg omedelbart följd av en sluttagg eller av en tomelementstagg. 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") måste tomelementstaggen användas och kan bara användas för element som är deklarerade som EMPTY.

Exempel på tomelement:

3.2 Elementtypsdeklarationer

I ett XML-dokument kan 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. Som användartillval, kan en XML-behandlare utfärda en varning när en deklaration nämner en elementtyp som inte är deklarerad, men det är inte ett fel.

En elementtypsdeklaration antar formen:

där namnet betecknar den deklarerade elementtypen.

Giltighetsbegränsning: Entydig elementtypsdeklaration

Ingen elementtyp får deklareras mer än en gång.

Exempel på elementtypsdeklarationer:

3.2.1 Elementinnehåll

En elementtyp har elementinnehåll när en sådan typ av element enbart får innehålla child-element (ingen teckendata), som kan men inte behöver vara åtskilda med tomrum (tecken som överensstämmer med begreppet S). 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 cps:

där varje namn är den elementtyp som 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 upprepningstecken samt överensstämmer med varje element i innehållet mot en elementtyp i innehållsmodellen. För kompatibilitet är det ett fel om ett element i dokumentet kan ö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 en parameterentitetsreferens förekommer i ett urval, en sekvens eller en blandad konstruktion, får för utbyte dess ersättningstext inte vara tom och varken det första eller det sista tecknet som inte är tomrum i ersättningstexten vara ett bindetecken ("connector") (| eller ,).

Exempel på elementinnehållsmodeller:

3.2.2 Blandat innehåll

En elementtyp har blandat innehåll när element av denna typ kan innehålla teckendata, valfritt ("optionally") blandat med child-element. I detta fall kan 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 bara förekomma inom starttaggar och tomelementstaggar. Begreppsdefinitionerna som används för att identifiera dem finns således i avsnitt "3.1". Attributlist-deklarationer kan 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").

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. Som användartillval kan en XML-behandlare 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 kan 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 kan en XML-behandlare som användartillval 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, en uppsättning symboltyper ("tokenized types") och uppräkningstyper. Strängtypen kan ha alla sorters literal data som värde; symboltyperna 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 Attributlistdeklarationer.

Giltighetsbegränsning: ID

Värdetypen ID måste överensstämma med namn-definitionen. Ett namn får inte förekomma fler ä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

Ingen elementtyp får 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: Namnsymbol

Värdetypen NMTOKEN måste överensstämma med namnsymbol-definitionen; värdetypen NMTOKENS måste överensstämma med namnsymboler.

Uppräkningsattribut kan 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 public identifiers, 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

Ingen elementtyp får ha mer än ett notationsattribut.

Giltighetsbegränsning: Uppräkning

Värden av denna typ måste överensstämma med en av namnsymbol-symbolerna i deklarationen.

För utbyte gäller att samma namnsymbol inte får 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-behandlare ska 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.Om deklarationen varken anger #REQUIRED eller #IMPLIED måste attributvärdet innehålla ett deklarerat ingångsvärde ("default value"). Nyckelordet #FIXED ["låst"] anger då att attributet alltid måste anta ingångsvärdet. Om ett ingångsvärde är deklarerat, när en XML-behandlare möter ett utelämnat attribut, måste den uppföra sig som om attributet vore närvarande med det deklarerade ingångsvärdet.

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: Godkänt ingångsvärde för attribut

Det deklarerade ingångsvärdet måste möta de lexikala begränsningarna för den deklarerade attributtypen.

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-behandlaren normalisera attributvärdet enligt följande:

• en teckenreferens bearbetas genom att mata in det åberopade tecknet i attributvärdet
• en entitetsreferens bearbetas genom att upprepat bearbeta ersättningstexten i entiteten
• ett tomrumstecken (#x20, #xD, #xA, #x9) bearbetas genom att mata in #x20 som normaliseringsvärde, med undantag av att endast ett ensamt #x20 matas in för en "#xD#xA"-sekvens som är del av en extern analyserad entitet eller entitetsvärdet hos en intern analyserad entitet
• andra tecken bearbetas genom att de får sina normaliserade värden

Om det deklarerade värdet inte är CDATA, måste XML-behandlaren 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).

Alla attribut som inte har någon inläst deklaration skall av en tolk som inte testar giltighet ["utan endast välutformning"] behandlas som om de vore deklarerade CDATA.

3.4 Villkorliga avsnitt

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

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. Notera att även innehållet i ignorerade villkorliga avsnitt måste, för att en analys ska vara tillförlitlig, läsas i ordning för att kunna upptäcka inkapslade villkorliga avsnitt och säkerställa att slutet på det yttersta (ignorerade) villkorliga avsnittet blir säkert upptäckt. 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.

Om nyckelordet för det villkorliga avsnittet är en parameterentitetsreferens, måste parameterentiteten ersättas med sitt innehåll innan XML-behandlaren bestämmer om den ska lyfta in eller förkasta det villkorliga avsnittet.

Ett exempel:

4. Fysiska strukturer

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-behandlaren och kan innehålla hela dokumentet.

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

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-behandlare 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 entitetsreferenser. Icke analyserade entiteter anropas med namn, givna i värdet på ENTITY- eller ENTITIES-attribut.

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. Parameterentiteter är analyserade entiteter för användning inom DTDn. Dessa två typer av entiteter använder olika former av referenser 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 entitetsreferenser

En teckenreferens 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 teckenreferenser måste det åberopade tecknet överensstämma med en definition av Char ["tecken"].

En entitetsreferens refererar till innehållet i en namngiven entitet. Referenser till analyserade generella entiteter använder och-tecken (&) och semikolon (;) som skiljetecken. Parameterentitetsreferenser använder procent-tecken (%) 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ågon parameterentitetsreferens eller ett dokument med "standalone='yes'", måste namnet i entitetsreferensen överensstämma med det i en entitetsdeklaration, med det undantaget att välutformade dokument inte behöver deklarera någon av följande entiteter: amp, lt, gt, apos, quot. Deklarationen av en parameterentitet måste föregå varje referens till den. På samma sätt måste deklarationen av en generell entitet föregå varje referens till den i form av ett ingångsvärde i en attributlist-deklaration. Notera att om entiteter är deklarerade i en extern delmängd eller i externa parameterentiteter, behöver inte ("not obligated to") en XML-behandlare som inte testar giltighet ["utan endast välutformning"] 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 entitetsreferensen överensstämma med det i en entitetsdeklaration. För utbyte måste 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 referens till den. På samma sätt måste deklarationen av en generell entitet föregå varje referens till den i form av ett ingångsvärde i en attributlist-deklaration.

Välutformningsbegränsning: Analyserad entitet

En entitetsreferens får inte innehålla namnet på en icke analyserad entitet. Icke analyserade entiteter får endast åberopas i attributvärden som deklarerats som ENTITY eller ENTITIES.

Välutformningsbegränsning: Ingen rekursivitet

En analyserad entitet får inte innehålla en rekursiv referens till sig själv, vare sig direkt eller indirekt.

Välutformningsbegränsning: I DTDn

Parameterentitetsreferenser får bara förekomma i DTDn.

Exempel på tecken- och entitetsreferenser:

Exempel på en parameterentitetsreferens:

4.2 Entitetsdeklarationer

Entiteter deklareras som följer:

Namnet identifierar entiteten i en entitetsreferens 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. Som användartillval kan en XML-behandlare utfärda en varning om entiteter är deklarerade flera gånger.

4.2.1 Interna entiteter

Om entitetsdefinitionen är ett EntityValue ["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 samma behandling av entitets- och teckenreferenser i the literal entity value ["en sträng avgränsad av anföringstecken"] kan krävas för att skapa korrekt ersättningstext: see "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

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.

SystemLiteral kallas entitetens systemidentifikation. Det är en URI, som får användas för att hämta in entiteten. Notera att hash-tecknet (#) och fragmentidentifikation som ofta används med URIer formellt sett inte är en del av själva URIn. En XML-behandlare får signalera ett fel om en fragmentidentifikation är angiven som en del av en systemidentifikation. 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. 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.

En XML-behandlare ska bearbeta ett icke-ASCII-tecken i en URI genom att representera tecknet i UTF-8 som en eller flera bytes och sedan växla dessa bytes genom det anvisade URI-förfarandet (dvs. genom att konvertera varje byte till %HH, där HH är den hexadecimala representationen av bytevärdet).

Som tillägg till en systemidentifikation kan en extern identifikation innehålla en public identifier. En XML-behandlare som försöker att tolka en entitets innehåll får använda en public identifier för att försöka att skapa en alternativ URI. Om XML-behandlaren inte kan göra det, måste den använda URIn såsom den 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 public identifier 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 får börja med en textdeklaration.

Textdeklarationen måste skrivas ut explicit, inte anges som referens till en analyserad entitet. I en extern analyserad entitet får en textdeklaration inte förekomma på annan plats än i början på entiteten.

4.3.2 Välutformade analyserade entiteter

Dokumententiteten är välutformad om den överensstämmer med en dokument-definition. En extern generell analyserad entitet är välutformad om den överensstämmer med definitionen av en extParsedEnt ["se nedan"]. En extern parameterentitet är välutformad om den överensstämmer med definitionen av en extPE. ["se nedan"]

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

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

4.3.3 Teckenkoder i entiteter

Varje extern analyserad entitet i ett XML-dokument kan använda olika koder för sina tecken. Alla XML-behandlare måste kunna läsa entiteter i endera UTF-8 eller UTF-16.

Entiteter kodade i UTF-16 måste börja med den byteordningsmärkning ("Byte Order Mark") som är beskriven i ISO/IEC 10646 Annex E och Unicode Appendix B (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-behandlare 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-behandlare att den ska 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-behandlare att kunna läsa entiteter som även använder sådana. Analyserade entiteter som lagras i en annan teckenkod än UTF-8 eller UTF-16 måste börja med en textdeklaration 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 skall 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-9" användas för de aktuella delarna av ISO 8859 samt värdena "ISO-2022-JP", "Shift_JIS" och "EUC-JP" användas för de olika formerna för teckenkodning i JIS X-0208-1997. XML-behandlare får stödja andra teckenkoder. Det rekommenderas att teckenkoder förutom de nyss nämnda som är registrerade (som charsets ["teckenuppsättningar"]) hos the Internet Assigned Numbers Autority [IANA], ska åberopas med sina registrerade namn. Notera att dessa registrerade namn är definierade som oberoende av kast ["om de är versaler eller gemener"], vilket innebär att XML-behandlare som stödjer dessa registrerade namn, ska kunna göra det oberoende av kast.

I frånvaron av information från ett externt överföringsprotokoll (t.ex. HTTP eller MIME), är det ett fel för en entitet som innehåller en teckenkodsdeklaration att presenteras för XML-behandlaren 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 fel om en extern textdeklaration förekommer någon annanstans än i början av en extern entitet.

Det är ett kritiskt fel ("fatal error") när en XML-behandlare möter en entitet med en teckenkod som den inte kan bearbeta.

Exempel på teckenkodsdeklarationer:

4.4 Bearbetning av entiteter och referenser i en XML-behandlare

Tabellen nedan summerar det sammanhang som teckenreferenser, entitetsreferenser och anrop av icke analyserade entiteter kan förekomma i och det nödvändiga beteeendet hos en XML-behandlare i respektive fall. Uttrycken i den vänstra kolumnen beskriver sammanhanget:

Referens i innehållet

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

Referens i attributvärde

som en referens 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 en referens - i endera ett attributvärde som har deklarerats som typen ENTITY eller som en av de symboler i attributvärdet som åtskiljs med tomrum och som har deklarerats som typen ENTITIES.

Referens i entitetsvärde

som en referens inom en parameter- eller en intern entitets entitetsvärde ["innanför anföringstecken"] i entitetsdeklarationen; motsvarar begreppet entitetsvärde.

Referens i DTD

som en referens inom endera den interna eller den externa delmängden i DTDn, men utanför ett entitetsvärde eller attributvärde.

4.4.1 Inte accepterad

Utanför DTDn har %-tecknet ingen särskild betydelse. Det som är en parameterentitetsreferens 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 Infogad

En entitet är infogad när dess ersättningstext är återfunnen och bearbetad i stället för själva referensen som om den vore del av dokumentet på det ställe där referensen 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, utom att ersättningstexten för entiteter som används för att undvika uppmärkningstecken (entiteterna amp, lt, gt, apos, quot) alltid behandlas som data. (Strängen "AT&T;" expanderas till "AT&T;" och det återstående och-tecknet blir inte tolkat som ett skiljetecken för en entitetsreferens.) En teckenreferens är infogad när det avsedda tecknet är bearbetat i stället för referensen.

4.4.3 Infogad vid giltighetstest

När en XML-behandlare accepterar en referens till en analyserad entitet, måste den, för att testa giltigheten ("validate") av dokumentet, infoga entitetens ersättningstext. Om entiteten är extern och XML-behandlaren inte försöker att testa giltigheten av XML-dokumentet, får XML-behandlaren, men behöver inte, infoga entitetens ersättningstext. Om en tolk som inte testar giltighet ["utan endast välutformning"] 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å en extern analyserad entitetsreferens 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 en referens till en icke analyserad entitet ["icke analyserade entiteter åberopas med entitetsnamn"].
• förekomsten av en tecken- eller en generell entitetsreferens i DTDn utom inom ett entitetsvärde eller attributvärde.
• en referens till en extern entitet i ett attributvärde ["som således inte är deklarerat som ENTITY eller ENTITIES"].

4.4.5 Infogad inom anföringstecken

När en entitetsreferens förekommer i ett attributvärde, eller en parameterentitetsreferens förekommer i ett entitetsvärde innanför anföringstecken, behandlas deras ersättningstext i stället för själva referensen som om de vore del av dokumentet på det ställe där referensen 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 symbol i värdet på ett attribut med den deklarerade typen ENTITY eller ENTITIES, måste en XML-behandlare som testar giltighet underrätta applikationen för system- eller public-identifikationen (om det finns någon) om både entiteten och dess anknutna notation.

4.4.7 Överhoppad ("Bypassed")

När en generell entitetsreferens förekommer i entitetsvärdet i en entitetsdeklaration, blir den överhoppad och lämnad som den är.

4.4.8 Infogad som PE

Precis som med externa analyserade entiteter behöver parameterentiteter bara bli infogade vid gitighetstest. När en parameterentitetsreferens är accepterad i DTDn och infogad, 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.

4.5 Konstruktion av ersättningstext för interna entiteter

Vid diskussionen om behandlingen av interna entiteter, är det nyttigt att urskilja två former av entitetsvärden. Entitetsvärdet inom anföringstecken är den citerade strängen i entitetsdeklarationen motsvarande begreppet entitetsvärde. Ersättningstexten är innehållet i entiteten efter ersättning av teckenreferenser och parameterentitetsreferenser.

På det sätt som entitetsvärdet inom anföringstecken är angivet i en intern entitetsdeklaration (EntityValue) kan det innehålla tecken-, parameterentiteter och generella entitetsreferenser. Sådana referenser måste helt inkapslas i entitetsvärdet inom anföringstecknen. Den faktiska ersättningstexten som är infogad på ovan angivet sätt, måste innehålla ersättningstexten från varje åberopad parameterentitet och måste innehålla det åberopade tecknet i stället för varje teckenreferens i entitetsvärdet inom anföringstecken. Emellertid måste generella entitetsreferenser bli lämnade som de är, oexpanderade. Till exempel med följande deklarationer givna:

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

Den generella entitetsreferensen "&rights;" skulle ha expanderats om referensen "&book;" hade förekommit 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 teckenreferenser".

4.6 Fördefinierade entiteter

Entitets- och teckenreferenser kan 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 teckenreferenser kan också användas; de blir omedelbart expanderade när de har accepterats och måste behandlas som teckendata. De numeriska teckenreferenserna "<" och "&" kan således användas för att undvika < och & när de uppträder i teckendata.

Alla XML-behandlare måste acceptera dessa entiteter, oberoende av om de är deklarerade eller inte. För utbyte skall ett giltigt XML-dokument deklarera dessa entiteter precis som alla andra entiteter innan de används. Om entiteterna i fråga är deklarerade måste de deklareras som interna entiteter vilkas ersättningstext är det enda tecken som ska undvikas eller som en teckenreferens till det tecknet, vilket visas nedan.

Notera att <- och &-tecknen i deklarationen av "lt" och "amp" har undvikits dubbelt för att möta kravet på att entitetsersättningar skall vara välutformade.

4.7 Notationsdeklarationer

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

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

XML-behandlare måste förse applikationer med namnet och de externa identifikationerna för alla notationer som deklarerats och som åberopats i ett attributvärde, en attributdefinition eller en entitetsdeklaration. De får dessutom lösa upp den externa identifikationen till en systemidentifikation, 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 åberopa notationer för vilka notationsspecifika applikationer inte är tillgängliga inom det system där XML-behandlaren eller applikationen arbetar.)

4.8 Dokumententitet

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

5. Konformitet

5.1 XML-behandlare som testar respektive inte testar giltighet

Konforma XML-behandlare delar upp sig i två klasser; sådana som testar respektive inte testar giltighet.

Såväl de XML-behandlare som testar giltighet som de som inte gör det 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.

XML-behandlare som testar giltighet måste rapportera överträdelser av de begränsningar som uttryckts av deklarationerna i DTDn och varje icke uppfylld giltighetsbegränsning som angivits i denna specifikation. För att uppnå det måste XML-behandlare som testar giltighet läsa och bearbeta hela DTDn och alla externa analyserade entiteter som åberopats i dokumentet.

XML-behandlare som inte testar giltighet behöver bara analysera dokumententiteten, inklusive hela den interna DTD-delmängden med avseende på välutformning. Eftersom de inte behöver analysera dokumentet med avseende på giltighet, måste de bearbeta alla deklarationer de läser i den interna DTD-delmängden och i alla parameterentiter som de läser ända fram till den första referensen 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 attraibuten med ingångsvärden. De får inte bearbeta entitetsdeklarationer eller attributlist-deklarationer som de möter efter en referens till en parameterentitet som inte är läst, eftersom entiteten kan ha innehållit övertrumfande deklarationer.

5.2 Användning av XML-behandlare

Beteendet hos en XML-behandlare som testar giltighet ä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 XML-behandlare som inte testar giltighet; 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-behandlare:

• Vissa välutformningsfel, i synnerhet de som kräver inläsning av externa entiteter, kanske inte blir upptäckta av en XML-behandlare som inte testar giltighet. 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 referenser i en XML-behandlare".
• Informationen som förmedlas av XML-behandlaren till applikationen kan variera, beroende på om XML-behandlaren läser parameter- och externa entiteter. T.ex. får inte en XML-behandlare som inte testar giltighet ["utan endast välutformning"] normalisera attributvärden, infoga ersättningstexten för interna entiteter eller ange ingångsvärden för attribut. Om den ändå gör det måste det vara avhängigt om den har läst deklarationer i parameter- eller externa entiteter.

För maximal tillförlitlighet i samarbetet mellan olika XML-behandlare skall applikationer som använder XML-behandlare som inte analyserar giltighet ["utan endast välutformning"] inte bygga på beteenden som inte krävs av sådana verktyg. Applikationer som kräver hjälpmedel som t.ex. användningen av ingångsvärden för attribut eller interna entiteter, som är deklarerade i externa entiteter, skall använda XML-behandlare som testar giltighet.

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 definierade av ett regelmässigt uttryck eller 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 i ISO/IEC 10646 vars kanoniska (UCS-4) kodvärde, tolkat som ett binärt tal utan förtecken ("unsigned"), har det angivna värdet. Antalet inledande nollor i #xN-formen är oväsentligt; antalet inledande nollor i det motsvarande kodvärdet styrs av den teckenkod som används och är inte betecknande för XML.

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

ö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 något tecken med ett värde utanför det angivna intervallet.

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

överensstämmer något tecken med ett värde som inte är bland de angivna tecknen.

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

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

A | B

överensstämmer med A eller B men inte båda.

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.

A*

överensstämmer med ingen, en eller flera förekomster av A.

/* ... */

kommentar.

[ wfc: ... ]

välutformningsbegränsning ("well-formedness constraint"); detta identifierar namnet på en begränsning för välutformade 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

(Internet Assigned Numbers Authority) Official Names for Character Sets, ed. Keld Simonsen m.fl. Se ftp://ftp.isi.edu/in-notes/iana/assignments/character-sets.

IETF RFC 1766

IETF (Internet Engineering Task Force). RFC 1766: Tags for the Identification of Languages, ed. H. Alvestrand. 1995.

ISO 639

(International Organization for Standardization). ISO 639:1988 (E). Code for the representation of names of languages. [Geneva]: International Organization for Standardization, 1988.

ISO 3166

(International Organization for Standardization). ISO 3166-1:1997 (E). Codes for the representation of names of countries and their subdivisions -- Part 1: Country codes [Geneva]: International Organization for Standardization, 1997.

ISO/IEC 10646

ISO (International Organization for Standardization). ISO/IEC 10646-1993 (E). Information technology -- Universal Multiple-Octet Coded Character Set (UCS) -- Part 1: Architecture and Basic Multilingual Plane. [Geneva]: International Organization for Standardization, 1993 (plus tillägg AM 1 through AM 7).

Unicode

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

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. Faculty of Mathematics at the University of Freiburg, 1993, available at ftp://ftp.informatik.uni-freiburg.de/documents/papers/brueggem/habil.ps

Brüggemann-Klein och Wood

A. Brüggemann-Klein und D. Wood. Deterministic Regular Languages. Extended abstract in A. Finkel, M. Jantzen, Hrsg., STACS 1992, S. 173-184. Springer-Verlag, Berlin 1992. Lecture Notes in Computer Science 577. Full version titled "One-Unambiguous Regular Languages" in 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.

IETF RFC1738

IETF (Internet Engineering Task Force). RFC 1738: Uniform Resource Locators (URL), ed. T. Berners-Lee, L. Masinter, M. McCahill. 1994.

IETF RFC1808

IETF (Internet Engineering Task Force). RFC 1808: Relative Uniform Resource Locators, ed. R. Fielding. 1995.

IETF RFC2141

IETF (Internet Engineering Task Force). RFC 2141: URN Syntax, ed. R. Moats. 1997.

ISO 8879

ISO (International Organization for Standardization). ISO 8879:1986(E). Information processing -- Text and Office Systems -- Standard Generalized Markup Language (SGML). First edition -- 1986-10-15. [Geneva]: International Organization for Standardization, 1986.

ISO/IEC 10744

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

B. 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 utan diakritiska tecken ["accenter, ö-prickar osv"]), ideografiska tecken och kombinationstecken (bl.a. innehåller denna klass de flesta diakritiska tecknen). Dessa klasser kombineras för att utforma klassen bokstäver ("letters"). 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, 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 giltigt XML-dokument också skall vara ett godkänt ("conformant") 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 teckenreferenser (icke normativt)

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

Om DTDn innehåller deklarationen

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

En referens 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 referenserna 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 referensen till parameterentiteten "zz". (Och det skulle vara ett fel om den accepterades, eftersom "zz" inte är deklarerad än.)
• på rad 5; teckenreferensen "<" expanderas omedelbart och parameterentiteten "zz" lagras med ersättningstexten "<!ENTITY knepig "fel-benägen" >", som är en välutformad entitetsdeklaration.
• på rad 6; referensen till "xx" accepteras och ersättningstexten för "xx" (nämligen "%zz;") analyseras. Referensen 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; referensen 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)

För kompatibilitet krävs det att innehållsmodeller i elementtypsdeklarationer blir deterministiska.

SGML kräver deterministiska innehållsmodeller (SGML kallar dem "otvetydiga"). XML-behandlare 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 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å referenserna till b reduceras till en enda referens, vilket ger modellen följande utseende (b, (c | d)). Ett inledande b överensstämmer nu tydligt bara med ett enda namn i innehållsmodellen. 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 regelrätta uttrycket (dvs. för varje löv-nivå i syntaxträdet för det regelrätta 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 teckenuppsättningsdeklaration fungerar som en intern etikett på varje entitet, som anger vilken teckenuppsättning som används. Innan en XML-behandlare 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 teckenuppsättningsdeklaration ä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-behandlaren utan eller med någon åtföljande (extern) information. Vi betraktar det första fallet först.

Eftersom varje XML-entitet som inte är i UTF-8- eller i UTF-16-format måste börja med en teckenuppsättningsdeklaration i XML, i vilken de första tecknen måste vara '<?xml', kan varje godkänd XML-behandlare 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".

• 00 00 00 3C: UCS-4, big-endian machine (1234-radföljd)
• 3C 00 00 00: UCS-4, little-endian machine (4321-radföljd)
• 00 00 3C 00: UCS-4, ovanlig oktett-radföljd (2143)
• 00 3C 00 00: UCS-4, ovanlig oktett-radföljd (3412)
• FE FF: UTF-16, big-endian
• FF FE: UTF-16, little-endian
• 00 3C 00 3F: UTF-16, big-endian, ingen byteordningsmärkning (och således, strikt sett, felaktigt)
• 3C 00 3F 00: UTF-16, little-endian, ingen byteordningsmärkning (och således, strikt sett, felaktigt)
• 3C 3F 78 6D: UTF-8, ISO 646, ASCII, en del av ISO 8859, Shift-JIS, EUC eller varje annan 7-bits, 8-bits eller uppsättning med blandad bitlängd som säkrar att ASCII-tecknen får sina normala positioner, sin längd och sina värden. Den aktuella teckenuppsättningsdeklarationen måste läsas för att fastställa vilken av dessa som gäller, men eftersom alla dessa teckenuppsättningar använder samma bit-mönster för ASCII-tecken, kan själva teckenuppsättningsdeklarationen läsas tillförlitligt
• 4C 6F A7 94: EBCDIC (i vissa fall måste den fulla teckenuppsättningsdeklarationen läsas för att klara ut vilken kodsida som används)
• andra: UTF-8 utan en teckenuppsättningsdeklaration eller om dataflödet annars är förvanskat, fragmenterat eller inslaget i en förpackning av något slag

(Den angivna algoritmen fungerar inte för UTF-7.)

Denna automatiska fastställelsenivå är tillräcklig för att läsa teckenuppsättningsdeklarationer i XML och tolka teckenkodsidentifieraren, som fortfarande är nödvändig för att urskilja de individuella medlemmarna i varje teckenkodsfamilj (dvs. att skilja UTF-8 från 8859 och delarna av 8859 från varandra eller att urskilja den specifika EBCDIC-kodsida som används, osv.).

Eftersom innehållet i teckenuppsättningsdeklarationen är begränsad till ASCII-tecken, kan en XML-behandlare tillförlitligt läsa hela teckenuppsättningsdeklarationen 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 teckenuppsättningsdeklarationen 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.

När väl XML-behandlaren 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 egen-definierat system kommer teckenuppsättningsdeklarationen i XML inte att fungera om varje mjukvara byter entitetens teckenuppsättning eller -kod utan att uppdatera teckenuppsättningsdeklarationen. De som tillämpar teckenkodsrutiner måste vara försiktiga för att säkra tillförlitligheten i den interna och externa information som används för att beskriva entiteten.

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, måste 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. Regler för den inbördes prioriteringen av den interna märkningen och MIME-typmärkningen i t.ex. ett externt protokollshuvud skall utgöra del av RFC-dokumentet som definierar MIME-typerna för text/xml och applikation/xml. Av utbytesskäl är emellertid följande regler rekommenderade.

• Om en XML-entitet ligger i en fil, används byteordningsmärkningen samt PIn för deklaration av teckenuppsättning (om de finns) för att bestämma teckenuppsättningen. All annan egenutveckling ("heuristics") och alla andra informationskällor är enbart till för att rätta till fel.
• Om en XML-entitet är åtföljd av en MIME-typ: text/xml, bestämmer teckenuppsättnings-parametern hos MIME-typen metoden för teckenkodning. All annan egenutveckling ("heuristics") och alla andra informationskällor är enbart till för att rätta till fel.
• Om en XML-entitet åtföljs av en MIME-typ: applikation/xml, används byteordningsmärkningen samt PIn för deklaration av teckenuppsättning (om de finns) för att bestämma teckenuppsättningen. All annan egenutveckling ("heuristics") och alla andra informationskällor är enbart till för att rätta till fel.

Dessa regler träder bara in i frånvaro av dokumentation av protokoll-nivån. I synnerhet när MIME-typerna text/xml och applikation/xml är definierade övertrumfar rekommendationerna i den relevanta RFCn dessa regler.

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 and 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 och 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.