Przedstawiamy aplikacje Rozszerzalnego Języka Znaczników (XML),
gdzie pojedynczy dokument XML może zawierać elementy i atrybuty (tutaj odnosi się do nich
"słownictwo znaczników"), zdefiniowane dla i używane przez wielokrotne moduły oprogramowania.
Jedna motywacja jest do tego modularnością: jeśli takie słownictwo znaczników istnieje,
które jest dobrze rozumiane i dla którego jest dostępne użyteczne oprogramowanie, lepiej jest
ponownie użyć te znaczniki raczej niż na nowo je wymyślać.
Takie dokumenty zawierające wielokrotne słownictwo znaczników stwarza problemy
przy rozpoznaniu i konflikt.Moduły oprogramowania muszą być zdolne rozpoznać elementy i atrybuty,
które mają zaprojektowane to przetworzenia, nawet w obliczu "konfliktu" mającego miejsce kiedy
znaczniki przeznaczone dla innego oprogramowania używają tego samego elementu
name (nazwa), lub nazwy atrybutu.
Te rozważania wymagają, by budowa dokumentu miała tak skonstruowane nazwy, żeby uniknąć konfliktów
pomiędzy nazwami z innych słowników znaczników.
Ta specyfikacja opisuje mechanizm,
przestrzenie nazw XML,
który dokonuje tego poprzez przypisanie
rozszerzonych nazw
dokumentom i atrybutom.
Przy EMPHASIZED, słowa kluczowe
MUST (musi),
MUST NOT (nie może),
REQUIRED (wymagany(,
SHOULD (powinien),
SHOULD NOT (nie powinien),
MAY (może)
w tym dokumencie mają być interpretowane jak opisano w
[Słowach kluczowych].
Zauważ, że wiele z nieterminali w produkcjach tej specyfikacji jest określone nie tutaj, a w specyfikacji XML
[XML].
Kiedy nieterminale określone tutaj mają takie same nazwy, co nieterminale określone w specyfikacji XML,
produkcje we wszystkich przypadkach odpowiadają podzbiorowi ciągu znaków połączonemu przez te odpowiadające tutaj.
W produkcjach tego dokumentu
NSC
to "Ograniczenie przestrzeni nazw", jedna z zasad, której dokumenty zgodne z tą specyfikacją
MUSZĄ
przestrzegać.
[Definicja:
Przestrzeń nazw XML
jest zidentyfikowana przez
odnośnik IRI;
nazwy elementów i atrybutów mogą być umieszczone w przestrzeni nazw XML,
używającej mechanizmów opisanych w tej specyfikacji.
]
[Definicja:
Nazwa rozszerzona to para składająca się z
przestrzeni nazw
i
nazwy lokalnej.
]
[Definicja:
Dla nazwy N w przestrzeni nazw zidentyfikowanej
przez IRI I,
nazwą przestrzeni nazw
jest I. Dla nazwy N
nie będącej przestrzenią nazw
nazwa przestrzeni nazw
nie ma wartości.
]
[Definicja:
W każdym przypadku
nazwą lokalną
jest N.
]
To ta kombinacja uniwersalnie zarządzanych przestrzeni nazw IRI ze słownikowymi nazwami okalnymi
jest efektywna przy unikaniu konfliktów nazw.
Odnośniki IRI mogą zawierać znaki niedozwolone w nazwach i są często niewygodnie długie,
więc rozszerzone nazwy nie są używane bezpośrednio dla elementów i atrybutów nazw w dokumentach XML.
W zamian są używane
nazwy określające.
[Definicja:
A
nazwa określająca
to temat nazwy do interpretacji przestrzeni nazw.
]
W dokumentach zgodnych z tą specyfikacją nazwy elementów i atrybutów pojawiają się jako nazwy określające.
Syntaktycznie są to
nazwy z prefiksem lub
nazwy bez prefiksu.
Deklaracja składni bazująca na atrybutach jest dostarczona do łączenia prefiksów do
nazw przestrzeni nazw i do łączenia domyślnych przestrzeni nazw, których stosuje do
nazw elementów bez prefiksów;
te deklaracje są w zakresie elementów, na których pojawiają się, tak żeby
różne łączenia mogły być stosowane w różnych częściach dokumentu.
Proces zgodny z tą specyfikacją
MUSI
rozpoznawać i działać na te deklaracje i prefiksy.
Pusty ciąg znaków, chociaż jest legalnym odnośnikiem IRI, nie może być używany jako nazwa
przestrzeni nazw.
Użycie relatywnych odnośników IRI, łącznie z odnośnikami takiego samego dokumentu,
jest niezalecane w deklaracjach przestrzeni nazw.
Uwaga:
Na to niezalecenie relatywnych odnośników URI zdecydowano się przez tajnie głosowanie W3C XML.
[Niezalecane relatywne URI].
Jest również zdeklarowane, że "późniejsze specyfikacje takie jak
DOM, XPath, itd.
nie będą definiować żadnych interpretacji dla nich".
Odnośniki IRI identyfikujące przestrzenie nazw są porównywane podczas określania czy nazwa należy do danej przestrzeni
nazw i czy dwie nazwy należą do tej samej przestrzeni nazw.
[Definicja:
Dwa IRI są traktowane jako ciągi znaków i są
identyczne
jeżeli i tylko jeśli te ciągi znaków są identyczne, tj. czy mają takie same sekwencje i znaki.
]
Porównanie jest z rozróżnieniem małych i dużych liter i żadno %-uwalnianie jest wykonane lub niewykonane.
Konsekwencją tego jest to, że odnośniki IRI, które nie są identyczne w tym sensie mogą być rozwiązane
do tego samego źródła. Przykłady zawierające odnośniki IRI, które różnią się tylko w przypadku %-uwalniania,
lub które są z zewnętrznymi elementami rekordu, które mają inne podstawowe URI (ale zauważ, że
relatywne IRI są niezalecane jako nazwy przestrzeni nazw).
W deklaracji przestrzeni nazw, odnośnik IRI to
znormalizowana wartość
atrybutu, więc zamiana znaku XML i odnośników elementu rekordu zostały wykonane przed jakimkolwiek porównaniem.
Przykłady:
Poniższe odnośniki IRI są wszystkie inne dla różnych celów identyfikacji przestrzeni nazw, ponieważ różnią
się w przypadku:
http://www.example.org/wine
http://www.Example.org/wine
http://www.example.org/Wine
Poniższe odnośniki IRI są równiez wszystkie różne dla innych celów identyfikacji przestrzeni nazw:
http://www.example.org/rosĂC
http://www.example.org/ros%c3%a9
http://www.example.org/ros%c3%A9
http://www.example.org/ros%C3%a9
http://www.example.org/ros%C3%A9
Tak jak te:
http://www.example.org/~wilbur
http://www.example.org/%7ewilbur
http://www.example.org/%7Ewilbur
Jeżeli element rekordu
eacute został określony jako e,
poniższe znaczniki początkowe wszystkie zawierają deklaracje przestrzeni nazw łączonych z prefiksem
p
do tego samego odnośnika,
http://example.org/rosĂC.
<p:foo xmlns:p="http://example.org/rosĂC">
<p:foo xmlns:p="http://example.org/rosé">
<p:foo xmlns:p="http://example.org/rosé">
<p:foo xmlns:p="http://example.org/rosé">
<p:foo xmlns:p="http://example.org/rosé">
Z powodu ryzyka nierozróżniania IRI, byłoby to równorzędne podczas usunięcia pośredniości,
użycie znaku %-uwalnianych znaków w nazwach przestrzeni nazw jest silnie zaniechane.
[Definicja:
Przestrzeń nazw
(lub bardziej szczegółowo, łączenia przestrzeni nazw)
jest
zdeklarowana przy użyciu rodziny zarezerwowanych atrybutów.
Takie nazwy atrybutów muszą zarówno być
xmlns lub początkowy xmlns:.
Te atrybuty, jak inne atrybuty XML, mogą być zapewnione
bezpośrednio lub domyślnie.
]
Znormalizowana wartość atrybutów
MUSI
być zarówno odnośnikiem IRI -
nazwą przestrzeni nazw
identyfikujący przestrzeń nazw - lub pusty ciąg znaków.
Nazwa przestrzeni nazw, aby służyć swojemu zamierzonemu celowi,
POWINNA
mieć charakter jednoznaczności i trwałości.
Nie jest celem, by była bezpośrednio do użycia dla odzyskiwania schematu (jeśli istnieje).
Jednolite nazwy źródeł
[RFC2141]
są przykładem składni, która jest za jest zaprojektowana z uwzględnieniem tych celów.
Jednak powinno się zauważyć, że zwykłe URL mogą być zarządzane w taki sposób, żeby osiągnąć te same cele.
[Definicja:
Jeżeli nazwa atrybutu pasuje
PrefixedAttName,
wtedy
NCName daje prefiks przestrzeni nazw,ybutów z
używanych do łączenia nazw elementów i atr
nazwą przestrzeni nazw
we wartości atrybutu w zakresie elementu, do którego jest załączona deklaracja.
[Definicja: Jeżeli
nazwa atrybutu pasuje
DefaultAttName,
wtedy
nazwa przestrzeni nazw
w
wartośi atrybutu, która jest
domyślną przestrzenią nazw
w zakresie elementu, do którego deklaracja jest załączona.]
Domyślne przestrzenie nazw i nakładanie deklaracji są omówione w
6
Używaniu przestrzeni nazw do elementów i atrybutów
.
Przykład deklaracji przestrzeni nazw, która łączy prefiks przestrzeni nazw
edi z nazwą przestrzeni nazw
http://ecommerce.example.org/schema:
<x xmlns:edi='http://ecommerce.example.org/schema'>
<!-- the "edi" prefix is bound to http://ecommerce.example.org/schema
for the "x" element and contents -->
</x>
Ograniczenie przestrzeni nazw: Zarezerwowane prefiksy i nazwy przestrzeni nazw
Prefiks xml
jest z definicji połączony z nazwą przestrzeni nazw
http://www.w3.org/XML/1998/namespace.
MOŻE,
ale nie musi być zdeklarowana, a
NIE MOŻE
być niezdeklarowana lub połączona z jakimikolwiek innymi nazwami przestrzeni nazw.
Inne prefiksy
NIE MOGĄ
być połączone z tą nazwą przestrzeni nazw.
Prefiks xmlns
jest tylko używany do zdeklarowania łączeń przestrzeni nazw i jest z definicji połączony z nazwą przestrzeni nazw
http://www.w3.org/2000/xmlns/.
NIE MOŻE
być zdeklarowany, lub niezdeklarowany. Inne prefiksy
NIE MOGĄ
być połączone z tą nazwą przestrzeni nazw.
Wszystkie inne początki prefiksy z trzyliterową sekwencją
x, m, l,
w jakichkolwiek kombinacjach są zarezerwowane. To znaczy, że:
użytkownicy
NIE POWINNI
używać ich poza tym, jak zdefiniowano w późniejszych specyfikacjach
procesory
NIE MOGĄ
ich traktować jako błędy krytyczne.
Chociaż nie są one same zarezerwowane, nie poleca się używać nazw z prefiksami, których
LocalPart zaczyna się na literę
x, m, l, w każdej
kombinacji, jak te nazwy byłyby zarezerwowane, jeżeli byłyby zarezerwowane bez prefiksu.
4 Nazwy określające
W dokumentach XML zgodnych z tą specyfikacją, niektóre nazwy (konstrukcje odpowiadające nieterminalowi
Nazwa)
MUSI
być podana do
nazwy określającej,
określonej w następujący sposób:
Nazwa określająca
Prefiks zapewnia
prefiks przestrzeni nazw, część nazwy określającej i
MUSI
być połączony z przestrzenią nazw odnośnik
IRI
w
deklaracji przestrzeni nazw.
[Definicja:
LocalPart zapewnia
część lokalną nazwy określającej.]
Zauważ, że funkcje prefiksu służą
tylko
jako miejsce dla przestrzeni nazw.
Aplikacje
POWINNY
używać nazw przestrzeni nazw, nie prefiksów w konstruowaniu naze, których zasięg rozciąga się poza
zawarty dokument.
5 Używanie nazw określających
W dokumentach XML zgodnych z tą specyfikacją,
element nazwy podany jako
nazwy kwalifikujące w
następujący sposób:
Nazwy elementów
Przykład nazwy określającej służącej jako nazwa elementu:
<!-- the 'price' element's namespace is http://ecommerce.example.org/schema -->
<edi:price xmlns:edi='http://ecommerce.example.org/schema' units='Euro'>32.18</edi:price>
Atrybuty są zarówno deklaracjami przestrzeni nazw
, lub ich nazwy są podane jako
nazwy określające:
Attribute
Przykład nazwy określającej służącej jako nazwa atrybutu:
<x xmlns:edi='http://ecommerce.example.org/schema'>
<!-- the 'taxClass' attribute's namespace is http://ecommerce.example.org/schema -->
<lineItem edi:taxClass="exempt">Baby food</lineItem>
</x>
Ograniczenie przestrzeni nazw: Prefiks zdeklarowany
Prefiks przestrzeni nazw, chyba że jest to
xml
lub xmlns,
MUSI
być zdeklarowany w atrybucie
deklaracji przestrzeni nazw
zarówno w znaczniku początkowym elementu, gdzie prefiks jest używany, lub elemencie przodku (tj. element, w którego
zawartości jest znacznik z prefiksem).
Co więcej, wartość atrybutu w środku takiej deklaracji
NIE MOŻE
być pustym ciągiem znaków.
To ograniczenie może prowadzić to operacyjnych trudności w przypadku, gdzie jest
zapewniony atrybut deklaracja przestrzeni nazw, nie bezpośrednio w
elemencie rekordu dokumentu XML, ale
przez domyślny atrybut zdeklarowany w zewnętrznym elemencie rekordu. Takie deklaracje mogą nie być odczytane
przez oproramowanie, które bazuje na niewalidującym procesorze XML.
Wiele aplikacji XML, przypuszczalnie zawierających te wrażliwe na zawarte przestrzenie nazw, nie może wymagać
walidujących procesorów.
Jeśli jest wymagana poprawna operacja z takimi aplikacjami
,
deklaracje przestrzeni naze
MUSZĄ
być zapewnione zarówno bezpośrednio, jak i przez demyślne atrybuty zdeklarowane w
wewnętrznym podzbiorze DTD
.
Nazwy elementów i atrybutów
są również podane jako nazwy kwalifikowane kiedy pojawiają się w deklaracjach
w
DTD:
Nazwy określające w deklaracjach
Zauważ, że walidacja bazująca na DTD nie jest świadoma przestrzeni nazw w nastepującym sensie:
DTD ogramicza elementy i atrybuty, które mogą pojawiać się w dokumencie przez niewystarczająco zinterpretowane
czy, nie przez pary (nazw przestrzeni nazw, nazwa lokalna).
Aby dokonać walidacji dokumentu, który używa przestrzeni nazw wobec DTD, te same prefiksy muszą być użyte
w przykładzie w DTD. DTD może jednak pośrednio ograniczyć przestrzenie nazw użyte w ważnym dokumencie przez
zapewnienie wartości
#FIXED
dla atrybutów, które deklarują przestrzenie nazw.
6 Używanie przestrzeni nazw do elementów i atrybutów
6.1 Zakres przestrzeni nazw
Zakres deklaracji przestrzeni nazw deklarującej prefiks rozciąga się od znacznika początkowego do końcowego, w
którym pojawia się na końcu odpowiadającego znacznika końcowego, z wyłączeniem zakresu jakichkolwiek wewnętrznych
deklaracji z tą samą częścią NSAttName.
W przypadku pustego znacznika zakresem jest sam znacznik.
Taka deklaracja przestrzeni nazw odnosi się do wszystkich nazw elementów i atrybutów wewnątrz jego zasięgu,
którego prefiks pasuje do tego określonego w deklaracji.
Rozszerzona nazwa
odpowiadająca nazwie elementu lub atrybutu z prefiksem posiada IRI, do którego
jest przyłączony
prefiks
jako jego
nazwa przestrzeni nazw,
i
część lokalna
jako jego
nazwa lokalna.
<?xml version="1.1"?>
<html:html xmlns:html='http://www.w3.org/1999/xhtml'>
<html:head><html:title>Frobnostication</html:title></html:head>
<html:body><html:p>Moved to
<html:a href='http://frob.example.com'>here.</html:a></html:p></html:body>
</html:html>
Wielokrotne prefiksy przestrzeni nazw mogą być zdeklarowane jako atrybuty pojedynczego elementu, jak
pokazano w tym przykładzie:
<?xml version="1.1"?>
<!-- both namespace prefixes are available throughout -->
<bk:book xmlns:bk='urn:loc.gov:books'
xmlns:isbn='urn:ISBN:0-395-36341-6'>
<bk:title>Cheaper by the Dozen</bk:title>
<isbn:number>1568491379</isbn:number>
</bk:book>
Wartość atrybutu w deklaracji przestrzeni nazw dla prefiksu
MOŻE
być pusta.
W obrębie deklaracji powoduje to usuwanie jakichkolwiek połączeń prefiksu z nazwą przestrzeni nazw.
Dalsze deklaracje
MOGĄ
znów ponownie zdeklarować prefiks:
<?xml version="1.1"?>
<x xmlns:n1="http://www.w3.org">
<n1:a/> <!-- legal; the prefix n1 is bound to http://www.w3.org -->
<x xmlns:n1="">
<n1:a/> <!-- illegal; the prefix n1 is not bound here -->
<x xmlns:n1="http://www.w3.org">
<n1:a/> <!-- legal; the prefix n1 is bound again -->
</x>
</x>
</x>
6.2 Domyślne przestrzenie nazw
Zakres deklaracji
domyślnych przestrzeni nazw
rozciąga się od początku znacznika początkowego, w którym
pojawia się na końcu odpowiadającego znacznika końcowego, z wyłączeniem zakresu jakichkolwiek domyślnych wewnętrznych
deklaracji przestrzeni nazw.
W przypadku pustego znacznika zakresem jest sam znacznik.
Domyślna deklaracja przestrzeni nazw dotyczy wszystkich nazw elementów bez prefiksów w jej zakresie.
Domyślne deklaracje przestrzeni nazw nie dotyczą bezpośrednio nazw atrybutów;
interpretacja atrybutów bez prefiksów jest określona przez element, na którym się pojawiają.
Jeżeli w zakresie jest domyślna deklaracja przestrzeni nazw to
rozszerzona nazwa
odpowiadająca nazwie elementu bez prefiksu posiada IRI
domyślnej przestrzeni nazw
jako jego
nazwa przestrzeni nazw.
Jeżeli nie ma w zakresie domyślnej deklaracji przestrzeni nazw, nazwa przestrzeni nazw nie ma wartości.
Nazwa przestrzeni nazw dla nazwy atrybutu bez prefiksu nigdy nie ma wartości.
We wszystkich przypadkach
nazwa lokalna to
część lokalna
(która jest oczywiście taka sama jako sama nazwa bez prefiksu).
<?xml version="1.1"?>
<!-- elements are in the HTML namespace, in this case by default -->
<html xmlns='http://www.w3.org/1999/xhtml'>
<head><title>Frobnostication</title></head>
<body><p>Moved to
<a href='http://frob.example.com'>here</a>.</p></body>
</html><?xml version="1.1"?>
<!-- unprefixed element types are from "books" -->
<book xmlns='urn:loc.gov:books'
xmlns:isbn='urn:ISBN:0-395-36341-6'>
<title>Cheaper by the Dozen</title>
<isbn:number>1568491379</isbn:number>
</book>
Większy przykład zakresu przestrzeni nazw:
<?xml version="1.1"?>
<!-- initially, the default namespace is "books" -->
<book xmlns='urn:loc.gov:books'
xmlns:isbn='urn:ISBN:0-395-36341-6'>
<title>Cheaper by the Dozen</title>
<isbn:number>1568491379</isbn:number>
<notes>
<!-- make HTML the default namespace for some commentary -->
<p xmlns='http://www.w3.org/1999/xhtml'>
This is a <i>funny</i> book!
</p>
</notes>
</book>
Wartość atrybutu w domyślnej deklaracji przestrzeni nazw
MOŻE
być pusta.
Ma to taki sam efekt w zakresie deklaracji, jak nie ma domyślnej przestrzeni nazw.
<?xml version='1.1'?>
<Beers>
<!-- the default namespace inside tables is that of HTML -->
<table xmlns='http://www.w3.org/1999/xhtml'>
<th><td>Name</td><td>Origin</td><td>Description</td></th>
<tr>
<!-- no default namespace inside table cells -->
<td><brandName xmlns="">Huntsman</brandName></td>
<td><origin xmlns="">Bath, UK</origin></td>
<td>
<details xmlns=""><class>Bitter</class><hop>Fuggles</hop>
<pro>Wonderful hop, light alcohol, good summer beer</pro>
<con>Fragile; excessive variance pub to pub</con>
</details>
</td>
</tr>
</table>
</Beers>
6.3 Jednoznaczność atrybutów
W dokumentach XML zgodnych z tą specyfikacją, żaden znacznik nie może zawierać dwóch atrybutów, które:
mają takie same nazwy, lub
posiadają nazwy określające z tą samą
częścią lokalną i z
prefiksami,
które zostały połączone z
nazwami przestrzeni nazw, które są
identyczne.
To ograniczenie jest równoważne do wymagania, że żaden element nie ma dwóch atrybutów z taką samą
nazwą rozszerzoną.
Na przykład każdy z początkowych znaczników
bad
jest niedozwolony w następujących przypadkach:
<!-- http://www.w3.org is bound to n1 and n2 -->
<x xmlns:n1="http://www.w3.org"
xmlns:n2="http://www.w3.org" >
<bad a="1" a="2" />
<bad n1:a="1" n2:a="2" />
</x>
Jednak każdy z następujących jest dozwolony, ponieważ domyślna przestrzeń nazw nie odnosi się do nazw atrybutów:
<!-- http://www.w3.org is bound to n1 and is the default -->
<x xmlns:n1="http://www.w3.org"
xmlns="http://www.w3.org" >
<good a="1" b="2" />
<good a="1" n1:a="2" />
</x>
7 Zgodność dokumentów
Ta specyfikacja odnosi się do dokumentów XML 1.1.
Aby zgadzać się z tą specyfikacją dokument
MUSI
być dobrze ukształtowany zgodnie ze specyfikacją XML 1.1
[XML 1.1].
W dokumentach XML zgodnych z tą specyfikacją nazwy elementów i atrubutów
MUSZĄ
pasować produkcji dla
QName
i
MUSZĄ
spełniać "Ograniczenia przestrzeni nazw". Wszystkie inne tokeny w dokumencie, które są
WYMAGANE,
dla dobrego ukształtowania XML 1.1, aby pasowły to produkcji XML dla
nazwy,
MUSZĄ
pasować do tworzenia tej specyfikacji dla
NCName.
[Definicja:
Dokument jest dobrze stworzony pod względem przestrzeni nazw, jeśli jest zgodny z tą specyfikacją.
]
Wynika to z dobrze ukształtowanego dokumentu pod względem przestrzeni nazw:
Wszystkie nazwy elementów i atrybutów zawierają zarówno zero, jak i jeden dwukropek;
Żadne nazwy elementów rekordu, celów instrukcji przetwarzania, lub nazw zapisów nie zawiera żadnych dwukropków.
Dodatkowo, dobrze ukształtowany dokument pod względem przestrzeni nazw może również być ważny pod względem przestrzeni
nazw.
[Definicja:
Dobrze ukształtowany dokument pod względem przestrzeni nazw jest
ważny pod względem przestrzeni
nazw, jeżeli
jest ważny zgodnie ze specyfikacją XML 1.1 i wszystkie tokeny inne niż nazwy elementów i atrybutów, które są
WYMAGANE,
dla ważności XML 1.1, aby pasowały do produkcji XML dla
nazwy,
aby pasowały do tworzenia specyfikacji dla
NCName.
]
To następuje w dokumencie ważnym pod względem przestrzeni nazw:
Żadne atrybuty z deklarowanym typem
ID, IDREF(S), ENTITY(IES), lub NOTATION
nie zawierają żadnych dwukropków.
8 Zgodność procesorów
Aby zgadzać się z tą specyfikacją procesor
MUSI
raportować naruszenie dobrego ukształtowania przestrzeni nazw, z wyjątkiem tego, że nie jest
WYMAGANE
do sprawdzania, czy nazwy przestrzeni nazw są dozwolonymi IRI.
[Definicja:
Walidujący procesor XML zgodny z tą specyfikacją jest
walidujący przestrzenie nazw, jeżeli w dodatku raportuje naruszenia ważności
przestrzeni nazw.
]
9 Międzynarodowe identyfikatory źródłowe (IRI)
Obecnie trwają prace nad stworzeniem RFC definiującego Międzynarodowe identyfikatory źródłowe
(IRI). Ponieważ te prace nie są jeszcz ukończone, ta część podaje syntetyczną definicję IRI dla celów
tej specyfikacji. Główna Grupa Robocza XML oczekuje wydać erratę zastępującą tę część z odnośnikiem
do RFC, kiedy będzie ona opublikowana.
Użytkownikom definiującym przestrzenie nazw radzi się, by ograniczali nazwy przestrzeni nazw do URI
do momentu publikacji RFC i oprogramowania wspierającego IRI do publicznego użytku.
Implementorom podobnie się radzi, aby nie odrzucali przestrzeni nazw, które naruszają projekty warunków
zezwolonych znaków.
Dla szerszej ogólnej definicji i dyskusji na temat IRI patrz
[Projekt IRI 5] (prace trwają).
Odnośniki URI są ograniczone do podzbioru znaków ASCII;
Odnośniki IRI zezwalają na większość znaków Unikod od #xA0 do przodu.
Wcześniejsze projekty IRI RFC
(przykład [Projekt IRI 3]) także dozwolone niektóre niedozwolonych znaków
ASCII, ale nie bieżący szkic
([Projekt IRI 5]).
[Definicja:
Znaki dodatkowe
dozwolone w IRI
[IRI draft 5]
are:
]
Płaszczyzna Unikod 0 znaki #xA0 - #xD7FF, #xF900-#xFDCF, #xFDF0-#xFFEF
Płaszczyzna Unikod 1-14 znaki #x10000-#x1FFFD ... #xD0000-#xDFFFD, #xE1000-#xEFFFD
[Definicja:
Odnośnik IRI
to ciąg, który może być zmieniony do odnośnika URI poprzez zastosowanie następujących kroków:
]
Zamień część hostname jeśli jest obecna, przy użyciu czynności ToASCII określonej w Części 4.1
[RFC3490]
ze znacznikami stanu
UseSTD3ASCIIRules i zbiorowi AllowUnassigned do TRUE.
Uwolnij wszystkie
dodatkowe znaki
następująco:
Każdy dodatkowy znak jest zmieniony na
UTF-8
[RFC3629]
jako jeden lub więcej bajtów.
Wynikowe bajty są uwalniane z mechanizmu uwalniającego URI (tj. zmienione do %HH,, gdzie HH to
zapis szesnastkowy wartości bajta).
Oryginalny znak jest zamieniony przez wynikowy charakter sekwencji.
Uwaga:
Algorytm w [Projekt IRI 5]
zawiera krok normalizacyjny UCS, ale to nie robi różnicy do którego ciągu znaków są odnośniki IRI.