XML名前空間 1.1


W3C

XML名前空間 1.1

W3C勧告 2004年2月4日

このバージョン[原文]:
http://www.w3.org/TR/2004/REC-xml-names11-20040204
最新のバージョン:
http://www.w3.org/TR/xml-names11
以前のバージョン:
http://www.w3.org/TR/2003/PR-xml-names11-20031105
編集者:
Tim Bray, Textuality <tbray@textuality.com>
Dave Hollander, Contivo, Inc. <dmh@contivo.com>
Andrew Layman, Microsoft <andrewl@microsoft.com>
Richard Tobin, University of Edinburgh and Markup Technology Ltd <richard@cogsci.ed.ac.uk> - Version 1.1

この文書のエラッタを参照いただきたい。これには、規範性のある改訂が含まれていることがある。

翻訳を参照すること。

この文書[原文]は、規範性のないこれらのフォーマットでも入手可能である。XML


概要

XML名前空間は、拡張可能マークアップ言語で使われる要素名や属性名に、IRI参照によって識別される名前空間を結合することによって修飾するための単純な手法を提供するものである。

この文書の位置づけ

この節は、この文書の公開時における位置づけを説明したものである。他の文書がこの文書に取って代わることがある。現行のW3C公刊物の一覧およびこの技術レポートの最新版は、http://www.w3.org/TR/ のW3C技術レポート索引で見ることができる。

この文書は、W3Cの勧告 (Recommendation) である。この文書は、W3C会員およびその他の利害関係者によってレビューされ、ディレクターによってW3C勧告として公布されている。この文書は、安定的な文書であって、参照素材として利用したり、他の文書から規範性ある参照としての引用に用いられてもかまわない。勧告を作成する際のW3Cの役割は、仕様に対する注意を引き、その広範な普及を推進することにある。このことは、ウェブの機能と相互運用性とを高める。

この文書は、W3C XML Activity の産物である。この仕様書は、英語版が規範性ある唯一のバージョンである。しかしながら、この文書の翻訳を探しているのであれば、http://www.w3.org/2003/03/Translations/byTechnology?technology=xml-names11 を見てみること。

この文書に関連することのある知的所有権についての文書は、ワーキンググループの公開の知的所有権情報開示ページで見ること。

既知の実装は、Namespaces 1.1 実装レポートに文書化されている。テストスイートも、XMLテストスイートページを経由して入手することができる。

この文書のエラーは xml-names-editor@w3.org までレポートいただきたい。公開アーカイブが利用可能である。この文書のエラッタリストは http://www.w3.org/XML/2004/xml-names11-errata で入手できる。

目次

1 動機と要約
    1.1 表記法や用例に関する注意
2 XML名前空間
    2.1 基本概念
    2.2 名前空間名としてのIRIの使用
    2.3 IRI参照の比較
3 名前空間を宣言する
4 有修飾名
5 有修飾名を使う
6 要素や属性に名前空間を適用する
    6.1 名前空間のスコーピング
    6.2 名前空間のデフォルト化
    6.3 属性の一意性
7 文書の適合性
8 プロセッサの適合性
9 国際化リソース識別子 (IRI)

付録

A 規範性ある参照
B Other references (規範性なし)
C XML名前空間の内部構造 (規範性なし)
D バージョン 1.0 以降の変更点 (規範性なし)
E 謝辞 (規範性なし)


1 動機と要約

我々は、複数のソフトウェアモジュールのために定義されて利用される要素や属性 (ここでは「マークアップ語彙」と呼ばれる。) が単一のXML文書に包含されてもよい拡張可能マークアップ言語 (XML) のアプリケーションを心に描く。その動機の一つは、モジュラ性である。しっかり理解されていて、そのための有益なソフトウェアモジュールがあるようなマークアップ語彙が存在するのであれば、このマークアップを再利用したほうが、それを再創作するよりもよい。

そのような複数のマークアップ語彙を包含する文書は、認識や衝突の問題を突きつける。ソフトウェアモジュールは、それが処理するよう予定されている要素や属性を認識できる必要がある。これは、何か他のソフトウェアパッケージを対象としているマークアップが同じ要素や属性名を使っているときに起こる「衝突」に直面したときにでもである。

