[405] 本項では、 XML名前空間や RDF における名前空間URL (名前空間URI / 名前空間名) の管理について扱います。
[5] XML名前空間や RDF などで使用する名前空間 URI を選ぶ際には、幾つか注意するべきことがあります。
[28] RFC 3986 (URI の一般構文) をはじめとする関連仕様に照らして正しい URI 参照を使うことは大前提です。
メモ: XML名前空間を含めて名前空間 URI を使う仕様の多くは、 実装が名前空間 URI の URI としての正しさを検証することを義務付けていません。 しかし、だからといって URI 参照として正しくないものを名前空間 URI として使うことの理由にはなりません。 (実装が正しさを検証することは義務ではありませんが、 正しくないものを扱えることも義務ではありません。)
[22] 元々 XML名前空間 1.0 ではどんな URI 参照も名前空間名として認めていました (長さ0の文字列を除きます)。しかし、 相対URI参照は解釈が一意に定まらない (文脈に依存する) ことから、使用しないことが望ましいと考えられるようになりました。 名前空間を扱う多くの仕様や実装では、 絶対 URI 参照でないものの取り扱いは未定義とするか、 まったく使用を認めていません。ですから、 名前空間 URI として絶対 URI 参照を使用することが実用上必須です。
参考: XML 総会の決議 W3C XML Plenary Ballot on URIs and Namespaces <http://www.w3.org/2000/09/xppa>
[6] 名前空間 URI は、必ず自分が使用権のあるものでなければなりません。 これは、過去・現在・未来に他の人が使うかもしれない名前空間 URI と衝突してしまうことを防ぐために非常に重要です。
[7] もしどこかの Webサイトを管理しているのなら、 一番手軽なのはその Web サイトに属する URI を使うことです。
たとえば John は http://www.example.org/john/ で始まる URI の Web 頁群を管理しているとしましょう。 www.example.org 全体の管理者が変態的な趣味を持っていなければ、 あるいは John が妙にお人よしで他の人に貸してあげていなければ、 http://www.example.org/john/2004/ns1/ という URI を使う権利を John は持っています。 ですから John はこれを名前空間 URI にできます。
しかし、 http://www.example.org/mike/2004/ns1/ までは John の管理権が行き届きません。これを名前空間 URI にしたいときには、まず Mike のご機嫌をうかがうことにしたほうが身のためです。
[8] 別の方法は、メイル・アドレスです。たとえば mailto:john@example.org?subject=2004-ns1 とします。 Web サイトは持っていなくてもメイル・アドレスを持っている人には有効な方法です。
ただしこの方法の大きな欠点が2つあります。 一つは、そのアドレスの使用権がいつまでも自分にあるとは限らないこと。 これは名前に西暦年を入れることで気休め程度には衝突の虞を回避できます。
もう一つは、 mailto:
URI の性質上、
安全な文字が少ないことです。 mailto:
URI
で使える文字は URI の制限と RFC 822
の制限の二重の制限を受けます。しかも mailto:
URI の仕様書は曖昧なので、安全に使えるのはアルファベットや数字やハイフン程度と考えておいたほうがよいでしょう
(しかしほとんどの場合はこれで十分のはずです)。
[21] 大域固有でない URI についての注意:
URI のすべてが大域的に固有ではありません。
例えば、 file:
URI scheme
は環境によって指すものが違います。
そのような URI を名前空間 URI に使用すると、
衝突を防ぐという本来の目的が達成できません。
大域的に固有でない URI を名前空間名に使用するべきではありません。
[11] urn:
URI scheme についての注意:
伝統的に名前空間 URI によく使われてきた URI scheme
に urn: URI があります。
もし urn: URI を名前空間に使いたいのであれば、
URN NID が正当なものであるかを確認してください。
URN NID (urn: の直後に来る部分) は IANA
に登録されたものか、 x- で始まるものしか使ってはいけません。
[12] 他人の考案した概念に URI を割当てる時の注意: 自分以外の人の考えた概念を取り入れる時に、 (許可なく) 自分が正当な使用権のない URI まで使ってしまわないように注意してください。
例えば、 RFC 2822 で定義された電子メイルの頭欄の語彙を XML で使いたいので、 XML 名前空間を作るとします。 そのときに、 Subject: 欄に対応する XML 要素の名前空間を urn:ietf:rfc:2822 としたくなるかもしれません。
確かに、その Subject という語彙は urn:ietf:rfc:2822 という文書で定義されているものなのですから、 これは適当な態度に思えます。しかし、 urn:ietf:rfc:2822 という名前の使用権を持つのは IETF であり、 その使い方を勝手に第三者が決めるべきではありません。 第三者が urn:ietf:rfc:2822 に勝手に意味を与えた後で、 IETF がそれに気づかずに別な意味を urn:ietf:rfc:2822 に与えてしまったら、困ったことになります。 (そうなる前に IETF が気づいたとしても、 IETF にとってはいい迷惑です。)
[9] 新しく作ろうとしている名前空間に重要な意味を持たせたいのだとしたら、 その名前をいつまでも使えるように保つことは極めて重要です。 さして重要ではないことに名前空間を使おうとしている場合であっても、 注意深く名前を選んで悪いことはありません。 一般的に言って、設計者がすぐに廃れるだろうと思ったものほど長生きします。
[10] 名前が使えなくなる状況は、おおよそ次の2つに集約できるでしょう。
[12] 例えば John は http://www.example.org/john/ns1/ という名前空間を使っていたとします。しかしその後 John は Example Organization から退会しました。それと同時に John が http://www.example.org/john/ で始まる URI の使用権を喪失したとするとどうでしょう。
Example Organization が大らかな組織であれば、 それ以後も http://www.example.org/john/ns1/ を使い続けたとしても、何の問題もないかもしれません。 そうでなかったとしたら、たとえば商標の問題などが起こるかもしれません。
別の可能性として、後から入会した別の John さんが http://www.example.org/john/ns1/ という名前を他の用途に使ってしまうかもしれません。
[13] 対策は、
などでしょう。後者の方法で、 http://www.example.org/john/ns1/ を http://www.example.org/john/2004/ns1/ とするだけでも、衝突の危険性はかなり下がるはずです。
年月日を URI に含めることは、他人との衝突だけではなく、 自分が以前に使った名前との衝突も防ぐことができます。
[14] ISP や無料鯖サービスの提供する Web サイト領域は、いつ名前が変わったり、サービスが中止されたりするかわかりません。 大学などのアカウントも、卒業後に消されてしまうことが多いです。 そのような URI を名前空間 URI に使うことは極力避けるべきです。
長く利用できそうな URI を持っていない場合は、 PURL のようなサービスを利用するのが便利です。
グループで多くの名前空間 URI を使う予定があるなら、 urn: URI を使うのも手です。ただし x- を使わない正式の NID を得るためには敷居が高いのが難点です。
[15] 名前空間 URI として http: URI のような取出しが定義されている URI scheme に沿ったものを選んだ場合は特に、 その URI を使って名前空間を定義する文書が得られるように設定しておくことが望ましいと考えられます。
たとえば、 http://www.example.org/john/2004/ns1/ という名前空間 URI を使うのであれば、 http://www.example.org/john/2004/ns1/ にはその名前空間を説明した文書を置いておくべきです。
文書は、人間可読なものであっても、 XML Schema や DTD や RDF Schema などのような機械可読なものであっても、 仕様書へのリンクだけであっても構いませんが、 とにかく何か情報があることが重要です。 http: URI なのに 404 であるとか、そもそも鯖が存在しないとかは論外です (が何も考えていない標準化団体や企業でそういうことをしているところが複数あります)。
文書が用意されていれば、その名前空間 URI を見た人が必要な情報を得ることができますし、 名前空間 URI の管理者にとっても、 後からうっかり別の目的に使ってしまう危険性が減ります。
[16] XML名前空間では名前は名前空間名 (URI) と局所名の組ですが、 RDF や WebDAV など他の幾つかの規格では名前空間 URI と局所名を連結して一つの URI 参照として扱います。
http://www.example.org/john/2004/ns のような「普通」の文字で終わる名前空間 URI を使うと、 そのような規格を使った時に、 http://www.example.org/john/2004/nslocal-name のように不恰好な URI となります。ですから、名前空間 URI の最後には http://www.example.org/john/2004/ns/ や http://www.example.org/john/2004/ns# のように記号をつけると良いでしょう。
関連: >>23
[17] URI参照で使える文字は決まっています。 どんな文字でも自由に使えるわけではありません。 また、 URI 参照一般では認められていても、 個々の URI scheme の制限により使えない文字・文字列もあります。
名前空間 URI はその scheme の仕様に沿った正しい URI 参照としましょう。 正しくない URI 参照を名前空間として使うことは、 自分が無知であることを宣伝するようなものであると共に、 他人にも規格違反を要求することにもなりかねません。
[18] XML名前空間 1.1 では URI 参照の代わりに、 その超集合である IRI参照を使っています。 しかし相互運用性を考えれば、 URI 参照を使うべきです。 (XML 名前空間 1.1 仕様書にもそう書いてあります。)
[19] URI で認められている文字であっても、 使わない方が安全な文字があります。
~ は、 URI で使うことが認められた文字です。
しかし、シフトJIS の 0x7E
の問題 (TILDE vs OVER LINE)
によって不都合が実際に生じています。
うまく回避できる方法がある場面もありますが、
いつも回避できる保証はないので、避けるほうが無難です。
(名前空間 URI は文字として一致検査されるので、 URI符号化で %7E
と書き変えてしまうと、別の名前空間 URI になってしまいます。)
[23] NUMBER SIGN
:
素片識別子の始まりを示す #
は >>16 のため名前空間URI
の最後につけられることが多いですが、 XPointer
で使われることが多いと想定される名前空間では避けた方がよいです。
素片識別子として使う XPointer の中に
#
(を含む名前空間 URI) が含まれていると、
その #
を %23
と百分率符号化する必要が生じるからです。
[25] 例: ある文書で使われている語彙の名前空間 URI は
http://www.example.com/vocab#
だとします。ここで、 XML文書 http://www.example.net/document が
<document xmlns="http://www.example.com/vocab#"> <content/> </document>
という内容であるとき、 content
要素を識別する XPointer (の一例) は
xmlns(x=http://www.example.com/vocab#)xpointer(/x:document/x:content)
となります。この XPointer を素片識別子とする URI参照は、
http://www.example.net/document#xmlns(x=http://www.example.com/vocab%23)xpointer(/x:document/x:content)
となります。 #
が %23
となっていることに注意してください。
[30]
AMPERSAND
:
アンド記号 (&
) は一般の URI で
(特に照会で) しばしば使われますが、 XML
で &
を記述する時は &
と逃避しなければなりません。
名前空間 URI を何度も XML 文書中に手入力する必要があるなら、
面倒でうっかりしてしまいがちですから、 &
を使うのは避けるべきです。
(名無しさん [sage])
[31]
APOSTIROHE
:
アポストロフィ ('
) は URI
で使うことができる文字ですが、属性値表記の引用符としても使われます。
不要な混乱を避けるために '
を名前空間 URI で使うのは避けるべきです。
(名無しさん [sage])
[26] 一般論として、似たような URI が他に使われていると混乱の元です。 似たような URI が名前空間 URI としても使われるのならなおさらです。
似ている
の基準は色々ありえますし、主観的なことでもあるので、
一概には言えませんが、
特に大文字・小文字だけの違いや記号類の有無や記号類だけの違いは気付きにくいので避けた方が良いです。
悪い例: XHTML 2.0 の古い案では名前空間 URI は
http://www.w3.org/2002/06/xhtml2
でした。
後の案で
http://www.w3.org/2002/06/xhtml2/
に変わりました。 (最後に斜線が付いています。)
悪い例: 株式会社単奈留玲の技術者であるトムは ABC 2004
という製品で使う名前空間 URI を
http://ns.example.com/abc-2004
としました。単奈留玲は翌年新版の ABC 2005
を出荷しましたが、トムに代わって設計を担当したジョンは
http://ns.example.com/abc/2005
という名前空間 URI にしました。
[27] Java で使う場合:
JSR#31 (JAXB 1.0) の C.5.1 で名前空間 URI
から Java のパッケージ名への変換方法が規定されています。
簡単に言えば、大文字は小文字になり、 /
と :
は .
になり、それ以外の記号類は
_
になります。ですから、
大文字・小文字や記号類だけが異なる名前空間 URI を使うのは避けた方が良いです。
[4] URIs for W3C Namespaces <http://www.w3.org/1999/10/nsuri>
この文書では、 W3C の仕様で使われる名前空間 URI の割当ての方針が述べられています。
[32] DCMI Namespace Policy <http://www.dublincore.org/documents/dcmi-namespace/>
この文書では、 DCMI の仕様で規定される語彙の名前空間 URI の管理の方針が述べられています。
[34] Best Practice Recipes for Publishing RDF Vocabularies <http://www.w3.org/TR/2006/WD-swbp-vocab-pub-20060314/#naming> (名無しさん 2006-03-15 03:19:06 +00:00)
[29] 組織で複数の名前空間 URI を使う予定があるのなら、 その組織内の名前空間 URI の割当ての規則を設けた方が良いです。
[36] 名前空間URI に含まれる意味のない年号をどうにか汁という Ian Hickson の主張が通って、 W3C の名前空間URI の方針が変わりそうです。
Proposal for short namespace URIs for W3C TRs [Was: XBL Namespace uses the data: scheme from Ian B. Jacobs on 2006-07-20 (www-tag@w3.org from July 2006) <http://lists.w3.org/Archives/Public/www-tag/2006Jul/0022> (名無しさん 2006-07-22 04:34:56 +00:00)