Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from http://www.xml.se/xml/REC-xml11-sv below:

XML Swedens översättning av XML 1.1

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

Översättningen utgår från vår översättning av XML 1.0 (Third Edition). Därefter har de ändringar tagits in som W3C gjort mellan XML 1.0 (Third Edition) och XML 1.1, som markerats med gult eller grönt i versionen XHTML med färgkodade revisionsangivelser. Eftersom vår översättning av XML 1.0 (Third Edition) har utgått från vår tidigare översättning av XML 1.0 har även denna översättning bibehållit mycket formateringen från den, men har updaterats till XHTML.

Observera att endast originaldokumentet på engelska har ett normativt värde. Här följer adresserna till origialdokumentet och den här översättningen:

• http://www.w3.org/TR/xml11
• http://www.xml.se/xml/REC-xml11-sv

För den som snabbt vill sätta sig in i skillnaderna mellan XML 1.0 och XML 1.1 hänvisas till avsnittet 1.3 Resonerande förklaring om XML 1.1.

Notera att beteckningssättet i de definitioner som anges med hakparanteser och nummer, t.ex. [1], finns förklarat i avsnittet "6 Beteckningssätt" sist i specifikationen.

Översättningen kan innehålla översättningsfel. Vi har emellertid försökt att vara så trogna det engelska originalet som möjligt och samtidigt försökt att hitta bra svenska ord för nya begrepp. Översättningskommentarer har vi lagt inom hakparanteser ["så här"]. Om vi har velat komplettera den svenska översättningen med originalorden på engelska har vi angett detta i parenteser med citationstecken ("like this"). Synpunkter på den svenska översättningen välkomnas på erik.mjoberg@xml.se. En lista på eventuella 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.

Denna version:

http://www.w3.org/TR/2004/REC-xml11-20040204/

Senaste version:

http://www.w3.org/TR/xml11

Föregående version:

http://www.w3.org/TR/2003/PR-xml11-20031105/

Redaktion:

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

Jean Paoli, Microsoft <jeanpa@microsoft.com>

C. M. Sperberg-McQueen, W3C <cmsmcq@w3.org>

Eve Maler, Sun Microsystems, Inc. <elm@east.sun.com>

François Yergeau <fyergeau@alis.com>

John Cowan <cowan@ccil.org>

För uppdateringar av detta dokument hänvisas till rättningar, som kan innehålla normativa rättningar.

Detta dokument finns även i dessa icke-normativa format: XML och XHTML med färgkodade revisionsangivelser.

Se även översättningar.

Copyright © 2004 W3C^® (MIT, ERCIM, Keio), All Rights Reserved. W3Cs regler för ansvar, varumärke, dokumentanvändning och licensiering av mjukvara 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 är en Rekommendation från W3C. Det har granskats av medlemmar i W3C och och andra intresserade och har ratifierats av W3Cs Director som en W3C-rekommendation. Det är ett stabilt dokument som kan användas som referensmaterial eller citeras som en normativ referens från andra dokument. W3Cs roll är nu att dra uppmärksamhet till specifikationen och att främja en bred användning, något som kommer att förbättra funktionaliteten och utbytet på webben.

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

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

En implementeringsrapport för XML 1.1 återfinns på http://www.w3.org/XML/2002/09/xml11-implementation.html .

Rapporter om fel i det engelska originalet till detta dokument görs till xml-editor@w3.org; arkiv finns tillgängliga. Fellistan för denna upplaga är tillgänglig på http://www.w3.org/XML/xml-V11-1e-errata.

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

1 Inledning
    1.1 Ursprung och mÃ¥l
    1.2 Terminologi
    1.3 Resonerande förklaring om XML 1.1
2 Dokument
    2.1 Välformade XML-dokument
    2.2 Tecken
    2.3 Vanliga syntaxkonstruktioner
    2.4 Teckendata och uppmärkning
    2.5 Kommentarer
    2.6 Processinstruktioner
    2.7 CDATA-avsnitt
    2.8 Prolog och dokumenttypsdeklaration
    2.9 FristÃ¥ende dokumentdeklaration
    2.10 Tomrumshantering
    2.11 Hantering av radbrytning
    2.12 SprÃ¥kidentifiering
    2.13 Normaliseringskontroll
