agenda 2002-09(下旬) Linkage Weblog

RSS 2.0 は標準になるべきではない

公開
2002年9月30日

RSSの登場と変遷にRSSの「歴史」が簡単に説明されている。RSS 0.91はUserLandのScriptingNews規格とのことだ。RSS 2.0も同様である。私も先日試用版をインストールしてみた「Radio UserLand (英語)」というソフトを販売している会社がUserLand (英語)であり、このUserLandのCEO(最高経営責任者)、Dave Winer (英語)氏のWeblogがScriptingNews (英語)らしい。

彼のWeblogは、The History of Weblogs (英語)にも自慢が書いてあるように、「インターネットで最も古く、長いWeblogの一つ」であるそうで、Weblog界隈での彼の影響力は大きいそうだ。

さて、UserLandとその周辺サイトのHTML文書のマークアップを見てみると、セマンティックウェブからはかけ離れている。XMLとはあまり関係のなさそうな、そこら辺のニュースサイトの方が見出しを見出しとしてマークアップしているという意味で、まだマシであると言える。

自然な流れとして、このテーブルだらけのサイトは、あちらの「CSSコミュニティ」、というよりはむしろ「Table-lessコミュニティ」によって批判された。2002年2月のことである。dive into mark/February 13, 2002 (英語)から、色々な批判を読むことができ、Scripting Newの、HTMLのbタグで見出しされた「Are tables really evil? (英語)」という記事にはDave氏の見解がある。英語を感覚的に読めない私でも傲慢性を感じる文章だ。彼はreasonably modern machines with a graphic Web browserの利用者のみをターゲットにしている。これはRadio UserLandの顧客層と一致すると思われるが、この一事でもって、彼は合理的ではあるもののWorld Wide Webの標準的な仕様や規格のことを考える立場として相応しくないことは明らかだ。

お仕着せのブラウザをそのまま使っているエンドユーザーにとって、そのサイトがtableでレイアウトされていようとCSSでレイアウトされていようと、また、見出しがheadingタグでマークアップされていようとbタグでマークアップされていようと、整形結果が同じであれば利益は殆ど変わらない。そういった大多数のエンドユーザーのみを考慮に入れるならば、UserLand (英語)がテーブルでレイアウトする行為は合理的であるし、また、WYSIWYG系オーサリングツールも兼ねているRadio UserLand (英語)にとって、CSSでレイアウトを分離する手法を新たに提供するのはコストが掛かる行為である。

利潤を追求する経済主体のgoalと、WWWのgoalは違う。そういうわけで、私はUserLandのRSS 2.0 (英語)は絶対に使わないだろう。

RDF Site Summaryと、Rich Site Summary(あるいはReal Simple Syndicationだか何だか)は明確に区別されるべき。

RSSの謎

公開
2002年9月26日

rss:description要素の中に文字参照でエスケープされたHTMLタグが登場したり、RSS 1.0のモジュール、content:encoded要素を使ってCDATAセクション内にHTMLタグ(らしきもの)が登場したりするRSSをたまに見かける。

なにやらパチもの臭いRSS 2.0 (英語)。そのRSS 2.0の (英語)。またdive into markで例示しているRSS 2.0のtemplate (英語)。さらにphilringnalda.comのRSS .1.0 feed (英語)。

何故XHTMLの名前空間を使うという方向に拡張しないのか不思議でならないのだけど、それは置いておくとして、とりあえずこれらのリテラルな要素(といっていいのかどうか)を解釈しようとすると、Myパーサに馬鹿馬鹿しい負担がかかるので不許可。

それにしてもこれらは一体なにを意図しているのだろうか。rss:description要素内に登場する<p>*rofl*</p>みたいな文字列は、paragraphとして表示しろってこと? 絶対に嫌だ。そもそもdescriptionではなくてcontentだしなあ。RSS aggregatorのようなUser Agentに対して情報を「完結」させたいという欲求だろうか。もうそうなると「Summary」ではない。まあ需要があるのなら勝手にすればよいのだろうけれど、他所様に勧めたりするのは勘弁して欲しいところだ。

私はRSSでは、「何が更新されて概ねどんな内容なのか」を知りたいだけなので、やたらにでかいリソースを「配信」されても困る。

まだ試験中の拙作RSS aggregatorのスクリーンショット(39kb)

slashdotのRSSもじゅーる

公開
2002年9月22日

My「RSS aggregator」のXSLTに、slashdot.orgのRSSモジュールを解釈させようと思ったのだけど:

  • <slash:section>security</slash:section>

http://slashdot.jp/slashdot.rdf (英語)より

例えばこれは、その親のrss:item要素がセキュリティに関する話題であることを示しているらしいことは想像がつくものの、その「セキュリティ」関連記事のアーカイブのURIがどこにも示されていないので、そんなものを知る由もない外部User Agentにとっては概ね無意味かと。まあ見出し自体が意味不明の場合には、例えば「やばいんじゃないの?これ」とかいう無意味な見出しであったなら、「セキュリティ」などとジャンルを示す要素が必要だけれど。そうではないわけだから。

