IRI

Edit New

IRI

[19] IRI (Internationalized Resource Identifiers) は、 利用可能な文字の種類を ASCII ベースから Unicode ベースへと拡張した、 URI の超集合である識別子 (の仕様) です。

仕様

[49] 現時点で最新かつ正式な IRI の仕様は、 IETF の提案標準である RFC 3987 です。 RFC 3987 は2004年12月に IESG に承認され、 2005年1月に RFC として発行されました。

IRI に関する様々な仕様と定義

[1] IRI の RFC (RFC 3987) が発行される前、あるいは発行された後にも、 URI/IRI 的なものを使う仕様の中には、 IRI 仕様を先取りして、あるいは独自に、 IRI のようなものを定義したり、 IRI の Internet Draftを参照したりしていました。 特に W3C の仕様書では、数多くの「IRI のようなもの」が定義されていました。

[50] たとえ実質的に同じ定義であったとしても、人為的なミス、仕様の改訂、政治的問題、 その他の理由で混乱が起こる危険性はあるので、困ったことですね、 などと昔ここに書いていたのですが、実際各仕様が定義している内容には少しずつ「ずれ」がある上、 その「ずれ」が遺物拡張IRI (旧称: XML資源識別子など) や HTML 5 の URL のような派生仕様を生み出すまでに至り、既に混乱は極まっている感があります。

「IRI」や「IRI 参照」を定義している仕様
RFC 3987 IRI・IRI 参照

[13] IETF で標準化された、“最も正しい”「IRI」や「IRI参照」の定義です。 両者は百分率符号化によって RFC 3986 の URI や URI参照に変換できる文字列であり、 ABNF で構文が定義されています。

[52] 実は RFC 3987 をよく読むと、 ABNF で表現されていない構文上の制約が本文中に含まれています。 RFC 3987 を引用している仕様の中には、「RFC 3987 の ABNF 生成規則に一致するもの」 のような参照の仕方をしているものがありますが、それでは ABNF に含まれない制約が厳密には参照されていないことになるので、要注意です。

[113] SVG Tiny 1.2 は以前の案では XML資源識別子を使ったりしていましたが、 最後の勧告では結局 RFC 3987 IRI参照になっています。

XLink の属性までも RFC 3987 IRI参照になってたりします。

[53] RFC 3987 になる前の古い Internet Draft には、最終版とは異なる定義をしているものもあります。 古い Internet Draft を参照している仕様は要注意です。

[54] また、現在改訂の作業が進められており、 Internet Draft も発行されています (draft-duerst-iri-bis)。改訂版には元々の IRI だけではなく、遺物拡張IRI の定義も含まれています。

XPointer IRI 参照

[2] 「IRI」を URI の拡張で Unicode 文字が使えるものと概念的に定義した上で、 XPointer 指示子を「IRI参照」で使う方法や、IRI参照を URI参照に変換する方法を規定しています。

用語として定義されているのは「IRI」ですが、実際規定があるのは 「IRI参照」 (と「URI参照」) です。 RFC 2396 時代の「URI」には素片識別子が含まれていないためでしょうか。

それによると、 XPointer 指示子を IRI参照中で使う場合、 % は百分率符号化を行わなければなりませんが、その他の文字はしても構わないのみです。

また、 IRI参照から URI参照への変換では、 RFC 2396 と RFC 2732 で URI参照中に認められない文字を百分率符号化することになっています。

[55] XPointer 指示子中には任意の Unicode 文字 (U+0000 〜 U+10FFFF、除外なし) がそのまま使えることになっています。従って、

XML 名前空間 IRI 参照

[3] XML名前空間 1.1 の第1版は、当時 RFC 3987 が出版されていなかったため、 RFC 3987 になる前の Internet Draft である draft-duerst-iri-03 と draft-duerst-iri-05 を参照しつつ (どちらも non-normative reference)、独自に IRI参照を定義しています。

それによると、「IRI参照」は、 hostname 部品があればそれに IDNA ToASCII 演算 (≒ Punycode 符号化) を施し、「追加文字」 を百分率符号化した結果、URI参照が得られる文字列です。

「追加文字」とは、Unicode の非ASCII文字から私用域や非文字や代理組の符号位置を除外したものです。

[56] この定義は実際上 (何が IRI参照で何が IRI参照ではないかという点で) draft-duerst-iri-05 と一致していることになっています (未検証)。 なお、「URI参照」の定義は明らかにされていません。XML名前空間 1.1 第1版の仕様書の参考文献には RFC 2396 と RFC 2732 が挙がっているのですが、両者は本文中のどこからも参照されていません。

[57] draft-duerst-iri-05 と RFC 3987 の定義は異なるようです (未検証)。 そのため、

[58] なお、XML名前空間 1.1 は既に改訂されており、 第2版では RFC 3987 を直接参照しています。 第1版における IRI の定義は第2版からは削除されています。

XInclude IRI 参照

[4] XInclude 1.0 の第1版は、当時 RFC 3987 が出版されていなかったため、 RFC 3987 になる前の Internet Draft である draft-duerst-iri-11 を参照しつつ (non-normative reference)、独自に IRI参照を定義しています。

それによると、「IRI参照」は、 Unicode の非ASCII文字のうち、私用域の文字や非文字と代理組の符号位置を除外したものを百分率符号化した結果が URI参照になる文字列です。

[59] 「URI参照」の定義は明記されていませんが、文脈によると少なくても RFC 2396 によっているようです。更に、 RFC 2396 だけでなく RFC 2732 もこの仕様書から normative reference として参照されています。

