このブログは、旧・はてなダイアリー「檜山正幸のキマイラ飼育記 メモ編」（http://d.hatena.ne.jp/m-hiyama-memo/）のデータを移行・保存したものであり、今後（2019年1月以降）更新の予定はありません。

今後の更新は、新しいブログ http://m-hiyama-memo.hatenablog.com/ で行います。

micro* (3)：microapplications

雑記／備忘

本編「micro* (3)：microapplications」のコピー。

出かける準備で早起きしました。あわただしいので中途半端な記述ですが、micro*シリーズその3（の断片）を投稿してから出発します。

マイクロアプリケーション（microapplication）とは、とりあえずはマイクロ文書を扱うプログラムだと定義できます。しかし、OS上で直接動くネイティブアプリケーションやサーバサイドWebアプリケーションではなくて、ブラウザー上（クライアントサイド）で動作するJavaScriptプログラムです。

マイクロアプリケーションのソフトウェアとしての特徴は：

  • 実行環境：Webブラウザ
  • 実装言語：JavaScript
  • 画面表示：ブラウザのHTMLレンダリング機能を使う
  • イベント：ブラウザが生成するイベントをJavaScriptのハンドラーで処理
  • データ入出力：文書の一部をデータとみなすか、XMLHttpによるリモートIO

Ajaxにより再発見・再認識されたXMLHttpコンポネントは、マイクロアプリケーションに対して、ブラウザの外とのIO手段を与えます。その他は、特に目新しいことはありませんが、マイクロアプリケーションは次のような意図を持っています。

  1. マイクロ文書に対する対話的フロントエンドを提供する。したがって、広義の（microformats.orgで策定されたものにかぎらない）マイクロフォーマットに関係する。
  2. お手軽さを失わない範囲で、再利用／共有可能性、相互運用性を意識する。
  3. （上の項の一部だが）できるならば表示先が何であるか（bodyかdivか、windowかframeかiframeかなど）に独立な作りにする。
  4. これらの目的のために、“あるコンベンション”に従う。

広義のマイクロフォーマットで記述されたマイクロ文書というデータに、マイクロアプリケーションが対話的振る舞いを与える、という構図です。

問題は、「あるコンベンション」がどうあるべきか／どう決めるか、ですが、それを今後提案できればと思っています。いずれにしても、microなコンベンションですから、最小限の規則集であり、非制限的なものです。コンベンションに沿ったマイクロアプリケーションをサポートするフレームワークがあれば便利でしょうが、フレームワーク必須にすると制限的になってしまうので好ましくありません。

もっと詳しいことは、またいずれ。

micro* (1): microな考え方／やり方

雑記／備忘

本編「micro* (1): microな考え方／やり方」のコピー。

microformatsが、どうして"micro"という言葉を選んだのか、どうも腑に落ちない感じがしました。（だって、Microsoftだってmicroだし。）

