Det här är en svensk översättning av W3Cs specifikation XML 1.0 (Fifth Edition) från den 26 november 2008. 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 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, XML 1.0 Second Edition Specification Errata, XML 1.0 Third Edition Specification Errata och XML 1.0 Fourth 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/2008/REC-xml-20081126, och denna svenska översättning på http://www.xml.se/xml/REC-xml-1_0-5th-ed-sv. 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 hakparenteser ["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 till erik.mjoberg(at)xml.se. 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.
Not: Den 7 februari 2013 modifierades denna specifikation på plats. Brutna länkar till RFC4646 och RFC4647 ersattes.
För uppdateringar av detta dokument hänvisas till rättningar, som kan innehålla normativa rättningar.
Se även översättningar.
Detta dokument finns även i dessa icke-normativa format: XML och XHTML med färgkodade revisionsangivelser.
Copyright © 2008 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3Cs regler för ansvar, varumärke och dokumentanvändning gäller.
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.
Detta avsnitt beskriver statusen för detta dokument då det publicerats. Andra dokument kan övertrumfa detta dokument. En lista på aktuella W3C-publikationer och den senaste revisionen av denna tekniska rapport finns i W3C technical reports index på http://www.w3.org/TR/.
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.
Detta dokument är en Rekommendation från W3C. Denna femte upplaga är inte en ny version av XML. 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-V10-4e-errata) i fjärde upplagan av XML 1.0, daterad den 16 augusti 2006. Speciellt lättar fel [E09] på restriktionerna för element- och attributnamn och möjliggör därigenom för slutanvändare att i XML 1.0 dra den väsentliga nyttan av det som hittills bara funnits i XML 1.1. Som en följd av detta blir många tänkbara dokument välformaterade som inte tidigare varit välformaterade och tidigare ogiltiga dokument, som använder de nu tillåtna tecknen i t.ex. ID-attribut, blir nu giltiga.
Denna upplaga övertrumfar föregående Rekommendation från W3C daterad den 16 augusti 2006.
Rapporter om fel i det engelska originalet till detta dokument görs till xml-editor@w3.org; arkiv finns tillgängliga. För att underlätta för läsare finns även XHTML med färgkodade revisionsangivelser. Den markerar särskilt varje ändring orsakad av ett fel i fellistan för den förra versionen med en länk till det aktuella felet i fellistan. De flesta av felen i fellistan anger en logisk grund för ändringen. Fellistan för denna femte upplaga finns tillgängliga på http://www.w3.org/XML/xml-V10-5e-errata.
En implementeringsrapport återfinns på http://www.w3.org/XML/2008/01/xml10-5e-implementation.html. En testserie upprätthålls som hjälp för att fastställa konformitet med denna specifikation.
Detta dokument har granskats av medlemmar i W3C, utvecklare av mjukvaror, andra W3C-grupper och ytterligare 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. I skapandet av en Rekommendation är W3Cs roll 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.
W3C håller en lista på patentupptäckter gjorda i samband med dokument från patentarbetsgruppen i W3C. Den sidan innehåller också instruktioner för upptäckter av patent. En person som har aktuell kunskap om ett patent som personen tror innehåller väsentliga anspråk skall avslöja informationen enligt avsnitt 6 av W3Cs patentpolicy.
1 Inledning
1.1 Ursprung
och mål
1.2 Terminologi
2 Dokument
2.1
välformaterade
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älformaterade,
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
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)
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.
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:
Denna specifikation bidrar, tillsammans med associerade standarder (Unicode [Unicode] och ISO/IEC 10646 [ISO/IEC 10646] för tecken, Internet BCP 47 [IETF BCP 47] och språkundertaggsregistret ("the Language Subtag Registry") [IANA-LANGCODES] för språkidentifieringstaggar), 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.
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:
[Definition: Ett dataobjekt är ett XML-dokument om det enligt definitionen i denna specifikation är välformaterat ("well-formed"). Ett XML-dokument är dessutom 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älformaterade analyserade entiteter".
[Definition: Ett textobjekt är ett välformaterat XML-dokument, om:]
dokument
, Dokument | ||||
|
För att ett dokument skall överensstämma med dokument
-beskrivning
förutsätts att:
[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
.]
[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 2.3 i [Unicode], skall motverkas.]
Teckenuppsättning | ||||||
|
Mekanismen för att omvandla teckenkodsnummer till bitar FÅR variera från entitet till entitet. Alla XML-tolkar MÅSTE acceptera UTF-8- och UTF-16-koden i [Unicode]. 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".
Not:
Författare av dokument uppmuntras att undvika "kompatibilitetstecken" ("compatibility characters"), som definieras i avsnitt 2.3 av [Unicode]. Även tecken definierade i följande intervall bör förhindras. De är antingen kontrolltecken eller permanent odefinierade Unicode-tecken:
[#x7F-#x84], [#x86-#x9F], [#xFDD0-#xFDEF], [#x1FFFE-#x1FFFF], [#x2FFFE-#x2FFFF], [#x3FFFE-#x3FFFF], [#x4FFFE-#x4FFFF], [#x5FFFE-#x5FFFF], [#x6FFFE-#x6FFFF], [#x7FFFE-#x7FFFF], [#x8FFFE-#x8FFFF], [#x9FFFE-#x9FFFF], [#xAFFFE-#xAFFFF], [#xBFFFE-#xBFFFF], [#xCFFFE-#xCFFFF], [#xDFFFE-#xDFFFF], [#xEFFFE-#xEFFFF], [#xFFFFE-#xFFFFF], [#x10FFFE-#x10FFFF].
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.
Tomrum | ||||
|
Not:
Närvaron av #xD i definitionen ovan upprätthålls enbart för bakåtkompatibilitet med den första upplagan. Följande förklaras även i 2.11 Hantering av radbrytning: Alla #xD-tecken som finns i ren teckenform i ett XML-dokument tas endera bort eller ersätts av #xA-tecken innan någon ny bearbetning görs. Det enda sättet att få ett #xD-tecken att överensstämma med denna definition är att använda teckenanrop i en sträng med entitetsvärde.
[Definition: Ett namn är en Namntyp ("Nmtoken") med en begränsad uppsättning av inledande tecken.] Otillåtna inledande tecken för namn inbegriper siffror, diakritiska tecken, punkt och bindestreck.
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.
Not:
Rekommendationen Namespaces in XML [XML Names] anger en innebörd hos namn som innehåller kolontecken. Därför bör författare inte använda kolon i XML-namn utom av namnrymdsskäl, men XML-tolk måste acceptera kolon som ett namntecken.
Det första tecknet i ett namn MÅSTE vara ett NameStartChar ["namnstarttecken"] och alla andra tecken MÅSTE vara NameChars["namntecken"]. Denna mekanism används för att hindra namn från att inledas med europeiska (ASCII) siffror eller med enkla kombinationstecken. Nästan alla tecken tillåts i namn, utom de som är eller rimligen kan kan användas som skiljetecken. Avsikten är att vara inräknande hellre än uteslutande, så att teckensystem som ännu inte är kodade i Unicode kan användas i XML-namn. Se J Förslag till XML-namn för förslag till att skapa namn.
Dokumentförfattare uppmuntras att använda namn som är meningsfulla ord eller kombinationer av ord i naturliga språk och att undvika symboliska eller tomrums-tecken i namn. Notera att KOLON, BINDESTRECK/MINUS, PUNKT, UNDERSTRECK och MITTPUNKT["·"] UTTRYCKLIGEN TILLÅTS.
ASCII-symboler och interpunktionstecken, tillsammans med en ganska stor grupp symboltecken i Unicode, utesluts från namn eftersom de är mer användbara som skiljetecken i sammanhang där XML-namn används utanför XML-dokument; förutsatt att denna grupp ger de sammanhangen klara garantier om vad som inte får vara del av ett XML-namn. Tecknet #x037E, GREKISKT FRÅGETECKEN, utesluts eftersom det blir ett semikolon när det normaliseras, vilket kan ändra innebörden i ett entitetsanrop.
Namn och namntyper | ||||||||||||||||||||||||
|
Not:
Names- och Nmtokens-definitionerna används för att efter normalisering definiera giltigheten hos attribut med namntypsvärden (se 3.3.1 Attributtyper).
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.
Literal data | ||||||||||||||||||||||||||||
|
Not:
Även om entitetsvärde-definitionen tillåter definitionen
av en entitet som består av en ensam explicit <
inom
anföringstecken (t.ex., <!ENTITY mylt "<">
),
rekommenderas starkt att undvika en sådan tillämpning eftersom varje anrop
till den entiteten kommer att orsaka ett välformateringsfel.
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 ""
".
Teckendata | ||||
|
[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.
Kommentarer | ||||
|
Ett exempel på en kommentar:
<!-- deklarationer för <huvud> &
<text> --> |
Notera att grammatiken inte tillåter en kommentar som slutar med
--->
. Följande exampel är inte välformaterat.
<!-- B+, B, eller B---> |
[Definition: Processinstruktioner (PIer) låter ett dokument innehålla instruktioner för applikationer.]
Processinstruktioner | ||||||||
|
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.
[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 "]]>
":]
CDATA-avsnitt | ||||||||||||||||
|
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:
<![CDATA[<hälsning>Hallå världen!</hälsning>]]>
|
[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älformaterat men inte giltigt:
<?xml version="1.0"?>
|
liksom detta:
<hälsning>Hallå världen!</hälsning> |
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.
Prolog | ||||||||||||||||||||||||
|
Även om VersionNum-definitionen överensstämmer med alla versionsnummer av formen '1.x', BÖR INTE XML 1.0-dokument ange ett annat versionsnummer än '1.0'.
Not:
När en XML 1.0-tolk stöter på ett dokument som specificerar ett 1.x-versionsnummer annat än '1.0', ska den berbeta det som ett 1.0-dokument. Det innebär att en XML 1.0-tolk godtar 1.x-dokument förutsatt att de inte har egenskaper som inte tillhör 1.0 ("non-1.0 features").
[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älformaterings- och giltighetsbegränsningar nedan. För ytterligare information, se "4. Fysiska strukturer".
Dokumenttypsdefinition | |||||||||||||||||||||||||||||
|
Notera att det är möjligt att konstruera ett välformaterat 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.
Namn
et
i dokumenttypsdeklarationen MÅSTE överensstämma med elementtypen hos rotelementet.markupdecl
ovan) ingår i ersättningstexten för ett
parameterentitetsanrop, MÅSTE båda ingå i samma
ersättningstext.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.
Extern delmängd | ||||||||
|
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:
<?xml version="1.0"?>
|
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:
<?xml version="1.0" encoding="UTF-8" ?>
|
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.
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).]
Fristående dokumentdeklaration | ||||||
|
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.
no
" om
någon extern uppmärkningsdeklaration innehåller deklarationer av:
amp
, lt
, gt
,
apos
, quot
), om anrop till
dessa entiteter förekommer i dokumentet eller Ett exempel på en XML-deklaration med en fristående dokumentdeklaration:
<?xml
version="1.0" standalone='yes'?> |
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:
<!ATTLIST dikt
xml:space (default|preserve) 'preserve'>
|
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.
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.
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:
<p xml:lang="en">The quick brown fox jumps over the lazy dog.</p>
|
Det språk som anges av xml:lang
gäller för det element där det är
angivet (inklusive attributvärdena) och för alla element i elementinnehållet, 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"). Applikationer bestämmer vilket av ett elements
attributvärden och vilka delar elementets teckeninnehåll, om det finns något,
som ska behandlas som språkberoende värden angivna av xml:lang
.
Not:
Språkinformation kan också anges genom externa transportprotokoll
(t.ex. HTTP eller MIME). Om den är tillgänglig, kan informationen användas av
XML-applikationer, men den mer lokala informationen angiven av xml:lang
bör anses övertrumfa den.
En enkel deklaration för xml:lang
kan se ut så här:
xml:lang CDATA #IMPLIED |
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:
<!ATTLIST dikt
xml:lang CDATA 'fr'>
|
[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.
Element | ||||||||||||||||
|
Denna specifikation utgör inte någon applikationsbegrä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.
Namn
et
i ett elements sluttagg MÅSTE överensstämma med elementtypen i starttaggen.elementdecl
["elementdeklarationen"] där namn
et
överensstämmer med elementtypen och ett av följande villkor gäller:
EMPTY
och elementet har inte
något innehåll (inte ens entitetsanrop, kommentarer,
processinstruktioner eller tomrum).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. mixed
,
och innehållet (efter ersättning av alla entitetsanrop med deras ersättningstext)
består av teckendata (inklusive CDATA-avsnitt), kommentarer, processinstruktioner och child-element
med elementtyper som överensstämmer med namnen i innehållsmodellen. ANY
och innehållet (efter
ersättning av alla entitetsanrop med deras ersättningstext) består av
teckendata, CDATA-avsnitt,
kommentarer, processinstruktioner
och child-element vilkas typer har deklarerats.[Definition: Början på varje XML-element, som inte är ett tomelement, är markerad med en starttagg ("start-tag").]
Starttagg | ||||||||||||||||||||||||
|
Namn
et
i start- och sluttaggarna anger elementets typ. [Definition: Namn
-AttValue
["attributvärde"]-paren
anropas som elementens attributspecifikationer ("attribute
specifications")], [Definition: med namn
et
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.
<
-tecken i attributvärdet<
.Ett exempel på en starttagg:
<termdef id="dt-hund"
term="hund"> |
[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:]
Sluttagg | ||||
|
Ett exempel på en sluttagg:
</termdef> |
[Definition: Texten mellan starttaggen och sluttaggen kallas elementets innehåll:]
Elementinnehå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 | ||||||
|
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:
<IMG align="left" |
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:]
Elementtypsdeklaration | ||||||||||
|
där namn
et
betecknar den deklarerade elementtypen.
Exempel på elementtypsdeklarationer:
<!ELEMENT br EMPTY>
|
[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") (cp
s), som
består av namn samt urvalslistor ("choice lists") eller sekvenslistor ("sequence
lists") med innehållsdelar:
Elementinnehållsmodeller | ||||||||||||||||||||
|
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".
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:
<!ELEMENT spec (front, body, back?)>
|
[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:
Deklaration av blandat innehåll | ||||||
|
där namn
en
anger de elementtyper som får förekomma som children. Nyckelordet PCDATA härrör
historiskt från termen "parsed character data" ["analyserad teckendata"].
Exempel på deklarationer av blandat innehåll:
<!ELEMENT p (#PCDATA|a|ul|b|i|em)*>
|
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:
[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:]
Attributlist-deklaration | ||||||||
|
Namn
et
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. Namn
et
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.
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; namntyperna är mer begränsade. Giltighetsbegränsningarna som angetts i
grammatiken tillämpas efter det att attributvärdet har normaliserats enligt avsnitt 3.3.3 Normalisering av attributvärden.
Attributtyper | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
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. #IMPLIED
eller #REQUIRED
som deklarerat ingångsvärde.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.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.NMTOKEN
MÅSTE överensstämma med namntyp
s-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:
Uppräkningsattributtyper | |||||||||||||||
|
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.
namn
-typ ("tokens")namntyp
s-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.
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.
Ingångsvärden för attribut | |||||||||||||||||||||||||||||
|
#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.]
#REQUIRED
["obligatorisk"] MÅSTE attributet specificeras för
alla element med den angivna attributtypen i attributlist-deklarationen.av typen IDREF eller ENTITY måste överensstämma med Namn-definitionen;
av typen IDREFS or ENTITIES måste överensstämma med Namn- ("Names")definitionen;
av typen NMTOKEN måste överensstämma med Nmtoken-definitionen;
av typen NMTOKENS måste överensstämma med Nmtokens-definitionen;
av uppräkningstyp (antingen en NOTATIONstyp eller en uppräkning) måste överensstämma med ett av de uppräknade värdena.
#FIXED
, MÅSTE exempel på attributet överensstämma med
ingångsvärdet.Exempel på attributlist-deklarationer:
<!ATTLIST termdef |
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.
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 "
"> <!ENTITY a "
"> <!ENTITY da "
"> |
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.
Attributspecifikation | a är NMTOKENS | a är CDATA |
---|---|---|
a="xyz" |
x y z |
#x20 #x20 x y z |
a="&d;&d;A&a; &a;B&da;" |
A #x20 B |
#x20 #x20 A #x20 #x20 #x20 B #x20 #x20 |
a="

A

B
" |
#xD #xD A #xA #xA B #xD #xA |
#xD #xD A #xA #xA B #xD #xA |
Notera att det sista exemplet inte är giltigt (men välformaterat) om a
är
deklarerat som typen NMTOKENS.
[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.]
Villkorliga avsnitt | |||||||||||||||||||||||||
|
<![
", "[
", 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:
<!ENTITY % utkast 'INCLUDE' >
|
[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.
[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.]
Teckenanrop | ||||||
|
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.]
Entitetsanrop | ||||||||||||||||||||||||||||||||||||||||||||||
|
Välformateringsbegränsning: Deklarerad entitet
standalone='yes'
", MÅSTE för ett entitetsanrop som inte förekommer i
den externa delmängden eller en parameterentitet namn
et 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älformaterade 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.standalone='no'
"
är specificerat eller det inte finns någon fristående deklaration),
det angivna namn
et 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.ENTITY
eller ENTITIES
.Exempel på tecken- och entitetsanrop:
Tryck på <tangent>mindre än</tangent>
(<) för att spara alternativ.
|
Exempel på ett parameterentitetsanrop:
<!-- deklarera parameterentiteten "ISOLat2"...
--> |
[Definition: Entiteter deklareras som följer:]
Entitetsdeklaration | ||||||||||||||||||||
|
Namn
et
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.
[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:
<!ENTITY Pub-Status "Detta är en
förhandspublicering av specifikationen."> |
[Definition: Om en entitet inte är intern, är det en extern entitet, som deklareras enligt följande:]
Extern entitetsdeklaration | ||||||||||||||
|
Om NDataDecl
föreligger, handlar det om en generell icke
analyserad entitet, annars är det en analyserad entitet.
Namn
et 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 3986]),
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 3986], 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:
%
HH, där HH
är den hexadecimala representationen av bytevärdet).[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:
<!ENTITY open-hatch |
Externa analyserade entiteter BÖR var och en börja med en textdeklaration.
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.
Dokumententiteten är välformaterad om den överensstämmer med en dokument
-definition.
En extern generell analyserad entitet är välformaterad om den överensstämmer med
definitionen av en extParsedEnt
["se nedan"]. Alla externa parameterentiteter är välformaterade per definition.
Not:
Endast analyserade entiteter som anropas direkt eller indirekt i dokumentet behöver vara välformaterade.
Välformaterad extern analyserad entitet | ||||
|
En intern generell analyserad entitet är välformaterad om dess ersättningstext
överensstämmer med definitionen av innehåll
.
Alla interna parameterentiteter är välformaterade per definition.
En konsekvens av välformatering 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.
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 närbesläktade teckenuppsättningar, som inbegriper, men inte begränsas till UTF-16BE, UTF-16LE eller CESU-8.
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 16.8 i [Unicode] (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.
Om ersättningnstexten för en extern entitet skall börja med tecknet U+FEFF och ingen textdeklaration finns med, MÅSTE en byteordningsmärkning ("Byte Order Mark") finnas med, vare sig entiteten är kodad i UTF-8 eller UTF-16.
Ä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:
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 felutformade kodenhetsföljder, som defierats i avsnitt 3.9 Unicode [Unicode]. 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:
<?xml encoding='UTF-8'?> |
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:
innehåll
. attributvärde
. 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
. entitetsvärde
. entitetsvärde
,
attributvärde
,
PI, kommentar, systemadress,
allmän adress
eller innehållet i ett förbisett villkorligt avsnitt (se 3.4
Villkorliga avsnitt).Entitetstyp | Tecken | ||||
Parameter | Intern generell |
Extern analyserad generell |
Icke analyserad | ||
Anrop innehåll |
Inte accepterat | Infogat | Infogat vid validering |
Förbjudet | Infogat |
Anrop i attributvärde |
Inte accepterat | Infogat inom anföringstecken |
Förbjudet | Förbjudet | Infogat |
Finns som attributvärde |
Inte accepterat | Förbjudet | Förbjudet | Underrätta | Inte accepterat |
Anrop i entitetsvärde |
Infogat inom anföringstecken |
Överhoppat | Överhoppat | Fel | Infogat |
Anrop i DTD |
Infogat som PE | Förbjudet | Förbjudet | Förbjudet | Förbjudet |
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
"].
[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.
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.
Följande är förbjudet och utgör kritiska fel:
entitetsvärde
eller attributvärde
. ENTITY
eller ENTITIES
"].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älformaterat:
<!ENTITY % JN '"Ja"' >
|
medan detta inte är:
<!ENTITY EndAttr "27'" >
|
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.
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.
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.
Det är ett fel för ett anrop till en icke analyserad entitet att uppträda i entitetsvärdet i en entitetsdeklaration.
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:
<!ENTITY % pub
"Éditions Gallimard" >
|
blir ersättningstexten för entiteten "book
":
La Peste: Albert Camus,
|
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".
[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älformaterat 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:
<!ENTITY lt "&#60;">
|
[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.]
Notationsdeklarationer | ||||||||
|
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.)
[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.
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älformateringsbegrä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älformatering. [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.
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älformaterings- 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:
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.
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 ::= uttryck |
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
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. [a-zA-Z]
, [#xN-#xN]
[abc]
, [#xN#xN#xN]
[^a-z]
, [^#xN-#xN]
[^abc]
, [^#xN#xN#xN]
"string"
'string'
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?
A
eller ingenting; valfritt
A
. A B
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
A
eller B
. A - B
A
men
inte överensstämmer med B
. A+
A
.
Konkatenering har företräde framför alternering, så att A+ | B+
är
identiskt med (A+) | (B+)
.A*
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:
/* ... */
[ wfc: ... ]
[ vc: ... ]
På grund av ändringar i definitionerna [4] och [5], är definitionerna i denna bilaga isolerade ("orphaned") och används inte längre för att bestämma namntecken. Denna bilaga kan komma att tas bort i en framtida upplaga av denna specifikation; andra specifikationer som önskar referera till definitionerna här bör göra det via en hänvisning till relevant(a) definition(er) i fjärde upplagan av denna specifikation.
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.
Tecken | ||||||||||||||||||||||||
|
De teckenklasser som definierats här kan härledas från Unicodes teckendatabas enligt nedan:
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].
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
<!ENTITY exempel
"<p>Ett och-tecken (&#38;) får undvikas
|
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
":
<p>Ett och-tecken (&) får undvikas
|
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 och-tecken (&) får undvikas
|
Ett mer komplext exempel illustrerar reglerna och deras konsekvenser fullt ut. I följande exempel är radnumren enbart till för referens.
1 <?xml version='1.0'?>
|
Detta producerar följande:
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.) <
" expanderas omedelbart och
parameterentiteten "zz
" lagras med ersättningstexten
"<!ENTITY knepig "fel-benägen" >
", som är en välformaterad
entitetsdeklaration. 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
". 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. I följande exempel
<!DOCTYPE foo [
|
är ersättningstexten för x de fyra tecknen "<" därför att anrop till generella entiteter i entitetsvärden blir överhoppade. Ersättningstexten för lt är ett teckenanrop till "mindre än"-tecknet, till exempel de fem tecknen "<" (se 4.6 Fördefinierade entiteter). Eftersom inget av dessa innehåller ett "mindre än"-tecken blir resultatet välformaterat.
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].
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 kommer att se på fallen i tur och ordning.
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:
00 00 FE FF |
UCS-4, big-endian machine (1234 order) |
FF FE 00 00 |
UCS-4, little-endian machine (4321 order) |
00 00 FF FE |
UCS-4, ovanlig oktettordning (2143) |
FE FF 00 00 |
UCS-4, ovanlig oktettordning (3412) |
FE FF ## ## |
UTF-16, big-endian |
FF FE ## ## |
UTF-16, little-endian |
EF BB BF |
UTF-8 |
Med ett byteordningsmärke:
00 00 00 3C |
UCS-4 eller andra koder med kodenheter på 32-bitar och ASCII-tecken kodade som ASCII-värden, i respective big-endian (1234), little-endian (4321) och två ovanliga byteordningar (2143 och 3412). Teckenkodsdeklarationen måste läsas för att bestämma vilken av UCS-4 eller andra stödda 32-bitarskoder som gäller. |
3C 00 00 00 | |
00 00 3C 00 | |
00 3C 00 00 | |
00 3C 00 3F |
UTF-16BE eller big-endian ISO-10646-UCS-2 eller annan kod med kodenheter på 16-bitar i big-endianordning och ASCII-tecken kodade som ASCII-värden (teckenkodsdeklarationen måste läsas för att bestämma vilken) |
3C 00 3F 00 |
UTF-16LE eller little-endian ISO-10646-UCS-2 eller annan kod med kodenheter på 16-bitar i little-endianordning och ASCII-tecken kodade som ASCII-värden (teckenkodsdeklarationen måste läsas för att bestämma vilken) |
3C 3F 78 6D |
UTF-8, ISO 646, ASCII, viss del av ISO 8859, Shift-JIS, EUC eller varje annan 7-bitars-, 8-bitars- eller kod med blandat antal bitar som tillförsäkrar att ASCII-tecknen har sina normala positioner, antal bitar och värden; den aktuella teckenkodsdeklarationen måste läsas för att bestämma vilken av dessa som gäller, men eftersom alla dessa koder använder samma bit-mönster för de relevanta ASCII-tecknen, kan själva teckenkodsdeklarationen läsas tillförlitligt |
4C 6F A7 94 |
EBCDIC (i någon variant; den fulla teckenkodsdeklarationen måste läsas för att tala om vilken kodsida som används) |
Annan | UTF-8 utan en teckenkodsdeklaration eller annars är dataströmmen felaktigt etiketterad (saknar en obligatorisk teckenkodsdeklaration), korrupt, fragmentarisk eller ligger i en förpackning av någon sort |
Not:
I fall ovan som inte kräver att teckenkodsdeklarationen måste läsas för att besämma teckenkoden, kräver avsnitt 4.3.3 ändå att teckenkodsdeklarationen läses, om den finns med, och att teckenkodsnamnet kontrolleras för överensstämmelse med den aktuella teckenuppsättningen hos entiteten. Det är också möjligt att nya teckenuppsättningar kommer att uppfinnas som gör det möjligt att använda teckenkodsdeklarationen för att bestämma teckenkoden i fall där detta inte behövs för närvarande.
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.
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.
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:
Den femte 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:
Denna upplaga kodades i en något ändrad version av XMLspec DTD, v2.10. XHTML-versionerna producerades med en kombination av XSLT-stilmallarna xmlspec.xsl, diffspec.xsl och REC-xml.xsl.
Följande förslag definierar vad som anses som den bästa tillämpningen för konstruktionen av XML-namn använda som elementnamn, attributnamn, mål för processinstruktioner, entitetsnamn, notationsnamn och värden på attribut av typ ID och är avsett som ledning för dokumentförfattare och schemabyggare. Alla referenser till Unicode förstås som avseende en viss version av Unicode-standaren större än eller lika med 5.0. Vilken version som bör användas är upp till omdömet hos dokumentförfattaren eller schemabyggaren.
De första två förslagen är direkt härledda från de regler som ges för identifierare ("identifiers") i Unicode-standardens Standard Annex #31 (UAX #31) och utesluter alla kontrolltecken, omslutande icke-utrymmeskrävande markeringar ("enclosing nonspacing marks"), ickedecimala nummer, privatanvända tecken, interpunktionstecken (med angivna undantag), symboltecken, kodluckor ("unassigned codepoints) och tomrumstecken. De andra förslagen är huvudsakligen härledda från Appendix B i tidigare upplagor av denna specifikation.