OPML(その2)

XML

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

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

肝心なところは

Archive: myPublicFeeds.opml
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]