このようなことを考慮すると、文書構造が、異なるマークアップ語彙に由来する名前が衝突することを避けるように名前を構築することが必須となる。この仕様書は、XML名前空間というメカニズムを解説する。これは、要素や属性に拡張名を割り当てることにより、これを実現するものである。

1.1 表記法や用例に関する注意

強調されている箇所では、この文書にある なければならない(MUST), てはならない(MUST NOT), 必須である(REQUIRED), べきである(SHOULD), べきでない(SHOULD NOT), てもよい(MAY)、というキーワードは、[Keywords] で解説されているとおり解釈されるべきものである。

この仕様書にある非終端生成規則の多くは、ここではなく、XML仕様書 [XML] で定義されている。ここで定義されている非終端規則が、XML仕様書で定義されている非終端規則と同じ名前を有するときには、すべての場合で、こちらにある生成規則が、そこで対応するものによって照合される文字列のサブセットに合致する。

この文書の生成規則において、NSC とは、「名前空間制約 (Namespace Constraint)」である。これは、この仕様書に適合する文書が従わなければならない(MUST)規則の一つである。

2 XML名前空間

2.1 基本概念

[定義: XML名前空間 (XML namespace) は、IRI参照によって識別される。要素名や属性名は、この仕様書で解説されているメカニズムを使ってXML名前空間の中に置かれてよい。]

[定義: 拡張名 (expanded name) は、名前空間名ローカル名とからなるペアである。] [定義: I というIRIによって識別される名前空間にある N という名前については、名前空間名I である。名前空間の中にない N という名前については、名前空間名は値がない。] [定義: どちらの場合でもローカル名 (local name)N である。] 大域的に管理されているIRI名前空間と、その語彙のローカル名とという、この組み合わせこそが、名前の衝突を避けるために効力を有するのである。

IRI参照は、名前の中には認められていない文字を包含することができ、また、よく不便に長くなるので、拡張名は、XML文書の中にある要素や属性を直接に命名するためには使われない。その代わりに、有修飾名 (qualified name) が使われる。[定義: 有修飾名 (qualified name) は、名前空間解釈に従う名前である。] この仕様書に適合する文書では、要素名や属性名は有修飾名として出現する。文法的には、それらは有修飾名無プリフィックス名かのいずれかである。プリフィックスを名前空間名に結合したり、無プリフィックス要素名に適用されるデフォルト名前空間を結合するために、属性ベースの宣言文法が用意される。これらの宣言は、一つの文書の中のいろいろな部分にいろいろなバインディングを適用できるよう、その宣言が出現する要素によってスコーピングされる。この仕様書に適合するプロセッサは、これらの宣言やプリフィックスを認識し、かつ、それらに基づいて動作しなければならない(MUST)

2.3 IRI参照の比較

ある与えられた名前空間に、ある名前が属しているかどうかや、二つの名前が同じ名前空間に属するかを判断するときに、名前空間を識別するIRI参照が比較される。[定義: 二つのIRIは文字列として扱われるのであって、その文字列が同一である場合、すなわち、同じキャラクタ列である場合に、かつ、そのような場合にのみ、同一 (identical) である。] 比較は、大文字小文字を区別するものであり、また、%-エスケーピングを実施したり復元したりはしない。

この結果、この意味では同一ではないIRI参照が、同じリソースへと解釈参照されることがある。例としては、大文字小文字や%-エスケーピングだけが違うIRI参照や、異なるベースURIをもつ外部実体にあるIRIがある (ただし、相対URIは名前空間名としては廃止方向であることに注意してほしい)。

名前空間宣言では、IRI参照は属性の既標準化値であり、そのため、XMLの文字参照や実体参照の置換は、一切の比較よりも先に既に実行されている。

例:

下記のIRI参照は、大文字小文字が異なっているので、名前空間を識別する上では、すべて異なっている。

  • http://www.example.org/wine

  • http://www.Example.org/wine

  • http://www.example.org/Wine

