ブログ  前の記事  次の記事  2008-04-09 

たけまる / AtomPub - サービス文書の記述力


2008-04-09

_ AtomPub - サービス文書の記述力 [atompub]

(2008-06-26 追記) その後の動向を [2008-06-26-1] に書きました.

ZIGOROu さんと Catalyst::Controller::Atompub をいじっていて,コレク
ション URI をデフォルトから変更したときのあれやこれやを修正したんで
すが (CodeRepos にあります),それについて書く前にサービス文書とその
欠点について簡単にふれておきます.

AtomPub サーバを開発していると,コレクションの設計には力を注いでも,
サービス文書はおざなりという人が多いのではないでしょうか.サービス
文書はとても影が薄いように思います.ひとつはサービス文書がなくても
動作する状況が多いこと,もうひとつは Atom API 時代には存在しなかっ
たことが理由でしょう.

■ そもそも,サービス文書は必要なのか

サービス文書には,コレクションに関する情報が書かれています.サービ
ス文書を読めば,POST すべき URI や許可されているメディアタイプなど
を知ることができます.たとえば,Windows Live Writer のようなブログ
クライアントは,サービス文書をみて "画像が許可されているかどうか"
などを判断しています.

Windows Live Writer のような汎用クライアントは,サービス文書がない
と動かないことが多いと思います.これらを使うときはサービス文書を用
意した方がいいでしょう.ところが,クライアントも自分で作ってしまう
ときは,コレクションの URI はわかっているわけで,サービス文書はなく
ても動きます.こうなると,サービス文書を用意するかどうかは気分の問
題ですw

余談ですが Catalyst::Controller::Atompub を使えば,サービス文書用の
コントローラクラスを作っておくだけで (ヘルパスクリプトでひな形を作
るだけでよい),最低限必要なサービス文書を提供できます.サービス文書
に手間をかけたくない方が多いと思ったので,極力簡単にしておきました.
詳しくは gihyo.jp の連載をみてください.

PerlでAtomPubサーバを作ろう!:第2回 写真付きブログサーバを作ってWindows Live Writerで書いてみる|gihyo.jp … 技術評論社

# ちなみに,Action ではなく Controller として実装されているのは,
# サービス文書クラスからコレクションを認識しやすくするためだったり
# します.

■ サービス文書の欠点

サービス文書の存在意義はさておき,その中身を見てみましょう.個人的
には,サービス文書は記述力が低いと感じています.というのは,静的な
コレクションしか想定されていないからです.

例を挙げて説明します.コメント付きブログを設計するとします./blog
というコレクションを用意し,POST /blog でエントリを追加します.この
とき,サービス文書は次のようになります.

<?xml version="1.0" encoding="utf-8"?>
<service xmlns="http://www.w3.org/2007/app" xmlns:atom="http://www.w3.org/2005/Atom">
  <workspace>
    <atom:title>My Weg Site</atom:title>
    <collection href="http://example.com/blog">
      <atom:title>My Blog</atom:title>
    </collection>
  </workspace>
</service>

さて,/blog/2008-04-09 というエントリを作ったとします.では,このエ
ントリにコメントをするために,/blog/2008-04-09/comments というコレ
クションを用意することにしましょう.POST /blog/2008-04-09/comments
でコメントできるようになります.

このとき,サービス文書は次のようになります.

<?xml version="1.0" encoding="utf-8"?>
<service xmlns="http://www.w3.org/2007/app" xmlns:atom="http://www.w3.org/2005/Atom">
  <workspace>
    <atom:title>My Weg Site</atom:title>
    <collection href="http://example.com/blog">
      <atom:title>My Blog</atom:title>
    </collection>
    <collection href="http://example.com/blog/2008-04-09/comments">
      <atom:title>My Blog - Comments for 2008-04-09</atom:title>
    </collection>
  </workspace>
</service>

では,翌日に /blog/2008-04-10 というエントリを作ると,サービス文書
はどうなるでしょうか.さらに,その翌日にもエントリを書いたら?

というわけで,サービス文書は静的で少数のコレクションしか想定してい
ないと思います.このへんが "記述力が弱い" という理由です.

■ サービス文書の仕様変更はあるのか

改良案として,上の例のようにエントリの子供としてコレクションが作ら
れるときは,大元のサービス文書に追加するのではなく,エントリの中に
埋め込んでしまう方法が考えられます.いま適当に考えた方法ですが,コ
メントはエントリをみてから書くものなので,流れとしても自然かなと.

<?xml version="1.0" encoding="utf-8"?>
<entry xmlns="http://www.w3.org/2005/Atom" xmlns:app="http://www.w3.org/2007/app">
  ...
  <app:service>
    <app:workspace>
      <title>My Blog - 2008-04-09</title>
      <app:collection href="http://example.com/blog/2008-04-09/comments">
        <title>My Blog - Comments for 2008-04-09</title>
      </app:collection>
    </app:workspace>
  </app:service>
</entry>

経緯は違うのですが,Google の Brian Smith がサービス文書をエントリ
で置き換えることを提案しているようです (上の例とは違うフォーマット
だと思う).彼の場合は,category 要素の指定方法が気にくわないという
ところからスタートしていますが,いずれにしろサービス文書の記述力が
乏しいことが裏付けられていますね.

まだこの提案は形になっていないので,今の段階で対応するのは時期尚早
だと思いますが,AtomPub を使いこなしたいという人は気に留めておいて
もいいでしょう.

一言メッセージをこっそり送信できます (非公開)
 今年の西暦→