「主要な話題」で述べたように、このサイトはXMLのサイ トであり、Chimaira（キマイラ）という名の文書／ソフトウェアに関するアー キテクチャを紹介・説明するのが目的である -- しばらくはそう見えないにし ても。
さて、Chimairaのソフトウェア的な側面はコンポネント・アーキテクチャな のだが、このコンポネント・アーキテクチャは、Chimairaのなかでも 重要な構成要素となるはずだ。そこで、この記事では、XMLとコンポネント・ アーキテクチャの関わりに触れておく。
ここ数年の僕の経験から、XML処理（特に対話的な処理）ではコンポネント・ アーキテクチャが絶対に必要であると言える（そのコンポネント・アーキテク チャがXML専用、対話的処理専用である必要はないが）。実際に、実験的コン ポネント・アーキテクチャを構想したり実装したりしてみて、ある程度うまく いくことも確認できた。が、反省点も数多い。
反省点、問題点は、実験的コンポネント・アーキテクチャが生まれ育った経 緯にも関係するのだが、要するに、暗黙の複雑性や不整合が混じり込んでしまっ たということだ。ここで、「暗黙の複雑性や不整合」とは、手に負えないよう なたぐいのものではない。問題は、それが“暗黙である”ことだ。まともな処 理を実現する機構では、ある程度の複雑性はいたしかたないが、それは明示的 でなくてはならない。
「暗黙の複雑性や不整合」に気が付いたのは、それを他人に説明するときに うまく説明できないという経験による。まー、僕は割と説明がうまいほうだか ら :-) 、ある種のレトリック（語り口のテクニック）で分かったつもりにさせることはでき る。が、どうもホントには分かっていないらしい。なぜか？ 関与している当人 達が、「簡単だ、単純だ」と思っていることでも、背後に相当な前提が含まれ ている。これが明示化されていなから、結局は他人には分からないのである。 この「他人には分からない」という特徴(?)は、ときには致命的な欠点になる。
暗黙の前提を大量に持ちながら、「これは単純です」と言うのはよろしくな い。そこでChimairaでは、前提やスコープをできるだけ明示化したい。
一般論として、前提やスコープを明示化しようとすると、それに関する記述 の量が増える。その記述を書くほうも読むほうも労力が増える。だから、労力 を減らすために、特定集団で共有された常識（つまりこれが暗黙の前提）に頼 ることになる。場合によって、特定集団（あるいは特定個人）の常識や能力に 頼るのは非常に有効だと思うのだが、先に指摘したとおり、それが暗黙の（当 人達にとってはそれと意識されない）複雑性や不整合を生み出すこともある。
僕は、特定集団／個人の暗黙的知識／能力を否定しないが（それどころか、 おおいに評価するが）、ここでは、明示的な前提から議論を組み立て、その議 論のスコープもハッキリとさせる（境界線を引く）ために労力をさきたい。
この記事の冒頭で僕はこう書いた（強調の修飾はいま追加）。
このサイトはXMLのサイトであり、Chimaira（キマイラ）という名の 文書／ソフトウェアに関するアーキテクチャを紹介・説明するのが目的である -- しばらくはそう見えないにしても。
なぜに「そう見えない」かというと、XMLやソフトウェアの具体的な話より は、背景の説明や理論的な準備が先行すると思うからだ。こういう順序で話を 進めることにはいくつかの理由がある。いたしかたない事情もあるのだが、前提 をまず明示化したいという動機も幾分かはある（メインは他の事情）。
僕は、現場（開発者）と関わるときは、理屈っぽい話はしないようにしてい る。あまりウケがよくない。あくびをされたり、けむたがられるのが関の山だ。 だが、ここ（Chimairaサイト）では、あえて理論から入ろうと意図している。 もちろん、理論だけでは不親切だし、あくびをされたり、けむたがられる（い や、ハナから読んでもらえない）だろうから、いずれだんだんには具体的な話 をしたいとは思っている。
コンポネント・アーキテクチャに話を戻そう -- 今までの僕の試行錯誤を整 理すれば、コンポネント・アーキテクチャとは、いくつかのトレース付きモノ イド圏（traced monoidal categories）のソフトウェア的な実現だろうと思っ ている。ここで、多くの人は「トレース付きモノイド圏」で、「…って、それ なに？」と反応するだろう。だからこそ、このサイトでは、圏論、形式言語理 論、計算科学など（これらの領域は重複しているが）の記事群を揃えようと思っ ているのだ。
記事が揃っていない今の段階でいろいろ言ってもしょうがない（説得力がな い）のだが、やたらに理屈っぽいと思えるかもしれないこのサイトが、非常に 具体的な問題意識から出発している、とは明言しておきたい(*注1)。
僕は十数年も前から、「理屈っぽい」とか「フォルマリストだ」とか（揶揄 的に）言われている。確かに、議論に大げさな道具を持ち出す傾向があるから、 それを否定はしない。だが、僕と一緒に仕事をしたプログラマ／技術者達は、 僕が具体的／個別的な問題にいつもこだわっている事をよく知っているだろう。 それらの問題を解くためには“手段を選ばない”。それで結果的に、大道具を持ち出 すこともあるってことだ。
最後に予告をしておく。予告の常として、先のことを言うのだから、あてに はならない。
Chimairaのコンポネント・アーキテクチャ部分を、「Janus（ヤヌス）」と呼 ぼうと思っている。Janusは1つの頭に2つの顔を持つ神である -- この言葉 "Janus"（双面神）は、僕が考えているコンポネントの主要な特徴をよく表し ている。つまり、コンポネントは2つの顔（面）を持つ。
いま詳論はしないが（予告だけね）、Junusコンポネント・アーキテクチャは、 Unix流のパイプ＆フィルターの正統な後継だと僕は思っている。対話的システ ムのアーキテクチャル・モデルであるMVCやPACもJanusの守備範囲に入る（た ぶん）。
Janusコンポネントの全体は、トレース付きモノイド圏になるが、実はもっと 強く、コンパクト閉圏になる。Janusコンポネント実装まですべて考えると、 そうしてできる圏のhom-setは、実装の変形（リファクタリングみたいなもの だ）を射とする圏になるから、双圏（bicategory）構造も持つ。多くの圏が、 このコンパクト閉双圏に構造を保って埋め込める。だから、Junusコンポネン ト・アーキテクチャは、まずまずの一般性を持つと期待できる。