注: この文書では、XMLの名前空間バージョン1.1の最終ワーキング・ドラフト ("Last Call Working Draft": 2002年9月) で提案された変更点にも触れています。

XMLで業務上および通信上の問題の解決を図る場合、たいていは複数のXMLボキャブラリーを組み合わせることが必要になります。(お望みなら、XMLボキャブラリー という用語をタグと属性の集合 と読み替えてもかまいません。)XMLには、名前を修飾して、さまざまな名前空間 (さまざまな業界に当てはまる名前空間など) に割り振るメカニズムがあります。会社、あるいは (もっと望ましいこととして) 業界のコンソーシアムは、要素に名前を割り振り、"title" または "state" などの一般的な用語を、別のボキャブラリーで使用されている名前と重複することを心配せずに使用することができます。

XML名前空間により、時間の経過に伴う名前の進化も可能になります。最初のバージョンのボキャブラリーを使用した後、現実世界での経験を踏まえて、拡張されたボキャブラリーを考え出すことがあるかもしれません。その場合、新しいバージョンを異なる名前空間に割り振ることができます。そして、XSLTを使用して、1つのボキャブラリーから別のボキャブラリーへとデータを変換することができます。

XSLTと言えば、このスタイルシートの標準には、従属的なスタイルシートのインポートが規定されています。そして、この従属的なスタイルシートには、他人が作成した汎用テンプレートが含まれている場合があります。テンプレートは名前を修飾して名前空間に割り振ることができますから、この場合にも衝突を回避できます。言い換えれば、自分のスタイルシートから名前付きテンプレートを呼び出すことができ、そのテンプレートには、(テンプレートの作者が選択した) 名前空間で修飾された独特の名前がある、ということになります。自分のスタイルシートにインポートされたテンプレートのライブラリーを、複数使用することさえできます。ライブラリーごとに異なる名前空間を使用することにより、テンプレートの名前の重複を回避できるでしょう。W3Cが勧告している多くの標準では、モジュール性のために名前空間を奨励しています。

さらに、XML名前空間のおかげで、XMLを処理するさまざまなツール (スタイルシート駆動のXSLTプロセッサーなど) は、自分が処理する命令と、他のプロセッサー用の命令（単なる追加のデータとみなす）を区別することができます。プロセッサーは、1つ (または2つ) の特定の名前空間からの要素を命令と見なすようにセットアップされます。名前空間を持たない要素はデータになります。命令と認識する名前空間以外の名前空間の要素もすべてデータになります。

XML名前空間の簡単な紹介

名前空間の正式な指定は、URIです。一般には、URL (URIの形式の1つ) が識別子と見なされるでしょう。URIは広範囲に渡る文字を使用するので、すべての修飾名に完全なURIを付加しなければならないとしたら、XML構文に厳しい影響を与えることになるでしょう。それで、XMLの名前空間の勧告では、名前に直接付加される 構文、すなわち接頭部も定義しています。構文について言えば、引用符 (単一または二重) を使ってURIストリングを囲み、コロンを使って接頭部を区切ります。その他の文字が干渉することはありません。接頭部は標準のXML名です。接頭部の使用を避けることもできます。その場合は、接頭部を持たないすべての名前に1つのURIを割り振るようにするか、文書中でデフォルトの名前空間が必要になるたびに、これをいちいち (しかも危険覚悟で) 割り振り直すようにします。事実上、ボキャブラリーを混ぜて使用するときには、接頭部が必要になります。

XML用の他の仕様と同様、XML名前空間の勧告はW3Cによって公開されています。W3Cは名前空間の勧告のバージョン1.1を開発中であり、このバージョンでは、正式な指定がInternationalized Resource Identifier (IRI) になります。URIとIRIの相違点は、特定の文字をエスケープして、害のないものにする方法にあります。

実際の名前空間の構文を見てみましょう。

<mddl:custodian xmlns:mddl="http://www.mddl.org/mddl/2001/1.0-final">Merrill Lynch</mddl:custodian>

