IRIもどき

Edit New

IRI (URL)

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

[173] に一旦 RFC となった後、 XML との互換性のために LEIRI を追加し、 Webとの互換性のために HTML5 における URI の定義に近いものを追加するなどした改訂版の作業が行われていましたが、 IETF 内外からの関心を得られず、2013年1月に IETF の IRI WG は閉鎖されました。これにかわって URL Standard が WHATWG Living Standard となっています。

[200] 本項は過去の URL 仕様に関するものです。本項の内容は当時の状況を説明したもので、 現状とは異なることがあります。最新の URL 仕様については URL Standard を参照してください。

代替

[231] 新しい仕様および実装は、 URL Standard で定められた URL を使うべきです。

仕様

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

[176] 改訂作業が中止される前の最後の Internet Draft は draft-ietf-iri-3987bis-13 で、2012年10月に発行されました。

[177] なお、 URL の現行仕様は URL Standard です。詳しくはそちらの項をご覧ください。

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)。

XTM 2.0 IRI に変換されるもの

[104] XTM 2.0 (ISO/IEC 13250-3) は、 href 属性値を本文では RFC 3987 IRI参照としています >>195。しかしながら、 RELAX NG スキーマ (規定、引用規格の版は明示せず。) と XML Schema スキーマ (参考、引用規格に含まれず。) では xs:anyURI としています。

[197] IRI参照と xs:anyURI の差異には言及がありません。

[196] 更に次のような不思議な規定も含んでいます。 href 属性値から IRI を得るためには、まずパーセント符号化を復号し、 UTF-8 バイト列から文字列を得て、文書の IRI に対して解決して絶対IRIを得ます >>195。

[198] UTF-8 として復号できない場合やパーセント符号化されていない非ASCII文字が既に含まれている場合の処理には言及がありません。
[199] IRI の解決の方法にも言及がありません。敢えて復号しているからには、 RFC 3987 が想定しているような URI に変換してからの解決ではないと思いますが。。。

「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]

HTMLにおけるURLも参照。

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 の間で実質的な変更はありません。
[149] XML Schema にもシステム識別子がありますが、こちらは xs:anyURI とされています。

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資源識別子」という言葉が一切出てきません。

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参照」の意味だということになってます。

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参照の違いに無頓着なようです。
最終版の anyURI について

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 の当該部分は後に分割された別の単独の仕様書に移動しています (>>180)。 しかしながら、その仕様書は CR に達した後、放置されているようです。 (実質的な内容は変化していません。)

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

W3C Charmod

[181] W3C Charmod は、 >>182 のようにURI参照から IRI参照への読み替え(?)を適合する仕様書に対して求めています。

[184] 「部分集合」を認めているので、ただの URI しか認めていなくても >>182 に適合しちゃうんですけど、 この規定の趣旨的にそれでいいのでしょうか。。。

[183] その他いくつか IRI に関する要件を定義しています。

[188] なお Charmod が参照しているのは RFC 3987 になる前の I-D です。

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 本体仕様書 >>130, >>129 と XQuery 1.0 and XPath 2.0 Functions and Operators >>125, >>124、 XDM >>122、XQuery 1.0 >>123 では、「URI」 は RFC 3986 で定義されて RFC 3987 で IRI として拡張されているものを指すと定義しています。 「基底URI」等の複合語の「URI」を「IRI」に置き換えることによる混乱を防ぐ意図があると述べられています。

XQuery 1.0 and XPath 2.0 Functions and Operators >>125, >>124 では更に「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) であるともしており、厳密には矛盾しています。

[143] InkML は用語「URI」について XPath 2.0 と同じような定義をしています。 しかし実際に URL を使える場所ではデータ型として XML Schema の xs:anyURI を使っています >>142。

[171] なお XPath の関数 resolve-uri() の定義では、 RFC 3986 と RFC 3987 IRI参照を参照しつつも、返す値は xs:anyURI であり、 しかも LEIRI参照 (>>116) として実装しても良いとされています。

出典

Voice Browser 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 を越えて勧告になるというのもおかしな話です。

[119] SSML 1.1 は >>45 とまったく同じ定義をしています。

CCXML URI

[136] CCXML 処理器は RFC 3986 URI が認められている場所で RFC 3987 IRI を認めなければならないとされています。

[138] しかし著者が URI でない IRI を使っても良いとは書かれていません。

