サイトマップ || ホーム > XML > XML名前空間 1.0 > WD-19980916

XML名前空間

W3CWD-xml-names-19980916


XML名前空間

World Wide Web Consortium ワーキングドラフト 1998年9月16日

このバージョン(原文):
http://www.w3.org/TR/1998/WD-xml-names-19980916
最新のバージョン:
http://www.w3.org/TR/WD-xml-names
以前のバージョン:
http://www.w3.org/TR/1998/WD-xml-names-19980802
http://www.w3.org/TR/1998/WD-xml-names-19980518
http://www.w3.org/TR/1998/WD-xml-names-19980327
編集者:
Tim Bray (Textuality) <tbray@textuality.com>
Dave Hollander (Hewlett-Packard Company) <dmh@corp.hp.com>
Andrew Layman (Microsoft) <andrewl@microsoft.com>

著作権  ©  1998 W3C (マサチューセッツ工科大学, フランス国立情報処理自動化研究所, 慶應義塾大学). すべての権利が留保されている。W3Cの免責 (liability), 商標 (trademark), 文書利用 (document use), ソフトウェア使用許諾 (software licensing) 規則が適用される。

この文書の位置づけ

この文書は、W3C XMLワーキンググループの合意点を表わした、進行中の作業である。これはW3C会員およびその他の利害関係者による検討のためのW3Cワーキングドラフトである。ワーキングドラフトとしての公開は、W3C会員による保証を意味するものではない。

このドラフトの公開とともに、名前空間仕様書は「最終呼び出し」に入る。1998年10月9日に終了する期間の間、このドラフトに関するコメントは xml-names-issues@w3.org(アーカイブ)にいる編集者へ送られるべきである。

我々は本質的な変更を予定していないが、なお、さらなる変更がありうることを警告し、ゆえに我々は、現在のこの仕様書を実装するのは実験的ソフトウェア、または簡単にフィールドアップグレードできるソフトウェアだけにするよう勧告する。これはドラフト文書であり、何時にても他の文書によって更新され、変更され、あるいは廃止される場合がある。W3Cワーキングドラフトを「進行中の作業」以外のものとして引用することは不適切である。

概要

XML名前空間は、URIによって特定される名前空間を結びつけることにより、XML文書で使われる名前を修飾化する単純な方法を提供するものである。

目次

1. 動機とまとめ
2. 名前空間を宣言する
3. 有修飾名
4. 有修飾名を利用する
5. エレメントやアトリビュートに名前空間を適用する
    5.1 名前空間のスコープ
    5.2 名前空間のデフォルト化
    5.3 アトリビュートの一意性
6. 適合性

付録

A. XML名前空間の内部構造
    A.1 伝統的な名前空間の不充分性
    A.2 XML名前空間パーティション
    A.3 拡張エレメント型およびアトリビュート名
    A.4 拡張アトリビュート名の一意性
B. 謝辞
C. 参照資料

1. 動機とまとめ

我々は、単一のXML文書が、複数のソフトウェアモジュールのために定義され、また利用されるエレメントやアトリビュートを含んでよいXML応用を思い描く。この動機のひとつはモジュラ性である。もし、よく理解されて有益なソフトウェアが利用可能であるようなそうしたマークアップ語彙があれば、このマークアップを再開発するよりも再利用する方がよい。

複数のマークアップ語彙を含んでいるそうした文書は、認識や衝突の問題を突きつける。ソフトウェアモジュールは、他のソフトウェア向けのつもりのマークアップが同じエレメント型やアトリビュート名を使っているときに発生する「衝突」に直面する場合であっても、そのモジュールが設計上処理するべきタグやアトリビュートを認識できる必要がある。

これらの考慮は、文書の構成物が、その包含文書を超えてスコープの広がるユニバーサルな名前をもつべきことを要求する。この仕様書は、これを実現するXML名前空間という機構を解説するものである。

[定義:]XML名前空間は、XML文書の中でエレメント型やアトリビュート名として使われる名前の集合体であり、URIにより特定される。 XML名前空間は、内部構造を有し、また数学的に言うとセットではないという点で、コンピューティング分野で慣習的に使われてきた「名前空間」と異なっている。これらの問題は "A. XML名前空間の内部構造" において論じられる。