これは単なるcustodian 要素ではなく、http://www.mddl.org/mddl/2001/1.0-final というURIによって識別されたボキャブラリーの中のcustodian 要素です。接頭部mddl は、要素名をそのURIと関連付けるために使用されています。このURIはmddl.orgドメインにあります。mddl.orgは、Market Data Definition Languageを保守している組織であり、custodian は、そのボキャブラリーの中の多数の要素の1つです。(このボキャブラリーは、投資とポートフォリオ管理に関係する要素を定義しています。)mddl.orgが、URIにいくつかのフィールドを設けることによって、他のボキャブラリーを定義したり、MDDLボキャブラリーの後続バージョンを公表したりするための準備をしていることに注意してください。

名前のローカル 部分とは、特定のボキャブラリーの中にある名前のことです。名前空間で修飾されていない名前の場合、ローカル部分だけが存在することになります。接頭部の付いた名前の場合、ローカル部分はコロンの後の部分を指します。たとえば、book:title およびbook:isbn という要素の場合、属する名前空間は同じですが、ローカル部分が異なります。book:title とperson:title という要素は、ローカル部分は同じですが、それぞれ異なる名前空間に属しているため、まったく無関係です。

修飾名に使用される接頭部

接頭部は、開発における論議を単純化してくれます。XMLベースのシステムを開発するときには、book:title やxsl:apply-templates などについて論じることができ、それぞれの名前空間の詳細を取り上げるのはほんの時たまで済みます。技術的な意味から言えば、接頭部は重要なものではありません。接頭部は、名前と名前空間のURIとを関連付ける一時的な省略語だからです。

しかし、デベロッパーの生産性を高めるために、論理的で一貫した接頭部の名前を確立することは、ベスト・プラクティス です。

接頭部は、要素と属性の名前を修飾し、関連付けます。また、状況によっては、キーワード・タイプのテキスト・ストリングにも当てはまります。たとえば、XML文書に現れるbook:title は、「書籍の特性としてのタイトル」に相当します。これは、XMLに目を通さなければならない人にとって便利です。接頭部book がURIに結び付けられている箇所を参照すれば、より正式な仕様、たとえば、「1999年にabaa.orgが公表した書籍のボキャブラリーの定義に従うタイトル」などと述べられている仕様を見出すことができます。

W3Cのいくつかの勧告では、名前空間で修飾してもしなくてもかまわないXML名を指してQName という用語を使用しています。また、仕様をきちんと読めば、時折 "QName-but-not-NCName (NCNameではないQName)" という用語を見ることもあるでしょう。これは、名前空間で修飾しなければならない XML名を指しています。(NCName という用語は、コロンのないXML名を指しています。NCは "no colon (コロンなし)" という意味です。)たとえば、XSLTの名前付きテンプレートには、単純なXML名ではなくQNameを付けることができます。こうして、すべて1つの特定の名前空間で名前を付けられているテンプレートのライブラリーを公開するのが容易になります。QNameでは、接頭部とローカル部分を区分するために、コロン (:) を特殊文字として使用しています。当然、接頭部とローカル部分はコロンを含んでいてはなりません。しかし、その他の点について言えば、XML名の所定の構文に従います。

特定のURIに複数の接頭部を関連付けることができます。XMLの標準では、一般に接頭部をその関連するURIに解決するよう強制しています。したがって、ローカル部分とURIが一致するなら、接頭部が異なっていても、名前は同じになります。接頭部は、一度に1つのURIにしか関連付けることができません。

名前空間URI

XML名前空間に関する記事はみな、URIはどこにも行かないということを指摘しなければなりません。つまり、URIが識別しているかのように見える素材を何か取ってくる必要はない、ということです。実際に、識別される場所のためにサーバーをセットアップしたり、その場所に取り出し可能な素材を用意しておいたりする必要はありません。XML名前空間の勧告が求めているのは、2つのURIが同一であることを確かめるためのストリング・マッチングだけです。とは言え、勧告では、名前空間の値はURI参照であると簡潔に述べて、この値がInternet Engineering Task ForceのRFC 2396の構文に従わなければならないことを暗に示しています。