下記のIRI参照も、名前空間を識別する上では、すべて異なっている。

  • http://www.example.org/rosé

  • http://www.example.org/ros%c3%a9

  • http://www.example.org/ros%c3%A9

  • http://www.example.org/ros%C3%a9

  • http://www.example.org/ros%C3%A9

これらも同様である。

  • http://www.example.org/~wilbur

  • http://www.example.org/%7ewilbur

  • http://www.example.org/%7Ewilbur

eacute という実体が &eatute; であると定義されている場合、下記の開始タグはすべて、プリフィックス phttp://example.org/rosé/code> という同じIRI参照に結合する名前空間宣言を含んでいる。

  • <p:foo xmlns:p="http://example.org/rosé>

  • <p:foo xmlns:p="http://example.org/ros&#xe9;">

  • <p:foo xmlns:p="http://example.org/ros&#xE9;">

  • <p:foo xmlns:p="http://example.org/ros&#233;">

  • <p:foo xmlns:p="http://example.org/ros&eacute;">

解釈参照された場合に等価となるIRIの間で混乱が起こるリスクがあるので、%-エスケーピングされた文字を名前空間名で使わないことが、強く奨励される。

3 名前空間を宣言する

[定義: 名前空間 (もっと厳密に言うなら、名前空間バインディング) は、予約済み属性の一族を使って宣言 (declare) される。そうした属性の名前は、xmlns であるか、xmlns: で始まるものでなければならない。これらの属性は、他の一切のXML属性のように、直接与えられてもよいし、デフォルトによって与えられてもよい。]

名前空間宣言のための属性名
[1]    NSAttName    ::=    PrefixedAttName
| DefaultAttName
[2]    PrefixedAttName    ::=    'xmlns:' NCName [NSC: 予約済みのプリフィックスおよび名前空間名]
[3]    DefaultAttName    ::=    'xmlns'
[4]    NCName    ::=    NCNameStartChar NCNameChar* /* XMLの Name マイナス ":" */
[5]    NCNameChar    ::=    NameChar - ':'
[5a]    NCNameStartChar    ::=    NameStartChar - ':'

属性の既標準化値は、IRI参照 - 名前空間を識別する名前空間名 - であるか、空文字列であるかのいずれかでなければならない (MUST) 名前空間名は、その意図された目的を果たすため、一意性と永続性という特性を有するものであるべきである(SHOULD)。これが (スキーマが存在する場合に) スキーマを引き出すために直接利用できることは、目標としていない。統一リソース名 (URN) [RFC2141] は、これらの目的を念頭に置いて設計された文法の一例である。しかしながら、普通のURLも、これらの同じ目的を達成するような方法で管理することができることに注意するべきである。

[定義: 属性名が PrefixedAttName に合致する場合、NCName名前空間プリフィックス (namespace prefix) を与える。これは、要素名や属性名を、その宣言の添付先である要素のスコープの中にある属性値の名前空間名に結合するために使われる。]

[定義: 属性名が DefaultAttName に合致する場合、属性値の名前空間名は、その宣言の添付先である要素のスコープの中にあるデフォルト名前空間 (default namespace) のそれである。] デフォルト名前空間や、宣言の上書きについては、6 要素や属性に名前空間を適用する で論じる。

名前空間宣言の例。これは、edi という名前空間プリフィックスを http://ecommerce.example.org/schema という名前空間名に結合するものである。

<x xmlns:edi='http://ecommerce.example.org/schema'>
  <!-- "x" 要素およびその内容について "edi" プリフィックスが
       http://ecommerce.example.org/schema に結合される -->
</x>

それ自体は予約されていないけれども、大文字小文字の組み合わせを問わず、LocalPart が x, m, l という3文字で始まる有プリフィックス名を使うことは、勧められない。これらの名前は、プリフィックスなしで使われれば、予約済みということになるからである。

4 有修飾名

この仕様書に適合するXML文書において、いくつかの名前 (Name という非終端規則に対応する構造物) は、有修飾名 (qualified name) として与えられなければならない(MUST)。これは、以下のように定義される。

