Autorzy:
Ireneusz Wojdyło
Kamila Wiatr
Katarzyna Smalec
Sebastian Snopek
Lokalizacja: http://www.t4tw.info/tlumaczenia/Namespaces/Namespaces.htm
Dokument ten jest tłumaczeniem rekomendacji W3C "Namespaces in XML". Przekład ten nie jest przekładem normatywnym
i może zawierać błędy wynikające z tłumaczenia. Status normatywny posiada
jedynie wersja w języku angielskim na stronie W3C http://www.w3.org/TR/1999/REC-xml-names-19990114/.
Dokument jest chroniony prawem autorskim. Copyright © 2003 W3C® (MIT, ERCIM, Keio).
Copyright C 1999 W3C (MIT, INRIA, Keio ), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
Ten dokument został zbadany przez członków W3C i inne zainteresowane strony, oraz został zatwierdzony przez Dyrektora jako Rekomendacja W3C. Jest on stabilny i może być używany jako materiał referencyjny lub cytowany w innych dokumentach jako referencja normatywna. Rolą W3C w utworzeniu tej rekomendacji było przyciągnięcie uwagi do tej specyfikacji oraz promowanie jej szerokiego zastosowania. Rozszerza to funkcjonalność i uniwersalność sieci internetowej.
Lista powszechnych błędów tej specyfikacji dostępna jest pod http://www.w3.org/XML/xml-names-19990114-errata.
Proszę o zgłaszanie błędów zawartych w tym dokumencie pod xml-names-editor@w3.org.
Przestrzenie nazw zapewniają prosta metodę określania nazw elementu i atrybutu używanych w dokumentach Rozszerzalnego Języka Znaczników przez łączenie ich z przestrzeniami nazw identyfikowanymi przez odnośniki URI.
Bierzemy pod uwagę aplikacje Rozszerzalnego Jezyka Znaczników (Extensible Markup Language (XML) w którym jeden dokument XML może zawierać elementy i atrybuty (do których odnosimy się jako ''słownictwo znaczników'') które są określone dla różnych modułów oprogramowania i używane przez nie. Jednym z powodów takiego stanu rzeczy jest modularność - jeśli dane słownictwo znacznika istnieje, które jest zrozumiałe i dla którego jest dostępne użyteczne oprogramowanie, lepiej jest, aby użyć ponownie dany znacznik, niż wynaleźć nowy.
Dokumenty posiadające różne słownictwo znaczników stanowią problemy związany z identyfikacją i powodują konflikt. Moduły oprogramowania powinny być w stanie identyfikować tagi i atrybuty które są przeznaczone przetwarzać, pomimo ,,konfliktów'' zdarzających się w sytuacji, kiedy dany znacznik przeznaczony dla innego zestawu oprogramowania korzysta z tego samego typu elementu lub nazwy atrybutu.
Powyższe rozważania wymagają od konstrukcji dokumentów posiadania uniwersalnych nazw, których zasięg rozciąga się poza dany dokument. Owa specyfikacja opisuje mechanizm przestrzeni nazw XML (XML namespaces), który to realizuje.
[Definicja:] Przezstrzeń nazw XML (XML namespace)jest zbiorem nazw, identyfikowanych przez odnośnik URI [RFC2396], których używa się w dokumentach XML jako typy elementów i nazwy atrybutów . Przestrzenie nazw XML tym różnią się od ,,przestrzeni nazw'' używanych normalnie w dziedzinach informatycznych, ze wersja XML posiada strukturę wewnętrzna i nie jest, w pojęciu matematycznym, zbiorem. Kwestie te omówione są w "A. Wewnętrznej Strukturze Przestrzeni nazw XML".
[Definicja:] Odnośniki URI które identyfikują przestrzenie nazw, uważa się za identycznew przypadku, kiedy są dokładnie takie same -,,znak po znaku''. Należy zwrócić uwagę na to, ze odnośniki URI które nie są identyczne, w tym znaczeniu, mogą spełniać role funkcyjnego odpowiednika . Przykłady włączają w to odnośniki URI, które różnią się jedynie wielkością znaków lub które występują w encjach zewnętrznych posiadających inne rzeczywiste base URI.
Nazwy z przestrzeni nazw XML mogą pojawić się jako kwalifikowane nazwy, posiadające pojedynczy dwukropek, dzielące nazwę na prefix przestrzeni nazw i część lokalną. Prefiks, który jest mapowany do odnośnika URI, dobiera przestrzeń nazw. Owa kombinacja wszechstronnie zarządzanych przestrzeni nazw URI i własna przestrzeń nazwy dokumentu tworzą unikalne identyfikatory o wszechstronnym zastosowaniu. Mechanizmy przewidziane są w stosunku do prefix scoping i defaulting.
Odnośniki URI mogą posiadać znaki nie dozwolone w nazwach, dlatego nie można ich używać bezpośrednio jako prefiksy przestrzeni nazw. W związku z tym, prefiks przestrzeni nazwy służy jako zastępstwo dla odnośnika URI. Składnię opartą na atrybutach (opisaną poniżej) używa się w celu deklarowaniapołączenia prefiksu przestrzeni nazwy z odnośnikiem URI - oprogramowanie które wspiera ową propozycje przestrzeni nazw musi identyfikować i działać na podstawie owych deklaracji i prefiksów.
Należy zauważyć, że wiele z nieterminali w wytworach tej specyfikacji nie jest tu określona, lecz w specyfikacji [XML]. Gdy nieterminale określone w tej specyfikacji noszą takie same nazwy jak nieterminale określone w specyfikacji XML, wytwory tej specyfikacji we wszystkich wielkościach znaków zgadzają się z podzbiorem ciągu znaków dobranych przez ich odpowiedniki w specyfikacji XML.
W wytworach tych dokumentów NSC to "Ograniczenie Przestrzeni nazw",
jedna z zasad której dokumenty podległe tej specyfikacji musza stosować.
Należy zauważyć, ze nazwy z zakresu Internetu użyte w przykładach, z wyjątkiem w3.org, są wybrane losowo i posiadają małe znaczenie.
[Definicja:] Daną przestrzeń nazw deklaruje się używając rodziny zastrzeżonych atrybutów . Taką nazwą atrybutu musi albo być xmlns, albo posiadać xmlns jako prefiks. Owe atrybuty, jak każde inne atrybuty XML, można zapewnić bezpośrednio lub przez wartość domyślną.
| Nazwy atrybutow dla Deklaracji Przestrzeni nazw | ||||||||||||||||||||||||||||
|
[Definicja:] Wartość atrybutu odnośnik URI jest tą nazwą przestrzeni nazwy identyfikującej przestrzeń nazwy. Nazwa przestrzeni nazw, aby spełniać swój zamierzony cel, powinna nosić cechy jednoznaczności i stałości. Nie jest celem, aby był użyteczny przy odzyskiwaniu schematu (jeśli taki istnieje). Przykładem składni przeznaczonej do spełniania powyższych celów jest ta używana w Zunifikowanym formacie nazw zasobów (Uniform Resource Names) [RFC2141]. Jednakże, należy zauważyć, ze zwykłymi URL można zarządzać w taki sposób aby uzyskać te same cele.
[Definicja:] Jeśli nazwa atrybutu pasuje do PrefixedAttName,
wtedy
NCName daje prefix przestrzeni nazw ,
używany do łączenia nazw elementów i atrybutów z
nazwą przestrzeni nazww wartości atrybutu w polu elementu do którego dołączona jest deklaracja. W takich deklaracjach, nazwa przestrzeni nazw może nie być pusta.
[Definicja:] Jeśli nazwa atrybutu pasuje do DefaultAttName,
wtedy
nazwa przestrzeni nazww wartości atrybutu jest tą domyślną przestrzenią nazw w polu elementu do którego dołączona jest deklaracja. W takiej domyślnej deklaracji, wartość atrybutu może nie być pusta. Domyślne przestrzenie nazw i nadpisywanie deklaracji są opisane w "5. Stosowanie Przestrzeni nazw do Elementów i Atrybutów".
Przykładem deklaracji przestrzeni nazw, która łączy prefiks przestrzeni nazw edi z nazwą przestrzeni nazw http://ecommerce.org/schema:
<x xmlns:edi='http://ecommerce.org/schema'> |
Ograniczenie Przestrzeni nazw:
Wprowadzenie "XML"
Prefiksy zaczynające się od trzy-literowej sekwencji x,
m, l, w jakiejkolwiek kombinacji wielkości znaków, są zastrzeżone do użycia przez XML oraz specyfikacje związane z XML.
[Definicja:] W dokumentach XML podległych tej specyfikacji, niektóre nazwy (konstrukcje odpowiadające nieterminalnej
Name)
mogą być podane jako kwalifikowane nazwy jak określono:
| Kwalifikonana Nazwa | ||||||||||||
|
Prefiks zapewnia część przestrzeni nazw prefiksukwalifikowanej nazwy, i musi zostać połączone z odnośnikiem przestrzeni nazw URI w deklaracji przestrzeni nazw.
[Definicja:]
LocalPart zapewnia część lokalną kwalifikowanej nazwy.
Należy zauważyć , ze prefiks spełnia jedynie funkcje znaku-wypełniacza dla nazwy przestrzeni nazw. Aplikacje powinny korzystać z przestrzeni nazw, nie prefiksu, w tworzeniu nazw których zasięg rozciąga się poza dany dokument.
W dokumentach XML podległym tej specyfikacji, typy elementów są podane jako kwalifikowane nazwy, jak widać poniżej:
| Typy Elementów | ||||||||||||||||||
|
Przykład kwalifikowanej nazwy służącej jako typ elementu::
<x xmlns:edi='http://ecommerce.org/schema'> |
Atrybutami są albo deklaracje przestrzeni nazw albo ich nazwy podane jako kwalifikowane nazwy:
| Attribute | ||||||||||
|
Przykład kwalifikowanej nazwy służącej jako nazwa atrybutu:
<x xmlns:edi='http://ecommerce.org/schema'> |
Ograniczenie Przestrzeni nazw: Prefiks Deklarowany
Prefiks przestrzeni nazw, o ile nie jest to xml lub xmlns, musiał być zadeklarowany w atrybucie deklarcji przestrzeni nazw
albo w start-tag elementu w którym używa się prefiksu, albo w elemencie będącym przodkiem (tzn.element w którego zawartości występuje znacznik posiadający prefiks).
Prefiks xmljest według definicji połączony z nazwą przestrzeni nazw http://www.w3.org/XML/1998/namespace.
Prefiks xmlns używa się dla połączeń przestrzeni nazw i sam nie jest połączony z żadna nazwa przestrzeni nazw.
Powyższe ograniczenie może prowadzić do problemów operacyjnych, w przypadku w którym zapewniono atrybut deklaracji przestrzeni nazw, nie bezpośrednio w encji dokumentu, XML, lecz przez atrybut docelowy zadeklarowany w encji zewnętrznej. Takie deklaracje mogą nie zostać odczytane przez oprogramowanie oparte na niewalidujacym procesorze XML. Wielu aplikacjom XML, włączając w to te przypuszczalnie obsługujące przestrzenie nazw, nie udaje się przejść wymaganej walidacji.Dla sprawnego działania z takimi aplikacjami, deklaracje przestrzeni nazw musza być zapewnione albo bezpośrednio, lub poprzez atrybuty docelowe zadeklarowane w wewnętrznym podzbiorze DTD.
Nazwy elementów i typy atrybutów są również podane jako kwalifikowane nazwy, gdy pojawiają się w deklaracjach w DTD:
| Kwalifikowane Nazwy w Deklaracjach | ||||||||||||||||||||||||||||
|
Deklarację przestrzeni nazw stosuje się do elementu, gdzie jest określona i do wszystkich elementów wewnątrz zawartości tego elementu, o ile nie są nadpisane przez inną deklaracje z ta sama częścią NSAttName:
<?xml version="1.0"?> |
Wielokrotne prefiksy przestrzeni nazw można zadeklarować jako atrybuty pojedynczego elementu, jak pokazano na przykładzie:
<?xml version="1.0"?> |
Domyślną przestrzeń naz stosuje się do elementu w którym jest zadeklarowana (jeśli element ten nie posiad prefiksu przestrzeni nazw), i do wszystkich elementów nie posiadających prefiksu wewnątrz zawartości tego elementu. Jeśli odnośnik URI w deklaracji przestrzeni domyślnej jest pusty, wtedy elementy nie posiadające prefiksu w polu tej deklaracji, nie powinny być w żadnej przestrzeni nazw. Należy zauważyć, że domyślnych przestrzeni nazw nie stosuje się bezpośrednio do atrybutów.
<?xml version="1.0"?> |
<?xml version="1.0"?> |
Dłuższy przykład zasięgu przestrzeni nazw:
<?xml version="1.0"?> |
Domyślną przestrzeń nazw można umieścić do pustego łańcucha znaków. To odnosi ten sam skutek, wewnątrz pola deklaracji, ze nie ma tam domyślnej przestrzeni nazw.
<?xml version='1.0'?> |
W dokumentach XML podległym tej specyfikacji, żaden tag nie może zawierać dwóch atrybutów które:
Na przykład, każdy z niewłaściwych start-tags jest niedozwolony w poniższym przykładzie:
<!-- http://www.w3.org is bound to n1 and n2 --> |
Jednakże, każdy z następujących jest dozwolony, ten drugi ponieważ domyślna przestrzeń nazw nie stosuje się do nazw atrybutów:
<!-- http://www.w3.org is bound to n1 and is the default --> |
W dokumentach XML będących w zgodzie z tą specyfikacją, typy elementów i nazwy atrybutów musza dobrać produkcje do QName i muszą spełnić ,,Ograniczenia Przestrzeni nazw''.
Dokument XML jest zgodny z ta specyfikacja, jeśli wszystkie inne znaki w tym dokumencie które są potrzebne, dla zgodności z XML , aby dopasowć produkcje XML do Name, posiadają zgodność produkcji tej specyfikacji z NCName.
Skutek zgodności w takim dokumencie jest następujący:
Ściśle mówiąc, wartości atrybutów zadeklarowane jako typy ID, IDREF(S), ENTITY(IES),
i NOTATION są również Names,
i dlatego powinny być bez dwukropka. Jednakże, deklarowany typ wartości atrybutów jest dostępny jedynie dla procesorów czytających deklaracje znaczników, tak jak na przykład
walidujące procesory.
Zatem, dopóki nie określono użycie procesora walidującego, nie ma pewności że zawartości wartości atrybutu zostały sprawdzone w kwestii zgodności z ta specyfikacją.
W dziedzinach informatycznych, określenie ,,przestrzeń nazw'' konwencjonalnie odnosi się zbioru nazw tzn. kolekcji nie zawierającej duplikatów. Jednak, traktowanie nazw używanych w znakowaniu XML jako przestrzeń nazw w wielkim stopniu osłabia ich użyteczność. Głównym celem korzystania z takich nazw w dokumentach XML, jest umożliwienie identyfikacji logicznych struktur w dokumentach przez moduły oprogramowania takie jak procesory zapytania, silniki renderujace kierowane arkuszem stylów, systemy walidacyjne oparte na schemacie.Należy rozważyć następujący przykład:
<section><title>Book-Signing Event</title> |
W tym przykładzie, tytuł nazwy występuje wewnątrz znacznika trzy razy, a sama nazwa z pewnością nie dostarczy wystarczającej informacji, aby zapewnić właściwe przetwarzanie przez moduł oprogramowania.
Kolejny problematyczny obszar jawi się w korzystaniu z ,,globalnych'' atrybutów, jak zobrazowano na poniższym przykładzie, fragmencie dokumentu XML, który ma być wyświetlony za pomocą arkuszu stylów CSS:
<RESERVATION> |
W tym przypadku atrybut CLASS, który opisuje podstawę opłaty biletu i przejmuje takie wartości jak "J", "Y", i "C", jest rózne na wszystkich semantycznych poziomach od atrybutu HTML:CLASSktóry jest użyty w celu stymulacji bogactwa składni w HTML, jako środek pokonania ograniczonego repertuaru elementu poprzez podział na podklasy.
XML 1.0 nie zapewnia wbudowanego sposobu na zadeklarowanie atrybutów ,,globalnych''- elementy danych takie jak atrybut HTML CLASSsą globalne jedynie w ich prozaicznym opisie, oraz w ich interpretacji przez aplikacje HTML. Jednakże, takie atrybuty, których ważną cechą charakterystyczną jest to, ze posiadają unikalne nazwy, można często zaobserwować w wielu aplikacjach.
Aby osiągnąć cel i sprawić ze kwalifikowane i nie kwalifikowane nazwy staną się użyteczne oraz spełnią swoja role, identyfikujemy nazwy pojawiające się w przestrzeni nazw XML jako należące do jednego z kilku rozłącznych tradycyjnych (tzn. podzielonych na zbiory) przestrzeni nazw, nazwanych partycjami przestrzeni nazw. Partycjami są:
W dokumentach XML podległym tej specyfikacji, nazwy wszystkich kwalifikowanych ( posiadających prefiks)atrybutów są przypisane partycji globalnych atrybutów, a nazwy wszystkich nie kwalifikowanych atrybutów są przypisane właściwej partycji poszczególnych typów elementów.
Dla udogodnienia związanego z określaniem zasad i tworzeniem porównań, określamy rozszerzalną formę, wyrażonej tu w składni elementu XML, dla każdego typu elementu i nazwy atrybutu w dokumentach XML.
[Definicja:] Rozszerzalny typ elementu jest wyrażony jako pusty element XML typu ExpEType. Posiada on wymagany atrybut type, który daje LocalPart i opcjonalny atrybut ns który, jeśli element jest kwalifikowany, pokazuje swoją nazwe przestrzeni nazw.
[Definicja:] Rozszerzalna nazwa atrybutu jest wyrażona jako pusty element XML typu ExpAName.
Posiada on wymagany atrybut name, który nadaje nazwe. Jeśli atrybut jest globalny, wtedy posiada wymagany atrybut ns, który daje nazwę przestrzeni nazw;
w przeciwnym razie, posiada wymagany atrybut eltype, który daje typ dołączonego elementu, i opcjonalny atrybut elns, który daje nazwę przestrzeni nazw, gdy jest znana, dołączonego elementu.
Nieznaczne różnice dotyczące przykładów podanych powyżej pokażą działanie rozszerzalnych typów elementów i nazw atrybutów. Po każdym z dwóch następujących fragmentów następuje tabelka przedstawiająca rozbudowę nazw:
<!-- 1 --> <section xmlns='urn:com:books-r-us'> |
Te nazwy rozwinęłyby się w następujący sposób:
| Line | Name | Expanded |
| 1 | section | <ExpEType type="section" ns="urn:com:books-r-us" /> |
| 2 | title | <ExpEType type="title" ns="urn:com:books-r-us" /> |
| 3 | signing | <ExpEType type="signing" ns="urn:com:books-r-us" /> |
| 4 | author | <ExpEType type="author" ns="urn:com:books-r-us" /> |
| 4 | title | <ExpAName name='title' eltype="author" elns="urn:com:books-r-us" /> |
| 4 | name | <ExpAName name='name' eltype="author" elns="urn:com:books-r-us" /> |
| 5 | book | <ExpEType type="book" ns="urn:com:books-r-us" /> |
| 5 | title | <ExpAName name='title' eltype="book" elns="urn:com:books-r-us" /> |
| 5 | price | <ExpAName name='price' eltype="book" elns="urn:com:books-r-us" /> |
<!-- 1 --> <RESERVATION xmlns:HTML="http://www.w3.org/TR/REC-html40"> |
| 1 | RESERVATION | <ExpEType type="RESERVATION" /> |
| 2 | NAME | <ExpEType type="NAME" /> |
| 2 | HTML:CLASS | <ExpAName name="CLASS" ns=http://www.w3.org/TR/REC-html40 /> |
| 3 | SEAT | <ExpEType type="SEAT" /> |
| 3 | CLASS | <ExpAName name="CLASS" eltype="SEAT"> |
| 3 | HTML:CLASS | <ExpAName name="CLASS" ns="http://www.w3.org/TR/REC-html40" /> |
| 4 | HTML:A | <ExpEType type="A" ns="http://www.w3.org/TR/REC-html40" /> |
| 4 | HREF | <ExpAName name="HREF" eltype="A" elns="http://www.w3.org/TR/REC-html40" /> |
| 5 | DEPARTURE | <ExpEType type="DEPARTURE" /> |
Ograniczenia wyrażone przez "5.3 Unikalność Atrybutów"powyżej, może być bezpośrednio zastosowane przez żądanie, aby żaden element nie posiadał dwóch atrybutów których rozszerzalne nazwy są równoznaczne tzn. posiadają te same pary attribute-value.
Ta praca odzwierciedla wkład pracy wielkiej rzeszy ludzi, włączając w to szczególnie członków Grup Roboczych XML Konsorcjum Sieci internetowej, Grupy Special Interest i uczestników W3C Metadata Activity. Szczególnie cenny był wkład Charlsa Frankstona z firmy Microsoft .