Feed Menus による新しい RSS / Atom フィード自動検出の構想

投稿 :

Feed Menus(www.ietf.org) なる仕様が IETF の Internet draft として公開されました。RSS / Atom フィードを簡単に見つけるための手段を提供するもののようです。

Feed Menus の使い方と目的

§

使い方はひじょうに簡単で、以下のような JSON ファイルを /.well-known/feed-menu.json として配置するだけ。HTML ページ側では HTTP フィールドや <head> 要素内でなにかする必要はありません。

{
  "feed-menu": "The Astor Theatre",
  "items": [
    {
      "feed-title": "Upcoming Shows",
      "rss": "/shows/upcoming.xml"
    }
  ]
}

仕様書の Introduction によれば、<link rel="alternate" type="XXX"> による既存のフィード自動検出機能(blog.whatwg.org)は以下の問題があるとされています。

  • フィードの <link> 要素をサイト内のすべてのページに挿入する必要があり、制作と配信の両面でオーバーヘッドが発生する。
  • 実際にはすべてのページに自動検出機能があるとは限らず、ユーザーはサイト内をくまなく探す羽目になることが多い。
    • せっかくフィードを提供しているのに、<link> 要素を設定せず <a> 要素でしかリンクしていないサイトは日本の企業サイトでもよく見かけますね。
  • 多くの CMS は自動検出機能を自動的に生成するため、サイト制作者が認識せぬままに壊れたフィードが配信されている例がある。
  • フィードの命名やフォーマットに関するベストプラクティスが存在しないため、多くのサイトでは RSS と Atom を両方提供するといった混乱が見られる。
    • 購読側としても、複数フォーマットのフィードが提供されているとどれを選択すれば良いのか迷いますね。エンジニアでない普通の人はフォーマットの違いなんか知らないでしょうし、分かったところでそのサイトの RSS 1.0 と RSS 2.0 と Atom (1.0) とが同一の内容を配信している保障はありませんから。

これらの問題に対して Feed Menus では、CMS 等はサイト制作者が認識しないままに自動で /.well-known/feed-menu.json を生成すべきではないとの制約を掛けており（第3章(www.ietf.org)に記載）、上記の問題のいくつかは緩和されることが期待できます。

一方で <a> 要素によってレンダリング画面に見える形でしかフィードをリンクしていないケースや、RSS と Atom の併存問題などは Feed Menus を使ったところで解決できないように思えます。

Google Reader の終了（2013年）以降、暗い話題しかなかったフィード界隈に久々に舞い降りた明るいニュースであることには興奮を隠せないのですが、これでなにか大きな改善が期待されるのかと考えてみると……既存の <link> 要素と <a> 要素を廃止できるわけもなく、単に JSON を増やす手間が加わるだけのような気も……。このドラフトを書かれた mnot 先生にはどんな未来が見えているのでしょうか。

Feed Menus を試す

§

私の個人サイト(w0s.jp)と本ブログ(blog.w0s.jp)は以前からフィード配信をしているので、Feed Menus にも対応してみました。前述のとおり JSON ファイルを規定のパスで配置するだけなので、作業自体は一瞬です。小さなファイルなのであまり意味はないものの、一応 Brotli で圧縮した .br ファイルも用意しています。

現段階ではブラウザの対応は行われていないので、実際の挙動を確認するにはアドオンのインストールが必要です。これは著者本人が A browser extension for Feed Menus(GitHub) として公開しています。

私は Chrome 用の手順に従い Vivaldi にアドオンをインストール、するとアドレスバーの右側にフィードアイコンが表示されます。このアイコンをクリックすると、対応サイトであればポップアップ内にフィード情報が表示されます。なお「Auto-Discover Feeds」のスイッチをオンにしておくと、対応サイトではアイコンがオレンジ色に変化するようになります。

サムネイル画像
Vivaldi で w0s.jp にアクセスして Feed Menus のポップアップを表示した様子。feed-menu.json で定義した3つのフィードアイテムが表示されている。オリジナル画像

なお仕様にあるようにフィードアイテムはネスト構造にもできるのですが、その際はサブメニューとして表示されるようで、その実例は mnot 氏の個人サイト(www.mnot.net)で確認できます。

サムネイル画像
Vivaldi で www.mnot.net にアクセスして Feed Menus のポップアップを表示した様子。1つのフィードアイテムの下に3つのカテゴリーが展開されている。オリジナル画像

<link> 要素による従来方式と Feed Menus との大きな違い

§

このように実際のブラウザの挙動を見ると、ネスト構造にできる点を除けば <link rel="alternate" type="XXX"> による従来方式と大差ないように思えます。

私のサイトも mnot 氏のサイトも、Atom フォーマットしか配信していないのでそのように見えてしまうのですが、RSS と Atom フォーマットを両方配信するケースでは根本的に考え方が異なるようです。まず <link> 要素の場合、HTML 仕様において以下のように定義されています。

For the purposes of feed autodiscovery, user agents should consider all link elements in the document with the alternate keyword used and with their type attribute set to the value application/rss+xml or the value application/atom+xml. If the user agent has the concept of a default syndication feed, the first such element (in tree order) should be used as the default.

HTML Standard – 4.6.8.1 Link type "alternate"(WHATWG)

このように、フィードの自動検出においては指定形式のすべての <link> 要素を考慮すべきとされています。RSS と Atom フォーマットが両方配信されていれば両方とも提示すべきであって、その選択はユーザーに任せるというやり方となります。

一方、Feed Menus の仕様には以下のように書かれているのみで、その際の挙動は定義されていません。

One of "rss" or "atom" is REQUIRED; both MAY be present.

Feed Menus – 2.2. Feed Objects(www.ietf.org)

そして前述の mnot 氏制作のアドオンでは rss と atom フィールドが両方指定されていた場合は rss が優先されて atom は無視されます[1]。

仕様で挙動が定義されていない以上、rss を優先するか atom を優先するか、それとも両方提示するかは実装依存であり、ユーザーに選択させている現状とはこの点が大きく変わると言えるでしょう。

Feed Menus はあくまで Internet draft として公開されたばかりのものであり、正式に RFC になったとしてブラウザや周辺ツールがどのように実装されるのか、そしてなによりこれがどの程度世間に受け入れられるのかは想像も付きません。現段階ではいますぐ対応する必要性もないでしょう。ただひとつ言えるのは、現状で RSS と Atom を両方配信しているサイト、あるいは RSS のバージョンを複数配信しているサイトなどはその選択方法の常識が変わる可能性はあるので、動向を注視した方がよいとは思います。

脚注