有修飾名
[6]    QName    ::=    PrefixedName
| UnprefixedName
[6a]    PrefixedName    ::=    Prefix ':' LocalPart
[6b]    UnprefixedName    ::=    LocalPart
[7]    Prefix    ::=    NCName
[8]    LocalPart    ::=    NCName

Prefix は、有修飾名の名前空間プリフィックスを与えるものであって、名前空間宣言の中にある名前空間IRI参照に結合されていなければならない(MUST)。[定義: LocalPart は、有修飾名のローカル部 (local part) を与える。]

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

5 有修飾名を使う

この仕様書に適合するXML文書では、要素は、以下のような有修飾名として与えられる。

要素名
[9]    STag    ::=    '<' QName (S Attribute)* S? '>' [NSC: プリフィックスが定義済み]
[10]    ETag    ::=    '</' QName S? '>' [NSC: プリフィックスが定義済み]
[11]    EmptyElemTag    ::=    '<' QName (S Attribute)* S? '/>' [NSC: プリフィックスが定義済み]

要素名として機能する有修飾名の一例:

属性は名前空間宣言であるか、あるいは、それらの名前が有修飾名として与えられるかのいずれかである。

属性
[12]    Attribute    ::=    NSAttName Eq AttValue
| QName Eq AttValue [NSC: プリフィックスが定義済み]

属性名として機能する有修飾名の一例:

名前空間制約: プリフィックスが定義済み

名前空間プリフィックスは、それが xml または xmlns であるのでない限り、そのプリフィックスが使われている要素の開始タグか祖先要素 (すなわち、その内容の中に、プリフィックスが付けられたマークアップが出現している要素) かのいずれにある名前空間宣言で宣言されていなければならない(MUST)。さらに、そうした最内の宣言の属性値は、空文字列であってはならない(MUST NOT)

この制約から、名前空間宣言が、XML文書実体の中で直接にではなく、外部実体の中で宣言されているデフォルト属性を経由して与えられる場合には、動作上の難点が導かれることがある。そうした宣言は、妥当性検証を行わないXMLプロセッサをベースとするソフトウェアに読んでもらえないことがある。多くのXMLアプリケーションは、おそらく名前空間を認識するものを含め、妥当性検証を行うプロセッサを必須としてはいない。そうしたアプリケーションで正しい動作が要求される場合、名前空間宣言は、直接にか、DTDの内部サブセットの中で宣言されたデフォルト属性を経由するかのいずれかによって与えられなければならない(MUST)

要素名や属性は、DTDの中にある宣言に出現するときには、有修飾名としても与えられる。

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

DTDベースの妥当性検証が、以下の意味で名前空間を認識しないものであることに注意してほしい。DTDは、文書内に出現してよい要素や属性を、それらの未解釈名によって制約するものであって、(名前空間名、ローカル名の) ペアによって制約するものではない。名前空間を使っている文書をDTDに照らして妥当性検証するためには、インスタンスと同じプリフィックスがDTDで使われなければならない。しかしながら、DTDは、名前空間を宣言する属性に #FIXED 値を与えることにより、妥当な文書中で使われている名前空間を間接的に制約してもよい。

6 要素や属性に名前空間を適用する

6.1 名前空間のスコーピング

プリフィックスを宣言する名前空間宣言のスコープは、それが出現する開始タグの最初から、対応する終了タグの最後にまで及ぶ。ただし、内側にあって同じ NSAttName 部を有する一切の宣言のスコープは除く。空タグの場合には、スコープはそのタグ自身である。

そうした名前空間宣言は、そのスコープの内部にあり、その宣言で指定されたプリフィックスに合致するプリフィックスをもつすべての要素および属性名に適用される。

有プリフィックス要素名または属性名に対応する拡張名は、そのプリフィックスに結合されているIRIを名前空間名としてもち、ローカル部をそのローカル名としてもつ。

<?xml version="1.1"?>

<html:html xmlns:html='http://www.w3.org/1999/xhtml'>

  <html:head><html:title>Frobnostication</html:title></html:head>
  <html:body><html:p>Moved to 
    <html:a href='http://frob.example.com'>here.</html:a></html:p></html:body>
