Polskie tłumaczenie Rekomendacji "Namespaces in XML 1.1"

Autor: Mariusz Żebrowski.
Lokalizacja: http://www.antyspam.pl/w3c/REC-xml-names11-20040204/

Dokument ten jest tłumaczeniem rekomendacji Namespaces in XML 1.1. Przekład ten nie jest przekładem normatywnym i może zawierać błędy wynikające z tłumaczenia. Status normatywny posiada jedynie wersja angielskojęzyczna na stronie W3C http://www.w3.org/TR/2004/REC-xml-names11-20040204/.
Dokument jest chroniony prawem autorskim. Copyright © 2004 W3C® (MIT, ERCIM, Keio).

W3C

Przestrzenie nazw w XML 1.1

W3C Rekomendacja z 4 lutego 2004

Obecna wersja
http://www.w3.org/TR/2004/REC-xml-names11-20040204
Najnowsza wersja
http://www.w3.org/TR/xml-names11
Poprzednia wersja
http://www.w3.org/TR/2003/PR-xml-names11-20031105
Autorzy:
Tim Bray, Textuality <tbray@textuality.com>
Dave Hollander, Contivo, Inc. <dmh@contivo.com>
Andrew Layman, Microsoft <andrewl@microsoft.com>
Richard Tobin, University of Edinburgh and Markup Technology Ltd <richard@cogsci.ed.ac.uk> - Version 1.1

Proszę zobaczyć erratę dla tego dokumentu, która może zawierać pewne normatywne poprawki.

Patrz także translacje.

Ten dokument  jest także dostępny w nienormatywnych formatach: XML.


Streszczenie

Przestrzenie nazw XML dostarczają prostych metod dla elementu kwalifikacyjnego i nazwę atrybutów użytych w dokumentach Rozszerzalnego Języka Znaczników (ang. Extensible Markup Language) przez skojarzenie ich z  przestrzeniami nazw identyfikowanymi przez referencje IRI.

Status tego Dokumentu

Ten paragraf opisuje status tego dokumentu od czasu kiedy jest publikowany. Inne dokumenty mogą zastapić ten dokument. Lista bieżących publikacji W3C i najnowsza weryfikacja tego technicznego raportu może być znaleziona na Inkeks raportów technicznych W3C na http://www.w3.org/TR/.

Ten dokument jest Rekomendowany przez W3C. Został on zbadany przez członków W3C i inne strony zainteresowane,  oraz zatwierdzony przez dyrektora W3C jako rekomendacja. To jest stabilny dokument i moze zostać użyty jako materiał referencyjny lub cytowany jak normatywne referencje z innego dokumentu. Rolą W3C w tworzeniu rekomendacji jest przyciąganie uwagi do tej specyfikacji i promowanie jej szerokiego zastosowania. Uwydatni to  funkcjonalność i interoperacyjność sieci Web.

Ten dokument jest produktem Działalności W3C XML. Tylko angielska wersja tej specyfikacji jest normatywną wersją. Jednakże dla przetłumaczenia tego dokumentu zobacz http://www.w3.org/2003/03/Translations/byTechnology?technology=xml-names11.

Dokumentacja z intelektualną wsnością może odnosić się do tych rekomendacji i moż być znaleziona na stronie publicznej Grupy Roboczej strona ujawniająca IPR .

Znane implementacje są dokumentowane w Raporcie implementacji Przestrzeni nazw  1.1. Zestaw testów jest także dostępny na stronie XML Test Suite.

Prosimy zgłaszać błędy występujące w tym dokumencie na adres xml-names-editor@w3.org; Publiczne archiwa są dostępne. Lista erraty dla tego dokumentu jest dostępna na http://www.w3.org/XML/2004/xml-names11-errata.

Spis treści

1 Motywacja i streszczenie
 1.1 A Notatka o zapisie i użyciu
2 Przestrzenie nazw XML
 2.1 Podstawowe pojęcia
2.2 Użycie IRI i nazw przestrzeni nazw
 2.3 Porównanie odnośników IRI