[139] XML Schema データ型では、本文中で URI と説明されている属性の一部は XML Schema anyURI とされています。

といっても多くの属性は ECMAScript 式として一旦評価されるので、 XML Schema 上にはデータ型として現れないことが多いです。

SPARQL URI

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

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

[155] SPARQL の URI() 関数は IRI() 関数の別名です。 RFC 3987 URI を表します。 >>154

GRDDL

[164] GRDDL 仕様書は正確な記述では「IRI」という用語を使い、説明では「URI」を使うものの、 両者は同じ意味 (RFC 3987 IRI) であるとしています >>163。ただし「base IRI」 「absolute URI」のような形で両者が混在し、却って混乱を招くようにも思えます。 なお HTML4、RDF、XML Schema に倣って IRI を使うと書いてありますが、 そのいずれも「IRI」は使っていませんw

HTML5 URI

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

[153] XBL2 も同じ定義でした (>>165、>>152)。

XHTML1 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) の標準的なクオリティーですから、 細かいことを気にしても仕方がないかもしれません。

XHTML2 URI

[131] XFrames は抽象モジュールの定義においてデータ型「URI」 のリンク先を XHTML2 の「URI」の定義にしています。 >>132

[133] また本文で「URI」は RFC 3987 IRI のことであるとしています。 >>132

例によって「IRI参照」ではなく「IRI」となっています。

[134] xml:base 属性のデータ型も「URI」になっています。 >>132

atomURI

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

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

MathML における URI

[120] MathML では URI は RFC 3986 URI を指すもの定義されていますが、その定義に「Note that」と続けて、 スキーマにおいては anyURI となっていて、 任意の XML 文字の連続が認められている、としています (この解釈は正しくないと思います)。更に、 百分率符号化によって URI を得る方法について軽く述べると共に、 IRI と LEIRI として解釈され得るのだとして RFC 3987 と draft-duerst-iri-bis-07 を参照しています (後者は改訂案として挙げられている程度の扱いのようです)。

出典

URI = XML Schema 1.1 xs:anyURI

[144] Media Ontology においては「URI」は RFC 3987 IRI のことを表すとされています。 またその定義は XML Schema 1.1 xs:anyURI (>>79) とされています >>145。

[146] XML Schema 1.1 における xs:anyURI は RFC 3987 またはその改訂版の IRI参照のことなので、一応定義は整合しています。

出典

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 の項を参照してください。

JSON-LD URL

[147] JSON-LD のデータ型「URL」は RFC 3987 IRI を表します >>148。

その他

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

URI への変換

[201] RFC 3987 IRI は RFC 3986 URI の文字を拡張したものと規定されているため、 RFC 3987 IRI から RFC 3986 URI への変換方法を定義しています。

これはパーセント符号化演算の一種といえます。

[202] この変換方法は、入力の与え方やドメイン名の処理方法に自由度があり、 利用する場面によって選択できるようになっています。

[203] 証明書の uniformResourceIdentifier では、 RFC 3987 が規定する方法からオプションを選択したプロファイルを定義し >>204、 これを使うことを要求しています。

セキュリティその他

[16] URL 参照。

相互運用性

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

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

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

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

[206] IRI のようなものは、先述の通り、 XML 関連仕様の数だけあります。 ということは複数の仕様を実装すると IRI のようなものも複数種類実装しないといけないことになります。 中には定義が相互に矛盾するものもあるので、実装不可能な組み合わせもあるかもしれません。 あるいは同じ仕様でも改訂により微妙に非互換に改められているかもしれません。

[207] そんな状況でとても相互運用性が保たれているとは思えないので、 きっと各実装がそれぞれ思う IRI のようなものを使っていて (あるいは採用しているライブラリーがたまたま実装していたものを使っていて)、 どの仕様書も有名無実状態なのではないかと推測されます。

[208] XML 系の仕様の多くは「正しくない」入力の処理は実装依存とする方針なので、 そのような雑な実装方法でも、「正しい」入力はどの実装でもわりと「正しく」 処理でき、「正しくない」入力はどうでも良いので総合的に適合していると言える、 かもしれません。 (もっとも、そのような仕様書解釈学的な正しさと、実世界の相互運用性はまったく別問題ですが...)

更に言えば、先述のような状況ですから、何が「正しい」入力で何がそうでないのかを判定すること自体も相当に困難だと思いますが...