</html:html>

この例に示すように、複数の名前空間プリフィックスを、単一の要素の属性として宣言することができる。

<?xml version="1.1"?>
<!-- 名前空間プリフィックスは両方とも全体で利用できる -->
<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>

あるプリフィックスを表す名前空間宣言の属性値は、空であってもよい(MAY)。これには、その宣言のスコープの内部で、そのプリフィックスと名前空間名との結合を解くという効果がある。さらに宣言をして、プリフィックスを再び宣言し直してもよい(MAY)

<?xml version="1.1"?>
<x xmlns:n1="http://www.w3.org">
    <n1:a/>               <!-- 合法; プリフィックス n1 は http://www.w3.org に結合される -->
    <x xmlns:n1="">
        <n1:a/>           <!-- 違法; プリフィックス n1 は、ここでは結合されない -->
    <x xmlns:n1="http://www.w3.org">
            <n1:a/>       <!-- 合法; プリフィックス n1 は、再び結合される -->
        </x>
    </x>
</x>

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

デフォルト名前空間宣言のスコープは、それが出現している開始タグの最初から、対応する終了タグの最後にまで及ぶ。ただし、内側にある一切のデフォルト宣言のスコープは除く。空タグの場合には、スコープはそのタグ自身である。

デフォルト名前空間宣言は、そのスコープの内部にあるすべての無プリフィックス要素名に適用される。デフォルト名前空間宣言は、属性名には直接には適用されない。無プリフィックス属性の解釈は、それが出現している要素によって決定される。

スコープ内にデフォルト名前空間宣言がある場合、無プリフィックス要素名に対応する展開名は、デフォルト名前空間のIRIを、その名前空間名としてもつ。スコープ内にデフォルト名前空間宣言がない場合、名前空間名は、値を有さない。無プリフィックス属性の名前空間名は、つねに値を有さない。すべての場合で、ローカル名は、ローカル部 である (これは、もちろん、無プリフィックス名そのものと同じである)。

<?xml version="1.1"?>
<!-- 要素は、この場合はデフォルトにより、HTML名前空間の中にある -->
<html xmlns='http://www.w3.org/1999/xhtml'>
  <head><title>Frobnostication</title></head>
  <body><p>Moved to 
    <a href='http://frob.example.com'>here</a>.</p></body>
</html>
<?xml version="1.1"?>
<!-- プリフィックスが付けられていない要素型は "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.1"?>
<!-- 最初は、デフォルト名前空間は "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>
      <!-- 評釈のためにHTMLをデフォルト名前空間にする -->
      <p xmlns='http://www.w3.org/1999/xhtml'>
          This is a <i>funny</i> book!
      </p>
    </notes>
</book>

デフォルト名前空間宣言の属性値は、空であってもよい(MAY)。これには、宣言のスコープの内部では、デフォルト名前空間がないのと同じ効果がある。

<?xml version='1.1'?>
<Beers>
  <!-- テーブル内部のデフォルト名前空間は、HTMLの名前空間である -->
  <table xmlns='http://www.w3.org/1999/xhtml'>
   <th><td>Name</td><td>Origin</td><td>Description</td></th>
   <tr> 
     <!-- テーブルのセルの内部にはデフォルト名前空間がない -->
     <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>

6.3 属性の一意性

この仕様書に適合するXML文書では、どのタグも、つぎのような二つの属性を包含してはならない。

  1. 同一の名前を有する、または

  2. 同じ ローカル部をもち、かつ、同一である名前空間名に結合されているプリフィックスをもつ有修飾名をもつ。

この制約は、どの要素も同じ展開名をもつ二つの属性を持っていないことを要求するのと等価である。

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

<!-- http://www.w3.org は n1 と 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>

しかしながら、以下はそれぞれ合法である。2番目のものは、デフォルト名前空間は属性名に適用されないからである。

<!-- http://www.w3.org は n1 に結合されていて、また、デフォルトでもある -->
<x xmlns:n1="http://www.w3.org" 
   xmlns="http://www.w3.org" >
  <good a="1"     b="2" />
  <good a="1"     n1:a="2" />