[60] XInclude IRI参照も XML名前空間 1.1 IRI参照 (>>3) も RFC 2396 + RFC 2732 の URi参照に基づき定義されているとみなすと、 XInclude IRI参照は XML名前空間 1.1 IRI参照のほぼ部分集合になりますが、

[61] なお、 XInclude 1.0 第1版では「IRI参照に変換されるもの」も定義されています (>>62)。

[64] この部分の規定は正誤票の PEX17 で削除され、 XML 1.1 の XML資源識別子を使うという規定に置き換わっています (>>65)。

「IRI に変換されるもの」や「IRI 参照に変換されるもの」を定義している仕様
XInclude IRI 参照に変換されるもの

[62] XInclude 1.0 第1版では「IRI参照」を定義していますが (>>4)、 href 属性値を IRI参照に変換する方法も定義しています。

それによると、 IRI参照に変換するためには属性値の次の文字を百分率符号化しなければなりません。

[63] この部分の規定は正誤票の PEX17 で削除され、 XML 1.1 の XML資源識別子を使うという規定に置き換わっています (>>65)。

XLink IRI 参照に変換されるもの

[27] XLink 1.1 の当初の WD は、 href 属性の値は RFC 3987 の IRI参照か、 U+0020 を百分率符号化すると RFC 3987 IRI参照になるものでなければならないと規定していました。 この規定は XLink 1.0 との後方互換性のためとされています。

[73]

「URI に変換されるもの」、「URI 参照に変換されるもの」を定義している仕様
HTML 4.01 URI 誤り処理

[10] HTML 4 は著者に対しては URI しか認めていませんが、 informative な附属書中で、利用者エージェントが非ASCII文字を含む URI 属性値の処理に関して、

  1. まずは UTF-8 として百分率符号化し、試してみる
  2. 古い文書に対応したい利用者エージェントは、前項が失敗した場合、 文書の文字符号化を使って百分率符号化し、試してみる

という方法を述べています (1項目は推奨されており、2項目は note での言及、 ただしどちらも informative)。

なお、 HTML 4 は「URI参照」の意味で「URI」という語を使っていると見られる上、 RFC 1738、RFC 1808、RFC 2396 をいずれも normative に参照しており、混乱しています。

[70]

XML システム識別子

[7] XML のシステム識別子は、 URI参照に変換できるものと定義されています。 (なお、 1.0 1e E76 以後、システム識別子に素片識別子が現れるのは誤りとされています。) 厳密な定義は正誤票で何度も重ねて訂正され、各版で内容が微妙に異なっています。

