OPML(その2)

RSSアグリケーター用のOPMLファイル(以下単にOPMLと略記)の仕様は簡単である.
Dave Winer氏はRFC化へ向けての提案を行っており以下のURLから読める.

myPublicFeeds.opml
http://blogs.law.harvard.edu/tech/myPublicFeedsOpml

肝心なところは

it should read the contents and look for a sequence of top-level s with at least the following attributes: type, text, description, xmlUrl. These attributes provide enough information so that the aggregator can provide a reasonable user interface for choosing one or more feeds from the site.

Type must be rss; text is the name of the feed; description is a one or two sentence description of the feed; xmlUrl points to the feed. Even though the type is rss, the feed it points to may be in any common syndication format understood by aggregators.

ちょっとまとめると

  • outline要素に最低限以下の属性を持つこと,type, text, description, xmlUrl
  • type属性の値はrssに固定,textはfeedの名前,descriptionは2,3語程度の概要,xmlUrlはRSS feedを得られる場所

基本的にはこれだけである.
ところがこれはあくまで標準化に向けての提案であって,現実にはこれに従わないOPMLファイルが多数流通しているのが実情である.
例えばbloglinesが吐くOPMLファイルはこうだ.


<outline title="梅田望夫・英語で読むITトレンド"
htmlUrl="http://blog.japan.cnet.com/umeda/"
type="rss"
xmlUrl="">http://blog.japan.cnet.com/umeda/index.rdf"/>
description属性がないのはまだ許せるとして,textの代わりにtitle属性にfeedの名前を格納している.feedの名前がtext属性に格納されていることを期待するようなアプリケーションがこのOPMLファイルを読み込むと,当然問題が発生する.

こういう問題に対処するためにtextとtitleの両方の属性にfeedの名前を記述するケースもあるようだ.というか日本国内ではこの形式が推奨されているらしい.

from http://bulknews.net/rss/opml.cgi


<outline text="asahi.com"
description="Feed for asahi.com via Bulknews"
htmlUrl="http://www.asahi.com/" title="asahi.com"
type="rss"
xmlUrl="">http://bulknews.net/rss/rdf.cgi?Asahi"/>
他にもマイナーな流儀があるらしいが,そこまでは面倒見切れないので省略.

そういうわけでOPMLを読むソフトウェアを作る場合は

  • まずtext属性の存在をチェック.存在するならばtext属性の値をfeedの名前として採用する.
  • text属性が存在しないならば,title属性の値を読む

という動作にしなければならない.

一方OPMLを書き出すソフトウェアを作る場合は

  • text属性とtitle属性の双方にfeedの名前を設定すること.
  • ダミーでいいからdescription属性を記述すること.
  • それでも他人様のアプリケーションがあなたの作ったOPMLファイルを正しく解釈してくれるとは期待しないこと

ということになる.

なんでこんな事態になっているかというと,本来OPMLというものは,なんでも載っけられる汎用コンテナみたいなもので,シンプルで使い勝手はよいが,その代わり相互運用性を確保しようとする場合,ファイル形式としてOPMLを採用するということとは別に,OPMLのoutline要素にどんな情報をどういう形式で乗っけるかということをちゃんと定めないといけない.そしてOPMLファイルを読み書きするソフトはその取り決めを守る必要がある.
ところがRSSアグリゲーター用OPMLの仕様をどうするかというコンセンサスが出来る前に,とにかくOPMLで適当に出力しちゃえみたな動きが広まってしまい,その結果,相互運用性に欠けるRSSアグリゲーター用俺流OPMLがあちこちで出来上がるということになってしまった.

一番上に書いたようにRSSアグリゲーター用OPMLファイルを標準化しようという動きはあるのだが,標準化されたからといって万事解決するかというとそういうことはなくて,どうせ旧形式,つまり標準化されていないOPMLファイルは残り続けるだろうから,OPML用ソフトウェアはそういう古いものの面倒も見続けなきゃいけないのである.
嗚呼.




[permalink][contents][page top]

Rubyレシピブック

Rubyレシピブック 268の技

購入,早速お役立ちである.
ところで表紙で踊っているのはリンゴ,赤ピーマン,ミニトマトといった赤系統の野菜や果物である.
どうでもいい脱線した話だが,昔NHKが夜の7:30くらいにアニメをやっていたころの話で,「キャプテン・フューチャー」とか「ナディア」とかいろいろ放映されたが,その中に「マルコ・ポーロの冒険」というのがあった.
もちろんあの東方見聞録を書いたマルコ・ポーロの話である.
以下完全にうろ覚えの話だが,旅から戻って来た商人,確か少年マルコ・ポーロの父か叔父だったと思うが,テーブルの上に宝石を多数,それもダイアモンドをぶちまけるシーンがあった.
アニメだから宝石がテーブルの上にぶちまけられるシーンにも効果音が必要である.さすがに本物のダイアモンドを使うわけにはいかないので音を収録する時にガラス玉で代用した.
ところがお子様と一緒にアニメを見ていたあるお父さんが,これはダイアモンドの音ではないと見破ったそうな.
そのお父さんの職業は宝石商であった.

なにが言いたいかというと....まあ無理難題ですね.

[permalink][contents][page top]

富士通−SamsungのPDP訴訟がスピード解決

富士通がプラズマパネルディスプレイパネル(PDP)に関する特許を侵害されたとして韓国Samsung SDIを日米で訴えていた問題で、富士通は6月7日、両社が和解することで合意したと発表した。

2chネタだがこっちの方が気になる

今回は当社も会社の団結を固めるために起こした訴訟という面があるんです。
外敵を作って内部の混乱から目を背けるという面なんですよね。


[permalink][contents][page top]

QWERTY配列

アルファベットのキー配列もさまざまな試みがなされた。タイプライターのキー配列は,英字キーの最上段を左から読むと「QWERTY」となることから,QWERTY配列と呼ばれた。タイピング・スピードが高速になると印字ヘッドが交差してしまうという機械部分の問題から,あまりタイピング速度が上がらないQWERTY配列に収束していったと言われている。1880年代後半のことだ。

「と言われている」と書いてあるように,ことはそう単純ではないらしい.

QWERTY配列はなぜ普及したか
http://homepage1.nifty.com/cura/oya/kb_arguments.html

[permalink][contents][page top]