</x>

7 文書の適合性

この仕様書は、XML 1.1 文書に適用される。この仕様書に適合するためには、文書は、XML 1.1 仕様書 [XML 1.1] に従って整形式でなければならない(MUST)

この仕様書に適合するXML文書では、要素名や属性名は、QName の生成規則に合致しなければならず(MUST)、かつ、「名前空間制約」を満たさなければならない(MUST)。XML 1.1 整形式であるために Name のXML生成規則に合致することが必須である(REQUIRED)この文書中の他のすべてのトークンは、この仕様書の NCName の生成規則に合致しなければならない(MUST)

[定義: 文書は、この仕様書に適合する場合、名前空間整形式 (namespace-well-formed) である。]

従って、名前空間整形式の文書では、つぎのようになる。

  • すべての要素名および属性名は、0個または1個のコロンを包含する。

  • 実体名、処理命令ターゲット、記法名は、コロンを包含しない。

さらに、名前空間整形式の文書は、名前空間妥当であることがある。

[定義: 名前空間整形式の文書は、それが XML 1.1 仕様書により妥当であって、かつ、XML 1.1 妥当であるためにXMLの Name の生成規則に合致することが必須とされている要素名及び属性名以外のすべてのトークンが、この仕様書の NCName の生成規則に合致する場合、名前空間妥当 (namespace-valid) である。]

従って、名前空間妥当な文書では、つぎのようになる。

  • ID 型、IDREF(S) 型、ENTITY(IES) 型、NOTATION 型の宣言型をもつ属性は、コロンを包含しない。

8 プロセッサの適合性

この仕様書に適合するためには、プロセッサは、名前空間整形式性の違反をレポートしなければならない(MUST)。ただし、その名前空間名が合法なIRIであることをチェックすることは、必須(REQUIRED) ではない。

[定義: この仕様書に適合する妥当性検証を行うXMLプロセッサは、さらに名前空間妥当性の違反をレポートする場合、名前空間妥当性検証を行う(namespace-validating) ものである。]

9 国際化リソース識別子 (IRI)

国際化リソース識別子 (Internationalized Resource Identifier, IRI) を定義するRFCを作成する作業は、現在進行中である。この作業は未完成であるので、この節では、この仕様書に関する限りで、IRIの文法的な定義を与える。XMLコアワーキンググループは、RFCが公開されたときには、この節をそのRFCへの参照で置き換えるエラッタを発行するつもりである。

名前空間を定義するユーザには、RFCが公開され、IRIをサポートするソフトウェアが一般的に利用されるようになるまで、名前空間名を限定するようアドバイスする。実装者には、同様に、認められる文字の点でドラフトに違反する名前空間名を拒絶しないよう、アドバイスする。

IRIについてのもっと一般性のある定義や議論については、 [IRI draft 5] (進行中の作業) を見ること。

URI参照は、ASCII文字のサブセットに限定される。IRI参照は、#xA0 以上のほとんどのUnicode文字を認める。初期の IRI RFC のドラフト (例. [IRI draft 3]) も、認められていないASCII文字をいくつか認めていたが、現行ドラフト ([IRI draft 5]) は認めていない。

[定義: [IRI draft 5] によりIRIで認められる追加文字 (additional character)は、つぎのものである。]

  • Unicode 第0面キャラクタ #xA0 - #xD7FF, #xF900-#xFDCF, #xFDF0-#xFFEF

  • Unicode 第1-14面キャラクタ #x10000-#x1FFFD ... #xD0000-#xDFFFD, #xE1000-#xEFFFD

[定義: IRI参照 (IRI reference) は、以下のステップを適用してURI参照に変換することのできる文字列である。]

  1. ホスト名部が存在する場合には、それを、[RFC3490] の Section 4.1 に指定された ToASCII 演算を、UseSTD3ASCIIRules フラグと AllowUnassigned フラグを TRUE に設定して使って変換する。

  2. すべての追加文字を、以下のとおりエスケーピングする。

    1. それぞれの追加文字を、1個以上のバイトとして、UTF-8 [RFC3629] を変換する。

    2. 結果として得られたバイトを、URIエスケーピングメカニズムを用いてエスケープする (すなわち、%HH に変換する。ここで HH は、バイト値を十六進表記したものである)。

    3. 元の文字を、結果として得られた文字の並びで置き換える。