XML名前空間出身の名前は、有修飾名 (qualified name) として現れる場合がある。これは、名前を名前空間プリフィクスとローカル部分とに分ける単一のコロンを含んでいる。プリフィックスは、URI [URI] に割り付けられるもので、名前空間を選択する。ユニバーサルに管理されているURI名前空間と文書独自の名前空間との組み合わせが、ユニバーサルに一意的な識別子を生み出すのである。混乱を避けて可読性を向上させるプリフィックススコープ化やデフォルト化のための機構が提供される。

URIは、名前の中では認められないキャラクタを含むことができるから、名前空間プリフィックスとして直接に利用することはできない。ゆえに、名前空間プリフィックスは、URIの代わりのプロキシとして働く。名前空間プリフィックスとURIとの関連づけを宣言するためには、以下に記述されているアトリビュートベースの文法が使われる。この名前空間提案をサポートするソフトウェアは、これらの宣言とプリフィックスとを認識し、それに基づいて行動しなければならない。

2. 名前空間を宣言する

この仕様書の生成規則の中間生成規則のなかには、ここではなくXML仕様書 [XML] の中で定義されているものも多い。ここで定義されている中間生成規則がXML仕様書の中で定義されている中間規則と同じ名前を有するときには、どのような場合にもここにある生成規則が、XML仕様書にある対応する生成規則により照合される文字列のサブセットに合致する。

[定義:]名前空間は、以下のように、プレフィックスが xmlns であるアトリビュートを使って宣言される。

アトリビュートを使った名前空間の宣言
[1]  NSDecl ::= PrefixDef Eq AttValue [ NSC: 空URI ]
[2]  PrefixDef ::= 'xmlns' (':' NCName)? [ NSC: 先頭の "XML" ]
[3]  NCName ::= (Letter | '_') (NCNameChar)* /* XMLの Name マイナス ":" */
[4]  NCNameChar ::= Letter | Digit | '.' | '-' | '_' | CombiningChar | Extender

[定義:]NSDecl 生成規則の AttValue は、名前空間を特定するための名前空間名として機能するURIである。 名前空間名は、その意図された目的を果たすため、一意性と永続性という特性を有するべきである。それが直接にスキーマ(存在すれば)の引き出しのために利用可能であることは目的ではない。これらの目的を念頭において設計された文法の例としては、URN (Uniform Resource Names) [RFC2141] がある。もっとも、通常のURLもこれらの同じ目的を達成するような方法で管理可能であることは留意されるべきである。

[定義:]PrefixDef 生成規則において、任意的なコロンと NCName とが与えられれば、NCName は、宣言の添付先のエレメントのスコープ内にあるこの名前空間と名前とを結びつけるために使われて、名前空間プリフィックスを与える。

[定義:]コロンと NCName とが与えられなければ、結びつけられる 名前空間名は、宣言の添付先のエレメントのスコープ内にあるデフォルト名前空間の名前空間名である。

名前空間制約:空URI
AttValue は、PrefixDef が単に xmlns である場合、すなわちデフォルト名前空間を宣言している場合に限り、空であってもよい。デフォルト名前空間や宣言の上書きは、"5. エレメントやアトリビュートに名前空間を適用する" で論じられる。

名前空間制約: 先頭の "XML"
大文字小文字の組み合わせを問わず、x, m, l という3文字の並びで始まるプリフィックスは、XMLやXML関連の仕様書による利用のために予約される。

名前空間宣言の例:

<?xml version="1.0"?>
  <x xmlns:edi='http://ecommerce.org/schema'>
    <!-- the edi namespace applies to the "x" element and contents -->
  </x>

3. 有修飾名

[定義:]この仕様書に適合しているXML文書においては、いくつかの名前(中間生成規則 Name に対応する構成物)が、以下に定義されるような有修飾名 (qualified name) として与えられてよい。

有修飾名
[5]  QName ::= (Prefix ':')? LocalPart
[6]  Prefix ::= NCName
[7]  LocalPart ::= NCName