[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

自動リンクとの関係

URL自動リンク

レンダリング

URLの表示

印刷との関係

URLの印刷

メモ

[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

[127] XQuery 1.0 and XPath 2.0 Functions and Operators (Second Edition) ( ( 版)) http://www.w3.org/TR/2010/REC-xpath-functions-20101214/#func-iri-to-uri

[128] XQuery 1.0 and XPath 2.0 Functions and Operators (Second Edition) ( ( 版)) http://www.w3.org/TR/2010/REC-xpath-functions-20101214/#func-escape-html-uri

[135] design team notes ( (Peter Saint-Andre 著, 版)) http://lists.w3.org/Archives/Public/public-iri/2011Apr/0043.html

[140] draft-weber-iri-guidelines-01 - Guidelines for Implementers of Internationalized Resource Identifiers (IRIs) ( ( 版)) http://tools.ietf.org/html/draft-weber-iri-guidelines-01

[141] Basic Data Types and Interfaces – SVG 1.1 (Second Edition) ( ( 版)) http://www.w3.org/TR/2011/REC-SVG11-20110816/types.html#DataTypeIRI

[150] draft-ietf-iri-3987bis-13 - Internationalized Resource Identifiers (IRIs) ( ( 版)) http://tools.ietf.org/html/draft-ietf-iri-3987bis-13

[151] Packaged Web Apps (Widgets) - Packaging and XML Configuration (Second Edition) ( ( 版)) http://w3c.github.com/packed-webapps/packaging/#iri-attribute

[156] IRI working group shutdown ( (Pete Resnick 著, 版)) http://lists.w3.org/Archives/Public/public-iri/2013Jan/0009.html

[157] RE: fate of IRI working group in IETF ( (Larry Masinter 著, 版)) http://lists.w3.org/Archives/Public/public-iri/2013Jan/0006.html

[158] IRI minutes from IETF 85 ( (Peter Saint-Andre 著, 版)) http://lists.w3.org/Archives/Public/public-iri/2013Jan/0000.html

[159] IRI minutes from IETF 85 ( (Peter Saint-Andre 著, 版)) http://lists.w3.org/Archives/Public/public-iri/2013Jan/0000.html

[160] draft-ietf-iri-bidi-guidelines-03 - Guidelines for Internationalized Resource Identifiers with Bi- directional Characters (Bidi IRIs) ( ( 版)) http://tools.ietf.org/html/draft-ietf-iri-bidi-guidelines-03

[161] draft-ietf-iri-comparison-02 - Comparison, Equivalence and Canonicalization of Internationalized Resource Identifiers ( ( 版)) http://tools.ietf.org/html/draft-ietf-iri-comparison-02

[162] RDFa Core 1.1 - Second Edition ( ( 版)) http://www.w3.org/TR/rdfa-core/#h3_s_curieprocessing

[178] IDNA, IRIs, and ://..../ authority field ( (Larry Masinter 著, 版)) http://lists.w3.org/Archives/Public/www-archive/2014Apr/0014.html

[179] IRIStatus - Internationalization ( ( 版)) https://www.w3.org/International/wiki/IRIStatus

[189] Internationalization Tag Set (ITS) Version 2.0 ( ( 版)) http://www.w3.org/TR/its20/#conversion-to-nif

[190] 42899 – (iri) IRI support (RFC 3987) ( ( 版)) https://bugzilla.mozilla.org/show_bug.cgi?id=42899

[191] Re: Working Group Decision on ISSUE-56 urls-webarch (correction) ( (Sam Ruby 著, 版)) http://lists.w3.org/Archives/Public/public-html/2011Mar/0404.html

[192] Re: [whatwg] [url] Feedback from TPAC ( (Sam Ruby 著, 版)) http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Nov/0010.html

[23] OASIS Open Document Format for Office Applications (OpenDocument) Version 1.2 - Part 1: OpenDocument Schema ( 版) http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#a18_3_2anyIRI

anyIRI

An IRI-reference as defined in [RFC3987], expressed in an [xmlschema-2] anyURI.

Note: The procedure for resolution of anyIRI values that are not IRI values is undefined.

[205] RFC 5122 - Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP) ( 版) https://tools.ietf.org/html/rfc5122

However, the foregoing syntax is not appropriate for inclusion in the registration of the xmpp URI scheme, since the IANA recognizes only URI schemes and not IRI schemes. Therefore, the ABNF syntax for an XMPP URI rather than for IRI is defined as shown in Section 3.3 of this document.

[209] GNU Wget 1.17.1 Manual: Download Options ( ()) https://www.gnu.org/software/wget/manual/html_node/Download-Options.html

‘--no-iri’

Turn off internationalized URI (IRI) support. Use ‘--iri’ to turn it on. IRI support is activated by default.

You can set the default state of IRI support using the iri command in .wgetrc. That setting may be overridden from the command line.

‘--local-encoding=encoding’

Force Wget to use encoding as the default system encoding. That affects how Wget converts URLs specified as arguments from locale to UTF-8 for IRI support.

Wget use the function nl_langinfo() and then the CHARSET environment variable to get the locale. If it fails, ASCII is used.

You can set the default local encoding using the local_encoding command in .wgetrc. That setting may be overridden from the command line.

‘--remote-encoding=encoding’

Force Wget to use encoding as the default remote server encoding. That affects how Wget converts URIs found in files from remote encoding to UTF-8 during a recursive fetch. This options is only useful for IRI support, for the interpretation of non-ASCII characters.

For HTTP, remote encoding can be found in HTTP Content-Type header and in HTML Content-Type http-equiv meta tag.

You can set the default encoding using the remoteencoding command in .wgetrc. That setting may be overridden from the command line.

[210] Model is defined in terms of IRIs; Protocol with URI · Issue #241 · w3c/web-annotation ( ()) https://github.com/w3c/web-annotation/issues/241

[211] 284474 – Converting to UTF-8 a url with an unescaped non-ASCII chars in the query part leads to an incompatibility with most server-side programs ( ()) https://bugzilla.mozilla.org/show_bug.cgi?id=284474

[212] XML-binary Optimized Packaging () https://www.w3.org/TR/xop10/

A [normalized value] which is a representation of a URI (see [RFC 2396] as amended by [RFC 2732]) referencing the part of the package containing the data logically included by the [owner element] (i.e., the xop:Include element information item). The [normalized value] MUST be a valid URI per the cid: URI scheme (see [RFC 2392]). In addition, the [normalized value] MUST be a valid lexical form of the XML Schema xs:anyURI datatype (see [XML Schema Part 2: Datatypes Second Edition]3.2.17 anyURI).

[17] Web Annotation Data Model () https://w3c.github.io/web-annotation/model/wd2/

[18] Web Annotation Vocabulary () https://w3c.github.io/web-annotation/vocab/wd/#dfn-iri

[213] Web Annotation Vocabulary () https://w3c.github.io/web-annotation/vocab/wd/#dfn-iri

NOTE

RDF [rdf-concepts] is fully internationalized and permits the use of IRIs for identifying resources. This specification uses the term IRI to make it clear that this is the case.

[214] Web Annotation Protocol () https://w3c.github.io/web-annotation/protocol/wd/#h-terminology

[215] Selectors and States () https://w3c.github.io/web-annotation/selector-note/#dfn-iri

[216] XQuery 3.1: An XML Query Language () https://www.w3.org/TR/2017/REC-xquery-31-20170321/#dt-URI

Within this specification, the term URI refers to a Universal Resource Identifier as defined in [RFC3986] and extended in [RFC3987] with the new name IRI.

[217] XML Path Language (XPath) 3.1 () https://www.w3.org/TR/2017/REC-xpath-31-20170321/#dt-URI

Within this specification, the term URI refers to a Universal Resource Identifier as defined in [RFC3986] and extended in [RFC3987] with the new name IRI.

[218] XQuery and XPath Data Model 3.1 () https://www.w3.org/TR/2017/REC-xpath-datamodel-31-20170321/#terminology

Within this specification, the term URI refers to a Uniform Resource Identifier as defined in [RFC 3986] and extended in [RFC 3987] with the new name IRI.

[219] XPath and XQuery Functions and Operators 3.1 () https://www.w3.org/TR/2017/REC-xpath-functions-31-20170321/#dt-uri

Within this specification, the term URI refers to Universal Resource Identifiers as defined in [RFC 3986] and extended in [RFC 3987] with a new name IRI. The term URI Reference, unless otherwise stated, refers to a string in the lexical space of the xs:anyURI datatype as defined in [XML Schema Part 2: Datatypes Second Edition].

Note:

Note that this means, in practice, that where this specification requires a "URI Reference", an IRI as defined in [RFC 3987] will be accepted, provided that other relevant specifications also permit an IRI. The term URI has been retained in preference to IRI to avoid introducing new names for concepts such as "Base URI" that are defined or referenced across the whole family of XML specifications. Note also that the definition of xs:anyURI is a wider definition than the definition in [RFC 3987]; for example it does not require non-ASCII characters to be escaped.

[220] XPath and XQuery Functions and Operators 3.1 () https://www.w3.org/TR/2017/REC-xpath-functions-31-20170321/#func-iri-to-uri

[221] R2RML: RDB to RDF Mapping Language ( ()) https://www.w3.org/TR/2012/REC-r2rml-20120927/#dfn-iri

IRI (corresponds to the Concepts and Abstract Syntax term RDF URI reference)

[222] A Direct Mapping of Relational Data to RDF ( ()) https://www.w3.org/TR/2012/REC-rdb-direct-mapping-20120927/#RDF-IRI

[33] IRI ::= RDF URI-reference as subsequently restricted by SPARQL

[223] RFC 5070 - The Incident Object Description Exchange Format () https://tools.ietf.org/html/rfc5070#section-2.15

A uniform resource locator (URL) is represented by the URL data type.

The format of the URL data type is documented in RFC 2396 [8].

The URL data type is implemented as an "xs:anyURI" in the schema.

[224] RFC 7970 - The Incident Object Description Exchange Format Version 2 () https://tools.ietf.org/html/rfc7970#section-2.13

A uniform resource locator (URL) is represented in the information

model by the URL data type. The format of the URL data type is

documented in [RFC3986].

The URL data type is implemented as an "xs:anyURI" type per

Section 3.2.17 of [W3C.SCHEMA.DTYPES].

[225] XSL Transformations (XSLT) Version 3.0 () https://www.w3.org/TR/2017/REC-xslt-30-20170608/#uri-references

Within this specification, the term URI Reference, unless otherwise stated, refers to a string in the lexical space of the xs:anyURI datatype as defined in [XML Schema Part 2].

[226] RIF Datatypes and Built-Ins 1.0 (Second Edition) () https://www.w3.org/TR/2013/REC-rif-dtb-20130205/#rif-iri-space

rif:iri (http://www.w3.org/2007/rif#iri), for internationalized resource identifiers or IRIs.

Constants in the rif:iri symbol space are intended to be used in a way similar to RDF resources [RDF-SCHEMA]. The lexical space consists of all absolute IRIs as specified in [RFC-3987]; it is unrelated to the XML primitive type xs:anyURI.

[227] DBpedia - Wikipedia Data Extraction / Re: [DBpedia-discussion] Invalid URIs with asian characters () https://sourceforge.net/p/dbpedia/mailman/message/36502187/

> org.apache.jena.riot.RiotException: [line: 146, col: 35] Bad IRI:

> http://ja.dbpedia.org/resource/ティム・バーナーズ=リー; Code: 47/NOT_NFKC in

> PATH: The IRI is not in Unicode Normal Form KC.

[228] Akoma Ntoso Naming Convention Version 1.0 () https://docs.oasis-open.org/legaldocml/akn-nc/v1.0/os/akn-nc-v1.0-os.html#_Toc409028138

A global IRI reference is a relative IRI reference where all parts are present except for protocol and authority (i.e., domain name). Thus, a global IRI reference always starts with a slash, to indicate that all other parts are explicitly specified. A local IRI reference, on the other hand, may have one or more parts missing (necessarily from left to right), and the corresponding global (and, subsequently, absolute) IRI reference is determined by adding the corresponding parts taken from the base document, as usual with relative IRI references with missing parts. In the following we will call all IRI references as simply IRI (they are all references, after all), and distinguish between absolute IRIs, global IRIs and local IRIs.

[229] Akoma Ntoso Naming Convention Version 1.0 () https://docs.oasis-open.org/legaldocml/akn-nc/v1.0/os/akn-nc-v1.0-os.html#_Toc478138472

–      A pair of eIds of the first and last elements of the sequence of parts being requested, separated by a dash “->“.

· [http://www.authority.org]/akn/eu/act/2003-11-13/87/eng@2015-01-20/~art_3->art_5

[230] GNU Wget 1.20 Manual () https://www.gnu.org/software/wget/manual/wget.html#index-idn-support

Updated: