前回の直接的な続きです。マイクロアプリケーションのソフトウェアとしての特徴を再掲しておきます（項目の順番は換えてある）。
- 実装言語：JavaScript
- 実行環境：Webブラウザ
- 画面表示：ブラウザのHTMLレンダリング機能を使う
- イベント：ブラウザが生成するイベントをJavaScriptのハンドラーで処理
- データ入出力：文書の一部をデータとみなすか、XMLHttpによるリモートIO
●プログラミング言語と実行環境
まず、アプリケーション開発言語はJavaScriptです。ですから、JavaScriptを、Webページに動きを付けるとか、Webデザインのオマケという位置づけではなくて、プログラミング言語として捉える必要があります。「プログラマのためのJavaScript」シリーズは、そのような観点からJavaScriptを見直す目的で書き始めたものです（まだ続く予定です）。
いまやJavaScriptは、Webブラウザだけではなく、さまざまな実行環境に組み込まれていますが、マイクロアプリケーションの舞台はブラウザです。画面表示とイベント処理に関しては、ブラウザという環境に制約されます。ネイティブアプリケーションのように、自分で描画（draw, paint）をしたり、低水準のイベントを取得する手段はありません。一方、ブラウザが色々な面倒をみてくれるので楽ちんな面もあります。
●データ形式
マイクロアプリケーションが扱うデータは、文書の一部かリモートIOの結果です。文書の一部とは、つまりマイクロ文書ですね。多くの場合は、マイクロ文書はデータであると同時に表示領域も兼ねているでしょうが、（headなどに含まれて）不可視のマイクロ文書もありえます。リモートIOは、XMLHttpで行われるので、データはテキストデータです。バイナリデータはImageオブジェクトを使ってロードされる画像に限られるでしょう（JavaScriptでバイナリを扱うのはうれしくないから）。
まとめれば、マイクロアプリケーションのデータは：
- (X)HTML文書の一部である要素やフラグメント
- ロードされたXML文書（DOMツリー）
- ロードされた非XMLテキスト形式（JSONなど）データ
- JavaScriptコードから作られた文字列やオブジェクト
フォーマットに注目すれば：
ここで、「それ以外のXML」はXML一般（generic XML）を指していません。広義のWebサービスのためにやり取りされる形式、特にRSSやAtomのような軽量メタデータ形式でしょう。RSSなどの一部に使用されてしまっているケースを除けば、RDFは対象外だと僕は思っています。RDFはとてもmicroだとは思えないからです。
いま説明したような、「単純、軽量、既存、よく使われている」なデータをマイクロデータと呼びましょう（なんでも「マイクロ」を付けるのが、そろそろ悪のりぎみかもしれない）。
- マイクロデータの記述形式が広義のマイクロフォーマットである。
- マイクロフォーマットで記述されたデータがマイクロデータである。（上と同義）
- (X)HTMLに埋め込み、または刷り込みされたマイクロデータがマイクロ文書である。
- hCard, hCalendar, hReviewは、刷り込みマイクロ文書のためのフォーマットの例である。
- Hatena Account Auto-Discoveryは、埋め込みマイクロ文書のためのフォーマットの例である。
- JSON、カンマ区切りは、非XMLのマイクロフォーマットの例である。
- マイクロデータは、ほとんど常にHTTPで転送される。
●もう一度、考え方
マイクロアプリケーション（microapplications）は、micro* の中心概念です。しかしこれは、HTML（文書記述形式）、HTTP（転送プロトコル）、ブラウザ（実際に動くソフトウェア）という、日常化／普遍化した既存技術の応用に過ぎません。
あえて「micro + application + s」から造語したのは、考え方、態度に名前を付けるためです。「マイクロアプリケーション」とは、アプリケーションに対する考え方／態度と、その考え方／態度により作られたアプリケーション達を総称する言葉です。
建物（家やオフィス）に例えるなら、microな立場は、新築（イノベーション）をするのではなくて改築（リノベーション）です。旧い素材を使い回すので、耐震性や寿命に期待は持てませんが、それでも、見違えるほどに快適になる可能性はあるし、作業は日曜大工でも進行します。改築の範囲内で斬新さをねらえるかもしれません。
考えてみる／やってみる価値はありそうでしょ。
