PR-xml-names-19981117
PR-xml-names-19981117
著作権 © 1998 W3C (マサチューセッツ工科大学、 フランス国立情報処理自動化研究所、 慶應義塾大学). すべての権利が留保されている。W3Cの 免責(liability)、商標(trademark)、文書利用(document use)、ソフトウェア使用許諾(software licensing) 規則が適用される。
この文書は現在、W3Cのメンバーによる検討を受けている。これは、XML活動 の配信可能文書として昨年来作成されてきた一連のワーキングドラフトから引き出された安定的な文書である。
コメントは xml-names-issues@w3.org (archive) 宛に願う。この勧告案 (Proposed Recommendation) の検討期間は1998年12月18日に終了する。その時から14日以内に文書の処分がアナウンスされる。W3C勧告 (Recommendation) になったり(小さい変更はありうる)し、ワーキングドラフト (Working Draft) の状態に戻されるかもしれないし、W3C作業項目して落とされる場合もある。この文書は、現時点においては、W3Cのスタッフや会員組織による保証の意味あいをもつものではない。
XML名前空間は、XML文書の中で使われるエレメント・アトリビュート名を、URI参照により特定される名前空間と結びつけることにより修飾するための単純な方法を提供するものである。
我々が思い描くのは、単一のXML文書が、複数のソフトウェアモジュールのために定義され利用されるエレメント・アトリビュート(ここでは「マークアップ語彙」と呼ぶ)を含んでよいXML (Extensible Markup Language) の応用形である。この動機のひとつはモジュラ性である。よく理解されていて便利なソフトウェアが利用可能であるそうしたマークアップ語彙が存在するならば、このマークアップを再開発するよりも再利用したほうがよい。
そうした文書は複数のマークアップ語彙を含むので、認識や衝突の問題を突きつけてくる。ソフトウェアモジュールは、ある他のソフトウェアパッケージ向けのつもりのマークアップが同じエレメント型やアトリビュート名を使っているときに発生する「衝突」に直面した場合であっても、そのが処理するべく設計されているタグやアトリビュートを認識できる必要がある。
これらの考慮は、文書構造が、包含文書を越えてスコープが広っているユニバーサルな名前をもつべきことを要求する。この仕様書は、これを実現するXML名前空間というメカニズムを記述する。
[定義:] XML名前空間とは、URI参照 [RFC2369] により特定され、XML文書の中でエレメント型やアトリビュート名として使われる名前の集合体である。 XML版名前空間は内部構造を有し、数学的に言うとセットではないという点で、XML名前空間はコンピューティング分野で伝統的に使われてきた「名前空間」と異なっている。これらの問題は "A. XML名前空間の内部構造" において論じられる。
[定義:] 名前空間を特定するURI参照は、キャラクタごとに正確に同じものであるときに同一とみなされる。 この意味で同一ではないURI参照も、実際には機能的に等価である場合があることに注意すること。例としては、大文字・小文字が違っているだけのURI参照や、異なる実効ペースURIをもつ外部エンティティの中にあるものがある。
XML名前空間からの名前は、有修飾名 (qualified name) として現れる場合がある。これは、単一のコロンを含み、これが名前空間プリフィックス (名前空間プリフィックス) と ローカル部分 (local part) とを切り分けているものである。プリフィックスは、URI参照へ割りつけられるものであり、名前空間を選択する。ユニバーサルに管理されているURI名前空間とその文書自身の名前空間との組み合わせが、ユニバーサルに一意的な識別子を生み出すのである。プレフィックスのスコーピングやデフォルティングのためには、メカニズムが提供されている。
URI参照は、名前の中では許されないキャラクタを含むことができるので、直接に名前空間プリフィックスとして使うことができない。したがって、名前空間プリフィックスは、URI参照のプロキシとして働く。名前空間プリフィックスとURI参照との結びつきを宣言するのには、後述のアトリビュートベースの文法が使われる。この名前空間提案をサポートするソフトウェアは、この宣言とプリフィックスとを認識してそれに基づいて動作しなければならない。
この仕様書内の生成規則 (production) の中の中間生成規則 (nonterminal) の多くは、ここではなく、XML仕様書 [XML] の中で定義されている。ここで定義されている中間生成規則がXML仕様書で定義されている中間生成規則と同じ名前をもつときには、ここの生成規則はどのような場合でも、向こうの対応するものによって照合される文字列のサブセットを照合する。
この文書の生成規則において、NSC とは「名前空間制約 (名前空間制約)」のことである。これは、この仕様書に適合している文書が従わなければならない規則のひとつである。
使用例の中で使われているインターネットドメイン名は、w3.org を除いてすべてランダムに選ばれたものであり、何らかの意味をもっていると取られるべきではないことに注意すること。
[定義:] 名前空間は、予約済みアトリビュートのファミリーを使って宣言される。そうしたアトリビュートの名前は、xmlns であるか、プレフィックスとして xmlns: もつかのいずれかでなければならない。これらのアトリビュートは、他のXMLアトリビュートのように、直接に、またはデフォルトにより提供されてもよい。
| 名前空間宣言のためのアトリビュート名 | ||||||||||||||||||||||||||||
|
[定義:] そのアトリビュートの値たるURI参照は、名前空間を特定する名前空間名である。 名前空間名は、その意図された目的を果たすため、一意性および永続性という特性を有するべきである。スキーマ(あれば)の引き出しのために直接に利用可能であることは、目標ではない。この目標を念頭に置いて設計された文法の例としては、URN (Uniform Resource Names) [RFC2141] の文法がある。もっとも、普通のURLも、これらの目標を達成するような方法で管理できることは注意されるべきである。
[定義:] アトリビュート名が PrefixedAttName に合致すれば、NCName が名前空間プリフィックスを与える。これは、宣言添付先エレメントのスコープ内にあるアトリビュート値の中の名前空間名にエレメント・アトリビュート名を結びつけるために使われるものである。 そうした宣言の中では、名前空間名は空であってはならない。
[定義:] アトリビュート名が DefaultAttName に合致すれば、アトリビュート値の名前空間名は、宣言添付先エレメントのスコープ内のデフォルト名前空間のものである。 そうしたデフォルト宣言の中では、アトリビュート値は空であってもよい。デフォルト名前空間と宣言の上書きとは、"5. 名前空間をエレメント・アトリビュートに適用する" において論じられる。
名前空間宣言の例.名前空間プリフィックス edi を名前空間名 http://wcommerce.org/schema に結びつけている。
<?xml version="1.0"?>
|
名前空間制約: 先頭の "XML"
大文字・小文字の組み合わせを問わず、x, m, l という3文字の並びで始まるプレフィックスは、XML仕様書やXML関連仕様書による利用のために予約される。
[定義:] この仕様書に適合しているXML文書においては、いくつかの名前(中間生成規則 Name に対応する構造物)が、以下に定義されている有修飾名 (qualified name) として与えられてよい。
| 有修飾名 | ||||||||||||
|
Prefix は、有修飾名の名前空間プリフィックス部分を提供するものであって、名前空間宣言内の名前空間URIに結びつけられなければならない。[定義:] LocalPart は、有修飾名のローカル部分を提供する。
プレフィックスは名前空間名のための場所取りとしてのみ機能することに注意すること。包含文書を越えてスコープが広がる名前を構築する際には、アプリケーションはプレフィックスではなく名前空間名を使うべきである。
この仕様書に適合しているXML文書においては、エレメント型は、以下の通り 有修飾名として与えられる。
| エレメント型 | ||||||||||||||||||
|
アトリビュートは、名前空間宣言か、有修飾名として与えられた名前かのいずれかである。
| アトリビュート | ||||||||||
|
名前空間制約: プレフィックスの宣言
名前空間プレフィックスは、それが 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'?>
|
この仕様書に適合しているXML文書においては、どのタグも、
2つのアトリビュートを包含してはならない。
たとえば以下では、bad 開始タグはそれぞれが違法である。
<!-- http://www.w3.org is bound to n1 and n2 -->
|
しかしながら、以下はそれぞれ合法である。2つ目ではアトリビュート名にデフォルト名前空間が適用されないからである。
<!-- http://www.w3.org is bound to n1 and is the default -->
|
この仕様書に適合するXML文書においては、エレメント型およびアトリビュート名は、NSDecl か QName かのいずれかの生成規則に合致しなければならず、かつ "名前空間制約" を満たさなければならない。
XML適合のために Name の生成規則に合致することを要求される文書内のその他すべてのトークンがこの仕様書の NCName の生成規則に合致すれば、XML文書はこの仕様書に適合する。
適合の効果は、そうした文書の中では
厳密に言うと、ID, IDREF(S), ENTITY(IES), NOTATION 型として宣言されたアトリビュート値も Names であり、そうするとコロン不要のはずである。しかしながら、アトリビュート値の宣言された型は、主に妥当性検証を受けた文書の中でのみ利用可能である。そうすると、整形式のXML文書においては、アトリビュート値の内容がこの仕様書への適合性をチェックされているという保証がないことにもなりかねない。
コンピューティング分野では、「名前空間」という用語は伝統的には名前のセット、すなわち重複を含まない集合体を指す。しかしながら、XMLマークアップ内で使われる名前をそうした名前空間として扱うことは、その有用性を著しく損なうことになる。XML文書においてそうした名前の主な用途は、クエリープロセッサやスタイルシート駆動のレンダリングエンジン、スキーマ駆動の妥当性検証器といったようなソフトウェアモジュールによる文書内の論理的構造の識別を可能にすることである。以下の例を考えてみよ。
<section><title>Book-Signing Event</title>
|
この例では、マークアップ内部に title という名前が3回出現しており、名前だけではソフトウェアモジュールによる正しい処理を可能にするのに不充分な情報しか提供されないことが明らかである。
もう一つの問題領域は、この例によって図説される「グローバル」なアトリビュートの利用に由来する。これはCSSスタイルシートを使って表示されるべきXML文書の断片である。
<RESERVATION>
|
この場合には、CLASS アトリビュートは、運賃の基礎を表わして "J", "Y", "C" といったような値をとるのであるが、CSSフォーマット効果を達成するために使われている HTML:CLASS アトリビュートから、すべての意味論的水準において区別されている。
XML 1.0 は、「グローバル」なアトリビュートを宣言する埋め込み済み方法を提供しない。HTMLの CLASS アトリビュートといったような項目は、散文的な記述やHTMLアプリケーションによる解釈の中でのみグローバルなのである。もっとも、名前が一意的であるということが重要で特徴的な機能であるそうしたアトリビュートは、多様なアプリケーションの中で発生しているのを広く見受けられる。
有修飾名・無修飾名をともにその意図された目的に沿い有益なものにするという目標を支援するため、我々は、XML名前空間内に現れる名前を、名前空間パーティションと呼ばれる数個の分解された伝統的な(すなわちセット構造の)名前空間のうちの1つに属するものとして識別する。パーティションは、つぎの通りである。
この仕様書に適合しているXML文書においては、すべての有修飾(プレフィックスつき)アトリビュートの名前はグローバルアトリビュートパーティションに割り当てられ、すべての無修飾アトリビュートの名前は、適当なエレメント型毎パーティションに割り当てられる。
規則を仕様化したり比較をしたりする際の便宜のため、我々は拡張形式を定義する。これは、XMLエレメント文法でここに表現されているものであり、XML文書内のエレメント型・アトリビュート名ごとに定義されるものである。
[定義:] 拡張エレメント型は、ExpEType 型の空XMLエレメントとして表わされる。これは、その型に LocalPart を与える必須アトリビュートである type と、そのエレメントが有修飾である場合にその名前空間名を与える任意的アトリビュートである ns とをもつ。
[定義:] 拡張アトリビュート名は、ExpAName 型の空XMLエレメントとして表わされる。これは、名前を与える必須アトリビュート name をもつ。アトリビュートがグローバルである場合には、これは名前空間名を与える必須アトリビュート ns をもつ。そうでない場合には、添付されたエレメントの型を与える必須アトリビュート elytpe と、既知であるならば、添付されたエレメントの名前空間名を与える任意的アトリビュート elns とをもつ。
上記に与えられている例をわずかに変形して、拡張エレメント型・アトリビュート名の働きを図説する。以下の2つの断片にはそれぞれ、名前の拡張を示した表が続いている。
<!-- 1 --> <section xmlns='urn:com:books-r-us'>
|
名前は以下の通りに展開されよう。
| 行 | 名前 | 展開後 |
| 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" /> |
上記の "5.3 アトリビュートの一意性" によって表わされた制約は、どのエレメントも拡張名が同一、すなわち同じアトリビュート値の対をもつ2つのアトリビュートをもたないことを要求することにより、そのまま実装されてもよい。
この作業は、とても数多くの方々からの入力を反映したものである。特に、W3C WMLワーキンググループやスペシャルインタレストグループのメンバー、およびW3Cメタデータアクティビティの参加者が挙げられる。