註:

[IRI draft 5] のアルゴリズムには、UCS正規化ステップが含まれているが、これは、どの文字列がIRI参照であるかに違いをもたらさない。

A 規範性ある参照

Keywords
RFC 2119: Key words for use in RFCs to Indicate Requirement Levels, S. Bradner, ed. IETF (Internet Engineering Task Force), March 1997. http://www.rfc-editor.org/rfc/rfc2119.txt で入手可能。
RFC2141
RFC 2141: URN Syntax, R. Moats, ed. IETF (Internet Engineering Task Force), May 1997. http://www.rfc-editor.org/rfc/rfc2141.txt で入手可能。
RFC2396
RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax, T. Berners-Lee, R. Fielding, and L. Masinter, eds. IETF (Internet Engineering Task Force), August 1998. http://www.rfc-editor.org/rfc/rfc2396.txt で入手可能。
RFC2732
RFC 2732: Format for Literal IPv6 Addresses in URL's, R. Hinden, B. Carpenter, and L. Masinter, eds. IETF (Internet Engineering Task Force), December 1999. http://www.rfc-editor.org/rfc/rfc2732.txt で入手可能。
RFC3490
RFC 3490: Internationalizing Domain Names in Applications (IDNA), P. Faltstrom, P. Hoffman, and A. Costello, eds. IETF (Internet Engineering Task Force), March 2003. http://www.rfc-editor.org/rfc/rfc3490.txt で入手可能。
RFC3629
RFC 3629: UTF-8, a transformation format of ISO 10646, F. Yergeau, ed. IETF (Internet Engineering Task Force), November 2003. http://www.rfc-editor.org/rfc/rfc3629.txt で入手可能。
XML
Extensible Markup Language (XML) 1.0 (Third Edition), Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, and François Yergeau eds. W3C (World Wide Web Consortium), 4 February 2004. http://www.w3.org/TR/REC-xml で入手可能。
XML 1.1
Extensible Markup Language (XML) 1.1, Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, and John Cowan eds. W3C (World Wide Web Consortium), 4 February 2004. http://www.w3.org/TR/xml11 で入手可能。

B その他の参照 (規範性なし)

IRI draft 3
Internationalized Resource Identifiers (IRIs), M. Duerst and M. Suignard eds. March 2, 2003. http://www.w3.org/International/iri-edit/draft-duerst-iri-03.txt で入手可能。
IRI draft 5
Internationalized Resource Identifiers (IRIs), M. Duerst and M. Suignard eds. October 26, 2003. http://www.w3.org/International/iri-edit/draft-duerst-iri-05.txt で入手可能。
1.0 Errata
Namespaces in XML Errata. W3C (World Wide Web Consortium). http://www.w3.org/XML/xml-names-19990114-errata で入手可能。
Relative URI deprecation
Results of W3C XML Plenary Ballot on relative URI References In namespace declarations 3-17 July 2000, Dave Hollander and C. M. Sperberg-McQueen, 6 September 2000. http://www.w3.org/2000/09/xppa で入手可能。
Requirements
Namespaces in XML 1.1 Requirements, Jonathan Marsh, ed. W3C (World Wide Web Consortium), March 2002. http://www.w3.org/TR/2002/WD-xml-names11-req-20020403/ で入手可能。

D バージョン 1.0 以降の変更点 (規範性なし)

このバージョンは、2002年12月6日時点のバージョン 1.0 のエラッタ [1.0 Errata] を組み込んでいる。本質的な変更点は2つある。

  • プリフィックスを宣言解除するためのメカニズムを用意した。

  • 名前空間名は、URIではなく、IRIとした。

編集上の変更点は、いくつかある。これには、一貫性を高めることを狙いとした多数の用語の変更や追加が含まれる。規範性のない付録である「XML名前空間の内部構造」が外された。


どら猫本舗 (webmaster@doraneko.org)