3 Deklarowanie przestrzeni nazw
4 Nazwy określające
5 Użycie nazw określających
6 Stosowanie przestrzeni nazw do elementów i atrybutów
 6.1 Zakres przestrzeni nazw
 6.2 Domyślne przestrzenie nazw
 6.3 Jednoznaczność atrybutów
7 Zgodność dokumentów
8 Zgodność procesorów
9 Międzynarodowe identyfikatory źródłowe (IRI)

Dodatki

A Odnośniki normatywne
B Inne odnośniki (Nienormatywne)
C Wewnętrzna struktura przestrzeni nazw XML (Nienormatywna)
D Zmiany od wersji 1.0 (Nienormatywne)
E Podziękowania (Nienormatywne)


1 Motywacja i streszczenie

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życiu

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

2 Przestrzenie nazw XML

2.1 Podstawowe pojęcia

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

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

2.3 Porównywanie odnośników IRI

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&#xe9;">

  • <p:foo xmlns:p="http://example.org/ros&#xE9;">

  • <p:foo xmlns:p="http://example.org/ros&#233;">

  • <p:foo xmlns:p="http://example.org/ros&eacute;">

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 nazw
[1] NSAttName PrefixedAttName
| DefaultAttName
[2]  PrefixedAttName ::= 'xmlns:' NCName[NSC: Reserved Prefixes and Namespace Names]
[3]   DefaultAttName   ::=   'xmlns'
[4]   NCName   ::=   NCNameStartChar NCNameChar*/* An XML Name, minus the ":" */
[5]   NCNameChar   ::=   NameChar - ':'
[5a]   NCNameStartChar   ::=   NameStartChar - ':'

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
[6]   QName   ::=    PrefixedName
| UnprefixedName
[6a]   PrefixedName   ::=    Prefix ':' LocalPart
[6b]    UnprefixedName   ::=    LocalPart
[7]   Prefix   ::=   NCName
[8]   LocalPart   ::=   NCName

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
[9]   STag   ::=   '<' QName (S Attribute)* S? '>' [NSC: Prefix Declared]
[10]   ETag   ::=   '</' QName S? '>'[NSC: Prefix Declared]
[11]    EmptyElemTag   ::=   '<' QName (S Attribute)* S? '/>' [NSC: Prefix Declared]

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
[12]   Atrybut   ::=   NSAttName Eq AttValue
| QName Eq AttValue [NSC: Prefix Declared]

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
[13]    doctypedecl   ::=   '<!DOCTYPE' S QName (S ExternalID)? S? ('[' (markupdecl | PEReference | S)* ']' S?)? '>'
[14]   elementdecl   ::=   '<!ELEMENT' S QName S contentspec S? '>'
[15]   cp   ::=   (QName | choice | seq) ('?' | '*' | '+')?
[16]   Mixed   ::=   '(' S? '#PCDATA' (S? '|' S? QName)* S? ')*'
| '(' S? '#PCDATA' S? ')'
[17]   AttlistDecl   ::=   '<!ATTLIST' S QName AttDef* S? '>'
[18]   AttDef   ::=   S (QName | NSAttName) S AttType S DefaultDecl

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:

  1. mają takie same nazwy, lub

  2. 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:

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:

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

[Definicja: Odnośnik IRI to ciąg, który może być zmieniony do odnośnika URI poprzez zastosowanie następujących kroków: ]

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

  2. Uwolnij wszystkie dodatkowe znaki następująco:

    1. Każdy dodatkowy znak jest zmieniony na UTF-8 [RFC3629] jako jeden lub więcej bajtów.

    2. Wynikowe bajty są uwalniane z mechanizmu uwalniającego URI (tj. zmienione do %HH,, gdzie HH to zapis szesnastkowy wartości bajta).

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

A Normatywne odnośniki

