REC-xml-names-19990114
REC-xml-names-19990114
著作権 © 1999 W3C (マサチューセッツ工科大学, フランス国立情報処理自動化研究所, 慶應義塾大学). すべての権利が留保されている。W3C の免責(liability), 商標(trademark), 文書利用(document use), ソフトウェア使用許諾(software licensing) 規則が適用される。
この文書は、W3C会員およびその他の利害関係者によって検討され、ディレクターによってW3C勧告として公布されているものである。この文書は安定的な文書であって、参照資料として使われたり、規範的参照として他の文書から引用に用いられてもかまわない。勧告作成におけるW3Cの役割は、仕様書に対する注意をひき、その広範な配備を推進することにある。これはウェブの機能性と相互運用性とを拡張するものである。
この仕様書(原文)の既知のエラーの一覧は http://www.w3.org/XML/xml-names-19990114-errata で入手できる。
この文書(原文)のエラーは xml-names-editor@w3.org までレポートいただきたい。
XML名前空間は、XML文書の中で使われるエレメントやアトリビュート名を、URI参照により特定される名前空間に結びつけることにより修飾するための単純な方法を提供するものである。
我々が思い描くのは、1つのXML(拡張可能マークづけ言語)文書が、複数のソフトウェアモジュールのために定義され、またモジュールによって使われるエレメントやアトリビュート(ここでは「マークアップ語彙」と呼ばれる)を含んでよいという、XMLの応用物である。このことの一つの動機はモジュラ性にある。よく理解され、有益なソフトウェアが利用可能であるようなマークアップ語彙が存在するならば、このマークアップを開発し直すよりもむしろ再利用するほうがよい。
そうした文書は、複数のマークアップ語彙を含むから、認識や衝突の問題を突きつけてくる。ソフトウェアモジュールは、他のあるソフトウェアパッケージ向けのマークアップが同じエレメント型やアトリビュート名を使っているときに生じる「衝突」に直面した場合であっても、そのモジュールが処理するように設計されているタグやアトリビュートを認識できる必要がある。
これらの考慮は、文書構造物が、スコープがその包含文書を越えて広がるユニバーサルな名前をもつべきことを要求する。この仕様書は、これを実現するXML名前空間という機構を記述したものである。
[定義:] XML名前空間 (XML namespace) とは、URI参照によって特定され、XML文書の中でエレメント型やアトリビュート名として使われる名前の集合体である。 XML版名前空間は内部構造を有し、また数学的に言うとセットではないという点で、XML名前空間はコンピューティング分野で伝統的に使われている「名前空間」とは異なる。これらの問題は "A. XML名前空間の内部構造" において論じられる。
[定義:] 名前空間を特定するURI参照は、キャラクタごとに正確に同じであるとき、同一 (identical) であるとみなされる。 この意味で同一ではないURI参照も実際には機能的に等価であることがあるので、注意してほしい。例としては、大文字小文字が違うだけのURI参照や、異なる実効ベースURIをもつ外部エンティティの中のURI参照がある。
XML名前空間からの名前は有修飾名 (qualified name) として現れることがある。これは、1個の名前空間プリフィックス (namespace prefix) と1個のローカル部分 (local part) とに名前を切り分ける1個のコロンを含んでいるものである。プリフィックスは、URI参照に割り付けられるものであり、名前空間を選択する。ユニバーサルに運営されるURI名前空間とその文書自身の名前空間との組み合わせは、ユニバーサルに一意的な識別子を生み出す。プリフィックスのスコーピングとデフォルティングのために機構が提供される。
URI参照は、名前の中では許されないキャラクタを含むことができるので、直接に名前空間プリフィックスとして使うことができない。したがって、名前空間プリフィックスは、URI参照のプロキシとして働く。名前空間プリフィックスとURI参照との結びつけを宣言するためには、後述のアトリビュートベースの文法が使われる。この名前空間提案をサポートするソフトウェアは、これらの宣言とプリフィックスとを認識してそれに基づいて行動しなければならない。
この仕様書の生成規則の中にある中間生成規則の多くは、ここではなくて、XML仕様書 [XML] の中で定義されている。ここで定義されている中間生成規則が、XML仕様書で定義されている中間生成規則と同じ名前を有するときには、どのような場合にもここにある生成規則は、対応するむこうの生成規則によって一致される文字列の、そのサブセットに一致する。
この文書の生成規則において、NSC とは、一の仕様書に準拠している文書が従わなければならない規則のひとつ、「名前空間制約 (Namespace Constraint)」である。
例の中で使われているインターネットドメイン名は、w3.org という例外はあるものの、すべてランダムに選ばれたものであって、何らかのインポートをもつものとして取られるべきではない。
[定義:] 名前空間は、1ファミリーの予約済みアトリビュートを使って宣言される。そうしたアトリビュートの名前は、xmlns であるか、あるいはプリフィックスとして xmlns: をもつかのいずれかでなければならない。これらのアトリビュートは、その他のXMLアトリビュートのように、直接に、またはデフォルトによって提供されてもかまわない。
| 名前空間宣言用のアトリビュート名 | ||||||||||||||||||||||||||||
|
[定義:] アトリビュートの値は、URI参照であり、名前空間を特定している名前空間名である。 名前空間名は、その意図された目的を果たすため、一意性および永続性という特性を有するべきである。(スキーマがある場合に)名前空間名がスキーマの引き出しのために直接に利用できることは、目標ではない。これらの目標を念頭において設計される文法の例が、URN(統一リソース名)[RFC2141] の文法である。もっとも、通常のURLもこれら同じ目標を実現するような方法で運用できることには留意されるべきである。
[定義:] アトリビュート名が PrefixedAttName に一致するならば、NCName は名前空間プリフィックスを与えるものであり、エレメントやアトリビュート名を宣言の添付先エレメントのスコープの中にあるアトリビュート値の名前空間名に結びつけるために使われる。 そうした宣言の中では、名前空間は空であってはならない。
[定義:] アトリビュート名が DefaultAttName に一致するならば、 そのアトリビュート値の名前空間名は、宣言の添付先エレメントのスコープの中にあるデフォルト名前空間のそれである。 そうしたデフォルト宣言の中では、アトリビュート値は空であってもよい。デフォルト名前空間や、宣言の上書きは、"5. 名前空間をエレメントやアトリビュートに適用する" で論じられる。
名前空間宣言の例。edi という名前空間プリフィックスを、http://ecommerce.org/schema という名前空間名に結び付けている。
<x xmlns:edi='http://ecommerce.org/schema'>
|
名前空間制約: 先頭の "XML"
大文字小文字の組み合わせを問わず、x, m, l という3文字の並びで始まるプリフィックスは、XMLやXML関連仕様書による利用のために予約済みである。
[定義:] この仕様書に準拠するXML文書では、いくつかの名前(Name という中間生成規則に対応する構造物)が、以下に定義されるように有修飾名 (qualified name) として与えられてもよい。
| 有修飾名 | ||||||||||||
|
Prefix は、有修飾名の名前空間プリフィックス部分を提供するものであり、名前空間宣言の中にある名前空間URI参照に結び付けられなければならない。[定義:] LocalPart は、有修飾名のローカル部分 (local part) を提供する。
プリフィックスは、もっぱら名前空間名のための場所取りとしてのみ働くことに注意してほしい。アプリケーションは、包含文書を越えてスコープの広がる名前を構築する際、プリフィックスではなく名前空間名を使うべきである。
この仕様書に適合する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"?>
|
この例に示されているように、複数の名前空間プリフィックスを、1つのエレメントのアトリビュートとして宣言することができる。
<?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文書では、エレメント型およびアトリビュート名は QName についての生成規則に一致しなければならず、また「名前空間制約」を満たさなければならない。
XML文書は、その文書内にある、Name についてのXML生成規則に一致することがXML準拠のために必須であるその他すべてのトークンが、この仕様書の NCName についての生成規則に一致するならば、この仕様書に準拠する。
準拠性の効果は、そのような文書においては、
厳密に言うと、ID, IDREF(S), ENTITY(IES), NOTATION 型であると宣言されたアトリビュート値もまた Names であって、そのためにコロンなしであるはずである。しかしながら、アトリビュート値の宣言型は、たとえば妥当性を検証するプロセッサといったような、マークアップ宣言を読むプロセッサでしか利用できない。そのため、妥当性を検証するプロセッサの使用が指定されていない限り、アトリビュート値の内容がこの仕様書に対する準拠性をチェックされているという保証はできないのである。
コンピューティング分野において、「名前空間」という用語は伝統的に名前のセット、すなわち重複を含まない集合体を指す。しかしながら、XMLマークアップの中で使われる名前をそうした名前空間として扱うことは、その有用性を著しく損なうであろう。XML文書の中のそうした名前の主な使用目的は、クエリープロセッサや、スタイルシート駆動のレンダリングエンジン、スキーマ駆動の検証器といったソフトウェアモジュールによる、文書の論理的構造の識別を可能にすることにある。以下の例を考えてみよう。
<section><title>Book-Signing Event</title>
|
この例では、マークアップの中に title という名前が3回出現しており、名前だけでは明らかに、ソフトウェアモジュールによる正しい処理を可能にするには不充分な情報しか提供しない。
もうひとつの問題領域は、この例に示されているように、「グローバル」なアトリビュートの利用に由来する。この例は、CSSスタイルシートを使って表示されるべきXML文書の断片である。
<RESERVATION>
|
この場合、CLASS アトリビュートは、運賃の基準を記述し、"J", "Y", "C" といった値を取るものであって、すべての意味論的レベルにおいて HTML:CLASS アトリビュートとは区別される。こちらは、サブクラス化による限定的なエレメントレパートリーの克服の手段として、HTMLにおける文法的なリッチさをシミュレートするために使われるものである。
XML 1.0 は、「グローバル」アトリビュートを宣言するための組み込み済みの方法を提供しない。HTMLの CLASS アトリビュートといったような項目は、その散文的記述や、HTMLアプリケーションによる解釈においてのみグローバルである。しかしながら、そうしたアトリビュートは、名前が一意的であるところに他とは違う重要な特徴があり、多様なアプリケーションでの出現が一般的に観察される。
有修飾名と無修飾名との両方をその意図された目的に沿うのに役立つものにするという目的を支援するため、我々は、XML名前空間の中に出現する名前を、名前空間区画という、数個に分解された伝統的な(すなわちセット構造の)名前空間のうちの1つに属するものとして識別する。区画には、つぎのものがある。
この仕様書に準拠するXML文書では、すべての有修飾(プレフィックスつき)アトリビュートの名前はグローバル属性区画に割り当てられ、すべての無修飾アトリビュートは適当な要素型ごと区画に割り当てられる。
規則を規定したり比較を行ったりする際の便宜のため、我々は、XML文書のそれぞれのエレメント型やアトリビュート名について、ここにXMLエレメント文法で表わされる展開形式を定義する。
[定義:] 展開エレメント型 (expanded element type) は、ExpEType 型の空XMLエレメントとして表わされる。これは、その型の LocalPart を与える必須の type アトリビュート1つと、エレメントが有修飾である場合にその名前空間名を与える任意的な ns アトリビュート1個とをもつ。
[定義:] 展開アトリビュート名 (expanded attribute name) は、ExpANmae 型の空XMLエレメントとして表わされる。これは、名前を与える必須の name アトリビュート1個をもつ。アトリビュートがグローバルである場合には、これは名前空間名を与える必須の ns アトリビュートをもつ。グローバルでない場合には、これは、添付されるエレメントの型を与える eltype という必須のアトリビュート1個と、既知であるときにはその添付されるエレメントの名前空間名を与える elns という任意的なアトリビュート1個とをもつ。
上記に与えられた例に基づく微妙な変形が、展開エレメント名やアトリビュート型の動作を説明するであろう。以下の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 XMLワーキンググループおよびスペシャルインタレストグループの会員やW3Cメタデータ活動の参加者を含め、きわめて多数の人々からの入力を反映したものである。Microsoft の Charles Frankston の貢献はとりわけ貴重であった。