版参照する URI 仕様百分率符号化しなければならない文字
1.0 1eRFC 2396 になる前の Internet Draft (RFC 1738 と RFC 1808 も参照、3ついずれも informative)非ASCII文字
1.0 1e E49同上非ASCII文字、RFC 2396 2.2 節 reserved 文字
1.0 1e E66RFC 2396、RFC 2732非ASCII文字
1.0 1e E78、1.0 2e、1.0 2e E5RFC 2396、RFC 2732非ASCII文字、RFC 2396 2.4 節除外文字 (ただし #, %, [, ] を除く)
1.0 2e E26、1.0 2e E43、1.0 3e、1.1 1e同上U+0000-U+001F, U+007F, U+0020, <, >, U+0022, {, }, |, U+005C, ^, `, U+0080 以上
1.0 4e E14、1.0 4e、1.1 1e E22、1.1 2eRFC 3986同上
  • 1.0 1e E49 の修正は誤った変更です (reserved は URI で使え’'る文字)。
  • 1.0 1e では「URI」とありましたが、 1e 正誤票 E88 で「URI参照に置き換えられています。
  • 1.0 2e と 1.0 3e の間で実質的な変更はありません。
RDF/XML:1999 (XML 1.0 1e の処理の参照)

[22] RDF の1999年の仕様では、生成規則上の URI-reference は XML における文字列であり、 RFC 2396 に従って解釈するとされていました。 構文上は URI として正しくない文字列も認められていたことになります。 Note では、 XML (の最新版) を引用しつつ、非ASCII文字は百分率符号化して URI として解釈することが実装に勧められています。

なお、この仕様書は「URI」と「URI参照」の両方の語が現れますが、 「URI参照」という語が現れるのは生成規則の名前だけで、 基本的に両者を区別していないようです。

[100] なお、 CellML は RDF の1999年の仕様書を引用していますが、 rdf:about 属性の値は RFC 2396 の URI (仕様書中の例示から察するに、 URI参照のつもり。) と規定しています。

>>99 も参照してください。
XLink/XML 基底/XML 署名 URI 参照に変換されるもの

[9] XLink xlink:href 属性や xml:base 属性や XML署名の URI 属性の値は、 次の文字を百分率符号化した後、 RFC 2396 URI参照として解釈されることになっています。

[72] 百分率符号化する文字の種類の規定では RFC 2396 と RFC 2732 に基づいているのですが、「URI参照」の定義としては RFC 2396 しか参照していません。仕様書中の文言を厳密に解釈するなら、 authority 部品中であっても [, ] は使えないことになります。

[32] SVG 1.0、SVG 1.1 は、 SVG 文書で用いられる xlink:href 属性について、 XLink 1.0 を参照しつつも XLink 1.0 と同じことを再度規定しています。

[8]

WebCGM URI に変換されるもの

[11] WebCGM 第2版は、 WebCGM 処理器が URI の解釈の際に非ASCII文字を百分率符号化しなければならないと規定しています。

この仕様書は RFC 2396 (だけ) を参照していますが、「URI参照」 という言葉を使わず、「URI」を「URI参照」も含めた意味で使っているようです。

処理の規定の部分では XML 1.0 第2版のシステム識別子の処理の規定 (>>7) を採用すると述べられているのですが、なぜかそれを参照するだけに留まらずにわざわざ独自の規定を行っており、 その規定が XML 1.0 第2版のものではなく、 XML 1.0 第1版と同じで非ASCII文字しか百分率符号化しないものとなっています。

[76]

  • なお、この部分の規定は第1版にはありませんでした。
  • RFC 2732 は参照されていません。従って、厳密には XML 1.0 の (正誤票適用時も含めた) どの版とも一致しません。

WebCGM 2.0 URI 参照に変換されるもの

[33] WebCGM の新しい版である WebCGM 2.0 の仕様書では、前版の記述 (>>11) と違って RFC 3986 と RFC 3987 を参照し、 「URI参照」という言葉を使ってより明確な形の規定に改められています。

ただし、「URI」という用語は「URI参照」と必ずしも区別されていないように見受けられます。

さて、この新しい規定では、 WebCGM における URI (URI参照ではなく。) は RFC 3987 3.1 節の百分率符号化を施した後、 RFC 3986 URI参照 (URI ではなく。) にならなければならないとされています。

RFC 3987 3.1節には ASCII 範囲内の URI で使えない文字を百分率符号化して構わないことになっていますが、 それが適用されるか否かには全く言及していません。

加えて、百分率符号化の適用例が示されているのですが、 その中には、百分率符号化以外の % が %25 になるという怪しい例が含まれています。

XML 型録 URI 正規化

[31] XML型録仕様書では、正規化と称して、型録処理器に対する入力や型録中で示された URI参照のようなものを URI参照に変換する処理を定義しています。 定義されている処理の内容は、 XLink 1.0 等 (>>8) と同じです。 「URI参照」の定義として RFC 2396 を参照している点も同じです。

XML型録で定義されている値が URI参照の属性については、 本文の定義に従うなら RFC 2396 の URI参照なのですが、 2003年以降の仕様に含まれる XML Schema や RELAX NG のスキーマでは anyURI となっています。

XSCD URI

[108] W3C XML Schema Definition Language (XSD): Component Designators という仕様の2008年11月の WD は、「URI」や「URI参照」や「IRI」や 「LEIRI」や「AnyURI」のような色々なものや Unicode 文字への言及が入り混じって、 何が著者の意図なのか、何が厳密な解釈なのかよくわからないのですが・・・。 はっきりした事実は、

[109] 本文の字面通り解釈 + RFC 3986 を引用している仕様書だから URI といえば RFC 3986 だろうという常識的推測だと、URI参照である絶対スキーマ部品指示子を含む (と思われる) スキーマ部品指示子に URI で認められない文字を含められることになって、 矛盾します。もっとも、この程度の矛盾した用語法はありがちなことなので、 だからこの解釈は間違いとは断言できませんが。でもこの解釈なら正準スキーマ部品指示子に正準なんて名前は付けませんよね。

EBNF だけを信用すると、 XPointer framework の定義を孫引きしているため、 絶対スキーマ部品指示子には U+0000~U+10FFFF すべてが現れ得ることになります。

正準スキーマ部品指示子の定義から絶対スキーマ部品指示子は LEIRI (WG Note、>>67) で EBNF は多少緩くなっていると推測すると、 そんなに矛盾はないと思います。でもそんなことどこにも書いていません。

[110] ちなみに、1つ前の WD では RFC 2396 URI だけを参照した単純な定義でした。 (それでも EBNF と食い違っているとかはありましたが。)

「XML 資源識別子」、「遺物拡張 IRI」、「遺物拡張 IRI 参照」を定義・参照している仕様

[66] 名前と内容と定義文書が頻繁に変わるこれは、そもそも W3C の XML中核WG が XML 関連仕様の URI/IRI の定義を統一するべく、作業を始めました。 はじめは XRI という名前でしたが、 OASIS の同名の仕様との衝突を避けるため、 XML資源識別子 (XML Resource Identifier、XMLRI とも) に改名されました。 XLink 1.1 で定義するつもりだったり (>>28)、 XML 1.1 で定義するつもりだったり (>>65) した後、 Internet Draft が出版されました。その頃名前は HRRI (確か、 Human Readable Resource Identifiers) でした。 それが RFC 3987 の改訂版となる Internet Draft に吸収され、 HRRI のような積極的に使いたくなる名前は避けるべきだとして 遺物拡張IRI (Legacy Extended IRI、LEIRI) および 遺物拡張IRI参照 (Legacy Extended IRI reference) として定義されるに至りました。この間、名前と定義文書だけでなく、 定義そのものも少しずつ変化しています。

[67] 作業が始まって5年以上が経つわけですが、 XML中核WG は LEIRI の作業の完了待ちで各種仕様の改訂作業も中断状態、もうほんと gdgd です。 業を煮やした XML中核WG は、2008年秋に LEIRI に関する Internet Draft と同じ内容の W3C WG Note を発行しました。 これを参照する形で XML 関連仕様の新版を発行するつもりのようです。

他の定義との差異や採用仕様などはこの項で説明します。歴史的経緯や技術的詳細は LEIRI の項をご覧ください。
XInclude 1.0 第2版 (将来の XML 1.1 の定義の参照)

[65] XInclude 1.0 の第1版勧告に対する正誤票の修正案 PEX17 では、独自の「IRI参照」 (>>4) や「IRI参照に変換されるもの」 (>>62) の定義を削除し、代わりに XML 1.1 の「XML資源識別子」であるとしました。 XML資源識別子とは RFC 3987 の IRI参照に変換されるものであるとも述べていました。

この修正は XInclude 1.0 第2版勧告に反映されました。 第2版は更に XML 1.1 の4.2.2節で「XML資源識別子」が定義されていると明確化しています。 ただし、実は XML 1.1 の改訂はこの時点では行われておらず (その後立ち消え)、 XML 1.1 には「XML資源識別子」という言葉が一切出てきません。

XLink XML 資源識別子

[28] XLink 1.1 CR は「XML資源識別子」を定義しています。 当時の XML中核WG の目論見としては、各種 XML 関連仕様の URI/IRI の定義をこれを参照する形に改める予定だったようです。

XML資源識別子を IRI参照にするためには次の文字を百分率符号化しなければなりません。

なお、 XML資源識別子を相対形から絶対形に解決する場合に、 IRI や URI を経由せずとも直接変換できることが明記されています。

[68]

XML 基底 2e PER (XLink 1.1 CR の参照)

[74] XML基底の第2版 PER では、第1版の URI参照に変換されるもの (>>9) の規定が削除され、 XLink 1.1 CR で定義されている XML資源識別子 (>>28) を参照する形に改められています。

勧告は >>115。
XLink 1.1 2nd LCWD (IRIbis 02 の参照)

[71] >>28 の次に出版された XLink 1.1 の WD では、XML資源識別子の定義は削除されており、 RFC 3987 の改訂案である draft-duerst-iri-bis-02 の LEIRI を参照するように改められています。

LEIRI W3C Note

[116] 2008年に W3C XML Core WG によって出版された W3C WG Note Legacy extended IRIs for XML resource identification は、 遺物拡張IRI (Legacy extended IRI, LEIRI) と 遺物拡張IRI参照 (Legacy extended IRI reference, LEIRI参照) を定義しています。

この仕様書は RFC 3987 の次の IRI 仕様案 Internet Draft (draft-duerst-iri-bis-04) の一部を W3C TR としてほぼそのまま再発行したものです。「IRI」そのものをも定義する同 ID とは異なり、 RFC 3987 を参照しています。

XML 基底第2版勧告 (LEIRI W3C WG Note の参照)

[115] >>74 の次の XML基底 第2版勧告では、 xml:base 属性の値は >>116 の LEIRI (文脈と例示から察するに LEIRI参照のことか。) です。

「anyURI」を定義・参照している仕様

[77] 後述のように、 XML Schema 第2部のデータ型に関する仕様書で定義されている URI・IRI のためのデータ型 anyURI は、「URI」という名前にも関わらず、実質的に IRI参照として定義されています。 このデータ型は XML Schema 仕様書内では XLink 1.0 を参照する形で定義がなされていますが、 スキーマで anyURI データ型を使う文書型の仕様書の中には、 RFC 3987 IRI参照などを引用するものもあって、 厳密には矛盾した、あるいは不必要な制約が加わった形の参照となっていることがあります。

XML Schema 1.0 anyURI

[15] XML Schema データ型 anyURI は、 URI を表すものであり、絶対形・相対形を含み、素片識別子があってもよいと定義されています。 更に、 RFC 2396 と RFC 2732 により定義される URI の役割を果たす値を表すものとして使うべきであるとされています。 そして、 anyURI から URI への変換は XLink 1.0 5.4節による、 とされています。 anyURI の字句空間は XLink 1.0 5.4 節に従った変化によって RFC 2396 + RFC 2732 の URI参照となる文字列、とされています。

[78] わかりにくい定義がなされているのですが、結局のところ、 XLink 1.0 URI参照に変換されるものと同じものを意図しているようです。 (XML Schema 第2部第1版が参照しているのは XLink 1.0 PR ですが、内容は >>8 と同じです。第2版は勧告を参照しています。) 厳密に解釈すれば XLink 1.0 の「URI参照」は RFC 2396 により、 XML Schema は RFC 2396 と RFC 2732 によっているので、 XML Schema の場合の方が表す範囲が広いことになります。

なお、 XLink 1.0 は文脈的に XML 1.0 で認められていない C0制御文字はそもそも対象外で認められていないように読めるのですが、 XML Schema はそのような除外が記されておらず、 C0制御文字も認められているとも解釈できます。 (XML Schema データ型 string は XML 1.0 で認められている文字だけと明記されているのですが、 anyURI については何も言及がありませんし、後者が前者の派生型というわけでもありません。)

ところで、 XML Schema 仕様書は「URI」を「URI参照」 の意味で使っているようです。

第2版では note が追加されるなど多少変更はありますが、実質的な規定の内容には変化がありません。

よくみると「anyURI represents a Uniform Resource Identifier Reference (URI)」 という定義になっていて、「URI」というのは「URI参照」の意味だということになってます。

[104]

RELAX NG anyURI

[75] RELAX NG を定義する ISO/IEC 19757‐2:2002 では、 RELAX NG の構文の定義の中で、「anyURI」を定義しています (6章)。 それによると、 anyURI とは、 XLink 1.0 5.4節の百分率符号化処理 (>>9) の結果が RFC 2396 + RFC 2732 の URI参照となる文字列です。

また、 7.4 節、7.6 節は anyURI として定義された属性の処理を規定していますが、 そこでは XLink 1.0 5.4節の百分率符号化処理 (>>9) と同じであると規定されています。

更に、附属書 A には RELAX NG 自体の RELAX NG スキーマ (規定) がありますが、 そこでは http://www.w3.org/2001/XMLSchema-datatypes を datatypeLibrary とした上で anyURI が関係する属性のデータ型として用いられています。

[29] 対応する翻訳JIS である JIS X 4177 にも、当然同じ規定があります。

[76] つまり、実質的には同じものを本文中では XML Schema を参照せずに規定し、 附属書中では XML Schema (>>15) を使って規定しています。 もっとも、厳密いえば ISO/IEC 19757‐2:2003 の中では XML Schema のデータ型の URL http://www.w3.org/2001/XMLSchema-datatypes の意味を特に定義しておらず、 XML Schema は参考文献にも挙がっていませんので、附属書Aの意図するところは (厳密には) 明確になっていません。
RDF/XML anyURI

[84] RDF/XML の2004年版仕様書は、構文の定義中に「anyURI」があり、 「Any URI.」と説明されているのですが、それ以上の詳しい説明はありません。

anyURI が使われているのは RDF/XML として解釈する XML 1.0 文書中の要素の名前空間URI と局所名を連結したもの (いわゆる展開URI) に関する部分です。他の部分との整合性を考えれば、 RDF URI参照 (>>6) と解するのが適切でしょうか。

XML Schema 1.1 anyURI

[79] XML Schema 1.1 における anyURI の定義は XML Schema 1.0 のもの (>>15) とは異なり、 RFC 3987 (またはその改訂版) の IRI参照とされています。 ただし、その字句空間は単なる文字列と同じで、それ以上の制約は設けられていません。 Note には anyURI が実用上有用であるためには RFC 3987 3.1節の百分率符号化によって RFC 3986 URI になる文字列であるべきだと述べられていますが、 note であって定義には含まれていません。

[80] なお、 XML Schema 1.1 も URI/IRI と URI参照/IRI参照の違いに無頓着なようです。
UDDI anyURI (XML Schema anyURI の参照)

[95] UDDI は XML Schema anyURI を採用しているのですが、 実用上、互換性の問題があったようで、非ASCII文字を含む anyURI の取扱いに関する技術ノートが出版されています。 非ASCII文字を含む anyURI をどのタイミングで XLink 1.0 の方法によって RFC 2732 URI に変換しなければならない・するべきかといったことなどが述べられています。

WSDL anyURI (XML Schema anyURI の参照)

[35] WSDL 2.0 は XML Schema 第2版の anyURI (>>15) を使っています。ですが、単に引用するだけではなく、

と述べられています。

実際に使用している箇所では、 RFC 3987 の絶対IRI のように更に制約があります。

[87] どうしてわざわざ「本質的に」などとわけのわからないことを付け加える必要があるのでしょう。 なお、この仕様書も URI/IRI と URI参照/IRI参照の違いには無頓着に見えます。

IRI・IRI 参照に近い意味で「URI」や「URI 参照」を定義している仕様
P3P URI

[25] P3P は用語の定義の中で「URI」を定義しています。その中では RFC 2396 によると述べているのですが、 HTML や XML においては W3C charmod WD の規定に従うとしています。 (ただし、 HTTP においては適用しないとされています。)

ですが、その参照 (normative reference) されている W3C charmod WD は、仕様が IRI (の当時の Internet Draft である draft-masinter-url-i18n-08) を使用するべきですと述べているに過ぎず、 P3P の実装が何をするべきなのかは明らかでありません。

[26] P3P 1.1 WD の当該規定は P3P 1.0 勧告から変更されていません。 参照している charmod WD も古いもののままです。

[40] なお、 WD の当該部分は後に分割された別の単独の仕様書に移動しています。 しかしながら、その仕様書は CR に達した後、放置されているようです。 (実質的な内容は変化していません。)

W3C 勧告から Work in progress な仕様を参照したことに大きな問題があります。

XML 暗号化 URI

[24] XML暗号化仕様書では、「URI」は XML Schema データ型 anyURI (>>15) と XML署名 URI 属性の規定 (>>8) に従わなければなりませんと規定されています。

なお、「URI」の参考文献として RFC 2396 (URI)、RFC 1738 (URL)、 RFC 2141 (URN)、RFC 2611 (URN) が参照されています。

[83] 手当たり次第に何でも引用できるものはしてしまおうとでもいうのでしょうか、 無茶苦茶ですね。引用されている XML署名の規定は XLink 1.0 の規定と同じ内容なので、実用上は XML Schema の規定とも同じで、 問題にはならないのですが・・・。

RDF URI 参照

[6] 2004年の RDF 仕様書は「RDF グラフにおける URI参照」 (RDF URI参照)」を定義しています。それによると、 RDF URI参照とは、

です。百分率符号化の対象としては、

が挙げられています。

[81] 非文字や代理組の符号位置が認められているのかどうかは不明瞭です。

[82]

と RDF URI参照を比較すると、 使える文字の種類としては RFC 3987 の方が RDF の方の部分集合になっています。しかし、構文的には逆に、 RFC 3987 で認められている authority 中の百分率符号化が RFC 2396 ベースの RDF URI参照では認められていなかったりします。

[96] RDF に対する照会言語である SPARQL は、中途半端に RFC 3987 に切り替え、ややこしいことをやってくれています。詳しくは RDF URI参照の項を参照してください。

DOM URI

[5] DOM水準3 では、中の人も相当困ったのでしょう、具体的な書式に言及することを諦めて、 抽象的な DOM URI を次の条件を満たすものとして定義しています。

  • 絶対識別子 (「絶対 URI」) は、 Web 上の資源を絶対的に識別する
  • 単純な文字列比較により絶対識別子は比較でき、他の等価性は DOM では扱わない
  • 相対識別子 (「相対 URI」) は簡単に判別可能かつある絶対識別子に対して絶対にできる
  • 資源の内容の取り出しは必要な時に行ってもよい

そして、一般に DOM 内では特定の書式を想定した処理はせず、 相対識別子の解決や内容の取り出しで必要になった場合に限り、 関係する仕様書に従って処理することとされています。 関係する仕様書の例としては、 HTML 4.01・XML 1.0・XML名前空間 1.0 については RFC 2396、XML名前空間 1.1 第1版についてはその IRI が示されています。

XSLT URI 参照

[30] XSLT 2.0 勧告では「URI参照」を定義しています。 また、XPL 仕様案では、「URI参照」の定義を、(当時の) XSLT 2.0 の WD から借りたとして同じことを定義しています。 それによると、「URI参照」は、 XML Schema の anyURI データ型の字句空間に属する文字列です。

加えて、外部資源を識別する URI参照については、 XLink 1.0 5.4節 (>>8) と同じ規則に適合しなければならないとの制約が加わります。

また、相対参照を解決する場合は RFC 2396 (XPL) または RFC 3986 (XSLT) 

 URI参照に変換しなければならない旨が規定されています。

なお、 XPL の仕様書は、その規定・言及の仕方の範囲内では特に何の問題もないとは思いますが、 RFC 2396 を引用しているものの、 RFC 2732 には言及すらしていません。

[37] 単に XML Schema の anyURI を参照するとだけ述べずに、 なぜあえて字句空間に限定し、更に別に XLink を参照する規定を敢えて加えたのかはよくわかりませんが、 「外部参照の」という限定があることを考えると、外部参照以外の URI参照には XLink の規定を適用しない、という意図があるのでしょうか。そうだとしても、 結局 XML Schema の規定する字句空間内では違いが現れないと思うのですが。

なお、 XPL 仕様書の参考文献一覧では XML Schema の発行年が2000年になっていますが (リンクは最新版へ)、 XML Schema 第1版の勧告は2001年です。 2000年当時の CR では「anyURI」は規定されておらず、「uriReference」 という名前でした。この仕様書自体は2005年なので、そのような古い仕様案を引用する意味はなく、 単なる誤記かもしれません。 XSLT 2.0 は XML Schema 第2版を参照しています。

XPath URI

[38] XPath 2.0 本体仕様書と XQuery 1.0 and XPath 2.0 Functions and Operators では、「URI」 は RFC 3986 で定義されて RFC 3987 で IRI として拡張されているものを指すと定義しています。 「基底URI」等の複合語の「URI」を「IRI」に置き換えることによる混乱を防ぐ意図があると述べられています。

XQuery 1.0 and XPath 2.0 Functions and Operators では更に「URI参照」も定義しています。「URI参照」は XSLT 2.0 (>>30) と同じく、 XML Schema 第2版 anyURI (>>15) の字句空間とされています (ただし特に規定がない場合との限定付き)。 (XSLT 2.0 とは異なり、こちらでは XLink 仕様に基づく変換のような規定はありません。)

[85] このおかしな定義のため、 XPath 2.0 においては「URI」 が RFC 3986/RFC 3987 ベース、「URI参照」 が RFC 2396/RFC 2732 ベースになってしまっています。

[111] SMIL は用語「URI」について XPath 2.0 と同じような定義をしています。

[112] しかし、 clipBegin 属性の定義では、 本文では RFC 3987 を参照しながらも BNF 風構文では RFC 3986 を参照しており、矛盾しています。

[114] EMMA は用語「URI」について XPath 2.0 と同じような定義をしています。 しかし同じ定義中で「URI」は XML Schema (日付は第2版、リンク先は最新版) の anyURI (>>15) であるともしており、厳密には矛盾しています。

出典
PLS URI

[45] PLS 仕様書では、「URI」を WebArch 仕様書に示された大域識別子であって、 XML Schema 第2版の anyURI (>>15) である、としています。 その上で、 informative purposes only としながら RFC 3986 と RFC 2732 を有用だろうとして引用しています。 RFC 3987 にも言及しています。

[89] 単に XML Schema だけを引用しておけばいいところ、なぜ敢えて色々わけのわからないものを引用しているのかが謎です。 WebArch を引用する意味はわかりませんし、 RFC 2732 への参照も消し忘れでしょうが、そんなものが review を越えて勧告になるというのもおかしな話です。

SPARQL URI

[97] SPARQL の XML 直列化書式では、 URI-reference というデータ型が xs:anyURI として定義されています。 RDF URI参照との関係でややこしいこともしてくれてます。

詳しくは RDF URI参照の項を参照してください。

HTML5 URI

[107] HTML5 の以前の案では、同仕様書内では「URI」は IRI を含むと定義されていました。 実際には、仕様書内の多くの場所では「URI (or IRI)」という形で使われていました。 HTML5 の現在の案では URL (>>69) を使っており、このような「URI」 の用法はなくなっています。

XHTML URI

[90] XHTML m12n 1.0 勧告では属性型「URI」は RFC 2396 URI とされていました (「A Uniform Resource Identifier, as per [URI].」) が、 XHTML m12n 1.1 勧告では XML Schema anyURI (>>15、第2版勧告) (「A Uniform Resource Identifier Reference, as defined by the type anyURI in XMLSCHEMA.」) に変更されています。

ただし、 DTD 内の注釈にある説明は「[URI]」と書かれており、 参考文献リストによれば「[URI]」は RFC 3986 を指しています。

また、 XML Schema 内の URI や URIs というデータ型の定義も、 anyURI を参照しているにも関わらず、 XML の注釈として「[URI]」 という説明が含まれており、 やはり RFC 3986 を示唆しています。

[91] XHTML m12n 1.0 では HTML 4 を引きずっていたのか、「URI参照」 のつもりで「URI」といっているようです。
[94] XHTML m12n 1.1 にはスキーマの定義より本文の規定が優先しなければならない XHTML族モジュールの適合性に関する規定があります。 (XHTML m12n 1.1 が適合 XHTML族モジュールなのかどうかは知りません。)

[92] XML事象には URI (的なもの) を値とする属性として handler 属性が定義されています。

XML事象は XHTML m12n の流儀にのっとって語彙が定義されているのですが、

[93] なお、 引用されている XHTML m12n は参考文献の章では XHTML m12n 1.0 勧告になっているのですが、それが含まれる節は C.2.Other References です。その直前が C.1.Normative References なのですから、 常識的に考えれば C.2. は non-normative なのでしょうが、そんなことはどこにも書かれていません。 もし non-normative だとすると、 XHTML m12n の枠組みにのっとって定義されているかのように見える XML事象仕様ですが、その根本的な部分が怪しくなります。

もっとも、これが旧 HTML WG (現 XHTML2 WG) の標準的なクオリティーですから、 細かいことを気にしても仕方がないかもしれません。
atomURI

[106] AtomPub の RELAX NG スキーマ (参考) では、 IRI を値とする要素や属性のデータ型が atomURI とされています。 xml:base も atomURI とされています。 本文 (規定) によると、 AtomPub の当該要素・属性の値は RFC 3987 IRI (または IRI参照) です。

詳しくは atomURI の項を参照してください。

IRI・IRI 参照に近い意味で「URL」を定義している仕様
HTTP における URL

[47] RFC 2068 は HTTP/1.1 における URL を定義していますが、 RFC 1738 で認められていない ASCII 文字 (national) や 0x80 以上のオクテット (右半面) を使うことを認めていました。 (ただし、 0x80 以上のオクテットの解釈は明記されていません。)

HTTP の URL が鯖が解釈するのだから、相互運用性の問題はないといったような理屈でした。

これは RFC 2616 で修正され、 RFC 2396 に従うようになりました。

HTML 5 URL

[69] HTML 5 は URL の処理を定義しており、そこでは任意の文字列が URL として与えられた時にどう扱わなければならないかを規定しています。 更に、妥当なURL を定義しています。妥当なURL は RFC 3986 URI や RFC 3987 IRI の部分集合になっています。

[48] HTML 5 の中の人である Ian Hickson は、 HTML 5 に URL の規定を含めるにあたり、 ietf-uri の人達に Web のための URL の独立した仕様を作る気がないか問い合わせましたが、 彼らは自分達には関係のない問題だと拒否したため、 HTML 5 に含まれることになりました。

詳しくは URI5 や URL の項を参照してください。

その他
OOXML Unicode 文字列

[101] Open Packaging では、パッケージ・クライアントが Unicode文字列を部分名に解決する方法を規定しています。 部分名とは、 pack URI の path 部分を指します。仕様書の例によると、 「Unicode文字列」は例えば xs:anyURI データ型の値です。

Unicode文字列は、IRI、URI を経て部分名にと変換されます。詳しくは次の通りです。

  1. IRI に (と書いてあるが実際には IRI参照に): RFC 3986 で予約文字でも非予約文字でもない ASCII 文字を百分率符号化します。
  2. URI に (と書いてあるが実際には URI参照に): RFC 3987 3.1節の第2段階により URI に変換します。
  3. 部分名に: 得られた URI参照が URI であれば、通常通り解決します (RFC 3986 によるURI参照の解決を指す?)。そうでない場合、 URI参照は相対参照で、前処理の後、 RFC 3986 の方法で解決します。(相対参照の解決の項を参照してください。)

[102]

  • xs:anyURI であっても、 XML Schema の定義とは異なった方法で処理しなければならないようです。
  • 相対参照の解決の方法が異なるので、他の多くの「IRI のようなもの」より多くの文字列を URI に変換して処理可能です。
  • 第1段階が終わった時点では実は IRI参照になっていないこともあります (IRI で認められない非ASCII文字の処理をしていないので)。
  • なお、 ECMA 376 の第4部の各マーク付け言語の定義では URI らしきものを値にする属性は xs:string として定義されています。

  • ECMA 376 Part 2
    • Annex A. Resolving Unicode Strings to Part Names
メモ

[46] RFC 4622 は xmpp: URL の構文を定義しているのですが、 RFC 3986 や RFC 3987 で認められていない ASCII 文字を使うことを認めていました。 これは RFC 5122 で修正され、 RFC 3986 や RFC 3987 に従うようになりました。

[88] 他の仕様書で定義された IRI 参照や URI 参照に変換できるものなどを参照している規格はこの他に多々あります。 XML 系の規格は XLink 1.0 を、新し目の規格は xs:anyURI を参照する傾向にあります。 (xs:anyURI は XLink 1.0 を参照しています。)

[12] HTML 4 は参考でエラー処理として現在の IRI も処理できるといいよとしか言っていないのに、 HTML 4 は IRI に対応してるんだとかぬかす IRI 氏んじゃウゼー (名無しさん 2005-02-01 11:43:21 +00:00)

[98] James Clark's Random Thoughts: What's allowed in a URI? ( 版) <http://blog.jclark.com/2008/11/what-allowed-in-uri.html>

解説記事。

メモ

[44] draft-duerst-iri-bidi-00 - Internet Identifiers and Bidirectionality (2007-07-20 13:22:23 +09:00 版) <http://www.tools.ietf.org/html/draft-duerst-iri-bidi-00>

[14] Editing 'Internationalized Resource Identifiers' <http://www.w3.org/International/iri-edit/>

[43] Resuming editing of IRI spec towards Draft Standard (Martin Duerst 著, 2007-06-04 08:31:57 +09:00 版) <http://permalink.gmane.org/gmane.org.w3c.public-iri/130>

安全性, アクセス可能性, 可用性

[16] 似た形の文字: UCS には図形記号が似た文字(列)が極めて多く含まれています。 紛らわしくて困るというだけなら (それだけでも大問題ですが) まだしも、なりすましなどの安全上の問題にもなります。 RFC 3987 の仕様ではできるだけ NFC や NFKC を使うことを勧めていますが、従来の文字符号化方式との関係 (RFC 3987 は従来の文字符号化方式で IRI が記述されていたら NFC に変換することを求めていますが、 RFC 3987 の対象外の世界で従来の文字符号化方式から UTF-8 などに変換済みなら NFC でないかもしれません。 IRI を作る側も、ファイル名など NFC でない因子を持っているかもしれません。) や悪意のある者が必ずしもそれに従うとは限りません。

[17] 見えない文字: UCS には図形記号を持たない文字が多く含まれています。 例えば U+3000 (IDEOGRAPHIC SPACE) も IRI で使えます。 IRI のような文字列があった時にどこで終わるのかわからないので不便ですし、 IDSP と EMSP と ENSP が2つ並んでいるものは区別できなかったりします

(>>16 の問題)。

単に見えないだけではなく、何らかの意味を持った文字もあります。 PARAGRAPH SEPARATOR は段落境界を意味します。 IRI の途中で改段落などされると甚だ迷惑ではあるのですが、 仕様上は認められているようです。 悪意のある人は悪いことに使うかもしれません。

[18] 双方向性: RFC 3987 には bidi に関する規定があります。 要約すると、 Unicode の bidi 算法をそのまま使うというものです。 最近の色々な規格 (例えば CSS) は全面的に Unicode の bidi 算法を採用しているので IRI の部分だけ他の算法を採用するというのは非現実的ではありますが、 Unicode の bidi 算法は普通の文章を主に想定しているので、 記号を普通の文章とは違う特別な意味で使っている IRI では予期せぬことが起こります (RFC 3987//6 にわずかながら例があります)。

IRI の途中で直感とは異なる形で表示上の場所が入れ替わるのは実用上大きな問題ですが、 なりすましの安全上の問題もかかえています。

相互運用性

[20] IRI が規格化される前から、色々な実装で URI が使える場所に URI で使えない文字があっても処理できるようになっていました。 しかし、その取扱い (利用者への提示の仕方や文字符号化方式など) は実装によりばらばらで、ある実装で動くように見えるものが別の実装では動かないといった問題が多発していました。

IRI が標準化されたことで長期的に見れば問題は減少に向かうでしょうが、 URI ではない IRI が積極的に使われるようになると短期的には問題が以前よりも多く発生するようになると思われます。

[21] IRI が標準化されたとはいえ、従来 URI を使ってきた規格がすべて IRI に移行するわけではありません。 以前の実装やデータとの互換性の問題がありますから、 即座に移行するものはないと言っても過言ではないでしょう。

URI しか使えない場所に無理矢理 IRI を使おうとするのは問題を複雑にするだけであり、 著者・情報提供者の自己満足以上のものは得られません。

[34] Bug 261929 - Consider sending urls in UTF-8 by default (images/links with non-ASCII chacters not displayed) <https://bugzilla.mozilla.org/show_bug.cgi?id=261929>

メモ

[36] 電子メール本文中の日本語ドメイン名URLをクリックできるようにするには - 日本語.jp (2006-11-29 16:15:15 +09:00 版) <http://nihongojp.jp/support/mail_guide/> (名無しさん 2006-12-29 07:19:52 +00:00)

[41] Amazon日本語URL時代における書籍名の新常識 - 坂本多聞のインサイドアウト (2007-06-09 23:47:23 +09:00 版) <http://rblog-ent.japan.cnet.com/tamon/2007/04/amazonurl_7390.html> (名無しさん 2007-06-09 14:49:43 +00:00)

[42] WordPressカスタマイズメモ【企業ホームページ制作方法】: SEO対策にはUTF-8(文字コード) (2007-06-07 13:21:14 +09:00 版) <http://wordpress.seesaa.net/article/35406256.html> (名無しさん 2007-06-09 14:50:32 +00:00)

[117] IRC logs: freenode / #whatwg / 20090917 ( 版) <http://krijnhoetmer.nl/irc-logs/whatwg/20090917>

Updated: