アカウント名:
パスワード:
そのための purl.org (だった) 訳ですが。
Web の情報に関しては W3C は近い存在ですが、外部のものを任意に置くにはちょっと存在的に異なりますね。
その内URIにDTD:とか定義されて、フォーマル公開識別子(FPI)で検索できるデータベースが必要になりそうだねー
つ[URN]
ティム・バーナーズ・リー先生も悲しんでおられます [kanzaki.com]。
UA に P2P の機能を持たせて、DTD を共有してしまえばいいような気がしてきた。ハッシュアルゴリズムが陳腐化したら、別のより堅実なアルゴリズムに乗り換えていくという前提でクライアントを設計させるとか、そんな感じで改善できないですかね？
RFC 3151 [ietf.org] だと urn:publicid:-:Netscape+Communications:DTD+RSS+0.91:EN とか。Category: Informational ですが。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「毎々お世話になっております。仕様書を頂きたく。」「拝承」 -- ある会社の日常
名前空間とネット上のリソース (スコア:1)
その内URIにDTD:とか定義されて、フォーマル公開識別子(FPI)で検索できるデータベースが必要になりそうだねー
# データベースへの接続は自分で責任もって環境変数URI_SERVER=http://www.w3c.org/dtd/とか定義
## あれ?後退してる?
M-FalconSky (暑いか寒い)
Re:名前空間とネット上のリソース (スコア:4, 興味深い)
最近のサイトは殆どRSS 0.91文書なんて吐いてない、と言っても
RSS 0.91文書は絶滅してはいない。また、太古の昔に生成された
RSS 0.91文書を処理する際に特別な対応を要求されるのは面倒。
そんなわけで、DTDとかを公的財産として登録したい奴から金を取って
永久保存を実行してくれる機関があると便利。料金は一括で受け取って
後はノーベル財団よろしく運用して毎年の維持費を捻出。赤字になったら
公的資金を注入するなり寄付でも募るなりして解決することにしとこう。
この料金システムはまさに墓地永代使用料。そして求めるは情報の墓場。
Re:名前空間とネット上のリソース (スコア:2, 参考になる)
そのための purl.org (だった) 訳ですが。
Web の情報に関しては W3C は近い存在ですが、外部のものを任意に置くにはちょっと存在的に異なりますね。
Re:名前空間とネット上のリソース (スコア:1, 興味深い)
そもそも、リダイレクト先の生存性は大抵の場合purl.orgに劣る。
そうでなければpurl.orgを使用する必要性は薄いから。だから、
リダイレクト先が死んでしまった際に、新しいリダイレクト先を
作らなければならない。でも、これにはちょっと問題がある。
まず、誰が新しいサーバを用意しなければならない。──でも誰が？
DTDの登録を依頼した本人は死んじゃってるかもしれないから駄目。
purl.orgにやらせる？なら初めからリダイレクト方式なんて
採用しないで実体を保存して供給してしまった方が話が早い。
「何処かの誰か」に期待してみる？あまりにも不確実。
次に、サーバにアップロードするDTDを用意しなければならない。
これは上の問題と本質的に一緒だから省略するけど、
一体何処の誰がDTDを保存しているの？
Re:名前空間とネット上のリソース (スコア:0)
>これは上の問題と本質的に一緒だから省略するけど、
>一体何処の誰がDTDを保存しているの？
Google先生か、WebArchiver....
Re:名前空間とネット上のリソース (スコア:0)
そうやって終の棲家を欲しがる生き物は、
長い目で見れば、なにもDTDだけとは限らない、
ってのがこの問題の味噌だと思う。
いや、世の全て(^^;のDTDだけでも、
十分に件数が多すぎて管理に困ると思うんだが、
仮にソレが解決できたとしてもだ、そのうしろには膨大な数／量の
「俺も永代管理してくれ！」系リソースが控えていると思う。
たとえばFREEソフトウェアでお馴染みなネットワークダウンロード。
apt-get とか yumとかruby gemとか。
ああいう奴のダウンロードファイルの、URLって、
ころころ変わられたら面倒だと思わないか？
(まああれ「だけなら」設定ファイルを弄って逃げるという手もあるが…
Re:名前空間とネット上のリソース (スコア:0)
Re:名前空間とネット上のリソース (スコア:1, 参考になる)
つ[URN]
ティム・バーナーズ・リー先生も悲しんでおられます [kanzaki.com]。
Re:名前空間とネット上のリソース (スコア:1)
名前とデータの関連付けの情報を別途持たなければなりませんし、関連付け情報を保守するのは大変だからです。
永続的にデータを示したいのであれば、ハッシュ値とハッシュアルゴリズム名で示せば良いと思います。
＃ハッシュアルゴリズム名が実際にどのアルゴリズムを示しているかはそうそう失われる物でもないでしょうし。
Re:名前空間とネット上のリソース (スコア:0)
ハッシュのアルゴリズムが失われなかったとしても、弱衝突耐性が突破されてしまえばハッシュとして機能しなくなってしまうのでは？
Re:名前空間とネット上のリソース (スコア:1)
UA に P2P の機能を持たせて、DTD を共有してしまえばいいような気がしてきた。ハッシュアルゴリズムが陳腐化したら、別のより堅実なアルゴリズムに乗り換えていくという前提でクライアントを設計させるとか、そんな感じで改善できないですかね？
[わかってもらうことは難しい。わかってあげることは、もっと難しい。]
Re:名前空間とネット上のリソース (スコア:1)
RFC 3151 [ietf.org] だと urn:publicid:-:Netscape+Communications:DTD+RSS+0.91:EN とか。Category: Informational ですが。