 | レベル: 中級 Dethe Elza (delza@livingcode.org), Senior Software Developer, Uniserve Communications Corporation
David Mertz, Ph.D (mertz@gnosis.cx), Author, Gnosis Software, Inc.
2007年 1月 09日 Ajax は Asynchronous JavaScript and XML を表します。そこにはあるのは、最近の Web ブラウザーでは、Web アプリケーションの使用中にサーバーとの間で送受信されるデータ用にチャネルをオープンしたままでも十分な信頼性を確保できる、という考え方です。これは、リンクをたどるとページ全体が新たにロードされるという標準的な Web 技術とは対照的です。Ajax ベースでの開発の多くの側面では、従来の Web ページを設計する場合とは異なる判断が要求されます。例えば「戻る」ボタンをどう処理するのか、更新されたデータをどう表示するのか、どのくらい頻繁に更新を送信するか、などの判断が要求されます。この記事では、そうした中の 1 つの側面に関連した話題、データ交換フォーマットに何を使うべきかについて解説します。
ここには非常に多くの選択肢があります。Ajax の X は XML を指しますが、XML は言語ではなく、言語を構築するためのツールキットです。そのため、最初に判断すべき項目として、既存の言語を使うのか、あるいは独自の言語を作るべきかという項目があげられます。この判断にはいくつかのトレードオフが関係してきます。既存の言語で用が足りるのか、あるいはもっと適切な言語を設計できるのかを考えなければなりません。その言語を処理するツールはあるのでしょうか、それともそうしたツールを作る必要があるのでしょうか。他の人とコミュニケーションする場合 (もしコミュニケーションしないとすると、そもそもなぜ Web アプリケーションを構築する必要があるのでしょう)、その言語はどのくらい知られているのでしょうか。他のアプリケーションは、そのデータに簡単にアクセスして、利用することができるのでしょうか。
明らかな選択肢としては、(X)HTML (マイクロフォーマットのサブセットを含む) や、グラフィック・データであれば SVG あるいは X3D、長期間にまたがるデータのスニペットには Atom、単純なアウトラインには OPML、そしてセマンティック・グラフには RDF などです。1 つの極端な場合として、DocBook や DITA、さらにはリッチでセマンティックで完全機能、そして非常に詳細な OpenOffice フォーマットのデータを送るかもしれません。(これらのフォーマットの詳細は「参考文献」を参照してください。)
逆の極端な例として、一歩前に戻り、Ajax の X を無視し、あらゆる種類のデータを送ることもできます。バイナリー・データ、あるいは画像やムービー、PDF ファイルなどを送ることもできますが、こうしたデータは JavaScript を使用するブラウザーでは処理が困難です。あるいはもっと手軽に、XML よりも単純なテキスト・フォーマットを送ることもできます。例えばタブ区切りやカンマ区切りのリスト、Markdown などの軽量構造テキスト、YAML、あるいは JSON などを XML の代わりに送るのです。完全な XML を使わなくても、何十もの選択肢があり、それらは XML Alternatives のサイトに完璧に文書化されています (「参考文献」を参照してください)。以上を要約すると、最もリッチ (そして詳細) なものから、よりリッチでなくて単純なものまでの連続的な選択肢の中から、下記をあげることができます。このリストの 1 つの項目内においてさえ、データをエンコードする方法がいくつも見つかるため、この並び順には議論の余地がありますが、大雑把な見積もり以上のものとしては捉えないでください。
- OpenOffice スプレッドシート
- DITA (Darwin Information Typing Architecture)
- DocBook
- RDF-XML
- XHTML
- マイクロフォーマット
- Atom
- OPML (Outline Processor Markup Language)
- カスタム XML
- Markdown / Textile / reStructured Text
- YAML (YAML Ain't Markup Language)
- JSON (JavaScript Object Notation)
- カンマ区切り (あるいはタブ区切り) のテキスト
何を基準に考えるべきか
このように多くの選択肢がある中で、一体どのようにすれば、詳細な情報に基づいた判断を下すことができるのでしょう。いくつかの理由から、上記のリストは必ずしも厳密に複雑な順には並んでいません。
- 第 1 に、こうしたフォーマットの大部分は、簡単な方法で使うことも複雑な方法で使うこともできます。
- 第 2 に、その複雑さが、作成の複雑さなのか、読み取りや構文解析、あるいは処理の複雑さなのかを区別する必要があります。例えば、XML そのものは比較的複雑ですが、パーサーは既にブラウザーの中にあり、そのため構文解析ステップは単純です。
- 第 3 に、複雑さは、どのようなタイプのデータを扱うかによって大きく変わります。そのデータはスプレッドシートやデータベースのように非常に厳密な構造を持っているのでしょうか。ワープロ文書やブログの投稿データのように非常に緩い構造を持っているのでしょうか。航空機のマニュアルのように大きな文書なのでしょうか、あるいはレスポンス・コードのように小さなデータ・スニペットなのでしょうか。もし大きなデータ・セットであれば、すべてを一度に送る必要はあるのでしょうか。あるいは必要に応じて部分的に送ることはできるのでしょうか。大きなデータ・セットを小さな部分に分割するのは、どのくらい難しいのでしょうか。また、そうした小さな部分を受信側が集めて再構成するために、どのくらいの情報を追加する必要があるのでしょう。
言い換えると、最も重要な要素は何なのでしょう。下記は、そうした要素として考えられるものです。
- 詳細さと帯域幅 (想像されるほど重要ではありませんが、時には重要なことがあります)
- 読みやすさ (そして書きやすさと管理のしやすさ)
- 構文解析の容易さ (クライアント・サイドとサーバー・サイド)
- 構文解析の速さ (ネイティブ対スクリプト)
- 情報損失 (つまり、順序付きペア → ディクショナリー → セット)
- 柔軟性 (受信側で何を待てばよいかがわかるため、柔軟でない方がよい場合もあります)
- 言語の移植性 (何種類の言語でそれを使えるのか)
- 正しさ (フォーマットに従っているかどうか、どのくらい容易にチェックできるか)
- 双方向性 (つまり Markdown → XHTML → Markdown でどのくらいデータが失われるか)
ほとんどの場合、スピードや帯域幅利用率、その他の効率を最優先とはせずに、もっと漠然としたもの、つまりユーザーの満足を優先しなければなりません。少しくらいネットワーク遅延があっても、その遅延を背後に隠すことができ、更新が瞬時に行われるように「見せかける」ことができれば、遅延は問題にはなりません。正にこの理由から、まったく新しい Web ページを生成する上で Ajax が重要なのです。
大まかな原則
少し危険なことは承知の上で、最初に大まかな原則を示しましょう。その後で、そうした原則を裏付ける例をいくつかあげることにします。下記にあげる例と、私自身が Web アプリケーションを構築する中で得た経験に基づいて、Ajax による手法を使う際の数ある選択肢の中から選択するためのガイドラインとして、私は次のようなものを考え出しました (編集者による注釈: この記事のこれから先の部分の著者は Dethe Elza です)。
-
データ用には JSON: 構造化データ、あるいは半構造化データの場合には、JSON を選択します。少なくとも 3 つのパーサーがブラウザーに組み込まれており (HTML と XML、そして JavaScript)、そのうち最も速いのは JavaScript です。また、JavaScript を使ってデータを処理するのであれば、面倒な DOM 操作に苦労するよりも、データが既に JavaScript になっていた方が便利です。そのデータが直接表示されるものではない場合、あるいは最初に変更されてから表示される場合、あるいは Web ページのさまざまな部分に表示される場合、あるいはフォーマットが異なる場合などは、おそらく JSON が適切な選択肢です。もしデータが、リレーショナル・データベースにうまく適合するものである場合には、おそらく JSON が適切です。大部分のプログラミング言語では、JSON 用のライブラリーが利用できるようになっているため、JSON はもはや単に JavaScript のためだけのものではありません。
-
複合コンテンツ (文書) 用には XML: ポストするデータにメタデータ (例えば URL など) が要求される場合、あるいはマークアップとテキストがさまざまな割合で入り交じっている場合 (例えばワープロ文書やブログの投稿データなど) には、XML を使います。もしデータが直接 1 ヶ所に表示されるのであれば、そのデータをサーバー上でフォーマットし、単純に Ajax を使ってそのデータを取得し、それを文書の中に直接挿入することができます (この手法はクライアント・サイド・インクルードと呼ばれることがあります)。David が MochiKit の記事 (「参考文献」を参照) の中で示したとおり、最近ではブラウザーに XML を提供し、それを CSS でフォーマットすることもでき、あるいは HTML を提供して、それをスタイリングするかどうかを選択することができます。どの XML を使うべきかに関して細かなガイドラインを示すことはできませんが、少なくとも、そのデータにとって十分適切な標準フォーマット (例えば XHTML や SVG、X3D など) を選ぶべきだ、と言うことはできます。そうすれば、そのフォーマットの小さなサブセットを使うことによって、そのデータを、先々他のシステムとより相互に利用できるようなものにし、また他のプログラマーに理解しやすく、適切に文書化することができます。場合によると、独自の XML フォーマットを作ることでうまくいく場合もありますが、その結果生ずる互換性の問題で苦しまずに済むためには、そのフォーマットを基本的な方法に大きく改善しなければならないかもしれません。もし迷った場合には、Web の共通語、HTML を使うのが得策です。
-
シンジケーションには Atom: ここでは非常に広い意味でシンジケーションを定義しています。もしデータが定期的に更新されるのであれば、そのデータを Atom でラップします。データにタイムスタンプ付ける必要がある場合には、Atom でラップします。基本的に、長期間にわたるデータ・フローに対しては、どんなものにも Atom フォーマットを標準エンベロープとして使います。そうすることによって、アグリゲーターやニュースリーダー、スクリプト・ライブラリーなど既存の多くのツールを利用でき、データの追跡や再利用が可能になります。このようにして、データを Web ページに挿入することができると同時に、ほとんど、あるいはまったく努力せずに、そのデータをシンジケーション・フィードにも利用することができます。
|
逆の選択
今度は、他に考えられるフォーマットを見てみましょう。同じサンプル・データを使いながら、それらのトレードオフと、各フォーマットがどう利用できるかについて説明します。これまでの何回かのコラム (「参考文献」を参照) では、フォーマットの機構に注目するために単純な例を使いましたが、今回は、現実の世界の例からのデータを使います。私の妻の Daniela は詩人であり、雑誌やコンテスト、その他のイベントに投稿したものを注意深く追跡しています。彼女は、それぞれの詩がどの段階にあるのか、どの詩が受け付けられ、あるいは却下され、それぞれの詩に対していくら支払われるのか、各イベントにいくらの費用がかかるか、などの情報を追跡する必要があります。リスト 1 は、そうしたデータの一部を示したものです。これは紙に書かれたものとほとんど同じです。
リスト 1
Room of One's Own
Submitted May 10, '05
* Hyacinth Blue
* Fabrication
* Thanksgiving
* Spilling the Peas
Accepted Hyacinth Blue
Accepted Sept 2005
Published Oct 2006
Paid Sept 2006
Paid $50 + 2 copies
Postage $1.12
Submission Fee: 0
Journal submission
Surrey International Writer's Contest
Contest submission
Submitted Aug. 31 2006
* 13th Child
Fee: $15
Postage: 1.05
Honorable Mention
Prize: $150 + copy of anthology
Accepted Sept. 26 2006
Publication Date Oct. 20 2006
Word on the Street
Public Reading
Invited speaker
Reading time: 10 minutes
Paid: T-shirt and lunch
Date: Sept 24 2006
Paideusis: The Journal of the Canadian Philosophy of \
Education Society
Submitted Oct. 13th 2006
* To carry over: metaphor invents us (seven poems)
Email submission
Referreed Journal
Accepted Oct. 16th 2006
Published (Pending) Nov. 2006
|
これは彼女にとっては十分なのですが、投稿するものが増えてくると、それぞれの詩の状態を追跡することが困難になってきます。その年の彼女の収入と経費を追跡することも次第に困難になります。また彼女は、他の情報、例えば平均的な応答時間 (投稿してから、受け入れられるまで、あるいは却下されるまでの時間) なども抽出したいと思っています。そこで私は彼女のために、「Fame Not Fortune」というアプリケーションを作ることを提案しました。これは Ajax による Web アプリケーションに適したものだと私は思っています。
当然のことながら、私は怠惰なので、新しいアプリケーションを作るよりも既に私達が作成したアプリケーションを使おうと考えました。彼女は詩の編集用に既にワープロとして Open Office (「参考文献」を参照) を使っています。そのため、Open Office のスプレッドシートを使えば追跡ができるかもしれません。図 1 はそれを示したものです。
図 1. Open Office スプレッドシートの例
もう既に、いくつかの問題が起きています。何よりも、スプレッドシートはこうした内容を追跡する上で自然なインターフェースではありません。追跡されるデータは非常に柔軟なため、各項目と一致していない列が多い上、私のターゲット・ユーザー (Daniela) にとって、スプレッドシートを起動することは Web サイトを見るほど自然で簡単でなことではありません。どうやら Web アプリケーションを作成する必要があるという私の直感があたっているようです。もちろん、Open Office は文書を XML で保存するため、より複雑なデータ・マイニングには Open Office を使い、データ入力には Web を使うようにすれば、「両方の良いところ」を組み合わせられるかもしれません。そうであれば、データを 1 つのフォーマットで保持するのは良い考えです。
Open Office では、ファイルの保存フォーマットは .odf ですが、これは実は単なる .zip ファイルであり、この中にはデータ以外に、他のリソース (埋め込み画像、スクリプト、スタイル情報など) が含まれています。この最小化された文書の内部を見ると、下記が見つかります。
- META-INF は、.odf 文書のコンテンツ・リストである manifest.xml を含むフォルダーです。
- Configurations2 は、ステータス・バーやメニューなど、UI に関するものを大量に含むフォルダーです。とりあえず、これを無視しても安全なようです。
- Thumbnails は、私の文書の小さな .png 画像を含むフォルダーです。
- content.xml は、どうやら私が入力した実際のデータのファイルのようです。
- meta.xml は文書に関する情報 (作成者や変更日、その他の詳細など) を含むファイルです。
- mimetype は「application/vnd.oasis.opendocument.spreadsheet」というストリングを含むファイルです。
- settings.xml は、私が Open Office に設定したすべてのプリファレンスを含むファイルのようです。
- styles.xml はスプレッドシートのフォーマット情報を含むファイルです。
以上からすると、Web アプリケーションと Open Office との間でデータを送信しようとする上で関心対象となるのは、.odf ファイル全体ではなく、このファイルの中にある content.xml のみです。この content.xml には、何が含まれているのでしょう。このファイルは、文字数が 17,629 文字で、23 個の XML 名前空間があり、(スタイル用の別ファイルがあるにもかかわらず) 63 行のスタイル情報を持ち、そして個々のセルは各セルごとのスタイル情報を持っています。これらはどれも、デスクトップ用のスプレッドシート・アプリケーションには必要なのかもしれません。しかし私としては、単に構文解析してソートし、破棄するだけのために、不要な情報をネットワークで送信する時間を費やしたくはありません。リスト 2 は比較のために、小さなスニペットである 1 行の実際のデータを示しています。
リスト 2
<table:table-row table:style-name="ro3">
<table:table-cell office:value-type="string">
<text:p>Room of One's Own</text:p>
</table:table-cell>
<table:table-cell table:style-name="Default"
office:value-type="string">
<text:p>Journal</text:p>
</table:table-cell>
<table:table-cell table:style-name="ce2"
office:value-type="string">
<text:p>Hyacinth Blue; Fabrication; Thanksgiving;
Spilling the Peas</text:p>
</table:table-cell>
<table:table-cell table:style-name="ce5"
office:value-type="date" office:date-value="2005-05-10">
<text:p>10 May 2005</text:p>
</table:table-cell>
<table:table-cell table:style-name="ce5"
office:value-type="date" office:date-value="2005-09-01">
<text:p>1 Sep 2005</text:p>
</table:table-cell>
<table:table-cell table:style-name="ce5"
office:value-type="date" office:date-value="2006-10-01">
<text:p>1 Oct 2006</text:p>
</table:table-cell>
<table:table-cell table:style-name="ce5"
office:value-type="date" office:date-value="2006-09-01">
<text:p>1 Sep 2006</text:p>
</table:table-cell>
<table:table-cell office:value-type="string">
<text:p>Hyacinth Blue</text:p>
</table:table-cell>
<table:table-cell table:style-name="ce6"
office:value-type="currency" office:currency="CAD"
office:value="50">
<text:p>50.00 CAD</text:p>
</table:table-cell>
<table:table-cell office:value-type="string">
<text:p>2 Copies of Publication Issue</text:p>
</table:table-cell>
<table:table-cell table:style-name="ce7"
office:value-type="currency" office:currency="CAD"
office:value="1.12">
<text:p>1.12 CAD</text:p>
</table:table-cell>
<table:table-cell table:style-name="ce7" />
<table:table-cell table:number-columns-repeated="244" />
</table:table-row>
|
それほど悪くはありません。それに、他の手段を詳細に検討するためには、これで十分です。データを XHTML の中に埋め込んだらどうなのでしょう。その場合には、データを構文解析したりフォーマットしたりする必要はなく、単純にリスト 3 のように直接表示することができます。
リスト 3
<html><body><ul>
<li><dl>
<dt>publisher</dt><dd>Room of One's Own</dd>
<dt>type</dt><dd>Journal</dd>
<dt>titles</dt><dd><ul>
<li>Hyacinth Blue</li>
<li>Fabrication</li>
<li>Thanksgiving</li>
<li>Spilling the Peas</li>
</ul></dd>
<dt>submitted</dt><dd>2005-05-10</dd>
<dt>accepted</dt><dd>2005-09-01</dd>
<dt>published</dt><dd>2006-10-01</dd>
<dt>payment received</dt><dd>2006-09-01</dd>
<dt>titles accepted</dt><dd><ul>
<li>Hyacinth Blue</li>
</ul></dd>
<dt>expenses</dt><dd><dl>
<dt>postage</dt><dd>CAD 1.12</dd>
</dl></dd>
<dt>payment</dt><dd><ul>
<li>CAD 50.00</li>
<li>2 Copies of Publication Issue</li>
</ul></dd>
</dl></li>
<li><dl>
<dt>publisher</dt>
<dd>Surrey International Writers' Competition</dd>
<dt>type</dt><dd>Contest</dd>
<dt>titles</dt><dd><ul>
<li>The Thirteenth Child</li>
</ul></dd>
<dt>submitted</dt><dd>2006-08-31</dd>
<dt>accepted</dt><dd>2006-09-26</dd>
<dt>published</dt><dd>2006-10-20</dd>
<dt>payment received</dt><dd>2006-10-20</dd>
<dt>titles accepted</dt><dd><ul>
<li>The Thirteenth Child</li>
</ul></dd>
<dt>expenses</dt><dd><dl>
<dt>postage</dt><dd>CAD 1.05</dd>
<dt>entry fee</dt><dd>CAD 15.00</dd>
</dl></dd>
<dt>payment</dt><dd><ul>
<li>CAD 150.00</li>
<li>Honorable Mention</li>
<li>Copy of Anthology</li>
</ul></dd>
</dl></li>
<li><dl>
<dt>publisher</dt><dd>Word on the Street</dd>
<dt>type</dt><dd>Invited Reader</dd>
<dt>event</dt><dd>10 Minutes of readings</dd>
<dt>event date</dt><dd>2006-09-24</dd>
<dt>payment</dt><dd><ul>
<li>T-Shirt</li>
<li>Lunch</li>
</ul></dd>
</dl></li>
<li><dl>
<dt>publisher</dt><dd>Paideusis: The Journal of the
Canadian Philosophy of Education Society</dd>
<dt>type</dt><dd>Refereed Journal</dd>
<dt>titles</dt><dd><ul>
<li>To Carry Over: Metaphor Invents Us (seven poems)</li>
</ul></dd>
<dt>submitted</dt><dd>2006-10-13</dd>
<dt>accepted</dt><dd>2006-10-16</dd>
<dt>published</dt><dd>Pending</dd>
<dt>titles accepted</dt><dd>All</dd>
</dl></li>
</ul></body></html>
|
これは、半構造化データから HTML への、ごく単純なマッピングです。デフォルトのスタイリングは大したものではありませんが、CSS を使ってクロス・プラットフォームの方法で非常に容易に再スタイリングを行うことができます。また、DOM を使ってデータをウォークすることも非常に容易であり、また十分に自己記述的でもあります。追加された HTML コードによって少しコードが膨れ上がっていますが、それほどひどくはありません。この例は XOXO アウトライン・マイクロフォーマット (「参考文献」を参照) に非常に似ており、もし最初の <ul /> 要素に「class="outline"」を追加すれば、XOXO アウトラインになるのではないかと私は思います。カスタムの XML 言語を使ってさらにセマンティック・コンテンツを追加することもできますが (例えば記述リストを <submission/> 要素で置き換えるなど)、この例の場合では、簡潔さの面からも読みやすさの面からも、それによる大きな利点はありません。次は、さらに単純な方向に進み、JSON (JavaScript Object Notation) を使う例を試してみます。
リスト 4
{ "publisher": "Room of One's Own",
"type": "Journal",
"titles": ["Hyacinth Blue", "Fabrication", "Thanksgiving",
"Spilling the Peas"],
"titles accepted": ["Hyacinth Blue"],
"submitted": "2005-05-10",
"accepted": "2005-09-01",
"published": "2006-10-01",
"payment received": "2006-09-01",
"expenses": [{"postage": "CAD 1.12"}],
"payment": ["CAD 50.00", "2 Copies of Publication Issue"]},
{ "publisher": "Surrey International Writers' Competition",
"type": "Contest",
"titles": ["The Thirteenth Child"],
"titles accepted": ["The Thirteenth Child"],
"submitted": "2006-08-31",
"accepted": "2006-09-26",
"published": "2006-10-20",
"payment received": "2006-10-20",
"expenses": [{"postage": "CAD 1.05"},
{"postage": "CAD 15.00"}],
"payment": ["CAD 150.00", "Honorable Mention",
"Copy of Anthology"]},
{ "publisher": "Word on the Street",
"type": "Invited Reader",
"event": "10 Minutes of readings",
"event date": "2006-09-24",
"payment": ["T-Shirt", "Lunch"]},
{ "publisher": "Paideusis: The Journal of the Canadian\
Philosophy of Education Society",
"type": "Refereed Journal",
"titles": ["To Carry Over: Metaphor Invents Us \
(seven poems)"],
"titles accepted": "All",
"submitted": "2006-10-13",
"accepted": "2006-10-16",
"published": "Pending"}
]
|
このリスト 4 では、内容は HTML エンコーディングの場合とまったく同じですが、一層スクリプト化しやすくなっています。これは JSON が単純に JavaScript のサブセットであるためです。データに対して、JavaScript オブジェクトやリスト、ストリングとして直接アクセスすることができます。このフォーマットは単純で簡潔であり、それまでのフォーマットの情報をすべて保持し、また構造もしっかり保持し、しかも半構造化データに対しても十分柔軟しています。これでも十分適切なのですが、さらに単純化することもできます。最初の例に戻り、スプレッドシートを使ってデータを保持します。1 つのスプレッドシートから別のスプレッドシートにデータを転送する場合には、CSV (comma-separated value) を使うのが一般的な方法です。この実績のあるフォーマットを使うと、次のような結果が得られます。
リスト 5
"Publisher", "Type", "Titles", "Submitted", "Accepted/Rejected", \
"Published", "Payment Received", "Titles Accepted", "Payment", \
"In Kind", "Postage", "Fees"
"Room of One's Own", "Journal", "Hyacinth Blue; Fabrication; \
Thanksgiving; Spilling the Peas", 10 May 2005, 1 Sep 2005, \
1 Oct 2006, 1 Sep 2006, "Hyacinth Blue", 50.00 CAD, \
"2 Copies of Publication Issue", 1.12 CAD,
"Surrey International Writer's Competition", "Contest", \
"The Thirteenth Child", 31 Aug 2006, 26 Sep 2006, 20 Oct 2006, \
20 Oct 2006, "The Thirteenth Child", 150.00 CAD, "Honorable Mention, \
Copy of Anthology", 1.05 CAD, 15.00 CAD
"Word on the Street, Vancouver", "Invited Speaker", \
"10 Minutes of Readings", , , 24 Sep 2006, , , , "T-Shirt, Lunch", ,
"Paideusis: The Journal of the Canadian Philosophy of Education \
Society", "Refereed Journal", "To Carry Over: Metaphor Invents Us \
(seven poems)", 13 Oct 2006, 16 Oct 2006, "(Pending) Nov 2006", , \
"All", , , "Email",
|
リスト 5 は、単純さの方向に進みすぎても大丈夫そうなことを示しています。ただしここで、JSON と CSV の間の重要な違いを指摘しておきたいと思います。CSV は一般的な方法ですが、標準化されているわけではなく、通常は ASCII テキストしか想定していません。一方 JSON は、明確に、そして規範的に定義されており、また Unicode の UTF-8 エンコーディングを使うように指定されています。この特定な例では ASCII の範囲外のテキストを何も使っていませんが、JSON (そして XML) は国際化テキストを処理できるのです。
Atom を利用する
Atom 配信フォーマットは、Fame not Fortune が追跡する情報と重複する部分が少しあります (例えば作者や公開日など)。すべてのデータを 1 つのフィードに置き、それからページの XML をフォーマットする方法もありますが、標準のアグリゲーターで追跡することもできます。これは、詩人達の作品追跡を補助するための他のツールと私のアプリケーションとの間の、重要な違いかもしれません。リスト 6 は、この Atom フィードがどのようになるかを示したものです (簡潔にするために、1 つのエントリーしかありません)。
リスト 6
<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
<title>Fame not Fortune</title>
<subtitle>Recent submissions</subtitle>
<link href="http://example.org/famenotfortune"/>
<updated>2006-12-03T20:37:16Z</updated>
<author>
<name>Daniela Elza</name>
</author>
<id>urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6</id>
<entry>
<title>Hyacinth Blue</title>
<link href="http://example.org/famenotfortune/hyacinthblue"/>
<id>urn:uuid:68C0BAAB-C955-45F9-BDD6-21A22FC809AF</id>
<updated>2006-12-01T20:37:16Z</updated>
<published>2006-10-01T12:12:12Z</published>
<category term="Journal"/>
<content type="xhtml">
<div xmlns="http://www.w3.org/1999/xhtml">
<dl>
<dt>publisher</dt><dd>Room of One's Own</dd>
<dt>titles</dt><dd><ul>
<li>Hyacinth Blue</li>
<li>Fabrication</li>
<li>Thanksgiving</li>
<li>Spilling the Peas</li>
</ul></dd>
<dt>submitted</dt><dd>2005-05-10</dd>
<dt>accepted</dt><dd>2005-09-01</dd>
<dt>payment received</dt><dd>2006-09-01</dd>
<dt>expenses</dt><dd><dl>
<dt>postage</dt><dd>CAD 1.12</dd>
</dl></dd>
<dt>payment</dt><dd><ul>
<li>CAD 50.00</li>
<li>2 Copies of Publication Issue</li>
</ul></dd>
</dl>
</div>
</content>
</entry>
</feed>
|
もし上記 (リスト 6) が見慣れたものに見えるとしたら、その理由は、Atom の entry 要素が、送信データに必要な全フィールドを持っていないためです。そのため、大部分のエントリーは上記の XHTML の例であり、<content/> タグで囲まれています。published フィールドと author を他の目的に使いましたが、それ以外は何もしていません。これも実際には published フィールドの濫用であり、本来はこのエントリーの公開日なのであって、このエントリーが含むデータの日付ではありません。追加フィールド用に独自の名前空間を作成し、こうしたフィールドで Atom の entry を拡張することもできますが、既存のアグリゲーターやフィード・リーダーはその情報を利用できず、描画しても見えないため、ここでの目的には意味がありません。単純に XHTML の例を Atom エンベロープの中にラップし、アプリケーションにシンジケーションをサポートさせることもできますが、純粋にデータを重視する観点から見ると、私にとって Atom による利点は何もありません。しかし、私のアプリケーションからデータを外に出したり外からデータを入れたりしたい場合には、Atom の entry にラップし、Atom 出版プロトコル (「参考文献」を参照) を使うととても有効です。ただし Atom を使おうとする場合には、データ・フォーマットが制限されることに注意してください。つまり Atom の <content/> タグで保持できるデータ型としては、テキスト (JSON フォーマットも可能です) と、すべての実体をエスケープした HTML、あるいは XHTML という 3 つに制限されます。最初に Atom を拡張しない限り、任意の XML コンテンツを Atom に埋め込むことはできませんが、そうしたデータに対するリンクを提供することはできます。従って、そのデータのシンジケーション・ストリームを提供したいのかどうかを、早めに決断することが重要です。なぜなら、Atom と統合することによって、他のデータ・フォーマットに対する判断も変わってくるからです。
まとめ
Ajax 対応の Web サイトや Web アプリケーションを構築する場合には、多くの判断を下す必要があります。データのフォーマットをどうするかの判断は、デフォルトのままにされたり、あるいは関連する問題を真剣に考えずに下されることが多すぎるようです。ここでは、少なくともこうした問題を考えるための元となる要素を提供し、判断を下すプロセスを組み立てる際に役立つようにしました。先にあげた大まかな原則を、下記に再掲します。
- データには JSON
- 文書には XML (特に理由がない限り XHTML が好ましい)
- シンジケーションする場合は Atom の中にラップする (そして Atom 出版プロトコルをサポートする)
この記事では数多くの例を挙げながら、フォーマットを考える上でのトレードオフと、私の考える大まかな原則について説明しました。私は何かを証明したわけではありません。ここで示した例はどれも特別な場合について述べたものであり、現実の世界の例の大部分は、どんなルールからも外れた例外ばかりのはずだからです。ここで示したガイドラインは私にとって有効なものですが、皆さんの時間や作業を節約する上でも少しは役立つかもしれません。今後のコラムでは、こうしたガイドラインに基づいて実際にサイトを構築する場合について報告したいと思っています。毎度のことですが、皆さんからの成功例、批判、そして提案なども大いに期待しています。
参考文献 学ぶために
製品や技術を入手するために
- JSON データを安全に構文解析し、シリアライズするための python ライブラリー、Simple JSON を入手してください。
- 皆さんの次期開発プロジェクトを IBM trial software を使って開発してください。developerWorks から直接ダウンロードすることができます。
議論するために
著者について
| 
| | David Mertz氏は多くの分野で活躍しています。ソフトウェア開発や、それについて著述もしています。その他、学術政策理念について分野を問わず、関係する雑誌に記事も書いています。かなり以前には、超限集合論、ロジック、モデル理論などを研究していました。その後、労働組合組織者として活動していました。そして、David Mertz氏自身は人生の半ばにもまだ達していないと思っているので、これから何かほかの仕事をするかもしれません。David Mertz氏の連絡先はmertz@gnosis.cxです。 |
記事の評価
| |
