 | レベル: 中級 Dethe Elza (delza@livingcode.org), Senior Technical Architect, Blast Radius
David Mertz, Ph.D (mertz@gnosis.cx), Author, Gnosis Software, Inc.
2006年 5月 23日 Atomは実際には2つの異なるものであり、両方ともシンジケーション（ブログやニュースフィードなど、定期的に更新されるその他の情報）に関連しています。Atom Syndication Formatは、エントリー（単独のトピックまたは項目）とフィード（トピックまたは項目の集合）を公開するためのIETF標準です。Atom Publication Protocol（Atom APIまたは省略してAPPと呼ばれることもあります）は、Atomリポジトリーのコンテンツを検索、一覧表示、追加、編集、および削除するための手段です。Syndication FormatとしてのAtomはIETFでの(検討)プロセスを経て標準になり、一方、Publishing ProtocolとしてのAtomは標準委員会でまだ作業中ですが、現時点では、その大半が枯れてきているようです。
では早速、Atomの魅力のすべてを探ることにしましょう。
Atomシンジケート
シンジケーション・フォーマットとしてのAtomは、さまざまな種類のRSS（その多くが今も使われています）での経験から生まれたものであり、まったく新しいものを作り上げるのではなく、RSSの仕様ではあいまいすぎて使い物にならない箇所を強化し（たとえば、RSSではタイトル要素にマークアップを含めることができるかどうかが規定されていません）、問題のある点を修正すること（集約されたコンテンツで起こりがちな、複数のフィードの中の重複するエントリーを識別することなど）を目的としています。初期のRSSフィード用のクライアントとツールのほとんどが、今ではAtomコンテンツをサポートしているか、サポートする予定です。それは、RSSの問題点が修正される点に魅力を感じてのことであり、私がこのフォーマットを推奨する理由もここにあります。しかし、Atomは基本的にRSSの段階的な改良であり、革命的な改良というわけではありません。Atomの進化の過程の1つが、2つの基本的種類のシンジケーション・ドキュメント、すなわち、フィードとエントリーのサポートです。フィードはRSSに匹敵する、エントリーの集合です。しかし、エントリーは独立したドキュメントのこともあり、投稿そのもの（おそらく、ニュース項目やブログの投稿）を含んでいるか、写真など外部リソースへの参照を含んでいます。両方を提供することによって、シンジケーション・フォーマットはパブリケーション・プロトコルを構築するための柔軟な基盤となっています。
リスト1は、小さなAtomフィードの例を示しています。
リスト1. Atomフィード
<?xml version='1.0' encoding='UTF-8'?>
<feed xmlns='http://www.w3.org/2005/Atom'>
<id>urn:uuid:E14A6C6B-A832-4AE9-9D67-263181407D5E</id>
<link rel="self" href="/temp/index.atom"/>
<updated>2006-04-19T18:43:55Z</updated>
<title type='text'>Cool gizmos</title>
<subtitle type='text'>The latest in high-tech gizmos.</subtitle>
<author>
<name>Dethe Elza</name>
<email>dethe.elza@livingcode.org</email>
</author>
<entry>
<id>urn:uuid:2C31F522-20A6-44DF-AA63-6524441FF6A3</id>
<published>2006-05-02T19:00:10Z</published>
<updated>2006-04-30T20:57:20Z</updated>
<title type='text'>This new gizmo is hot, hot hot!</title>
<content type='text'>I just got my hands on the latest gizmo
that's sweeping the nation: it's totally rad.</content>
</entry>
</feed>
|
プロトコル、より多くのプロトコル、そしてAPI
Atomのパブリケーション・プロトコルとしての側面は、より野心的です。Webベースのコンテンツ（たとえば、ブログ）を管理するための共通のプロトコル（しばしば誤ってAPIと呼ばれますが）を作り上げる試みのいくつかには、必要な機能が欠けていて、そのための対処法や専用のインターフェースが必要でした。また、多くの場合、これらの試みでは、RESTなど、Webアプリケーションの優れた実践が活かされませんでした。最初の試みはLiveJournalでしたが、すべてをHTTP POSTで処理して、GET、PUT、およびDELETEを無視し、HTTP認証を使用しません。XML-RPCも同じパターンに従っていて、LiveJournalプロトコルと同じように、すべてを1つのURIで送信します。かなり最近まで、XML-RPCは文字列をASCIIのみに制限していたので、そもそもXMLの優れた利点の1つが失われていました。XML-RPC自体はパブリケーション・プロトコルではありませんが、Manila RPC、Blogger API、MetaWeblog API、LiveJournal XML-RPC Client/Server Protocolなど、いくつかのパブリケーション・プロトコルはXML-RPCに基づいています。これらのプロトコルのいずれでも国際化は考慮されていず、すべてパスワードをプレーン・テキストで送信し、いずれも容易には拡張できませんでした。Atom Publishing ProtocolはXMLをフルに活用し（国際化、XML名前空間を使用して拡張可能）、HTTPをフルに使用しています（すべてのメソッド、認証、URIによるリソースの識別）。
ウェブログ・プロトコルのほかに、Atom Publishing Protocolは一般にWebコンテンツの管理に便利なツールであり、Bugzilla、Google Data APIｓ Protocol、「XMLの論考」の前回の記事（「参考文献」を参照）で言及したカレンダー・サイトの多くなど、さまざまな場所で使用され、前回の記事では触れませんでしたが、後でお話しするある重要なサイトでも使用されています。
Atom Publishing Protocolは、書き込み可能なWebへと続く道の重要なマイルストーンだと思います。Webは常に双方向を目的としてきましたし、PUTおよびDELETEメソッドは常にHTTPの一部でしたが、読み取り/書き込みWebに向かう過程で何かが起きました。今は、wiki、XML-RPC、そして最も重要なWebDAVによって、Webの本来のビジョンにゆっくりと戻りつつあります。WebDAV（単にDAVとも呼ばれます）は、Distributed Authoring and Versioning（分散オーサリングおよびバージョン管理）プロトコルであり、その目標は「書き込みや共同作業が可能なメディアとしてのWebの本来のビジョンを達成すること」です（WebDAV FAQより）。したがって、APPをDAVと比較するのは正しいことです。DAVは、ロッキング、任意のメタデータの格納、格納したリソースの移動や名前変更など、APP以上の機能を備えています。その気になれば、Atomも、XML名前空間により容易に拡張可能なので、任意のメタデータをサポートできます。Atomは実際にはそのようなコラボレーションをサポートするわけではなく、パブリッシングをサポートするだけなので（後には編集も）、ロッキングのニーズはそれほどなく、リソース名前変更はDELETEの後でPUTを使用することによって可能です。Atomはそのすべてを、HTTPを拡張したり、新しいメソッドを追加したりせずに行います。残念なことに、WebDAVは複雑であり、これまで、大手ベンダーの実装の不手際によって苦しめられてきました。それでも、WebDAVコミュニティーはHTTPに対するDAVの拡張に満足せず、Advanced Collections、Versioning and Configuration Management（ご存知のように、Distributed Authoring and Versioningはバージョン管理をサポートしていなかったので）、Access Controlなど、さらに拡張を重ねてきました（または今も作業中です）。そして、カレンダー管理も十分ではなかったので、さらにHTTPを拡張して、CalDAVが作成されました。
WebDAVが今までWebの後継者になれなかったのも当然かもしれません。実装が難しい上に、セットアップと管理が複雑です。DAVにもそれなりのサクセス・ストーリーがあり、特にSubversionという形で成功を収めました。これは、CVSの後継者と目されているバージョン管理システムです。SubversionはDAVとVersioning拡張（DeltaVとも呼ばれます）に基づきますが、DAVの「いい所取り」に独自のプロトコルを混ぜ合わせたものです。そのため、Subversionはすばらしいものではありますが、それによってDAVの奇怪な複雑さが正当化されるわけではありません。DAVが目指しているものの90％については、APPの方がふさわしいと思いますし、残りの10％については、他のシステムの方がふさわしいと思います。APP自体は究極のソリューションではありません。APP単独では、認証の問題を解決できず、クエリー・メカニズムを提供せず、リアルタイム・コラボレーションのようなものを目指していないことは確かです。読み取り/書き込みWebは、まだ成長期だと思いますし、Jabber XMPPプロトコルがリアルタイムの双方向のピア・ツー・ピアプロトコルとしてWebブラウザーに組み込まれる日を楽しみにしていますが、これについては今後の記事で取り上げることにします。
James Tauberは、AtomとSubversionの両方に関係したDemokritosという名前のPythonプロジェクトに取り組み、Atom Storeを提供しています。興味深いのは（少なくとも、この状況で）、パーシスタンス（永続性）を提供するために、表面下でSubversionを使用している点です。このプロジェクトはまだ初期段階ですが（次期バージョンでは認証が追加されると期待されています）、その進展から目を離せません。Google Baseは、Atom Storeの商業版と考えることができ（今では旧版となったAtom Syndication Formatのバージョン0.3をバルク・アップロードに使用していますが）、AmazonのS3データ・ストアはHTTP GET/PUT/DELETEを使用する点で、概念的にはAtom Publishing Protocolと同じです。選択肢は豊富にあり、それらの選択肢がシンプルで堅牢な標準に収束されれば、なお良いことです。
Atom Publishing Protocolの仕組みとして、クライアントはイントロスペクション・ドキュメント、すなわち、提供されたコレクション、それらの機能（書き込み可能、編集可能など）、およびそれらのアドレス（URI）を要約したドキュメントについて問い合わせることができます。これから、クライアントはコレクションそのものに対してクエリーを発行し、それらに含まれているリソース（Atom Entryや写真、オーディオ、ビデオなどのメディア）に関する同様の情報を見つけることができます。コレクションはAtomフィードであり、新しい素材を追加するには、Atom EntryドキュメントをPUTして、そのリソースへのURIを受け取るだけです。そのURIを使用して、そのリソースをさらに操作することができます（編集するにはPOST、読み取るにはGET、削除するにはDELETE）。たとえば、リスト2は単純なイントロスペクション・ドキュメントです。
リスト2. イントロスペクション・ドキュメントのサンプル
<?xml version="1.0" encoding='utf-8'?>
<service xmlns="http://purl.org/atom/app#">
<workspace title="Gizmo Page" >
<collection
title="Cool gizmos"
href="http://example.org/gizmo/index.atom" >
<member-type>entry</member-type>
</collection>
<collection
title="Photos of Gizmos"
href="http://example.org/gizmo/image" >
<member-type>media</member-type>
</collection>
</workspace>
</service>
|
これらの最初の段階について、1つの疑問が残ります。そもそも、どのようにしてイントロスペクション・ドキュメントを見つけるのでしょうか。Atom Feed AutodiscoveryというIETFドラフトがあり、期限切れになっているにもかかわらず広く実装されていますが、このドラフトでは、1つ以上のAtomフィードの参照をHTMLページのメタデータに埋め込む方法が説明されています。この方法は、イントロスペクション・ドキュメントにも同じように有効です。この技法はきわめて単純です。HTMLドキュメントの<head>に、rel属性にキーワードalternateを含み、type属性の値がapplication/atom+xmlであり、href属性がAtomフィードを指す<link>要素を挿入します。Atomワーキング・グループは、これがどの程度イントロスペクション・ドキュメントに有効か最終結論を出していませんが、おそらく前述のようなことになると思われ、Atom wikiで詳しく説明されているように、次のような変更が加えられるでしょう。すなわち、rel属性はintrospectionであり、type属性はapplication/atomserv+xmlでなければならず、hrefはフィードではなくイントロスペクション・ドキュメントを指すことになるでしょう。いずれにしても、<link>要素は、可読値をtitle属性に含んでいなければなりません。たとえば、次のとおりです。
<link rel="instrospection" type="application/atomserv+xml"
href="/introspection.atomsrv" title="All about my feeds"/>
|
Atomとマイクロフォーマットの関係
前回の「XMLの論考」で、マイクロフォーマットは実はAtomと組み合わせたときに本領を発揮するのかもしれないと述べました。これに関する結論はまだ出ていません。Uche OgbujiはAtomのファンですが、マイクロフォーマットの実用性について反対意見を述べています。私が知る限り、特にAtomをターゲットとした進行中のマイクロフォーマットが2つあります。AtomのサブセットであるhAtomと、「XHTML Microformats for the Atom Publishing Protocol」のIETFドラフトです。後者は、カテゴリーとエラーを記述するためにAPP内で使用する2つのマイクロフォーマットを提案しています。筆者は、これらに適した用途を、まだ見つけることができません。
さらにおもしろいことに、マイクロフォーマットは他のドキュメントに埋め込まれるように設計され、AtomドキュメントはHTMLまたはXHTML断片を（慎重に管理して）含むように設計されています。したがって、Atomフィードに、たとえばスケジュールをhCalendarを使って埋め込んでいけない理由はありません。また、事実、前回の記事が編集の最終段階にある頃、GoogleはカレンダーのフィードをAtomフォーマットで購読できるCalendar製品をリリースしました。残念ながら、iCalendar情報を含めてフィードを取得することはできますが、GoogleはhCalendarをフィードでは提供していません。早速この方法に飛びついて、GreaseMonkeyスクリプトなど、ページ内のhCalendarを検索して、それをGoogle Calendarに追加するプログラムを書いている人もいますが、私は別の方法をとりたいと思いました。すなわち、私のGoogle Calendar Atomフィードを使用して、私のウェブログにhCalendarフォーマットでイベントを追加するという方法です。少し検索してみましたが、すでにこれをやっている人は見つからなかったので、お粗末なスクリプトを手早く自作しました。私はこれをPythonで書きましたが、httplib2とElementTreeという2つのサードパーティ・ライブラリーが必要です（両方とも、「参考文献」にリンクがあります）。これは例として作成したものであり、例の伝統にのっとって、エラー・チェックは含まれていませんし、特に柔軟性があるわけでもありません。リスト3は、このスクリプトの使い方を示すテスト関数です。
リスト3. Atom-to-weblogのスクリプトの例
'''
Utility to grab a Google Calendar feed and return hCalendar code
This module has one public function:
events_for_feed(feed_uri, start, end) -> [hCalendarEvents]
'''
import StringIO
import httplib2
import cElementTree
_ATOM_NS = 'http://www.w3.org/2005/Atom'
_GDATA_NS = 'http://schemas.google.com/g/2005'
_MONTHS = [None, 'Jan', 'Feb', 'Mar', 'Apr', 'May', 'Jun', 'Jul',
'Aug', 'Sep', 'Oct', 'Nov', 'Dec']
_EVENT_TEMPLATE = '''<div class="vevent"
xmlns="http://www.w3.org/1999/xhtml">
<abbr class="dtstart" title="%(start)s">%(start_hr)s</abbr> -
<abbr class="dtend" title="%(end)s">%(end_hr)s</abbr> -
<span class="summary">%(summary)s</span> - at
<span class="location">%(where)s</span>
<div class="description">%(description)s</div>
</div>
'''
def _end_human_readable(ts):
return ts[11:16]
def _start_human_readable(ts):
month = _MONTHS[int(ts[5:7], 10)]
return '%s %s, %s - %s' % (month, ts[8:10], ts[:4], ts[11:16])
def _entries_for_feed(feed_uri, start, end):
h = httplib2.Http('.cache')
resp, content = h.request('%s?start-min=%s&start-max=%s' %
(feed_uri, start, end), 'GET')
doc = cElementTree.parse(StringIO.StringIO(content))
return doc.findall('//{%s}entry' % _ATOM_NS)
def _event_for_entry(entry):
when = entry.find('{%s}when' % _GDATA_NS)
start = when.get('startTime')
start_hr = _start_human_readable(start)
end = when.get('endTime')
end_hr = _end_human_readable(end)
where = entry.find('{%s}where' % _GDATA_NS).get('valueString')
summary = entry.findtext('{%s}title' % _ATOM_NS)
description = entry.findtext('{%s}content' % _ATOM_NS)
return locals().copy()
def events_for_feed(feed_uri, start, end):
return [_EVENT_TEMPLATE % _event_for_entry(entry) for entry in
_entries_for_feed(feed_uri, start, end)]
def test():
feed_uri = 'http://www.google.com/calendar/feeds/\
dethe.elza@gmail.com/public/full'
start = '2006-04-30T00:00:00'
end = '2006-05-30T00:00:00'
for event in events_for_feed(feed_uri, start, end):
print event
if __name__ == '__main__':
test()
|
Calendarフィードと開始日および終了日をスクリプトに書き、それがhCalendarフォーマットの文字列のリストを返せば、ウェブログに埋め込むことができます。これが読み取り/書き込みWebの利点です。Googleのように、目的のフォーマットをサポートしていないが、使用フォーマットが公開され、ドキュメント化されていれば、必要なものを自分で作ることが必ずできます。マイクロフォーマットとAtomは互いのために作られたのだという私の主張は、とても実証されたとは言えませんが、この例は、両者がさまざまな方法でよく連携することを（また、いつものことながら、まだやるべき作業が多く残っていることを）示していると思います。
フレンドリーなAtom
Atom Publication Protocolと、GoogleのCalendar拡張など、その他のハロー効果仕様に関する作業はまだ進行中です。Atomを採用するサイトが急増し、アプリケーションやプログラミング・ツールでもAtomを採用するものが増えています。オープンなフォーマット、拡張性、そして明確な定義を持つAtomは、リレーショナル・データベースが企業のパワーとなったように、Webのパワーとなるかもしれません。HTTP GETとView Source（[ソースの表示]）は、Webの最初期にそうだったように、今も強力なコンビです。
この駆け足の紹介記事で、Atom Syndicationフォーマットがなぜ重要かということと、Atom Publication Protocolによってそれが使いやすくなるということがわかっていただけたでしょうか。これらの新しいテクノロジーの使い方について、さらに詳しく知りたい方は、「参考文献」のリンクを試してみてください。
参考文献 学ぶために
議論するために
-
Universal Feed Parser：このPythonプログラムで、あらゆる既知の形のRSSとAtomをパースしてください。(文書の)妥当性確認よりも最大限のデータ抽出に焦点が置かれています。すなわち、厳密には正しくない多くのフィードをパースできます。
- Joe GregorioのPythonライブラリー、クライアントサイドHTTP用Httplib2：HTTP 1.1、HTTPS、3種類のHTTP認証、キャッシュ、圧縮、すべてのHTTPメソッドなどがサポートされます。
-
Subversion：WebDAVを使用したCVSに対して段階的改良を実現するバージョン管理ユーティリティーを試してください。
-
Demokritos：James TauberのAtom Storeを試してください。Pythonで作成されていて、パーシスタンスのためにSubversionを使用しています。
-
Feed Validator：（自分または他人の）Atomフィードのエラーをチェックします。
- 「Atom Publishing Protocol Test Suite」：APPをサポートしているサイトがこのプロトコルに準拠しているかどうかをテストします。（HTTP認証を含みます。）
-
ElementTree：Frederik LundhのPython用XMLライブラリー。
著者について
| 
| | David Mertz氏は多くの分野で活躍しています。ソフトウェア開発や、それについて著述もしています。その他、学術政策理念について分野を問わず、関係する雑誌に記事も書いています。かなり以前には、超限集合論、ロジック、モデル理論などを研究していました。その後、労働組合組織者として活動していました。そして、David Mertz氏自身は人生の半ばにもまだ達していないと思っているので、これから何かほかの仕事をするかもしれません。 |
記事の評価
| |