3 Logiska strukturer
    3.1 Starttaggar, sluttaggar och tomelementstaggar
    3.2 Elementtypsdeklarationer
        3.2.1 ElementinnehÃ¥ll
        3.2.2 Blandat innehÃ¥ll
    3.3 Attributlist-deklarationer
        3.3.1 Attributtyper
        3.3.2 IngÃ¥ngsvärden för attribut
        3.3.3 Normalisering av attributvärden
    3.4 Villkorliga urval
4 Fysiska strukturer
    4.1 Tecken- och entitetsanrop
    4.2 Entitetsdeklarationer
        4.2.1 Interna entiteter
        4.2.2 Externa entiteter
    4.3 Analyserade entiteter
        4.3.1 Textdeklarationen
        4.3.2 Välformade, analyserade entiteter
        4.3.3 Teckenkoder i entiteter
        4.3.4 Versionsinformation 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 Definitioner för teckennormalisering
C Expansion av entitets- och teckenanrop (icke normativt)
D Deterministiska innehållsmodeller (icke normativt)
E Automatiskt fastställande av teckenuppsättningar (icke normativt)
E.1 Fastställande utan extern teckenkodsinformation
E.2 Prioritieringar i närvaro av extern teckenkodsinformation
F W3Cs arbetsgrupp för XML (icke normativt)
G W3C XML Core Working Group (icke normativt)
H Produktionsuppgifter (icke normativt)
I Förslag till XML-namn (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:

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

Denna specifikation bidrar, tillsammans med associerade standarder (Unicode och ISO/IEC 10646 för tecken, Internet RFC 3066 för språkidentifieringstaggar, ISO 639 för kodning av namn på språk och ISO 3166 för kodning av namn på länder) till den information som behövs för att förstå XML version 1.1 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:

fel ("error")

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

kritiskt fel

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

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

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

giltighetsbegränsning ("validity constraint")

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

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

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

överensstämma med ("match")

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

för kompatibilitet ("for compatibility")

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

för utbyte ("for interoperability")

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

W3Cs XML 1.0-rekommendation gavs först ut 1998 och har, trots utgivningen av åtskilliga felaktigheter ("errata"), vilket kulminerade i en tredje upplaga 2004, (med avsikt) kvarstått som oförändrad med avseende på vad som är välformad XML och vad som inte är det. Denna stabilitet har varit extremt nyttig för interoperabilitet. Emellertid har Unicode-standarden, som XML 1.0 vilar på, inte varit statisk med avseende på teckenspecifikationer och utvecklats från version 2.0 till version 4.0 och längre. Tecken som inte fanns i Unicode 2.0 kan redan användas som teckendata i XML 1.0. Emellertid är de inte tillåtna i XML-namn som t.ex. elementtypsnamn, attributnamn, attributvärden av uppräkningstyp, mål för processinstruktioner osv. Vissa tecken, som borde ha tillåtits i XML-namn var dessutom inte tillåtna beroende på översyner och bristande överensstämmelse i Unicode 2.0.

Helhetssynen på namn har ändrats sedan XML 1.0. Medan XML 1.0 angav en stel definition på namn, där allt som inte var tillåtet var förbjudet, har XML 1.1-namn utformats så att allt som inte är förbjudet (av en viss orsak) är tillåtet. Eftersom Unicode kommer att tillåtas fortsätta att växa förbi version 4.0, kan ytterligare ändringar i XML undvikas genom att tillåta nästan alla tecken i namn, inklusive de som ännu inte har anvisats.

Utöver dettta försöker XML 1.0 ansluta sig till konventioner för radbrytning i olika operativsystem, men diskriminerar de konventioner som används av IBM och IBM-kompatibla stordatorer. Som ett resultat är XML-dokument på stordatorer inte enkla textfiler enligt de lokala konventionerna. XML 1.0-dokument som skapats på stordatorer måste endera bryta mot de lokala radbrytningskonventionerna eller tillämpa annars onödiga översättningssteg innan tolkning och efter generering skett. Att tillåta direkt interoperabilitet är särskilt viktigt när data datalager delas mellan stordator- och icke-stordatorsystem (i motsats till att kopieras till och från varandra). Därför adderas XML 1.1-tecknet NEL (#x85) ["next line"] till listan av radbrytningstecken. För fullständighetens skull stöds också radseparatortecknet #x2028 i Unicode.

Slutligen finns ett väsentligt behov att definiera en standardåtergivning av godtyckliga Unicode-tecken i XML-dokument. Därför tillåter XML 1.1 användning av teckenreferenser till kontrolltecknen #x1 t.o.m. #x1F, av vilka de flesta är förbjudna i XML 1.0. Av stabilitetsskäl får emellertid dessa tecken i fortsättningen inte användas direkt i dokument. För att förbättra stabiliteten i fastställandet av teckenuppsättningar, måste de återstående kontrolltecknen #x7F t.o.m. #x9F, som var fritt tillgängliga i XML 1.0-dokument, nu också förekomma endast som teckenanrop. (Tomrumstecken är naturligtvis undantagna.) Den mindre uppoffring detta medför med avseende bakåtkompatibilitet får anses som försumbar. På grund av potentiella problem med APIer, är #x0 fortfarande förbjudet både direkt och som teckenanrop.

En ny XML-version (snarare än en uppsättning felaktigheter i XML 1.0) skapas, eftersom ändringarna påverkar definitionen av välformade dokument. Tolkar för XML 1.0 måste fortsätta att avvisa dokument som innehåller nya tecken i XML-namn, nya radbrytningstecken och anrop till kontrolltecken. Skillnaden mellan XML 1.0- och XML 1.1-dokument anges av versionsinformationen i XML-deklarationen i början på varje dokument.

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

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

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

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

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

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

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

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

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

Not:

Författare av dokument uppmuntras att undvika "kompatibilitetstecken" ("compatibility characters"), som definieras i avsnitt 6.8 av [Unicode] (se även D21 i avsnitt 3.6 av [Unicode3]). Även tecken definierade i följande intervall bör förhindras. De är antingen kontrolltecken eller permanent odefinierade Unicodetecken:

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

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.

Not:

Närvaron av #xD i definitionen ovan upprätthålls enbart för bakåtkompatibilitet med den första upplagan ["av XML 1.0"]. 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 datatyp ("token") som börjar med en bokstav eller ett av nÃ¥gra fÃ¥ interpunktionstecken och fortsätter med bokstäver, siffror, bindestreck, understrykningstecken, kolon, eller punkter, sammantaget kända som namntecken.] Namn som börjar med strängen "xml" eller med varje annan sträng som överensstämmer med (('X'|'x') ('M'|'m') ('L'|'l')), är reserverade för standardisering i denna och kommande versioner av specifikationen.

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-tolkar måste acceptera kolon som ett namntecken.

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

Det första tecknet i ett namn MÅSTE vara ett NameStartChar ["namnstarttecken"] och varje annat tecken MÅSTE vara NameChars ["namntecken"]; denna mekanism används för att förhindra att namn som börjar med europeiska (ASCII-) siffror eller med vanliga kombinationstecken. Nästan alla tecken tillåts i namn utom de som antingen är eller möjligen kan användas som avgränsningstecken. Avsikten är att inkludera snarare än utesluta, så att skrivsystem som ännu inte kodats i Unicode kan användas i XML-namn. Se I Förslag till XML-namn för förslag till hur namn skapas.

Dokumentförfattare uppmuntras att använda namn som är meningsfulla ord eller kombinationer av ord i naturliga språk och att undvika symboliska tecken eller tomrumstecken i namn. Notera att KOLON, BINDESTRECK-MINUS, PUNKT, LÅG LINJE (underscore) OCH MITTPUNKT uttryckligen är tillåtna.

ASCII-symboler och interpunktionstecken tillsammans med en ganska stor grupp av symboltecken i Unicode är uteslutna från namn därför att de är mer användbara som avgränsningstecken i sammanhang där XML-namn används utanför XML-dokument; så att denna grupp ger nämnda sammanhang klara garantier om vad som inte kan vara en del av ett XML-namn. Tecknet #x037E, GREKISKT FRÅGETECKEN, är uteslutet för att det blir ett kolon vid normalisering, vilket skulle kunna ändra meningen hos entitetsanrop.

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.

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

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

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

Ett exempel på en kommentar:

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

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

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

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

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

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

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

men följande är ett XML 1.0-dokument därför att det inte har en XML-deklaration:

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

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

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

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

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

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

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

Giltighetsbegränsning: Rotelementstyp

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

Giltighetsbegränsning: Riktig deklaration/PE-inkapsling

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

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

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

Välutformningsbegränsning: Extern delmängd

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

Välutformningsbegränsning: PE mellan deklarationer

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

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

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

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

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

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

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

XML 1.1-tolkar bör även acceptera XML 1.0-dokument. Om ett dokument är välutformat eller giltigt XML 1.0 och förutsatt att det inte innehåller några kontrolltecken i intervallet [#x7F-#x9F] annat än som teckenanrop, får det göras till välutformat respektive giltigt XML 1.1 helt enkelt genom att ändra versionsnumret.

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

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

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

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

Giltighetsbegränsning: Fristående dokumentdeklaration

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

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

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

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

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

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

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

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

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 allt nedan till ett ensamt #xA-tecken:

1. tvåteckenföljden #xD #xA
2. tvåteckenföljden #xD #x85
3. det ensamma tecknet #x85
4. det ensamma tecknet #x2028
5. varje #xD-tecken som inte omedelbart följs av #xA eller #x85.

Tecknen #x85 och #x2028 kan inte tillfredsställande upptäckas och översättas innan en teckenentitetsdeklaration (om en sådan finns) har blivit läst. Därför är det ett kritiskt fel att använda dem i XML-deklarationen eller textdeklarationen.

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

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

Exempel:

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

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:

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:

Alla analyserade entiteter i XML (inklusive dokumententiteter) BÖR normaliseras fullt i enlighet med definitionen av [Charmod] ["teckenmodell"] kompletterad av följande definitioner av relevanta konstruktioner för XML:

1. Ersättningstexten för alla analyserade entititeter
2. All text som i sammanhanget överensstämmer med en av följande definitioner:
   1. CData
   2. CharData ["teckendata"]
   3. content ["innehåll"]
   4. namn
   5. Nmtoken ["namntecken"]

Ett dokument är emellertid ändå välutformat även om det inte är fullt ut normaliserat. XML-tolkar BÖR erbjuda en möjlighet för användaren att verfiera att dokumentet som bearbetas är i fullt normaliserad form och rapporterar till applikationen huruvida det är normaliserat eller inte. Möjligheten att inte verifiera BÖR väljas bara när inmatad text är säkerställd på sätt som definierats av [Charmod].

Säkerställandet av full normalisering MÅSTE genomföras genom att först säkerställa att entiteten är i include-normaliserad form som definieras i [Charmod] och därefter säkerställa att inget av de relevanta begreppen som angetts ovan börjar (efter det att teckenanrop har expanderats) med ett sammansättningstecken ("composing character") som definieras i [Charmod]. Icke-validerande tolkar MÅSTE bortse från möjliga avnormaliseringar ("denormalizations") som skulle orsakas av import av externa entiteter som de inte läser.

Not:

Sammansättningstecknen är alla Unicode-tecken av icke-noll-kombinationsklass ("non-zero combining class"), plus ett litet antal av klass-nolltecken ("class-zero characters") som icke desto mindre finns med som icke inledande tecken i vissa kanoniska upplösningar ["av sammansatta tecken"] i Unicode. Då dessa tecken är avsedda att följa bastecken, innebär begränsningar av relevanta konstruktioner (inklusive innehåll) från att börja med ett sammansättningstecken inte någon meningfull inskränkning av uttrycksfullheten hos XML.

Om en tolk, när den verifierar full normalisering, träffar på tecken för vilka den inte kan bestämma normaliseringsegenskaperna (dvs tecken introducerade i en senare version av [Unicode3] än den den som används i tillämpningen av tolken), FÅR tolken, på användarens initiativ, förbise alla möjliga denormaliseringar orsakade av dessa tecken. Möjligheten att förbise dessa denormaliseringar BÖR inte väljas av applikationer när tillförlitlighet eller säkerhet är livsviktigt.

XML-tolkar FÅR INTE transformera indata till att bli i fullt normaliserad form. XML-applikationer som skapar XML 1.1-utdata från antingen XML 1.1- eller XML 1.0-indata BÖR tillförsäkra att utdata är fullt normaliserad; det är inte nödvändigt för interna bearbetningsformer med full normalisering.

Syftet med detta avsnitt är att med kraft uppmuntra XML-tolkar att tillförsäkra att skaparna av XML-dokument har normaliserat dem ordentligt, så att XML-applikationer kan göra tester t.ex. identitetsjämförelser av strängar utan att oroa sig över olika möjliga "stavningar" av strängar som Unicode tillåter.

Om en tolk omkodar entiteter som ligger i en icke-Unicode-kod till Unicode, BÖR den använda en normaliseringsomkodare ("normalizing transcoder").

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

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

Välutformningsbegränsning: Elementtypsöverensstämmelse

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

Giltighetsbegränsning: Giltigt element

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

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

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

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

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

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

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

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

Välutformningsbegränsning: Inga externa entitetsanrop

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

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

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

Ett exempel på en starttagg:

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

Ett exempel på en sluttagg:

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

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

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

Exempel på tomelement:

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

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

[Definition: En elementtypsdeklaration antar formen:]

där namnet betecknar den deklarerade elementtypen.

Giltighetsbegränsning: Unik elementtypsdeklaration

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

Exempel på elementtypsdeklarationer:

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

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

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

Giltighetsbegränsning: Riktig grupp/PE-inkapsling

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

Exempel på elementinnehållsmodeller:

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

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

Giltighetsbegränsning: Inga dubbla typer

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

Exempel på deklarationer av blandat innehåll:

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

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

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

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

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

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

Giltighetsbegränsning: ID

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

Giltighetsbegränsning: Ett ID per elementtyp

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

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

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

Giltighetsbegränsning: IDREF

Datatypen 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

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

Giltighetsbegränsning: Namntyp

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

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

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

Giltighetsbegränsning: Notationsattribut

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

Giltighetsbegränsning: En notation per elementtyp

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

Giltighetsbegränsning: Ingen notation på tomelement

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

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

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

Giltighetsbegränsning: Uppräkning

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

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

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

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

Giltighetsbegränsning: Obligatoriskt attribut

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

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

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

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

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

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

Exempel på attributlist-deklarationer:

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

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

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

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

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

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

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

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

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

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

Giltighetsbegränsning: Riktigt villkorligt avsnitt/PE-inkapsling

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

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

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

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

Ett exempel:

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

Välutformningsbegränsning: Giltigt tecken

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

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

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

Välutformningsbegränsning: Deklarerad entitet

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

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

Giltighetsbegränsning: Deklarerad entitet

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

Välutformningsbegränsning: Analyserad entitet

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

Välutformningsbegränsning: Ingen rekursivitet

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

Välutformningsbegränsning: I DTDn

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

Exempel på tecken- och entitetsanrop:

Exempel på ett parameterentitetsanrop:

[Definition: Entiteter deklareras som följer:]

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

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

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

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

Giltighetsbegränsning: Deklarerad notation

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

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

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

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

[Definition: Som tillägg till en systemadress FÅR en extern adress innehålla en allmän adress.] En XML-tolk som försöker att tolka en entitets innehåll FÅR använda alla kombinationer av allmänna adresser och systemadresser såväl som ytterligare information utanför omfattningen av dennna specifikation för att försöka att skapa ett alternativt URI-anrop. Om XML-tolken inte kan göra det, MÅSTE den använda URI-anropet såsom det har specificerats i innehållet mellan anföringstecknen i systemadressen. 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:

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

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

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

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

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

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

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

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

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

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

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

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

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

Exempel på textdeklarationer med teckenkodsdeklarationer:

Varje entitet, inklusive dokumententiteten, kan deklareras separat som XML 1.0 eller XML 1.1. Den versionsdeklaration som förekommer i dokumententiteten bestämmer versionen hos dokumentet i sin helhet. Ett XML 1.1-dokument kan ropa in externa entiteter i XML 1.0 så att annars kopierade versioner av externa entiteter, särskilt externa DTD-delmängder, inte behöver sparas. I sådant fall tillämpas emellertid reglerna för XML 1.1 för hela dokumentet.

Om en entitet (inklusive dokumententiteten) inte är märkt med ett versionsnummer, behandlas den som om den vore märkt som version 1.0.

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

Anrop i innehåll

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

Anrop i attributvärde

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

Finns som attributvärde

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

Anrop i entitetsvärde

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

Anrop i DTD

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

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:

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

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

medan detta inte är:

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 det ä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:

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

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

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

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

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

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

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

Giltighetsbegränsning: Unikt notationsnamn

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

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

[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älutformningsbegränsningar enligt denna specifikation från innehållet i dokumententiteten och alla andra analyserade entiteter som de läser.

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

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

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

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

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

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

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

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

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

#xN

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

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

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

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

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

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

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

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

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

"string"

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

'string'

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

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

(uttryck)

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

A?

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

A B

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

A | B

överensstämmer med A eller B.

A - B

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

A+

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

A*

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

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

/* ... */

kommentar.

[ wfc: ... ]

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

[ vc: ... ]

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

IANA-CHARSETS

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

IETF RFC 1766

IETF (Internet Engineering Task Force). RFC 1766: Tags for the Identification of Languages, ed. H. Alvestrand. 1995. (Se http://www.ietf.org/rfc/rfc1766.txt.)

IETF RFC 2396

IETF (Internet Engineering Task Force). RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax. T. Berners-Lee, R. Fielding, L. Masinter. 1998. (Se http://www.ietf.org/rfc/rfc2396.txt.)

IETF RFC 2732

IETF (Internet Engineering Task Force). RFC 2732: Format for Literal IPv6 Addresses in URL's. R. Hinden, B. Carpenter, L. Masinter. 1999. (Se http://www.ietf.org/rfc/rfc2732.txt.)

IETF RFC 3066

IETF (Internet Engineering Task Force). RFC 3066: Tags for the Identification of Languages, ed. H. Alvestrand. 2001. (Se http://www.ietf.org/rfc/rfc3066.txt.)

ISO/IEC 10646

ISO (International Organization for Standardization). ISO/IEC 10646-1:2000. Information technology — Universal Multiple-Octet Coded Character Set (UCS) — Part 1: Architecture and Basic Multilingual Plane and ISO/IEC 10646-2:2001. Information technology — Universal Multiple-Octet Coded Character Set (UCS) — Part 2: Supplementary Planes, liksom, från tid till annan, tillagd med, ersatt av en ny upplaga eller utökad med tillägg av nya delar. [Geneva]: International Organization for Standardization. (Se http://www.iso.ch/ för den senaste versionen.)

Unicode

The Unicode Consortium. The Unicode Standard, Version 4.0. Reading, Mass.: Addison-Wesley, 2003, även uppdaterad från tid till annan genom publicering av nya versioner. (Se http://www.unicode.org/unicode/standard/versions för den senaste versionen och tilläggsinformation om versioner av standarden och av the Unicode Character Database).

XML-1.0

W3C. Extensible Markup Language (XML) 1.0 (Third Edition). Tim Bray, Jean Paoli, C.M. Sperberg-McQueen, Eve Maler, François Yergeau (editors) (Se http://www.w3.org/TR/REC-xml.)

Aho/Ullman

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

Berners-Lee m.fl.

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

Brüggemann-Klein

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

Brüggemann-Klein och Wood

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

Charmod

W3C. Character Model for the World Wide Web. Martin J. Dürst, François Yergeau, Richard Ishida, Misha Wolf, Asmus Freytag, Tex Texin. (Se http://www.w3.org/TR/charmod/.)

Clark

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

IANA-LANGCODES

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

IETF RFC 2141

IETF (Internet Engineering Task Force). RFC 2141: URN Syntax, ed. R. Moats. 1997. (Se http://www.ietf.org/rfc/rfc2141.txt.)

IETF RFC 3023

IETF (Internet Engineering Task Force). RFC 3023: XML Media Types. eds. M. Murata, S. St.Laurent, D. Kohn. 2001. (See http://www.ietf.org/rfc/rfc3023.txt.)

IETF RFC 2781

IETF (Internet Engineering Task Force). RFC 2781: UTF-16, an encoding of ISO 10646, ed. P. Hoffman, F. Yergeau. 2000. (See http://www.ietf.org/rfc/rfc2781.txt.)

ISO 639

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

ISO 3166

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

ISO 8879

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

ISO/IEC 10744

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

WEBSGML

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

XML Names

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

Denna bilaga innehåller nödvändiga definitioner för teckennormalisering. För ytterligare bakgrundsinformation och exempel, se [Charmod].

[Definition: Text anses vara i en Unicode-kodform om den är kodad i UTF-8, UTF-16 eller UTF-32.]

[Definition: Föråldrad kodning ("legacy encoding") anses gälla varje teckenkodning som inte baseras på Unicode.]

[Definition: A normaliseringsomkodare ("normalizing transcoder") är en omkodare som konverterar från en föråldrad kodning till en Unicode-kodform och tillförsäkrar att resultatet är i Unicode Normalization Form C (se UAX #15 [Unicode]).]

[Definition: Ett teckenundvikande ("character escape") är en syntaktisk metod definierad i ett märk- eller programspråk som tillåter en eller flera av:]

1. användning av tecken med syntaxinnebörd ("syntax-significant characters") samtidigt som det bortses från deras innebörd i syntaxen i språket , eller
2. användning av tecken som inte kan representeras i den teckenkoden som gäller för en instans i det språket, eller
3. användning av tecken generellt, utan använding av tillhörande teckenkoder.

[Definition: Certifierad text är text som uppfyller åtminstone ett av följande villkor:]

1. den har bekräftats genom inspektion att vara text i normaliserad form
2. den använda textbehandlingskomponenten är identifierad och är känd för att producera enbart normaliserad text.

[Definition: Text är, för syftet med denna specifikation, Unicode-normaliserad om den är i en Unicode-kodform och är i Unicode Normalization Form C, enligt en version av Unicode Standard Annex #15: Unicode Normalization Forms [Unicode] åtminstone så sen som den äldsta versionen av the Unicode Standard som innehåller alla tecken som faktiskt finns i texten, men inte tidigare än version 3.2.]

[Definition: Text är infogningsnormaliserad ("include-normalized") om:]

1. texten är Unicode-normaliserad och inte innehåller några teckenundvikanden eller infogningar vilkas expansion skulle orsaka att texten inte längre blir Unicode-normaliserad; eller
2. texten är i en föråldrad kodning och, om den vore omkodad till en Unicode-kodform via en normaliserande omkodare, den resulterande texten skulle uppfylla villkoret 1 ovan.

[Definition: Ett sammansättningstecken är ett tecken som uppfyller ett eller båda av följande villkor:]

1. det andra tecknet i den kanoniska upplösningskonverteringen ("canonical decomposition mapping") av vissa primära sammansättningar ("primary composite") (som definierats i D3 av UAX #15 [Unicode]), eller
2. av den kanoniska kombinationsklassen ("canonical combining class") non-zero (som definierats i Unicode [Unicode]).

[Definition: Text är helnormaliserad ("fully-normalized") om:]

1. texten är i en Unicode-kodform, är infogningsnormaliserad och ingen av de relevanta konstruktioner som sammanfogar texten börjar med ett sammansättningstecken eller ett teckenundvikande som representerar ett sammansättningstecken; eller
2. texten är i en föråldrad kodning och, om den vore omkodad till en Unicode-kodform via en normaliserande omkodare, den resulterande texten skulle uppfylla villkor 1 ovan.

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

Om DTDn innehåller deklarationen

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

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

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

Detta producerar följande:

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

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 betraktar det första fallet först.

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

Med ett byteordningsmärke:

Med ett byteordningsmärke:

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.

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

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

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

Den aktuella 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:

• Leonid Arbouzov, Sun Microsystems
• Mary Brady
• John Cowan (Redaktör för XML 1.1, första upplagan)
• John Evdemon, Microsoft
• Andrew Fang, Arbortext
• Paul Grosso, Arbortext (Vice ordförande)
• Arnaud Le Hors, IBM (Vice ordförande)
• Dmitry Lenkov, Oracle
• Anjana Manian, Oracle
• Glenn Marcy, IBM
• Jonathan Marsh, Microsoft
• Sandra Martinez, NIST
• Mark Needleman, SIRSI
• Liam Quin, W3C (Staff Contact)
• Lew Shannon
• Richard Tobin, University of Edinburgh
• Daniel Veillard
• Norman Walsh, Sun Microsystems
• François Yergeau, Alis Technologies

Denna upplaga kodades i XMLspec DTD, 2.5. XHTML-versionerna producerades med en kombination av XSLT-stilmallarna xmlspec.xsl, diffspec.xsl och REC-xml-3e.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 3.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-standarden, version 3.0, 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 [XML-1.0] Appendix B.

1. Det första tecknet i ett namn bör tillhöra Unicodes generella kategori ("General Category") Ll, Lu, Lo, Lm, Lt eller Nl eller annars vara '_' #x5F.
2. Andra tecken än det första bör tillhöra Unicodes generella kategori Ll, Lu, Lo, Lm, Lt, Mc, Mn, Nl, Nd, Pc eller Cf eller annars vara något av följande: '-' #x2D, '.' #x2E, ':' #x3A or '·' #xB7 (mittpunkt). Eftersom Cf-tecken inte är direkt synliga, bör de användas med varsamhet och bara när det är nödvändigt, för att undvika att skapa namn som är urskiljbara för XML-tolkar men ser likadana ut för människor.
3. Bildtecken ("ideographic characters") som har en kanonisk upplösning ("decomposition") (inklusive dem i intervallen [#xF900-#xFAFF] och [#x2F800-#x2FFFD], med 12 undantag) bör inte användas i namn.
4. Tecken som har en kompatibilitetsupplösning ("compatibility decomposition") (de med en "kompatibilitetsformateringstagg" ("compatibility formatting tag") i fält 5 i Unicode-teckendatabasen -- markerad genom att fält 5 börjar med ett "<") bör inte användas i namn. Detta förslag gäller inte #x0E33 THAI CHARACTER SARA AM eller #x0EB3 LAO CHARACTER AM, som trots sina kompatibilitetsupplösningar är i reguljär användning i vissa skrifter.
5. Kombinationstecken ("combining characters") enbart avsedda för användning med symboler (inklusive dem i intervallen [#x20D0-#x20EF] och [#x1D165-#x1D1AD]) bör inte användas i namn.
6. Inskrivningstecken för anteckningar ("interlinear annotation characters") ([#xFFF9-#xFFFB) bör inte användas i namn.
7. Avvikelseurvalstecken ("variation selector characters") bör inte användas i namn.
8. Namn som är meningslösa, outtalbara, svåra att läsa eller lätt förväxlingsbara med andra namn bör inte användas.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.3