Prefix は、有修飾名の名前空間プリフィックス部分を与えるものであり、名前空間宣言内で名前空間URIと結びつけられなければならない。[定義:]LocalPart は、有修飾名のローカル部分を与える。

プリフィックスは名前空間名の場所取り役としてのみ機能することに注意すること。アプリケーションは、包含文書を越えてスコープの広がる名前を構築する際には、プレフィックスではなく名前空間名を使うべきである。

4. 有修飾名を使う

この仕様書に適合しているXML文書においては、エレメント型は、以下のように有修飾名として与えられる。

エレメント型およびアトリビュート名
[8]  STag ::= '<' QName (S Attribute)* S? '>' [ NSC: プレフィックスの宣言 ]
[9]  ETag ::= '</' QName S? '>' [ NSC: プレフィックスの宣言 ]
[10]  EmptyElemTag ::= '<' QName (S Attribute)* S? '/>' [ NSC: プレフィックスの宣言 ]

アトリビュート名は、以下のように有修飾名として与えられる。

アトリビュート
[11]  Attribute ::= QName Eq AttValue [ NSC: プレフィックスの宣言 ]

名前空間制約: プレフィックスの宣言
名前空間プレフィックスは、それが xml または xmlns でない限り、そのプレフィックスが使われているエレメントの開始タグか、祖先エレメント(すなわち、その内容の中でプレフィックスされたマークアップが発生しているエレメント)かのどちらかの名前空間宣言アトリビュートにおいて宣言されていなければならない。xml というプレフィックスは、定義により、urn:Connolly:input:required という名前空間名に強制的に結びつけられる。xmlns というプレフィックスは、名前空間バインディング用にのみ使われ、それ自身はどの名前空間名とも結びつけられない。

この制約は、名前空間宣言アトリビュートが直接にXML文書エンティティ内で与えられず、外部エンティティで宣言されたデフォルトアトリビュートを経由して与えられている場合には、操作上の難局に至らしめることがある。そうした宣言は、妥当性検証を行わないXMLプロセッサに基づくソフトウェアには読まれない場合がある。多くのXMLアプリケーションは、おそらく名前空間の大文字小文字を区別するものを含めて、妥当性検証を行うプロセッサを要求できない。そうしたアプリケーションを使った正しいオペレーションのため、名前空間宣言は、直接に、またはDTDの内部サブセットで宣言されたデフォルトアトリビュートを経由するかのいずれかで与えられなければならない。

エレメント名およびアトリビュート型は、DTDで宣言の中に現れるときには、有修飾名として与えられもする。

宣言内の有修飾名
[12]  doctypedecl ::= '<!DOCTYPE' S QName (S ExternalID)? S? ('[' (markupdecl | PEReference | S)* ']' S?)? '>'
[13]  elementdecl ::= '<!ELEMENT' S QName S contentspec S? '>'
[14]  cp ::= (QName | choice | seq) ('?' | '*' | '+')?
[15]  Mixed ::= '(' S? '#PCDATA' (S? '|' S? QName)* S? ')*'
| '(' S? '#PCDATA' S? ')'
[16]  AttlistDecl ::= '<!ATTLIST' S QName AttDef* S? '>'
[17]  AttDef ::= S QName S AttType S DefaultDecl

5. エレメントやアトリビュートに名前空間を適用する

5.1 名前空間のスコープ化

名前空間宣言は、同じ PrefixDef 部分をもつ他の名前空間宣言によって上書きされない限り、それが指定されているエレメント、およびそのエレメントの内容の内部にあるすべてのエレメントに適用されるものとみなされる。

<?xml version="1.0"?>
<!-- everything here is explicitly in the HTML namespace -->
<html:html xmlns:html='http://www.w3.org/TR/REC-html40'>
  <html:head><html:title>Frobnostication</html:title></html:head>
  <html:body><html:p>Moved to 
    <html:a href='http://frob.com'>here.</html:a></html:p></html:body>
  </html:html>

この例に示されているように、複数の名前空間プリフィックスを単一エレメントのアトリビュートとして宣言することができる。

