atom:link@rel="enclosure" と atom:content はどう違うのだろうか

The Atom Syndication Format (RFC4287) を読んでみると、外部のリソースを表現として atom:link と atom:content が使えることになっていますが、その両者の使い分けや使いどころがわかりません。

以下は、私の勝手な推測、考え方、気づきなどを書き流したものです。

次のような atom:link@rel="enclosure" を使ったポッドキャスティングの例がよく引き合いになりますが、

<link rel="enclosure" type="audio/mpeg" length="1337"
  href="http://example.org/audio/ph34r_my_podcast.mp3"/>

意味として捉えると、次のように atom:content を使ったほうが適切にも思えます。

<content type="audio/mpeg" 
  src="http://example.org/audio/ph34r_my_podcast.mp3"/>

atom:link は length という atom:content にない属性を持っています。この length によって外部リソースがサイズが把握できるので、外部リソースを選択的にダウンロードするような用途でうまく機能しそうな気がします。

であれば、atom:content が外部リソースを表現できる必要性がない気がしますし、逆に atom:content も length 属性を持ってしまえばよい気がします。

ポッドキャスティングではなくエントリ内の画像と捉えると、コンテンツ内のリソースと捉えることができるので、atom:link じゃなく atom:content が適切であるという解釈もできます。ですが、atom:content が length 属性を持たない理由にはなりません。

atom:link@rel="enclosure" は、次のように RSS 2.0 Specification の enclosure 要素に対応します。この RSS 2.0 の仕様に影響を受けているのかもしれません。

<enclosure url="http://www.scripting.com/mp3s/weatherReportSuite.mp3"
  length="12216320" type="audio/mpeg" />

もしかすると、歴史的な背景とか、他の標準仕様との関係とかを知らないと、うまく理解できないのかもしれません。

まだモヤモヤしますが、今のところの結論としては、エントリ自体が外部リソースであるか、外部リソースがエントリ内の部分を表現するときは atom:content を使い、指定したときだけダウンロードするなど、外部リソースを選択的に操作するときは atom:link を使うという整理になりました。

どないなもんでしょう。

Head Firstオブジェクト指向分析設計 ―頭とからだで覚えるオブジェクト指向の基本 Brett McLaughlin Gary Pollice 長瀬 嘉秀 by G-Tools