この標準情報(TR)は, 1999年1月にWorld Wide Web Consortium(W3C)から公表された Namespaces in XML勧告を翻訳し, 技術的内容を変更することなく作成した標準情報(TR)である。
この標準情報(TR)は,XML名前空間を規定する。 XML名前空間は,XML文書の中で使用する要素及び属性の名前を,URI参照で識別する名前空間と関連付け,これによって,それらの名前を修飾するための単純な方法を提供する。
複数のソフトウェアモジュールのために定義され使用される要素及び属性 (これを"マーク付け語い"という。)を,一つの拡張可能なマーク付け言語 (Extensible Markup Language,以降XML)の文書が含んでもよい場合を想定する。これを想定する動機の一つは,モジュール性にある。よく理解されたマーク付け語いが存在し,それを使用する有用なソフトウェアが利用可能となっている場合,このマーク付けを再開発するよりもむしろ再利用するほうがよい。
複数のマーク付け語いを含む文書では,要素型及び属性名の認識,並びにそれら名前の衝突が問題となる。ソフトウェアモジュールは,他のソフトウェアパッケージ用マーク付けで同じ要素型又は属性名が使われている場合,名前の"衝突"に直面するが,その場合でも,そのモジュールが処理するものとして設計されているタグ及び属性を認識できることが必要である。
こうしたことは,スコープが文書を越えて広がる普遍的な名前を,文書の構成要素がもつほうがよいことを示している。この標準情報(TR)では,これを達成する XML名前空間 という機構を示す。
XML名前空間とは,URI参照[RFC2396]によって識別され,XML文書の中で要素型及び属性名として使用される名前の集まりとする。 XML名前空間は,内部構造をもっており,数学的な集合ではないという点で,計算機分野で慣習的に使用する "名前空間"とは異なる。これに関しては,"附属書A XML名前空間の内部構造"を参照すること。
名前空間を識別するURI参照は,文字ごとに全く同じ場合,同一とみなす。 この意味で同一ではないURI参照も,実際には機能的に等価となることがあることに注意されたい。この例として,大文字・小文字だけが違うURI参照,又は異なる実効的基底URIをもつ外部実体の中でのURI参照がある。
XML名前空間を使った名前は,修飾された名前として出現してよい。この修飾された名前は,名前を一つの名前空間接頭辞及び一つの ローカル名に分離するコロンを一つ含む。 URI参照に対応付けられる接頭辞が,名前空間を選択する。普遍的に管理されるURI名前空間と文書自体の名前空間との組合せが,普遍的に一意な識別子を生成する。さらに,接頭辞のスコープ及びデフォルトのための機構を提供する。
URI参照は,名前には許されない文字を含むことが可能で,直接には名前空間接頭辞として使うことができない。そこで,名前空間接頭辞はURI参照の代理として機能する。名前空間接頭辞とURI参照との関連を宣言するために,2.以降で示す属性に基づく構文を使用する。この名前空間規定をサポートするソフトウェアは,これらの宣言及び接頭辞を認識し,それに基づいて動作しなければならない。
この標準情報(TR)の生成規則の中の非終端記号の多くは,この標準情報(TR)ではなく,XMLの規定[XML]の中で定義されている。この標準情報(TR)で定義する非終端記号が, XMLの規定で定義する非終端記号と同じ名前をもつ場合,この標準情報(TR)での生成規則は,すべての場合において,XMLの規定の対応する生成規則にマッチする文字列の部分文字列とマッチする。
この規定の生成規則におけるNSC
とは,この規定に適合する文書が従わなければならない規則の一つ,"名前空間制約(Namespace
Constraint)" のこととする。
例で使用するすべてのインタネットドメイン名は,
w3.org
以外は無作為に選ばれたものであって,何らかの意味をもつものとして受け取らないほうがよい。
名前空間は,一連の予約済み属性を使って宣言される。それら属性の名前は,xmlns
とするか,又は接頭辞としてxmlns:
をもたなければならない。これらの属性は,他のXML属性と同様に,直接に又はデフォルトで提供される。
名前空間宣言用の属性名 | ||||||||||||||||||||||||||||
|
URI参照である属性の値を,名前空間を識別する名前空間名とする。 名前空間名は,その意図する目的を果たすために,一意性及び永続性という特徴をもつことが望ましい。 (スキーマが存在する場合に)スキーマ検索のために名前空間名を直接に利用できることは,目標とはしない。これらの目標を念頭におき設計された文法としては,例えば,Uniform Resource Name(URN)[RFC2141]の文法がある。しかし,通常のURLも, これらと同じ目標を達成する方法で管理可能なことには注意したほうがよい。
属性名が PrefixedAttName
にマッチする場合, NCName
は,名前空間接頭辞を与える。この接頭辞は,その宣言が指定されている要素のスコープの中の属性値における名前空間名に,要素名及び属性名を関連付けるために使用する。
この宣言においては,名前空間名は,空であってはならない。
属性名が DefaultAttName
にマッチする場合,その属性値における名前空間名は,宣言が指定されている要素のスコープの中のデフォルト名前空間の名前空間名とする。
これらデフォルト宣言では,属性値は空であってもよい。デフォルト名前空間と宣言の上書きとについては, "5. 要素及び属性への名前空間の適用"で示す。
名前空間宣言の例を次に示す。この例では,名前空間接頭辞edi
を,名前空間名http://ecommerce.org/schema
に関連付けている。
<x xmlns:edi='http://ecommerce.org/schema'> |
名前空間制約:先頭の"XML"
三つの字,x
,m
及びl
の大文字・小文字の任意の組合せの並びで始まる接頭辞は, XML規定及びXML関連規定による利用のために予約済みとする。
この標準情報(TR)に適合するXML文書では,名前(すなわち,非終端子Name
に対応する構成要素)の幾つかを,次に定義する修飾された名前として与えてもよい。
修飾された名前 | ||||||||||||
|
Prefix
は,修飾された名前の名前空間接頭辞の部分を与え,名前空間宣言
の中の名前空間URI参照に関連付いていなければならない。 LocalPart
は,修飾された名前のローカル名を与える。
接頭辞は,名前空間名のためのプレースホルダとして機能するだけであることに注意されたい。文書を越えてスコープの広がる名前を構築する場合,アプリケーションは,接頭辞ではなく名前空間名を使うほうがよい。
この標準情報(TR)に適合するXML文書では,要素型は, 修飾された名前を用いて,次のとおりに与えられる。
要素型 | ||||||||||||||||||
|
要素型として機能する修飾された名前の例を次に示す。
<x xmlns:edi='http://ecommerce.org/schema'> |
属性は,名前空間宣言か,又はその属性の名前が修飾された名前として与えられるものとする。
属性 | ||||||||||
|
属性名として機能する修飾された名前の例を次に示す。
<x xmlns:edi='http://ecommerce.org/schema'> |
名前空間制約:接頭辞が宣言されていること
名前空間接頭辞は,それがxml
又はxmlns
でない限り,その接頭辞を使用する要素の開始タグ又は先祖要素(すなわち,接頭辞付きのマーク付けがその内容の中に出現する要素)の名前空間宣言の中に宣言されていなければならない。 接頭辞xml
は,定義によって,名前空間名
http://www.w3.org/XML/1998/namespace
に束縛される。接頭辞xmlns
は,名前空間束縛だけに使用するものであって,それ自体はどの名前空間名にも束縛されない。
この制約は,名前空間宣言属性が,直接にXML文書実体の中にではなく,外部実体の中で宣言されたデフォルト属性を経由して提供される場合に,操作上の困難を生じるかもしれない。それら宣言は,妥当性を検証しないXMLプロセサに基づくソフトウェアでは読めないかもしれない。 XMLアプリケーションは,恐らく名前空間を認識可能なものでさえ,妥当性を検証するプロセサを要求してもその要求が満たされないことが多い。それらアプリケーションでの正しい操作のために,名前空間宣言は,直接に,又はDTDの内部サブセットの中で宣言されたデフォルト属性を経由して,提供しなければならない。
要素型及び属性名は,DTDの中の宣言に出現する場合にも,修飾された名前として与えられる。
宣言における修飾名 | ||||||||||||||||||||||||||||
|
名前空間宣言は,同じNSAttName
部分をもつ他の名前空間宣言によって上書きされない限り,それが指定された要素とその要素の内容の内部にあるすべての要素とに適用されるものとする。
<?xml version="1.0"?> |
次の例に示すとおり,複数の名前空間接頭辞を,一つの要素の属性として宣言できる。
<?xml version="1.0"?> |
デフォルト名前空間は,それが宣言されたところの要素(その要素が名前空間接頭辞をもたない場合。),及びその要素の内容の内部にあるすべての接頭辞がない要素に適用されるものとする。デフォルト名前空間宣言におけるURI参照が空の場合,その宣言のスコープの中の接頭辞がない要素は,どの名前空間の中にも存在しないものとする。デフォルト名前空間は,直接に属性には適用されないことに注意されたい。
<?xml version="1.0"?> |
<?xml version="1.0"?> |
名前空間のスコープについて,もう少し大きな例を次に示す。
<?xml version="1.0"?> |
デフォルト名前空間を,空文字列に設定することができる。これは,その宣言のスコープの内部では,デフォルト名前空間が存在しないことと同じ効果をもつ。
<?xml version='1.0'?> |
この標準情報(TR)に適合するXML文書では,どのタグも次に示す二つの属性をもってはならない。
例えば,次の例では,各bad
開始タグは文法に合わない。
<!-- http://www.w3.orgは,n1及びn2に束縛されている。--> |
しかし,次は文法に合っている。これは,2番目の'good'タグで,デフォルト名前空間は属性名に適用されないことによる。
<!-- http://www.w3.orgがn1に束縛されており,デフォルトでもある。--> |
この標準情報(TR)に適合するXML文書では,要素型及び属性名は, QName
に対する生成規則にマッチし, "名前空間制約"を満たさなければならない。
XML文書は,その文書の中の, XML適合性のためにName
に対するXML生成規則にマッチすることを要求される(要素型又は属性名以外の)他のトークンすべてが,この標準情報(TR)のNCName
に対する生成規則にマッチする場合,この標準情報(TR)に適合する。
これら文書における適合性の効果は,次のとおり。
厳密に言うと,型ID
,型IDREF
,型IDREFS
,型ENTITY
,型ENTITIES
及び型NOTATION
と宣言された属性値もName
であって,そのためにコロンを含まないことが望ましい。しかし,属性値の宣言型は,例えば,妥当性を検証するプロセサなどの,マーク付け宣言を読むプロセサだけで利用できる。そこで,妥当性を検証するプロセサの使用を指定しない限り,この標準情報(TR)への適合性に対して,属性値の内容を検査するという保証をすることはできない。