<?xml version="1.0"?>
<!-- both namespace prefixes are available throughout -->
<bk:book xmlns:bk='urn:loc.gov:books'
         xmlns:isbn='urn:ISBN:0-395-36341-6'>
    <bk:title>Cheaper by the Dozen</bk:title>
    <isbn:number>1568491379</isbn:number>
</bk:book>

5.2 名前空間のデフォルト化

デフォルト名前空間は、それが宣言されているエレメント(そのエレメントが名前空間プリフィックスをもたない場合)、およびそのエレメントの内容の内部にありプリフィックスをもたないすべてのエレメントに適用されるものとみなされる。もしデフォルト名前空間宣言の中のURIが空ならば、その宣言のスコープ内のプレフィックスなしエレメントは、どの名前空間の中にもないものとみなされる。デフォルトの名前空間はアトリビュートに直接適用されないことに注意すること。

<?xml version="1.0"?>
<!-- everything is in the HTML namespace, in this case by default -->
<html xmlns='http://www.w3.org/TR/REC-html40'>
  <head><title>Frobnostication</title></head>
  <body><p>Moved to 
    <a href='http://frob.com'>here</a>.</p></body>
  </html>
<?xml version="1.0"?>
<!-- unprefixed names are from "books" -->
<book xmlns='urn:loc.gov:books'
      xmlns:isbn='urn:ISBN:0-395-36341-6'>
    <title>Cheaper by the Dozen</title>
    <isbn:number>1568491379</isbn:number>
</book>

より大きい名前空間スコープ化例:

<?xml version="1.0"?>
<!-- initially, the default namespace is "books" -->
<book xmlns='urn:loc.gov:books'
      xmlns:isbn='urn:ISBN:0-395-36341-6'>
    <title>Cheaper by the Dozen</title>
    <isbn:number>1568491379</isbn:number>
    <notes>
      <!-- drop the default into HTML for some commentary -->
      <p xmlns='urn:w3-org-ns:HTML'>
          This is a <i>funny</i> book!
      </p>
    </notes>
</book>

デフォルト名前空間は、いったん宣言されて、上書きされる場合がある。

<?xml version='1.0'?>
<Beers>
  <!-- the default namespace is now that of HTML -->
  <table xmlns='http://www.w3.org/TR/REC-html40'>
   <tr><td>Name</td><td>Origin</td><td>Description</td></tr>
   <tr> 
     <!-- drop the HTML namespace inside table cells -->
     <td><brandName xmlns="">Huntsman</brandName></td>
     <td><origin xmlns="">Bath, UK</origin></td>
     <td>
       <details xmlns=""><class>Bitter</class><hop>Fuggles</hop>
         <pro>Wonderful hop, light alcohol, good summer beer</pro>
         <con>Fragile; excessive variance pub to pub</con>
         </details>
        </td>
      </tr>
    </table>
  </Beers>

5.3 アトリビュートの一意性

この仕様書に適合しているXML文書においては、開始タグは次のアトリビュートを2つ含んではならない。

  1. 同一の名前をもち、あるいは
  2. 同じローカル部分と、辞書的に等価である名前空間名に結合されているプリフィックスとをもつ有修飾名をもつもの。名前空間名はURIであり、それを支配するRFCが辞書的な等価性を確定するための規則を含んでいることに注意すること。

たとえば、以下では悪い開始タグはそれぞれ違法である。

<!-- http://www.w3.org is bound to n1 and n2 -->
<x xmlns:n1="http://www.w3.org" 
   xmlns:n2="http://www.w3.org" >
  <bad a="1"     a="2" />
  <bad n1:a="1"  n2:a="2" />
</x>

もっとも、以下のものはそれぞれ合法である。

<!-- http://www.w3.org is bound to n2 and is the default -->
<x xmlns:n1="http://www.w3.org" 
   xmlns="http://www.w3.org" />
  <good a="1"     b="2" />
  <good a="1"     n1:a="2" />
</x>

6. 適合性

