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.
1.1 A Notatka o zapisie i u¿yciuPrzy 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.
2.2 U¿ycie IRI jako przestrzeni nazwPusty 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".
2.3 Porównywanie odno¶ników IRIOdno¶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.
3 Deklarowanie przestrzeni nazw[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. ]
Atrybut nazwy deklaracji przestrzeni nazwZnormalizowana 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±ceW 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±caPrefiks 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±cychW dokumentach XML zgodnych z t± specyfikacj±, element nazwy podany jako nazwy kwalifikuj±ce w nastêpuj±cy sposób:
Nazwy elementówPrzyk³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:
AttributePrzyk³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 deklaracjachZauwa¿, ¿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.
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.
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.
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