とはいえ、slash:sectionがどういった要素であるかハッキリしないので、とりあえず、slashで修飾されている名前空間のURI (英語)(http://slashcode.com/rss/1.0/modules/Slash/)を開いてみた。

「Example」というセクションで例が示されているものの、結局のところ何の要素であるかは不明。しかも、「Namespace Declarations」はこのように明示されていた:

  • xmlns:slash="http://purl.org/rss/1.0/modules/slash/"

……名前空間違うぞ。

リダイレクトされるURLは同じだけどな。わらい。

わらい。と書いただけでは批判にならんので一応以下。

slashdot.orgは一体何のためにこのモジュールを公開しているだろう。この公開されている定義に従って名前空間の接頭辞「slash」を定義したとして、実際のスラッシュドット・ジャパンとかRSSの「slash:section要素」にはマッチし得ないのだけど。名前空間が違うから。

仮にこのモジュールの利用者がスラッシュドット以外に居たとして(仮にです)、User Agentは名前空間を2つ定義しなければならない。例:

  • xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
  • xmlns:slashy="http://slashcode.com/rss/1.0/modules/Slash/"

接頭辞はslashだろうがflashだろうが何でもいいのだけど、とにかく二つ用意する必要が。

実際には利用者などいそうにないから、実害はないのだろうけれど。利用者がいようがいまいが、とりあえず折角のPURL (英語)が無意味になってしまっていることは確か。しかし、突然変更されるような気がする(謎)、後者のslashcode.comドメインのURIは使いたくない。と。まあ勿体無いとしか言いようがない。

rss:channel要素のrdf:about属性

公開
2002年9月20日

The {resource} URL of the channel element's rdf:about attribute must be unique with respect to any other rdf:about attributes in the RSS document and is a URI which identifies the channel. Most commonly, this is either the URL of the homepage being described or a URL where the RSS file can be found

RDF Site Summary (RSS) 1.0 より

そういういい加減なことじゃあ困る。どちらかにして貰いたい。RSSファイルそのもののURLなのか、概要を表現されたサイトのURLなのか。実際、両方のケースが存在するのでちょっとした不利益を被ってしまった。

試作した「RSS aggetator」は:

  1. RSSリソースのURLをリストにしたXMLファイルを設定ファイルとして
  2. 最初にそのXMLファイルを解析、各リソースのDOMツリーを取得し
  3. (MS用語でいうところの)「データアイランド(XML要素)」に格納しておく
  4. 以後の各種操作は全てその「データアイランド」のDOMツリーにアクセスして解決

ところが、その「データアイランド」にアクセスして得られる情報の中に、RSSそのものを指すURIが全く含まれていないケースが発生する。rss:channel要素のrdf:about属性に、RSS自身のURLが記述されていない場合、DOMツリーからはもうRSS自身のURLを取り出すことができないのだ。スラッシュドット ジャパンのRSS (英語)然り、dive into markのRSS (英語)然り。

何が嫌かって、対象となるリソースへのアクセスを、DOMツリーで全て解決できない点。それにXML的にもどうだろう。rss:channel要素内のrss:link要素が解決してくれる主要データを、何でわざわざ「メタのメタ」rdf:about属性に再び記述しなければならないのだろうか。ナンセンス。そんなメタ情報は要らない。

RDF的には、about属性にRSSファイル自身のURLを記述する方こそナンセンスのようにも思えるので仕方ないのかとも思ったのだけど、RSSファイルの「コンテンツ」は何かといったらそれは各rss:item要素であって、rss:channel要素は、HTMLのhead要素に近い。RSSファイル自身のメタ情報だ。

The channel element contains metadata describing the channel itself, ..

RDF Site Summary (RSS) 1.0 より

その属性は、メタ情報のメタ情報という位置付けになるはず。つまりこの場合のrdf:about属性は、「このメタ情報は何についてのメタ情報なのか」を意味付けすべきだ。

以上より、たとえ仕様書の定義が一意でないにしろ、W3CのRSS (英語)やThe Web KanzakiのRSSのように、rss:channel要素のrdf:about属性には、RSSファイル自身のURLを記述するのがより自然であるといえる。

追記

RSS解析

公開
2002年9月19日

Amphetadesk (英語)はローカル環境で利用するBulknewsのようなもの。RSSで提供されたニュース等を集積してくれる。実際に使ってみたところ、Shift_JISが扱えないものの、概ね良好な使い心地。

インストールは簡単で、実行ファイルをクリックするだけ。後はブラウザでHTMLファイルを操作してカスタマイズする。ニュース等の一覧も普段使っているブラウザで閲覧する形。


17日のdive into mark (英語)は、Weblogに良くある「日替わり推奨リンク」等をRSSでどうマークアップするかについて楽しげに語っている。これを読んで、向こうのXML/HTMLオタク達の間でRSSが流行している理由が何となく分かってきた。

比較的ローカルな合意に基づいて名前空間つきの要素を拡張。User Agentをカスタマイズしてより効率的にWeb巡回しようということだろうか。


Amphetadesk (英語)のオタクチックなカスタマイズ方法を調べていて思ったのだけど、そんな知識を得るよりは自分で作った方が有意義、というか面白そう。Amphetadesk (英語)はテーブルレイアウトな上デザインがあまりパッとしないし。

  • title要素とdescription要素だけをざっと集めて定義リストを生成(by DOM)
  • 詳細はスタイルシートで変換(by XSLT)

拡張要素があったとしても、名前空間接頭辞を定義してxsl:template要素を一つ増やすだけ。XSLTを有効に使える分デッドリンク修復ツールよりは簡単そうだ。というか、自作デッドリンクチェックはえらく時間がかかる。2039個のリンクのうち60個くらいのデッドリンクがあったのだけど、某Web archiveへのリンクに修正するか、デッドリンクであることを明示するかまだ悩んでいる。というか、18日の午後やたらHEADリクエストを送っていたのは私です。笑。

MSXML4.0を利用したデッドリンク対策

公開
2002年9月17日

所謂「リンクチェッカ」はデッドリンクを教えてくれるものの、書き換えまではやってくれない。折角MSXML4.0をインストールしたのだから、それくらいは何とかなるだろうという試み。DOMでノードを操作できるので、下手な正規表現でとんでもない変換をしてしまうというリスクは防げる。

1. 全てのソースファイルの、href属性値とsrc属性値を取得

これでhref属性とsrc属性を全て収めたノードリストを取得できる。

  • nlAttrs.item(index).nodeValue

これででURIを取得できる。

2. リソースの存在を確認

IXMLHTTPRequest (英語)という素晴らしい?オブジェクトがある。new ActiveXObject('Msxml2.XMLHTTP.4.0'); で作成。

これを使えば、リソースの存在確認は簡単に行える。


var xmlhttp = new ActiveXObject('Msxml2.XMLHTTP.4.0');
function isResource(sURL){
  xmlhttp.open('HEAD', sURL, false);
  xmlhttp.send();
  if(xmlhttp.status &lt; 400) return true;
  else return false;
}

2002-09-19T01:44:13+09:00改善。

var oHTTP;
function isResource(_sURL){
var isRes = false;
 oHTTP = new ActiveXObject('Msxml2.XMLHTTP.4.0');
 window.status = 'requesting :' + _sURL;
 oHTTP.open('HEAD', _sURL, false);
 oHTTP.onreadystatechange = function(){
  if(oHTTP.readyState == 4){
   isRes = (oHTTP.status < 400) ? true : false;
   oHTTP.abort();
  }
 };
 oHTTP.send();
 return isRes;
}
  • #で文書のフラグメントを指定してある
  • newsプロトコル

これらをURIとして指定するとエラーが出るようだ。サーバが消滅していたりすると異常に時間がかかるし。

但しローカルのリソースについては、存在する場合はstatusは0になるので問題ないが、存在しない場合、sendメソッドがスクリプトエラーになってしまう。しかし絶対パスでローカルを参照していること自体が問題なので、これは正規表現で判別して事前に警告するようにし、相対パスはWWWに置いてあるリソースの絶対URIに変換すればいい。この辺りはどうということのない普通のJavaScriptなので省略。

3. デッドリンクな要素を適切なものに変換

リンク先がデッドリンクだったa要素等を、何か別の要素に置き換える。これはW3CのDOMで適当に行う。

ここで、一時的にサーバの調子が悪かった(一時的なデッドリンク)ということも考えられるので、いつでも元に戻せるようにしておく必要がある。つまり次回のデッドリンクチェックの際、そのURIも確認する必要がある。

例えば:

  • <a href="http://foo.com/">foo.com</a>
  • <span class="dead-link" title="http://foo.com/">foo.com(デッドリンクです@2002-09-16T21:06:31+09:00)</span>

前者を後者のように置き換えて、次回のチェックの際にリソースhttp://foo.com/bar.htmlの存在を確認し、復活していたら前者に戻す。このspan要素全てをノードリストに収めるには:

  • var nlSpans = DOMDocument.selectNodes('//span[@class = "dead-link"]');

一行で終り(未確認だけど)。

尚、名前空間がnullでない場合は、要素名の前に名前空間接頭辞をつけてやる必要が。

参照:MS独自拡張selectNodesメソッドについて

余談

IXMLHTTPRequest (英語)オブジェクトを利用すれば、fub_redカスタムパネルにWWWCのような更新チェッカを入れられるような気がする。気のせいかも。

余談2

私はかつて、自宅サーバの野望を抱いていたのですが、知識が追いつくその前にISPによって見事に砕かれてしまいました。というわけでサーバーサイドスクリプトにはコンプレックスがあります。ご注意ください(謎)。