この仕様書に適合しているXML文書においては、エレメント型およびアトリビュート名は、NSDecl か QName かのいずれかの生成規則に合致しなければならず、「名前空間制約」を満たさなければならない。

XML適合のために Name に合致することが要求される文書内のその他すべてのトークンがこの仕様書の NCName の生成規則に合致すれば、XML文書はこの仕様書に合致する。

適合性の効果として挙げられるのは、つぎのことである。そうした文書の中では

厳密に言うと、ID, IDREF(S), ENTITY(IES), NOTATION 型として宣言されたアトリビュート値も Names であり、コロンは不要なはずである。しかしながら、アトリビュート値の宣言型は、主に妥当性を検証されている文書でのみ利用可能である。そこで 整形式のXML文書においては、アトリビュート値の内容がこの仕様書に適合するかチェックされているという保証はできないのである。

付録

A. XML名前空間の内部構造

A.1 伝統的名前空間の不充分性

コンピューティングの分野では、「名前空間」という用語は慣習的に名前のセット、すなわち重複を含まない集合を指す。しかしながら、名前空間といったようなXMLマークアップの中で使われる名前の取り扱いは、その有用性を大きく損なう。そうしたXML文書内の名前の主要な利用法は、クエリー処理器やスタイルシート駆動のレンダリングエンジン、スキーマ駆動の検証器といったようなソフトウェアモジュールによる、文書の論理的構造の識別を可能にすることである。以下の例を考えてみよ。

<section><title>Book-Signing Event</title>
<signing>
  <author title="Mr" name="Vikram Seth" />
  <book title="A Suitable Boy" price="$22.95" /></signing>
<signing>
  <author title="Dr" name="Oliver Sacks" />
  <book title="The Island of the Color-Blind" price="$12.95" /></signing>
</section>

この例では、マークアップの中に title という名前が3回現れ、名前だけでは明かに、ソフトウェアモジュールによる正しい処理を可能にするには不充分な情報しか提供されない。

この例はCSSスタイルシートを使って表示されるべきXML文書の断片であるが、もうひとつの問題領域は、この例で示されているような「グローバルな」アトリビュートの利用から生じる。

<RESERVATION>
 <NAME HTML:CLASS="largeSansSerif">Layman, A</NAME>
 <SEAT CLASS="Y" HTML:CLASS="largeMonotype">33B</SEAT>
 <DEPARTURE>1997-05-24T07:55:00+1</DEPARTURE></RESERVATION>

この場合では、CLASS アトリビュートは、運賃の基準を記述し、"J" や "Y", "C" といった値をとるのであるが、すべての意味論的水準において、CSSフォーマット効果を達成するために使われる HTML:CLASS アトリビュートから区別されている。

XML 1.0 は、「グローバルな」アトリビュートを宣言するための組み込み済みの方法を提供しない。HTMLの CLASS アトリビュートといったような項目は、その散文的記述や、HTMLアプリケーションによる翻訳においてのみ、グローバルである。しかしながら、そうしたアトリビュートは、それらの名前が一意的であるということがその重要な特徴的機能であり、多様なアプリケーションの中で起こることが広く観察される。

A.2 XML名前空間パーティション

有修飾名も無修飾名もともにその意図された目的に沿うのに便利なようにするという目標を支援するため、我々は、XML名前空間内に現れる名前を、名前空間パーティションと呼ばれる、解体されたいくつかの伝統的な(すなわちセット構造の)名前空間のひとつに属するものとして識別する。パーティションには次のものがある。

全エレメント型パーティション (The All Element Types Partition)
このパーティションには1つのXML名前空間内のすべてのエレメント型が現れる。それぞれが一意的なローカル部分を有する。名前空間名とローカル部分との組み合わせが、エレメント型を一意的に特定する。
グローバルアトリビュートパーティション (The Global Attribute Partition)
このパーティションは、グローバルなものとしてこの名前空間内で定義されるすべてのアトリビュートの名前を含む。グローバルアトリビュートの唯一の必須の特性は、そのグローバルアトリビュートパーティション内においてその名前が一意的であるということである。この仕様書は、そうしたアトリビュートの適切な利用に関して何らの主張もなさない。名前空間名とアトリビュート名との組み合わせが、グローバルアトリビュートを一意的に特定する。
エレメント型ごとパーティション (The Per-Element-Type Partitions)
全エレメント型パーティションの中にある型はそれぞれ、結びつけられた名前空間を有し、そのエレメントに与えられる無修飾アトリビュートの名前はその中に現れる。1エレメント上で重複するアトリビュート名の出現はXML 1.0 によって禁止されるから、これは伝統的な名前空間である。アトリビュート名とエレメントの型との組み合わせが、無修飾アトリビュートそれぞれを一意的に特定する。

