WD-xml-names-19980802
WD-xml-names-19980802
著作権 © 1998 W3C(マサチューセッツ工科大学, フランス国立情報処理自動化研究所, 慶應義塾大学).すべての権利が留保されている。W3Cの liability(免責)、trademark(商標)、document use(文書利用)、software licensing(ソフトウェア仕様許諾)規則が適用される。
このドラフト仕様書は、W3C XMLワーキンググループの現在の合意を示す進行中の作業である。これは、W3C会員およびその他の利害関係者による検討のためのW3Cワーキングドラフトである。ワーキングドラフトとしての公開は、W3C会員の保証を含意するものではない。
このドラフトは、名前空間仕様書の広範囲な見直しを組み込んでいる。ある点においては未完成であるが、ワーキンググループは、初期の実装作業の間に問題が発見されない限り、ドラフトが記述する機能を機能的に変更しないつもりである。そうした問題をできるだけ迅速に発見するために、特別編集チームが結成され、ワーキングドラフトの公開で始まり、8月22日および23日のモントリオールでのXMLワーキンググループミーティングのすぐ後に終わる1ヶ月の期間の間、実装者からのフィードバックを受け付けている。実装経験レポートは xml-names-issues@w3.org まで送られたい。
我々は本質的な変更を予定していないが、なおさらなる変更があり得ることを警告し、したがって現在のところは実験的ソフトウェアまたは簡単にフィールドアップグレードできるソフトウェアだけがこの仕様書を実装するよう勧告する。XMLワーキンググループは、最終リリースに先立ってこの仕様書に変更を加えるワーキンググループの能力を初期の実装が制約することを許すつもりはない。これはドラフト文書であり、何時にても他の文書により更新され、置換され、あるいは廃止される場合がある。W3Cワーキングドラフトを「進行中の作業」以外のものとして引用することは不適切である。
XMLワーキンググループの狙いは、この名前空間設備がXML仕様書の将来のバージョンの統合的部分となるべきことである。
XML名前空間は、XML文書によって使われる名前を、URIで識別される名前空間に結びつけることにより有修飾化するための単純な方法を提供する。
我々は、異なるソフトウェアモジュールのために定義され、またそれらによって利用されるマークアップを含んだXML文書の利用を心に描いた。この動機の一つがモジュラ性である。もし広く理解されており、有益なソフトウェアで利用可能であるマークアップのセットがあれば、このマークアップを再発明するよりも再利用する方がよい。
複数の独立したソースからのマークアップを含んでいるそうした文書は、認識および衝突の問題をつきつける。ソフトウェアモジュールは、ある他のソフトウェアパッケージ向けのマークアップが同じエレメント型やアトリビュート名を使っているときに発生する「衝突」に直面した場合であっても、モジュールが処理するよう設計されているマークアップ(タグ、アトリビュート)を認識できる必要がある。
これらの考察は、文書構造が、それを含んでいる文書を越えてスコープが広がるユニバーサルな名前をもつべきことを要求する。この仕様書は、これを実現するXML名前空間という機構を解説する。
[定義:] XML名前空間は、XML文書においてエレメント型、アトリビュート名として使われる名前の集積であり、URIにより識別される。 XML版の名前空間は、内部構造を有し、数学的にいうとセットではないという点で、計算訓練において伝統的に使われてきた「名前空間」とは異なる。これらの問題は "6. XML名前空間の内部構造" において論じられる。
XML名前空間からの名前は有修飾名として現れる場合がある。これは名前を名前空間プリフィックスとローカル部分とに分離するコロンを含んだものである。ユニバーサルに管理されるURI名前空間と文書自身の名前空間との組み合わせは、ユニバーサルに一意的であることが保証された識別子を生み出す。混乱をさせて可読性を高めるためにプリフィックスを落とすための機構が提供される。
URIは、名前の中では認められないキャラクタを含みうるので、直接に名前空間プリフィックスとして使うことができない。したがって、名前空間プリフィックスはURIのプロキシとして機能する。以下に記述されたアトリビュートベースの文法が、名前空間プリフィックスとURIとの結び付きを宣言するために使われる。この名前空間提案をサポートするソフトウェアは、この宣言とプリフィックスを認識し、それに基づいて動作しなければならない。
[定義:] 名前空間は、以下のようにプリフィックスが xmlns であるアトリビュートを使って宣言される。 この仕様書の生成規則の中にある中間生成規則の多くは、ここではなくXML仕様書 [XML] の中で定義されていることに注意すること。ここで定義されている中間生成規則がXML仕様書の中で定義されている中間生成規則と同じ名前をもつときは、すべての場合においてここにある生成規則は、そこにある対応するものによって照合される文字列のサブセットを照合する。
| アトリビュートを使った名前空間の宣言 | ||||||||||||||||||||
|
[定義:] NSDef 生成規則の SystemLiteral は、名前空間を識別するための名前空間名として機能するURIである。 名前空間名は、その意図された目的を果たすため、一意性及び永続性という特性を有するべきである。スキーマ(があったとしても)の引き出しのために名前空間名が直接的に利用可能であるということは、目的ではない。これらの目的を念頭において設計された文法の例は、Uniform Resource Names [RFC2141] についてのものである。しかしながら、通常のURLは、これらの目的を達成するような方法で管理できることは注意されるべきである。
[定義:] PrefixDef 生成規則において、任意的なコロンと NCName とが提供されれば、その NCName は名前空間プリフィックスを与え、宣言の添付先のエレメントのスコープ内にあるこの名前空間と名前とを結びつけるために使われる。
[定義:] コロンと NCName とが提供されなければ、結びつけられる名前空間名は、宣言の添付先のエレメントのスコープ内にあるデフォルト名前空間の名前空間名である。
名前空間制約:空URI
SystemLiteral は、PrefixDef が単に xmlns であるとき、すなわちデフォルト名前空間を宣言しているときに限り、空であってもよい。そうした宣言の効果は、その値をヌルに設定して、デフォルト名前空間のどれか高次の宣言を上書きすることである。デフォルト名前空間および宣言の上書きは "5. 名前空間のスコープ化とデフォルト化" において論じられる。
名前空間宣言の例:
<?xml version="1.0"?>
|
[定義:] この仕様書に適合するXML文書において、いくつかの名前(Name という中間生成規則に対応する構造)は、いかに定義されるように、有修飾名として与えられてもよい。
| 有修飾名 | ||||||||||||
|
Prefix は有修飾名の名前空間プリフィックス部分を提供するものであり、名前空間宣言の中の名前空間URIと結びつけられなければならない。[定義:] LocalPart は有修飾名のローカル部分を提供する。
プリフィックスは、名前空間名のための場所確保としてのみ機能することに注意すること。アプリケーションは、包含文書を越えてスコープが広がる名前を構築するときには、プリフィックスではなく名前空間名を使うべきである。
この仕様書に適合するXML文書において、エレメント型は、以下のように有修飾名として与えられる。
| エレメント型、アトリビュート名 | ||||||||||||||||||
|
アトリビュート名は、以下のように有修飾名として与えられる。
| アトリビュート | ||||||
|
名前空間制約:プリフィックスの宣言
名前空間プリフィックスは、それが xml または xmlns であるのでない限り、名前空間宣言の中で宣言されていなければならない。xml および xmlns という名前空間プリフィックスは予約され、黙示的に宣言されているものとみなされる。大文字小文字の組み合わせを問わず x, m, l という3文字の列で始まるプリフィックスは、XMLおよびXML関連の仕様書による利用のために予約される。
エレメント名、アトリビュート型もまた、DTD内の宣言の中に現れるときには有修飾名として与えられる。
| 宣言内の有修飾名 | ||||||||||||||||||||||||||||
|
名前空間宣言は、それが指定されているエレメントに適用され、同じ PrefixDef 部をもつ他の名前空間宣言によって上書きされない限り、そのエレメントの内容の内部にあるすべてのエレメントに適用されるものとみなされる。
<?xml version="1.0"?>
|
この例に示されるように、単一エレメントのアトリビュートとして複数の名前空間プリフィックスを宣言できる。
<?xml version="1.0"?>
|
デフォルト名前空間は、(そのエレメントが名前空間プリフィックスをもたなければ)それが宣言されているエレメントと、そのエレメントの内容の内部にあるプレフィックスなしエレメントすべてとに適用されるものとみなされる。デフォルト名前空間は直接にアトリビュートに適用されるのでないことに注意すること。プレフィックスがつけられていないアトリビュートの名前空間は、その添付先のエレメントの型の、また(もしあれば)そのエレメントの名前空間への機能である。詳細は "6. The Internal Structure of XML Namespaces" を見ること。
<?xml version="1.0"?>
|
<?xml version="1.0"?>
|
もう少し大きい名前空間スコーピングの例
<?xml version="1.0"?>
|
デフォルト名前空間は、一度宣言されても、上書きされる場合がある。
<?xml version='1.0'?>
|
計算訓練においては、「名前空間」という用語は伝統的に名前のセット、すなわち重複を含まない集合を指す。しかしながら、そうした名前空間として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名前空間の中に現れる名前を、名前空間パーティションと呼ばれる、数個の分解された伝統的な(すなわちセット構造の)名前空間の一つに属するものとして識別する。パーティションは
この仕様書に適合するXML文書では、すべての有修飾(プレフィックス付き)アトリビュートの名前はグローバルアトリビュートパーティションに割り当てられ、すべての無修飾アトリビュートの名前は適切なエレメント型ごとパーティションに割り当てられる。
規則を規定し比較をなす上での便宜のため、我々は、XML文書の中にあるエレメント型とアトリビュート名とのそれぞれについて、ここでXMLエレメント文法で表現される展開形式を定義する。
[定義:] 展開エレメント型は、ExpEType 型の空XMLエレメントとして表現される。これは、型の LocalPart を与える必須の type アトリビュートと、エレメントが有修飾であれば名前空間名を与える任意的な ns アトリビュートとをもつ。
[定義:] 展開アトリビュート名は、ExpAName 型の空XMLエレメントとして表現される。これは、名前を与える必須の name アトリビュートをもつ。アトリビュートがグローバルであれば、名前空間名を与える必須の ns アトリビュートをもつ。そうでなければ、添付されたエレメントの型を与える必須の eltype と、既知ならば添付されたエレメントの名前空間名を与える任意的な 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" /> |
この仕様書に適合するXML文書では、展開名が等しい2つのアトリビュートをもってよいエレメントはない。すなわち、どのエレメントも、同じアトリビュート値の対と、同じ内容をもつ子エレメントとをもつことができないのである。
この仕様書に適合するXML文書の中の名前は、QName の生成規則にマッチし、この文書の「名前空間制約」を満足するエレメント型名およびアトリビュート名である。
Name XML生成規則に合致することがXML適合のために要求される文書内のその他すべてのトークンがこの仕様書の NCName 生成規則に合致し、その中でエレメントが一意的な拡張名をもつアトリビュートを有するならば、XML文書はこの仕様書に適合する。
適合性の影響は、そうした文書の中では
ということである。
厳密に言うと、ID, IDREF(S), ENTITY(IES), NOTATION 型として宣言されているアトリビュート値も Names であり、そのためコロンなしであるべきである。しかしながら、アトリビュート値の宣言された型は、主として検証されている文書の中でしか利用できない。そこで整形式XML文書では、アトリビュート値の内容がこの仕様書に適合するようチェックされているという保証ができないのである。
この作業は、特に、W3C XMLワーキンググループおよび特別利害グループのメンバーや、W3Cメタデータアクティビティの参加者を含め、きわめて数多くの人々からの入力を反映している。