Słowa kluczowe
RFC 2119: Słowa kluczowe dla użycia w RFC do Wskazania poziomów wymagań , S. Bradner, ed. IETF (Internet Engineering Task Force), marzec 1997. Dostępny na http://www.rfc-editor.org/rfc/rfc2119.txt
RFC2141
RFC 2141: Składnia URN, R. Moats, ed. IETF (Internet Engineering Task Force), maj 1997. Dostępne http://www.rfc-editor.org/rfc/rfc2141.txt.
RFC2396
RFC 2396: Jednolite identyfikatory źródła (URI): Składnia rodzajowa, T. Berners-Lee, R. Fielding, and L. Masinter, eds. IETF (Internet Engineering Task Force), sierpień 1998. Dostępny na http://www.rfc-editor.org/rfc/rfc2396.txt
RFC2732
RFC 2732: Format dla literowych adresów IPv6 w URL, R. Hinden, B. Carpenter i L. Masinter, ed. IETF (Internet Engineering Task Force), grudzień 1999. Dostępny na http://www.rfc-editor.org/rfc/rfc2732.txt.
RFC3490
RFC 3490: Międzynarodowe nazwy domen w aplikacjach (IDNA), P. Faltstrom, P. Hoffman, and A. Costello, ed. IETF (Internet Engineering Task Force), marzec 2003. Dostępne na http://www.rfc-editor.org/rfc/rfc3490.txt
RFC3629
RFC 3629: UTF-8, format transformacji ISO 10646, F. Yergeau, ed. IETF (Internet Engineering Task Force), listopad 2003. Dostępny na http://www.rfc-editor.org/rfc/rfc3629.txt
XML
Rozszerzalny język znaczników (XML) 1.0 (wydanie trzecie), Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, i François Yergeau ed. W3C (World Wide Web Consortium), 4 lutego 2004. Dostępne na http://www.w3.org/TR/REC-xml.
XML 1.1
Rozszerzalny język znaczników (XML) 1.1, Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, i John Cowan ed. W3C (World Wide Web Consortium), 4 lutego 2004. Dostępny na http://www.w3.org/TR/xml11.

B Inne odnośniki (Nienormatywne)

Projekt IRI 3
Międzynarodowe identyfikatory źródła (IRI), M. Duerst and M. Suignard eds. marzec 2, 2003. Dostępne na http://www.w3.org/International/iri-edit/draft-duerst-iri-03.txt.
Projekt IRI 5
Międzynarodowe identyfikatory źródła (IRI), M. Duerst i M. Suignard ed. październik 26, 2003. Dostępne na http://www.w3.org/International/iri-edit/draft-duerst-iri-05.txt.
1.0 Errata
Przestrzenie nazw w XML Errata. W3C (World Wide Web Consortium). Dostępne na http://www.w3.org/XML/xml-names-19990114-errata.
Relatywna deprecjacja URI
Wyniki zebrania plenarnego W3C XML Tajne głosowanie na temat relatywnych odnośników URI W deklaracji przestrzeni nazw 3-17 lipca 2000, Dave Hollander i C. M. Sperberg-McQueen, 6 września 2000. Dostępny na http://www.w3.org/2000/09/xppa.
Wymagania
Przestrzenie nazw w XML 1.1 Wymagania, Jonathan Marsh, ed. W3C (World Wide Web Consortium), marzec 2002. Dostępne na http://www.w3.org/TR/2002/WD-xml-names11-req-20020403/.

C Wewnętrzna struktura przestrzeni nazw XML (Nienormatywne)

This appendix has been deleted.

D Zmiany od wersji 1.0 (Nienormatywne)

Ta wersja zawiera erratę do wersji 1.0 z 6 grudnia 2002 [1.0 Errata]. Są dwie dalsze ważne zmiany:

Jest kilka zmian redakcyjnych, łącznie z ilością zmian terminologii i dodatków mających na celu stworzenie większej konsystencji. Nienormatywny dodatek "Wewnętrzna struktura przestrzeni nazw" została usunięta.

E Podziękowania (Nienormatywne)

Ta praca odzwierciedla wkład wielu ludzi, przede wszystkim łącznie z członkami Konsorcjum World Wide Web Grupy roboczej XML i Grupy Specjalnego Interesu oraz uczestnikom Działalności Metadata W3C. Wkład Charlse'a Frankstona z Microsoftu była szczególnie cenna.