この仕様書に適合しているXML文書においては、すべての有修飾(プレフィックスつき)アトリビュートの名前はグローバルアトリビュートパーティションに割り当てられ、無修飾アトリビュートの名前は適切なエレメント型ごとパーティションに割り当てられる。

A.3 拡張エレメント型およびアトリビュート名

規則を規定したり比較をしたりする際の便宜のため、我々は、XML文書内のエレメント型とアトリビュート名とのそれぞれについて、ここでXMLエレメント文法で表わされる拡張形式を定義する。

[定義:]拡張エレメント型は、ExpEType 型の空XMLエレメントとして表わされる。これは、その型の LocalPart を与える type という必須アトリビュートと、そのエレメントが有修飾である場合にその名前空間名を与える ns という任意的アトリビュートとを有する。

[定義:]拡張アトリビュート名は、ExpAName 型の空XMLエレメントとして表わされる。これは、その名前を与える name という必須アトリビュートを有する。アトリビュートがグローバルである場合には、その名前空間名を与える ns という必須アトリビュートを有する。そうでない場合には、添付されたエレメントの型を与える eltype という必須アトリビュートと、既知であるときにはその添付されたエレメントの名前空間名を与える elns という任意的アトリビュートとを有する。

上記に与えられた例の簡単な妥当性検証により、拡張エレメント型およびアトリビュート名の働きが説明される。以下の2つの断片には、それぞれ名前の拡張を示す表が続いている。

<!-- 1 --> <section xmlns='urn:com:books-r-us'>
<!-- 2 -->   <title>Book-Signing Event</title>
<!-- 3 -->   <signing>
<!-- 4 -->     <author title="Mr" name="Vikram Seth" />
<!-- 5 -->     <book title="A Suitable Boy" price="$22.95" />
             </signing>
           </section>

名前は以下のように拡張される。

行番号 名前 拡張後の名前
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">
<!-- 2 --> <NAME HTML:CLASS="largeSansSerif">Layman, A</NAME>
<!-- 3 --> <SEAT CLASS="Y" HTML:CLASS="largeMonotype">33B</SEAT>
<!-- 4 --> <HTML:A HREF='/cgi-bin/ResStatus'>Check Status</HTML:A>
<!-- 5 --> <DEPARTURE>1997-05-24T07:55:00+1</DEPARTURE></RESERVATION>
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" />

A.4 拡張アトリビュート名の一意性

上記の "5.3 アトリビュートの一意性" によって表わされた制約は、どのエレメントも、拡張名が等価、すなわち、同じアトリビュート値の対と同じ内容の子エレメントを有する2つのアトリビュートを有しないことを要求することにより、そのまま実装してもよい。

B. 謝辞

この作業は、特にW3C XMLワーキンググループや特別利害グループのメンバーや、W3Cメタデータアクティビティに参加者を含め、きわめて多数の人々からの入力を反映している。

C. 参照資料

RFC2141
URN Syntax, ed. R. Moats.
IETF RFC 2141, 1997年5月.
XML
Extensible Markup Language (XML) 1.0, eds. Tim Bray, Jean Paoli, C. M. Sperberg-McQueen. W3C勧告 1998年2月10日.
http://www.w3.org/TR/1998/REC-xml-19980210 で入手可能である。
URI
Uniform Resource Identifiers (URI): Generic Syntax eds. T. Berners-Lee, R. Fielding, L. Masinter, IETF RFC 2396, 1998年8月.
どら猫本舗 (webmaster@doraneko.org)