W3Cによって公表されるURIは、いつもhttp: プロトコルとw3.org ドメイン・ネームを使用しています。したがって、HTTP URLを使用することは安全なアプローチと見なすことができ、それゆえにベスト・プラクティス と言えます。

ドメイン・ネームは、名前の衝突を避けるためのかぎです。全世界的なDomain Name Systemを使用することにより、名前空間URIは「誰がそう言っているのか」という質問に対する答えを提出します。ドメイン・ネームを持っているのなら、名前を制御するための世界を持っているということになります。これはサーバーのみならず、XML名前空間にも当てはまります。たとえば、mddl.org は、投資に関係するXMLボキャブラリーを定義する組織に属しているドメイン・ネームであり、それ以外の誰も、mddl.orgドメインの下の名前やURLを割り当てることはできません。

将来、W3Cは名前空間URIが取り出し可能なリソースを指すようにするための指針を確立するかもしれません。W3Cのさまざまな委員会が代案を検討しています。おそらく、URIによって識別される素材そのものは、スキーマまたは記述そのものへの間接的なポインターとなり、実際の記述の構文は、時間の経過とともに進化して行かれるようになるでしょう。現在のところ、W3Cの名前空間のために使用されているURIは、そのURIが名前空間であると述べる簡単なテキスト・ページを指しています。一例として、http://www.w3.org/1999/XSL/Transform にアクセスしてみてください。

名前空間の構文の機能を定義しているW3Cの文書は、名前空間のURIを指して名前空間名 という用語を使っています。XML文書の重要な部分を定義しているXML Information Setの勧告でも、この用語を同じように使用しています。しかし、XPath関数のname() とlocal-name() を名前空間ノードに適用すると、接頭部が戻されます。

したがって、名前空間名 という用語の使用を避けるか、意味が明快な文脈でだけ使用するのがベスト・プラクティス です。XQueryでは、構文について論じるときに、名前空間接頭部 および名前空間URI という用語を使用しています。後者は、名前空間宣言の中のURIを指すために安心して使用できる用語です。

上に戻る

すでに使用中の名前空間

さまざまなXMLボキャブラリーのために名前空間が指定されています。その中には、MathMLなどのようにW3C自体が公表したものもあれば、DSMLなどのように業界コンソーシアムが公表したもの (OASIS Technical Committeeによる) もあります。(参考文献を参照。)読者の組織でも同じことができます。

その上、XMLファミリーの他のW3C勧告では、それらの勧告によって定義される事柄を区別するために名前空間を使用しています。XMLの勧告は、要素名を何も定義していませんが、XML文書の中で使用できる2つの属性を記述しています。すなわち、xml:space とxml:lang です。XML Baseの勧告では、このリストにxml:base が追加されています。それぞれxml という接頭部を使用していますが、それはこれらの属性が、すべてのXML文書用にデフォルトで定義されている名前空間の中にあるということを示しています。W3Cは、最近の正誤表 (Erratum) の中で、XMLに組み込まれる名前にはxml で始まる接頭部を使用できないと宣言しました。

