この文書のエラッタを参照いただきたい。これには、規範性のある改訂が含まれていることがある。
翻訳を参照すること。
この文書[原文]は、規範性のないこれらのフォーマットでも入手可能である。XML
Copyright © 2004 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3Cの免責(liability), 商標(trademark), 文書利用(document use), ソフトウェア使用許諾(software licensing)規則が適用される。
この節は、この文書の公開時における位置づけを説明したものである。他の文書がこの文書に取って代わることがある。現行のW3C公刊物の一覧およびこの技術レポートの最新版は、http://www.w3.org/TR/ のW3C技術レポート索引で見ることができる。
この文書は、W3Cの勧告 (Recommendation) である。この文書は、W3C会員およびその他の利害関係者によってレビューされ、ディレクターによってW3C勧告として公布されている。この文書は、安定的な文書であって、参照素材として利用したり、他の文書から規範性ある参照としての引用に用いられてもかまわない。勧告を作成する際のW3Cの役割は、仕様に対する注意を引き、その広範な普及を推進することにある。このことは、ウェブの機能と相互運用性とを高める。
この文書は、W3C XML Activity の産物である。この仕様書は、英語版が規範性ある唯一のバージョンである。しかしながら、この文書の翻訳を探しているのであれば、http://www.w3.org/2003/03/Translations/byTechnology?technology=xml-names11 を見てみること。
この文書に関連することのある知的所有権についての文書は、ワーキンググループの公開の知的所有権情報開示ページで見ること。
既知の実装は、Namespaces 1.1 実装レポートに文書化されている。テストスイートも、XMLテストスイートページを経由して入手することができる。
この文書のエラーは xml-names-editor@w3.org までレポートいただきたい。公開アーカイブが利用可能である。この文書のエラッタリストは http://www.w3.org/XML/2004/xml-names11-errata で入手できる。
1 動機と要約
1.1 表記法や用例に関する注意
2 XML名前空間
2.1 基本概念
2.2 名前空間名としてのIRIの使用
2.3 IRI参照の比較
3 名前空間を宣言する
4 有修飾名
5 有修飾名を使う
6 要素や属性に名前空間を適用する
6.1 名前空間のスコーピング
6.2 名前空間のデフォルト化
6.3 属性の一意性
7 文書の適合性
8 プロセッサの適合性
9 国際化リソース識別子 (IRI)
A 規範性ある参照
B Other references (規範性なし)
C XML名前空間の内部構造 (規範性なし)
D バージョン 1.0 以降の変更点 (規範性なし)
E 謝辞 (規範性なし)
このようなことを考慮すると、文書構造が、異なるマークアップ語彙に由来する名前が衝突することを避けるように名前を構築することが必須となる。この仕様書は、XML名前空間というメカニズムを解説する。これは、要素や属性に拡張名を割り当てることにより、これを実現するものである。
強調されている箇所では、この文書にある なければならない(MUST), てはならない(MUST NOT), 必須である(REQUIRED), べきである(SHOULD), べきでない(SHOULD NOT), てもよい(MAY)、というキーワードは、[Keywords] で解説されているとおり解釈されるべきものである。
この仕様書にある非終端生成規則の多くは、ここではなく、XML仕様書 [XML] で定義されている。ここで定義されている非終端規則が、XML仕様書で定義されている非終端規則と同じ名前を有するときには、すべての場合で、こちらにある生成規則が、そこで対応するものによって照合される文字列のサブセットに合致する。
この文書の生成規則において、NSC
とは、「名前空間制約 (Namespace Constraint)」である。これは、この仕様書に適合する文書が従わなければならない(MUST)規則の一つである。
[定義: XML名前空間 (XML namespace) は、IRI参照によって識別される。要素名や属性名は、この仕様書で解説されているメカニズムを使ってXML名前空間の中に置かれてよい。]
[定義: 拡張名 (expanded name) は、名前空間名とローカル名とからなるペアである。] [定義: I というIRIによって識別される名前空間にある N という名前については、名前空間名は I である。名前空間の中にない N という名前については、名前空間名は値がない。] [定義: どちらの場合でもローカル名 (local name) は N である。] 大域的に管理されているIRI名前空間と、その語彙のローカル名とという、この組み合わせこそが、名前の衝突を避けるために効力を有するのである。
IRI参照は、名前の中には認められていない文字を包含することができ、また、よく不便に長くなるので、拡張名は、XML文書の中にある要素や属性を直接に命名するためには使われない。その代わりに、有修飾名 (qualified name) が使われる。[定義: 有修飾名 (qualified name) は、名前空間解釈に従う名前である。] この仕様書に適合する文書では、要素名や属性名は有修飾名として出現する。文法的には、それらは有修飾名か無プリフィックス名かのいずれかである。プリフィックスを名前空間名に結合したり、無プリフィックス要素名に適用されるデフォルト名前空間を結合するために、属性ベースの宣言文法が用意される。これらの宣言は、一つの文書の中のいろいろな部分にいろいろなバインディングを適用できるよう、その宣言が出現する要素によってスコーピングされる。この仕様書に適合するプロセッサは、これらの宣言やプリフィックスを認識し、かつ、それらに基づいて動作しなければならない(MUST)。
空文字列は、合法的なIRI参照ではあるが、名前空間名としては使うことができない。
相対IRI参照を名前空間宣言の中で使うことは、同文書参照を含め、廃止方向 (deprecated) である。
このように相対URI参照を廃止方向としたのは、W3C XML Plenary Ballot [Relative URI deprecation] による決定である。これはまた、「DOMやXPathなどといったような今後の仕様書は、それら(訳註:相対URI参照)の解釈を定義しないであろう」とも宣言している。
ある与えられた名前空間に、ある名前が属しているかどうかや、二つの名前が同じ名前空間に属するかを判断するときに、名前空間を識別するIRI参照が比較される。[定義: 二つのIRIは文字列として扱われるのであって、その文字列が同一である場合、すなわち、同じキャラクタ列である場合に、かつ、そのような場合にのみ、同一 (identical) である。] 比較は、大文字小文字を区別するものであり、また、%-エスケーピングを実施したり復元したりはしない。
この結果、この意味では同一ではないIRI参照が、同じリソースへと解釈参照されることがある。例としては、大文字小文字や%-エスケーピングだけが違うIRI参照や、異なるベースURIをもつ外部実体にあるIRIがある (ただし、相対URIは名前空間名としては廃止方向であることに注意してほしい)。
名前空間宣言では、IRI参照は属性の既標準化値であり、そのため、XMLの文字参照や実体参照の置換は、一切の比較よりも先に既に実行されている。
例:
下記のIRI参照は、大文字小文字が異なっているので、名前空間を識別する上では、すべて異なっている。
http://www.example.org/wine
http://www.Example.org/wine
http://www.example.org/Wine
下記のIRI参照も、名前空間を識別する上では、すべて異なっている。
http://www.example.org/rosé
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
これらも同様である。
http://www.example.org/~wilbur
http://www.example.org/%7ewilbur
http://www.example.org/%7Ewilbur
eacute という実体が &eatute; であると定義されている場合、下記の開始タグはすべて、プリフィックス p を http://example.org/rosé/code> という同じIRI参照に結合する名前空間宣言を含んでいる。
<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é">
<p:foo xmlns:p="http://example.org/rosé">
解釈参照された場合に等価となるIRIの間で混乱が起こるリスクがあるので、%-エスケーピングされた文字を名前空間名で使わないことが、強く奨励される。
[定義: 名前空間 (もっと厳密に言うなら、名前空間バインディング) は、予約済み属性の一族を使って宣言 (declare) される。そうした属性の名前は、xmlns であるか、xmlns: で始まるものでなければならない。これらの属性は、他の一切のXML属性のように、直接与えられてもよいし、デフォルトによって与えられてもよい。]
[1] |
NSAttName
|
::= |
PrefixedAttName
|
|
| DefaultAttName
|
||||
[2] |
PrefixedAttName
|
::= |
'xmlns:' NCName
|
[NSC: 予約済みのプリフィックスおよび名前空間名] |
[3] |
DefaultAttName
|
::= |
'xmlns'
|
|
[4] |
NCName
|
::= |
NCNameStartChar NCNameChar*
|
/* XMLの Name マイナス ":" */ |
[5] |
NCNameChar
|
::= |
NameChar - ':'
|
|
[5a] |
NCNameStartChar
|
::= |
NameStartChar - ':'
|
属性の既標準化値は、IRI参照 - 名前空間を識別する名前空間名 - であるか、空文字列であるかのいずれかでなければならない (MUST)。 名前空間名は、その意図された目的を果たすため、一意性と永続性という特性を有するものであるべきである(SHOULD)。これが (スキーマが存在する場合に) スキーマを引き出すために直接利用できることは、目標としていない。統一リソース名 (URN) [RFC2141] は、これらの目的を念頭に置いて設計された文法の一例である。しかしながら、普通のURLも、これらの同じ目的を達成するような方法で管理することができることに注意するべきである。
[定義: 属性名が PrefixedAttName に合致する場合、NCName は名前空間プリフィックス (namespace prefix) を与える。これは、要素名や属性名を、その宣言の添付先である要素のスコープの中にある属性値の名前空間名に結合するために使われる。]
[定義: 属性名が DefaultAttName に合致する場合、属性値の名前空間名は、その宣言の添付先である要素のスコープの中にあるデフォルト名前空間 (default namespace) のそれである。] デフォルト名前空間や、宣言の上書きについては、6 要素や属性に名前空間を適用する で論じる。
名前空間宣言の例。これは、edi という名前空間プリフィックスを http://ecommerce.example.org/schema
という名前空間名に結合するものである。
<x xmlns:edi='http://ecommerce.example.org/schema'> <!-- "x" 要素およびその内容について "edi" プリフィックスが http://ecommerce.example.org/schema に結合される --> </x>
この仕様書に適合するXML文書において、いくつかの名前 (Name という非終端規則に対応する構造物) は、有修飾名 (qualified name) として与えられなければならない(MUST)。これは、以下のように定義される。
[6] |
QName
|
::= |
PrefixedName
|
| UnprefixedName
|
|||
[6a] |
PrefixedName
|
::= |
Prefix ':' LocalPart
|
[6b] |
UnprefixedName
|
::= |
LocalPart
|
[7] |
Prefix
|
::= |
NCName
|
[8] |
LocalPart
|
::= |
NCName
|
Prefix は、有修飾名の名前空間プリフィックスを与えるものであって、名前空間宣言の中にある名前空間IRI参照に結合されていなければならない(MUST)。[定義: LocalPart は、有修飾名のローカル部 (local part) を与える。]
プリフィックスが名前空間名のための場所取りとしてのみ機能することに注意してほしい。アプリケーションは、包含側文書を超えてスコープが広がっている名前を構築する際には、プリフィックスではなく、名前空間名を使うべきである(SHOULD)。
この仕様書に適合するXML文書では、要素名は、以下のような有修飾名として与えられる。
[9] |
STag
|
::= |
'<' QName (S Attribute)* S? '>'
|
[NSC: プリフィックスが定義済み] |
[10] |
ETag
|
::= |
'</' QName S? '>'
|
[NSC: プリフィックスが定義済み] |
[11] |
EmptyElemTag
|
::= |
'<' QName (S Attribute)* S? '/>'
|
[NSC: プリフィックスが定義済み] |
属性は、名前空間宣言であるか、あるいは、それらの名前が有修飾名として与えられるかのいずれかである。
[12] |
Attribute
|
::= |
NSAttName Eq AttValue
|
|
| QName Eq AttValue
|
[NSC: プリフィックスが定義済み] |
名前空間プリフィックスは、それが xml
または xmlns
であるのでない限り、そのプリフィックスが使われている要素の開始タグか祖先要素 (すなわち、その内容の中に、プリフィックスが付けられたマークアップが出現している要素) かのいずれにある名前空間宣言で宣言されていなければならない(MUST)。さらに、そうした最内の宣言の属性値は、空文字列であってはならない(MUST NOT)。
この制約から、名前空間宣言が、XML文書実体の中で直接にではなく、外部実体の中で宣言されているデフォルト属性を経由して与えられる場合には、動作上の難点が導かれることがある。そうした宣言は、妥当性検証を行わないXMLプロセッサをベースとするソフトウェアに読んでもらえないことがある。多くのXMLアプリケーションは、おそらく名前空間を認識するものを含め、妥当性検証を行うプロセッサを必須としてはいない。そうしたアプリケーションで正しい動作が要求される場合、名前空間宣言は、直接にか、DTDの内部サブセットの中で宣言されたデフォルト属性を経由するかのいずれかによって与えられなければならない(MUST)。
要素名や属性名は、DTDの中にある宣言に出現するときには、有修飾名としても与えられる。
[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
|
そうした名前空間宣言は、そのスコープの内部にあり、その宣言で指定されたプリフィックスに合致するプリフィックスをもつすべての要素および属性名に適用される。
有プリフィックス要素名または属性名に対応する拡張名は、そのプリフィックスに結合されているIRIを名前空間名としてもち、ローカル部をそのローカル名としてもつ。
<?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>
この例に示すように、複数の名前空間プリフィックスを、単一の要素の属性として宣言することができる。
<?xml version="1.1"?>
<!-- 名前空間プリフィックスは両方とも全体で利用できる -->
<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>
あるプリフィックスを表す名前空間宣言の属性値は、空であってもよい(MAY)。これには、その宣言のスコープの内部で、そのプリフィックスと名前空間名との結合を解くという効果がある。さらに宣言をして、プリフィックスを再び宣言し直してもよい(MAY)。
<?xml version="1.1"?>
<x xmlns:n1="http://www.w3.org">
<n1:a/> <!-- 合法; プリフィックス n1 は http://www.w3.org に結合される -->
<x xmlns:n1="">
<n1:a/> <!-- 違法; プリフィックス n1 は、ここでは結合されない -->
<x xmlns:n1="http://www.w3.org">
<n1:a/> <!-- 合法; プリフィックス n1 は、再び結合される -->
</x>
</x>
</x>
デフォルト名前空間宣言のスコープは、それが出現している開始タグの最初から、対応する終了タグの最後にまで及ぶ。ただし、内側にある一切のデフォルト宣言のスコープは除く。空タグの場合には、スコープはそのタグ自身である。
デフォルト名前空間宣言は、そのスコープの内部にあるすべての無プリフィックス要素名に適用される。デフォルト名前空間宣言は、属性名には直接には適用されない。無プリフィックス属性の解釈は、それが出現している要素によって決定される。
スコープ内にデフォルト名前空間宣言がある場合、無プリフィックス要素名に対応する展開名は、デフォルト名前空間のIRIを、その名前空間名としてもつ。スコープ内にデフォルト名前空間宣言がない場合、名前空間名は、値を有さない。無プリフィックス属性の名前空間名は、つねに値を有さない。すべての場合で、ローカル名は、ローカル部 である (これは、もちろん、無プリフィックス名そのものと同じである)。
<?xml version="1.1"?> <!-- 要素は、この場合はデフォルトにより、HTML名前空間の中にある --> <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"?>
<!-- プリフィックスが付けられていない要素型は "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>
大きめの名前空間スコーピングの例:
<?xml version="1.1"?> <!-- 最初は、デフォルト名前空間は "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> <!-- 評釈のためにHTMLをデフォルト名前空間にする --> <p xmlns='http://www.w3.org/1999/xhtml'> This is a <i>funny</i> book! </p> </notes> </book>
デフォルト名前空間宣言の属性値は、空であってもよい(MAY)。これには、宣言のスコープの内部では、デフォルト名前空間がないのと同じ効果がある。
<?xml version='1.1'?> <Beers> <!-- テーブル内部のデフォルト名前空間は、HTMLの名前空間である --> <table xmlns='http://www.w3.org/1999/xhtml'> <th><td>Name</td><td>Origin</td><td>Description</td></th> <tr> <!-- テーブルのセルの内部にはデフォルト名前空間がない --> <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>
この仕様書に適合するXML文書では、どのタグも、つぎのような二つの属性を包含してはならない。
この制約は、どの要素も同じ展開名をもつ二つの属性を持っていないことを要求するのと等価である。
たとえば、以下では、bad
開始タグはそれぞれ違法である。
<!-- http://www.w3.org は n1 と 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>
しかしながら、以下はそれぞれ合法である。2番目のものは、デフォルト名前空間は属性名に適用されないからである。
<!-- http://www.w3.org は n1 に結合されていて、また、デフォルトでもある --> <x xmlns:n1="http://www.w3.org" xmlns="http://www.w3.org" > <good a="1" b="2" /> <good a="1" n1:a="2" /> </x>
この仕様書は、XML 1.1 文書に適用される。この仕様書に適合するためには、文書は、XML 1.1 仕様書 [XML 1.1] に従って整形式でなければならない(MUST)。
この仕様書に適合するXML文書では、要素名や属性名は、QName の生成規則に合致しなければならず(MUST)、かつ、「名前空間制約」を満たさなければならない(MUST)。XML 1.1 整形式であるために Name のXML生成規則に合致することが必須である(REQUIRED)この文書中の他のすべてのトークンは、この仕様書の NCName の生成規則に合致しなければならない(MUST)。
[定義: 文書は、この仕様書に適合する場合、名前空間整形式 (namespace-well-formed) である。]
従って、名前空間整形式の文書では、つぎのようになる。
すべての要素名および属性名は、0個または1個のコロンを包含する。
実体名、処理命令ターゲット、記法名は、コロンを包含しない。
さらに、名前空間整形式の文書は、名前空間妥当であることがある。
[定義: 名前空間整形式の文書は、それが XML 1.1 仕様書により妥当であって、かつ、XML 1.1 妥当であるためにXMLの Name の生成規則に合致することが必須とされている要素名及び属性名以外のすべてのトークンが、この仕様書の NCName の生成規則に合致する場合、名前空間妥当 (namespace-valid) である。]
従って、名前空間妥当な文書では、つぎのようになる。
ID 型、IDREF(S) 型、ENTITY(IES) 型、NOTATION 型の宣言型をもつ属性は、コロンを包含しない。
[定義: この仕様書に適合する妥当性検証を行うXMLプロセッサは、さらに名前空間妥当性の違反をレポートする場合、名前空間妥当性検証を行う(namespace-validating) ものである。]
IRIについてのもっと一般性のある定義や議論については、 [IRI draft 5] (進行中の作業) を見ること。
URI参照は、ASCII文字のサブセットに限定される。IRI参照は、#xA0 以上のほとんどのUnicode文字を認める。初期の IRI RFC のドラフト (例. [IRI draft 3]) も、認められていないASCII文字をいくつか認めていたが、現行ドラフト ([IRI draft 5]) は認めていない。
[定義: [IRI draft 5] によりIRIで認められる追加文字 (additional character)は、つぎのものである。]
Unicode 第0面キャラクタ #xA0 - #xD7FF, #xF900-#xFDCF, #xFDF0-#xFFEF
Unicode 第1-14面キャラクタ #x10000-#x1FFFD ... #xD0000-#xDFFFD, #xE1000-#xEFFFD
[定義: IRI参照 (IRI reference) は、以下のステップを適用してURI参照に変換することのできる文字列である。]
ホスト名部が存在する場合には、それを、[RFC3490] の Section 4.1 に指定された ToASCII 演算を、UseSTD3ASCIIRules フラグと AllowUnassigned フラグを TRUE に設定して使って変換する。
すべての追加文字を、以下のとおりエスケーピングする。
それぞれの追加文字を、1個以上のバイトとして、UTF-8 [RFC3629] を変換する。
結果として得られたバイトを、URIエスケーピングメカニズムを用いてエスケープする (すなわち、%HH に変換する。ここで HH は、バイト値を十六進表記したものである)。
元の文字を、結果として得られた文字の並びで置き換える。
註:
[IRI draft 5] のアルゴリズムには、UCS正規化ステップが含まれているが、これは、どの文字列がIRI参照であるかに違いをもたらさない。
このバージョンは、2002年12月6日時点のバージョン 1.0 のエラッタ [1.0 Errata] を組み込んでいる。本質的な変更点は2つある。
プリフィックスを宣言解除するためのメカニズムを用意した。
名前空間名は、URIではなく、IRIとした。
編集上の変更点は、いくつかある。これには、一貫性を高めることを狙いとした多数の用語の変更や追加が含まれる。規範性のない付録である「XML名前空間の内部構造」が外された。