武田の近況報告「Microformats (とSemantic Web）」とAmazon Web サービス ブログ「Microformats 運動」を引用してみます。なお、ブラケット内は僕が挿入したものです。

そもそも[なぜ]Microなのかというと，既存の大量な詳細なドキュメントで規定される人間が読むことができないようなフォーマット("megaformat!")に対して，format自身も小さいし，簡単に理解できるようなフォーマットだから，ということでしょう．

Microformats運動は、必ずしも新しい形式を作るのではなく、現在動いている既存の方法にほんの少し手を加えて、多くの人が共通に悩んでいる問題にシンプルな解を提供し、かつそれによって今動いている仕組みには最小限の影響しか与えないことを目指しています。

大げさ大規模ではない、少ない手間でそれなりの効果を得る、変更を最小化する、というようなところがマイクロ（極小、微少／微小）なんでしょうかね。

で、言葉自体の詮索＜せんさく＞はやめて、microという形容詞を「microformatsの意味におけるmicro」だと解釈すると、その背後には、なにかmicro主義とか、microの哲学とでも呼ぶような発想があるような気がします。もっとも、「主義」とか「哲学」という大仰＜おおぎょう＞な言葉はmicroじゃないので、“microな考え方／やり方”と呼んでおきましょう。

「Microformats (とSemantic Web）」から再び引用します：

推進しているご当人のよると，microformatsの基本理念とは

  1. 特定の問題を解け
  2. できるだけ簡単に...発展的な改良
  3. 人が先,機械は後... 表示可能で処理可能，現状のやり方に合わせろ
  4. いまあるスタンダードを使いまわせ... semantic (X)HTML, RFC
  5. モジュラリティと埋め込み可能性

だそうです

これは、ソフトウェアツールズ、したがってパイプ＆フィルターに通じるものを感じます。ソフトウェアツールズ的発想は、新しいプログラムはできるだけ書かずに、ひとつのことを上手にこなす小さな既存ツールを組み合わせろ、ってことですから。

実際の個別format仕様（hCard, hReviewなど）を見ると、ショボイ感じがするのですが、そのショボサがmicroさであり、メリットにつながっているようです。つまり、誰でも短時間で理解できて、今すぐそれで何かをできる、ということ。

僕は、基礎から作り直すアプローチも嫌いではない（いや、好きかな）けど、基盤整備に時間がかかって「いつになったら、やりたいことができるんだよー」というイライラ感も理解できるし、自分もイライラしたりしますから、microな（あるいはminiな）アプローチの必要性もけっこう切実に感じます。

僕自身のバイアスを入れて、microな考え方／やり方をまとめれば、まずは、単純（simple）、軽量（lightweight）、枯れた既存技術の（新しい）組み合わせ（a (new) combination of mature technologies）であること；この特徴は分かりやすいでしょ。

それと、非制限的（nonrestrictive）って条件が入るかな；非制限的とは、そのアーキテクチャやフレームワーク全体の使用を強要しないってことです。all or nothingみたいなことではなくて、利用したい人は一部分だけを選んで使ってもよいし、それでもちゃんと役に立つ、と。その技術や手法の体系内にロックインしないということです。

microな方法は、短期的な解決策である可能性が高いから、ロックインしたりしたらダメです。そして、現状うまくいっているものにインパクトを与えてもまずい。今の不便さを解消して、何かをできるようにする（enabling）けど、囲い込み（encompassing）はしないようなやり方。

このような考え方／やり方をmicroなんだと捉えれば、formats以外にも適用が可能なんじゃないでしょうか。それで、ワイルドカードのつもりのスターを付けてmicro*って見出しを付けたのです。… 続くかもしれない。

micro* (2)：microdocuments

雑記／備忘

本編「micro* (2)：microdocuments」のコピー。

"micro"という形容詞に、microformatsの背後にある理念が込められている、という（ひょっとすると僕の勝手な）前提に基づき、その理念に沿ったナニモノカの総称としてmicro*を提案しました。それが前回。

さてと、micro*のワイルドカード部にdocumentsを代入してmicrodocumentsって概念をひねり出しましょう。最初に注意：実は、"micro-document architecture"って言葉は、OmniMarkという会社（今はStiloって会社になっている）が随分と昔（10年くらいたつだろうか?）から提唱していた方式の名前です。よって、microdocumentsって言葉の使用は問題ありかもしれない。が、とりあえず僕が私的に使うだけならいいでしょう、たぶん。

●microdocumentの概念

microformatsのなかで、hCard, hCalendar, hReviewなどは、多重マークアップ・ベースのボキャブラリと考えられます。これらのボキャブラリでマークアップされた(X)HTML文書の一部分をマイクロ文書（microdocument）と呼びましょう。つまり、記述言語がmicroformats（のなかの特定フォーマット）で、その記述言語で書かれた文書内文書（documents within a document）がマイクロ文書です。（後で、もう少し定義を拡張します。）

前回、マイクロの意味は「単純、軽量、既存技術の組み合わせ、非制限的」と説明しましたが、マイクロ文書のマイクロは、辞書的な意味である「小規模、空間的に狭い、細粒度」などと解釈してもツジツマがあいます。

マイクロ文書は、構文的には完結した文書とはかぎらない、文書の一部分です。しかし、意味的には自立している情報担体＜じょうほうたんたい；information bearing oobject＞です。たとえば、hCardフォーマットで記述された部分は、そこだけ切り取っても名刺情報として意味を持ちます。

●XML複合文書との違い

マイクロ文書は、一般的なXML複合文書の構成素（成分文書）とは違う概念です。例えば、vCard（RFC2426）情報を次のようにXMLエンコードするほうが正統派ですが、それはマイクロな解決策ではありません。



<vc:vCard xmlns:vc="Namespace URI for XML-encoded vCard">

 ...

</vc:vCard>

僕は、「マイクロ」に、時間的にもマイクロであること、つまり短期的解決であること、もっと言えば「当座しのぎ」的な意味を含めています。その代わり、「今すぐ使える」、「既にあるものだけで間にあう」、「現状にインパクトを与えない」などのメリットがあります。

上のような正統派のXMLエンコーディングでは、ブラウザ表示に悪影響を与えますし、取り扱いには新しい技術を必要とするので、「マイクロじゃない」と判断するのです。

ここいらのことも含めて、もう一度マイクロ文書を定義すると：

  1. 構文的には、(X)HTML文書の要素、または（単一要素とはかぎらない）フラグメントである。
  2. 意味的には、そこだけで自立しており、そこだけを取り出して扱える。（ただし、もとの(X)HTML文書との関連が重要なこともある。）
  3. Webブラウザーの表示に悪影響を与えない（brwoser-friendly）。
  4. そのフォーマットを知っているアプリケーション（microdocument-aware applications/tools）により抽出したり操作したりできる。

●埋め込みと刷り込み

マイクロ文書は、ホスティング環境である(X)HTML文書に寄生して運ばれます。これは、「埋め込まれている」と言ってもいいのですが、hCardなどはホスト文書への“入り込み方”がMathMLなどの埋め込みとは異なります。次の例を見てください。



<div class="vcard">

 <a class="url fn" href="http://www.chimaira.org/">

  檜山正幸

 </a>

 <div class="org">檜山正幸事務所</div>

</div>

class属性を意識しなければ（無視すれば）、これは単なるdiv要素に過ぎません。vCardとしての意味を与える情報は、class属性を通じて、あたかも“透かし”のように刷り込まれているのです。

しかし、すべてのマイクロ文書が刷り込み（imprint）方式で寄生しているわけではありません。例えば、はてなのAccount Auto-Discovery情報は埋め込まれています。あるいは、次のようなhead内のフラグメントもマイクロ文書と考えていいでしょう。



 <title>マイクロ文書について</title>

 <meta name="DC.creator " content="檜山正幸" />

 <meta name="DC.date" content="2005-08-20" />

●まとめと注意

マイクロ文書は、(X)HTMLへの寄生を意図した（いろいろな意味で）小さな情報単位です。本格的な複合文書とは少し違った方式で、単一文書へ多様な情報の埋め込み／刷り込みを可能とします。

何度か触れているように、マイクロなアプローチは、本格的で重い手法をあえて避けているので、長期的（時間的マクロ）な視点では問題点とリスクを抱えています。しかし、お手軽さと即効性が魅力です。

micro* の続きはたぶんある、けど、来週は休み。