W3Cは、自分が定義する各ボキャブラリーに固有の接頭部を使用しています。各勧告は、こうした接頭部は機能的に特殊なものではなく、終始一貫して使用されるものに過ぎないということを示すよう、心を砕いています。MathMLの例に戻ると、MathML 2.0の勧告では、外側の要素として<mml:math xmlns:mml="http://www.w3.org/1998/Math/MathML"> という要素を提案していますが、ここでmml はこの仕様で好まれる接頭部です。mml ストリングも、文書を読む人以外には、特殊なものではありません。実際にMathMLボキャブラリーを識別するストリングは、URI (http://www.w3.org/1998/Math/MathML) です。(このボキャブラリーにおいて、接頭部ストリングに関わらずローカル部分名math が付いた要素が外側要素です。)

XML Inclusionsの勧告には、設計上のジレンマがありました。つまり、インクルージョンのための構文要素は、xml:base やxml:lang のように、単一のストリング値で表現できなかったのです。インクルージョンの宣言は、次の3つの部分を必要とする場合があります。

• インクルードされるリソースのhref。
• 前提となる符号化方式。
• 構文解析方式。

これらの部分を属性として1つの要素にまとめることができますが、この要素にinclude またはxml:include という名前を付けるなら、XMLの利用可能な要素名の集合に影響して、人間にとってもマシンにとっても一様に厄介な例外を生じることになりかねません。解決策は、この1つの要素のためだけの名前空間を定義するというものでした。典型的なインクルード要素は次のようなものです。

<xi:include href="http://example.com/std/defs" parse="xml" />

この例で、要素の開始タグの中にxi 接頭部の宣言が含まれていることに注意してください。1つのファイルの中に複数のXMLインクルージョンがある場合、xi を最上部で宣言するすることができます。この場合、各要素は依然としてxi:include という名前になりますが、名前空間宣言は開始タグの中に含まれないことになります。

<document ...>
<-- ...other content... -->
<xi:include href="http://example.com/system/common" parse="xml" />
<-- ...other content... -->
<xi:include href="http://example.com/system/style" parse="xml" />
<-- ...other content, and perhaps more include elements... -->
</document>

汎用XMLのインクルードの名前空間を設けることは、XSLTやXML Schemaの中で、こうしたインクルードとアプリケーション特有のインクルードとを別々にしておくことにもなります。

XSLTとXML Schemaの両者の場合は、精緻な勧告によって、それぞれ変換またはデータ設計を記述するための完全な文書の記述法を与えています。これらの文書を、それぞれXSLTスタイルシートおよびスキーマ定義と言います。XMLの基本的な設計原則のうちの1つに従えば、これらはそれぞれ特殊な固有の名前空間の中のボキャブラリーを使うXML文書です。詳しく言えば、XML Schemaはスキーマ定義文書用の1つのボキャブラリーと、インスタンス文書 (スキーマによって定義されるデータ) に現れるスキーマ項目用のもう1つのボキャブラリーを定義しています。スキーマ定義とXSLTスタイルシートは、自分の言語の要素および属性を、他の名前空間の要素および属性と混ぜる場合があります。そのため、接頭部が必要になります。

W3Cが使用する接頭部を使用するのは、ベスト・プラクティス です。たとえば、XSLTの勧告や、XSLTに関する書籍の大部分では、XSLTボキャブラリーの要素を識別するために接頭部xsl を使用しています。自分のスタイルシートで忠実にxsl 接頭部を使用するなら、自分のデプロイメントの計画について論じる際や、XSLTの書籍を調べる際に、接頭部を言い換えるという頭の中のオーバーヘッドが不要になります。

上に戻る

XMLの中で修飾名を確立する

XML文書は、文書要素 (最外部の要素) から順に下る、ツリー構造です。どの要素についても名前空間を宣言できます。これにより、その要素によって定義されるサブツリーとそのすべての子の中で、その名前空間が認識されることになります。宣言は属性と似ていますが、大部分のW3Cの勧告では、これを別個のタイプのノードと見なしています（訳注：XML Information Setや、XPathでは、ある要素において有効な名前空間宣言、すなわちその要素かその祖先の要素で宣言された名前空間を、属性とは異なるタイプのデータとみなします。しかし、実際に要素中に現れる名前空間宣言そのものは、属性とみなすことが多いようです）。XMLを見れば、名前空間宣言が、関係する要素の開始タグの中で、属性とぴったり並んでいるのが分かるでしょう。構文には2つのバリエーションがあります。

• xmlns:prefix="URI"
• xmlns="URI"

最初の構文は、広く使用されています。この構文は、接頭部をURIに関連付けます。2番目の構文は、接頭部が付いていない要素にデフォルトの名前空間があるということを宣言します。XMLの設計全体の中で、これら2つの構文はどちらも、XMLの目的上、xml で始まる名前は予約済みという条件下に置かれています。デフォルトの名前空間は、文書の初期状態ではどの名前空間URIにも結び付けられていません。このような、名前空間無しの要素名をサポートするため、事前に定義したデフォルトの名前空間の定義を削除するための構文があります。つまり、これをヌル・ストリングに割り振ることです。(ヌル・ストリングは、URIとしては技術的に有効ですが、名前空間URIとしては禁止されています。)接頭部はさまざまなURIへと設定することができますが、少なくともXML 1.0文書に関しては、接頭部の定義を削除することはできません。

名前空間宣言のバリエーション

2002年の4月、W3CのXMLワーキング・グループは、名前空間の接頭部にヌル・ストリングを割り振れるようにXML名前空間の改訂を考慮中であると発表しました。9月版の提案で、そのような宣言は、接頭部の定義を削除して、対立を回避したり、不必要な名前空間ノードを除去したりするためにしか使用できないこと、およびある接頭部がヌルに割り振られている場合、その文書の中のどんな場所であっても、修飾名はその接頭部を使用できない、と使用法が制限されました。今のところは、使用していない不必要な名前空間ノードを削除する必要があるなら、XSLTのexclude-result-prefixes 機能を使用できるということに注意してください。

ツリーの最上部で接頭部を1つのURIに関連付けることができますが、サブツリーの中でこれを別のURIに関連付けることができます。その場合は、サブツリーの最上部の要素の開始タグでxmlns:prefix="new-uri" 宣言を使用します。また、サブツリー内のサブサブツリーの中でさらに別のURI (あるいは元のURI) に関連付けることもできます (以下同様に続く)。こうすると、生のXML文書を読まなければならない人は混乱してしまうかもしれません。

以下の例はコンパクトなものですが、大きな文書の中ですべてのxmlns 宣言を見つけるのがいかに困難か、想像してみてください。

<data:document xmlns:data="http://example.com/namespace/fields">
  <-- ...other content... -->
  <data:legacy xmlns:data="http://example.com/namespace/legacy-data">
    <-- ...data of an older style... -->
    <data:item xmlns:data="http://example.com/namespace/fields">
      <-- ...this one item within legacy uses the standard namespace... -->
    </data:item>
  </data:legacy>
  <-- ...other content... -->
</data:document>

以下のより好ましい習慣を適用することができます。

ここに挙げるベスト・プラクティス は、所定の接頭部を、システム内のすべてのXML文書を通じて、1つの名前空間のためだけに使用するというものです。これが実際的でない場合は、せめて、単一の接頭部を、単一の文書の中で1つのURIだけに関連付けるようにしてみてください。もう1つのベスト・プラクティス は、必要な関連付けをすべて文書要素の開始タグに置き、文書全体を通じて適用することです。そうすれば、すべての宣言を見つけるのがより簡単になります。単一の開始タグの中に入れることのできる名前空間宣言の数は無制限です。

ソフトウェア・ツールでXMLを生成する場合、そのツールは名前空間ノード (xmlns 宣言) をツリーの中に入れなければなりません。そうすれば、名前を修飾することが必要な箇所で、名前空間が有効になります。名前空間に関連付けられた接頭部がある場合は、名前空間が必要になる要素よりも上の部分で名前空間を宣言することができます。これには、冗長な宣言が少なくなるという望ましい効果を伴う場合があります。Xalan XSLTプロセッサーは、こうしたことを行うツールの一例です。

接頭部はすべて、使用される前に宣言しておかなければなりません。ただし、xml とxmlns は例外です。これらの接頭部はすべてのXML文書に渡って有効かつ不変と見なされます。属性に似た構文を利用して、外部実体の中で宣言の一部をデフォルトの属性としてセットアップしたくなるかもしれません。

ここでベスト・プラクティス となるのは、宣言を文書の中に含めて、前提事項と依存関係を少なくすることです。

デフォルトの名前空間 (接頭部の付いていない要素に適用される名前空間) を使用するかどうかは、個人的な判断に属します。あらゆる場所ですべての要素名に接頭部を付けることに慣れているなら、いくつかの落とし穴を避けられます。しかし、接頭部を付けることに疲労困憊する人もいれば、1つの名前空間が文書の実際の コンテンツに適用されるので、これをデフォルトにすれば、その区別を付けることができると感じる人もいます。後者の方法に従うなら、所定の文書でデフォルトにできる名前空間を決定するための設計原則を確立する必要があります。もちろん、こうした規則は、実際にXML文書を読む (もしかすると作成もする) 人々の益にしかなりません。

接頭部の使用に関するベスト・プラクティス は、どこでも接頭部を使用することか、エンド・ユーザーに配信される実際のコンテンツを除くすべての項目でこれを使用することのいずれかです。システム・デベロッパーだけが変更するプロセス制御要素には、すべて接頭部を付けます。その中には、XSLTスタイルシート、スキーマ定義などが含まれます。自分の組織から見て外部のXMLボキャブラリーの項目には、すべて接頭部を付けます。ただし、エンド・ユーザーに配信される実際のコンテンツは例外となる場合もあります。

属性は若干異なる

属性は、自分が属している要素とは異なる名前空間に現れることがあります。たとえば、<movie:title xml:lang="fr"> にはmovie 名前空間のものではない属性が含まれています。属性名に接頭部があるなら、その名前は接頭部によって示される名前空間にあります。しかし、属性名に接頭部がないなら、その属性名に名前空間はありません。これは、デフォルト名前空間が割り振られている場合にさえ当てはまります。W3CのXML名前空間の勧告は、この点を次の例によって示しています。

<x xmlns="http://www.w3.org" xmlns:n1="http://www.w3.org">
  <good a="1" n1:a="2" />
</x>

要素は、デフォルト名前空間のURIの宣言によって影響を受けます。つまり、x もgood もURI "http://www.w3.org" に関連付けれます。というのは、これがデフォルト名前空間だからです。属性n1:a もこの名前空間に関連付けられます。これは、n1 接頭部 (同じURIに関連付けられている) を使用しているためです。a 属性が2回宣言されていることによる競合はありません。なぜなら、n1:a はhttp://www.w3.org 名前空間に属していますが、接頭部の付いていないa はその名前空間に属していないからです。後者は、どの名前空間にも属していません。

上にxml:lang が例示されているので、要素の内容が特定の自然言語に従うことを宣言する方法として、xml:lang 属性を使用することがベスト・プラクティス であることに注目しましょう。

W3Cボキャブラリーが要素と属性の両方を指定している場合、修飾されている要素の上に属性が現れる限り、通常、この属性を名前空間によって修飾する必要はありません。<xi:include href="http://example.com/std/defs" parse="xml" /> というXML Includeの例に戻ると、href およびparse 属性はxi:include 要素の有意の属性として指定されています。したがって、xi:include 要素を処理できるXMLパーサーは、これらの属性をインクルード操作の詳細として解釈しなければなりません。

指定可能な属性名の世界において、"xml" (順序はこのとおり、ただし大文字小文字の組み合わせは問わない) で始まる名前はすべて、W3Cが定義するものとして予約されています。このようにして、xmlns="http://foo.com" のような名前空間宣言は、別個の構文ではなく、属性の構文を使用できるようになっています。

ほとんどのW3C仕様は、これを属性 ではなく名前空間宣言 と呼んでいます。それで、会話の中でこの区別を守ることはベスト・プラクティス です。(名前空間の勧告文書そのものでは、これらの宣言を、紹介の部分では予約済み属性 と呼んでいます。DOM Level 3でも、こうした宣言をxmlns 名前空間の属性として扱っています。)

xmlns:fooname="http://foo.com" のような名前空間宣言の構文は、修飾名を持つ属性と同じですが、最初の "xml" という文字がその特殊な役割を伝えており、これも会話の中では名前空間宣言 です。しかし、xml:space="preserve" のような属性は、正しい用語法に従うとやはり属性 です。とは言え、この属性は予約済みの名前空間に入っています。XMLを認識するものの、名前空間に対応していないアプリケーションでXML文書を処理すると、おそらくQNameは生き残り、名前空間宣言は属性として扱われるでしょう。

XML名前空間の最初の勧告では、xmlns 接頭部は関連するURIを持たない ものとして指定されていました。将来、W3Cはこれを変更するかもしれません。これは、現実世界では大きな影響をもたらさないかもしれません。というのは、大部分のXMLツールおよびプロセスは、名前空間宣言を自動的に管理するからです。自動的に管理してくれない場合でも、たいてい、ツリー状に表現したXMLに名前空間ノードを作成する方法や、これを作成することを避ける方法はあるものです。XMLがファイルに入っている場合、名前空間宣言には、要素の開始タグに入った標準的なxmlns シーケンスがありますが、ファイルを読むXMLパーサーは、xmlns が名前空間に関連付けられているかどうかにかかわりなく、これを識別できるでしょう。(XMLは名前空間なしで発足したので、名前空間に対応していない初期のXMLパーサーに遭遇する可能性があるかもしれません。ここに挙げたベスト・プラクティスが多少なりとも関係あるのであれば、そのようなパーサーは避けるようにしてください。)

妥当性検査と名前空間

XML Schemaの勧告には、文書構造を名前空間の要素と属性で定義するための備えが完全になされています。その上、修飾名として有効でなければならないストリングのために、特殊なQNameデータ型が定義されています。スキーマ定義文書は、文書構造のためにターゲット名前空間を指定できます。

文書構造を指定するための旧式の文書型定義 (DTD) 構文は、名前空間に対応していません。しかし、DTDはコロンを含んだ要素名と属性名を許容しています。DTDと名前空間を一緒に使用したい場合、特定の接頭部を指定し、これを要素名および属性名の固定部分として扱うことによって、そうすることができます。この技法については、Cover PagesのC. M. Sperberg-McQueenのメモに詳細に説明されています (参考文献を参照)。これを実行しなければならない場合は、相当の困難を覚悟してください。(DTDでは、XML文書に明示的に現れない属性に値を割り当てることができます。このDTDのメカニズムを使って、xmlns という名前の属性を設定するというのは間違ったアイデアです。)

先を見越す

ここまでの部分で、W3Cが据えた基礎を説明してきました。第2回では、独自のXMLボキャブラリーを確立するための最良の方法をより深く探ります。第2回では、名前空間に対応した名前変更の技法を説明します。

参考文献

• David Marstonの2番目の記事、"XML名前空間の使用を計画する: 第2回" で、XML名前空間を徹底的に調べ、独自のXMLボキャブラリーを定義してください。
  
  
• W3CのXML名前空間1.0勧告は、標準を確定しています。
  
  
• W3CのXML Schemaの勧告には、3つの部分があります。すなわち、Primer、Structures、およびDatatypes です。
  
  
• W3Cは、識別子に関する体系的な原則を開発しています。
  
  
• XInclude はW3Cの勧告になろうとしています。
  
  
• W3CのXML Information Setの勧告は、XMLツリー構造の部分の意味を識別する抽象的な設計です。
  
  
• "現実世界でのXML Schema" は、命名のアイデアを提供します (developerWorks、2002年1月)。
  
  
• Christina Lauの "XML and WebSphere Studio Application Developer" の第6回では、スキーマの中での名前空間の使用法についての指導を行っています。
  
  
• W3CのボキャブラリーであるMathML と、OASIS Technical CommitteeによるDirectory Services Markup Language (DSML) についてさらに調べてください。
  
  
• The Cover Pagesで、C. M. Sperberg-McQueenによるDTDと名前空間に関するメモをご覧ください。
  
  
• 最新の"XPointer xmlns() Scheme" のドラフトで、名前空間を宣言するための若干異なる方法を調べてください。
  
  
• URIの一般構文であるRFC 2396 には、URIの詳細が豊富に説明されています。
  
  
• developerWorks XMLゾーンで、さらにXMLの参考文献を調べてください。
  
  
• XMLおよびその関連テクノロジーのIBM Certified Developer になる方法をお調べください。
  
  

著者について

この記事を評価する

コメント

上に戻る

目次

• XML名前空間の簡単な紹介
• すでに使用中の名前空間
• XMLの中で修飾名を確立する
• 参考文献
• 著者について
• コメント