キマイラ・サイト、あるいはChimairaアーキテクチャの予定は、全然ハッキ リしませんね。予定というからには、時間的な要素を含むべきでしょうが、そ れはわからない。が、なにをやるべきかは割とハッキリしてます。「なにをや るべきか」を言い換えると、問題とか課題です。
というわけで、予定とは言えないけれど、僕が何をやろうとしているかの概 要として、2005年4月時点における問題・課題について、思い付いた順に述べ ます。「問題・課題」といっても、まったく解けてない、見当も付かないもの は載せません。ある程度の見通しが立っているものです。（見通しが外れる事 態もあり得ますが。）
XMLでは、「文書型」、「要素型」という言葉を使うことがあります。が、こ れらの言葉の意味はサッパリわかりません。僕は、理解可能な定義／説明を見 たことがありません -- いや、訂正：例外的に意味がハッキリと取れる言明は 「要素型とは、要素のタグ名のことである」という定義です。これは理解でき ます。が、理解はできても同意はできません。
W3C XML Schema Part1/Part2 では、単純型やら複雑型やらを定義してますが、 これも満足できません。（単純型は、まーけっこう実用的とも言えますが）全 体として、プログラミング言語の型システムとの関係がなんだかわかりません。 「プログラミング言語とは別物なんだ」と言われてしまうと、僕は困りますし、 納得もできません。アドホックにマッピングするのもバカげた話です。
XML的型システム（一種類である必要は全然ありません）が確立して、それが プログラミング言語の型システムとしっかりとした関係を結んでいる状況を期 待しているわけです。
XML的型システムは、構文的にならざるを得ません。これは、生成的／構成的 な型システムです。これを多少抽象化すると、代数仕様に近いもの（代数仕様 そのものと言ってもいいのだけど）になります。サブタイプ／スーパータイ プの型階層は、包含または埋め込みで与えられます。
一方、現在のプログラミング言語とその周辺技術は、（好き嫌いは別にして） オブジェクト指向っぽいものが主流です。オブジェクティブな型システムは、 まったく生成的／構成的ではなくて、観測的です。そして、型階層は射影によ り与えられます。
状況を端的に述べれば、生成的包含的な型システムと、観測的射影的な型シ ステムが、うまく噛み合わないまま併存しているのです。いや、併存といえる ほどに「両者が理解されている状況」にはなっていないでしょう。
生成的包含的な型システムが代数仕様により記述されるのに対して、観測的 射影的な型システムは余代数仕様により記述されます。代数仕様と余代数仕様 は、隠蔽代数仕様で統合されると期待されます。モデルとしては、同一の台集 合上に代数と余代数が共存するような構造でしょう。
構文記述はできるだけ自由にできたほうがいいと思っています。なぜなら、 XMLの応用はものすごく多様（であるべき）なので、各領域が対象とするモノ、 そこに見いだされる構造、その領域固有の要求などもまた、ものすごく多様だ からです。
XMLの構文構造がツリーだからといって、記述対象がツリーだとは限らないし、 対象をツリーに限定するのもヒドイ話です。レコードやテーブルにXMLを使う ことに目くじら立ててもしょうがないじゃないですか。そんなことして何もい いことないでしょう。「つまらない応用だ」とか「それは本来のXMLの使い方 ではない」とかコゴトを言ってみて、それが生産的ですか？
「つまらない応用」でも「ヒドイ使い方」でも、その領域においては理にか なっているかもしれません。問題になるのは、コストが増大してしまったり、 弊害をもたらす場合です。明白な害悪がない限りは、どこの誰がどんな目的で どうXMLを使おうがトヤカク言うべきじゃないと思うのです。これについては 例えば、「XMLボキャブラリ のアンチ・パターン」の「僕のペットたち」の事例を見てください。 「僕のペットたち」を否定しちゃいけない、というのが僕の主張です。そ れと、同じくアンチ・パター ンの「原理主義」のような態度もやめて欲しいわけね(*注1)。
僕（檜山）こそ「XML原理主義者」ではないか、と思われているフシがありま すね。まー、致し方ない面もあります。が、僕が批判の対象としているのは、 かなり広い範囲にわたりコストが増大したり弊害をもたらす場合、 または詐欺みたいな行為であり、「僕のペットたち」的応用を否定したことは ないぞ。ただし、「本来のXMLの使い方」にこだわりがないと言えば嘘になる。 個人的な感覚としての「本来の使い方」はあるのだけど、それに客観的な価値 があると強弁するつもりはないですよ。
と、まー、そんな事情で、考えられる限りの記述対象／データ構造に対して XMLの恩恵が行き渡るようにしたい。正規表現やBNFが便利なのは経験上明らか だし、XMLとも相性がいいから、構文記述としての正規表現やBNFの守備範囲を 拡張するのが当面の課題ですね。「再帰的（あるいは正規な）データ構造」と いうキーワードにより、型システムとの通路も開けそうだし。
「モジュール」、「コンポネント」という2つの言葉は、慣用としての使い分 けはあるでしょうが、本質的に区別する必然性はないよね。要するに、自律的 であると同時に部品となるような単位です。粒度によって「モジュール／コン ポネント」を使い分けるときもあるようですが、 僕は構文側がモジュールでソフトウェア側がコンポネントと呼び分けているだ けです。
構文モジュールの定式化としては、再帰代入系が満足のいくものだと思って います。これは、再帰構造をうまく表現しているし、大域的に（マクロ、また はウルトラ・マクロなスケールで）とてもいい性質を持っています（トレー ス付きモノイド圏）。よって、再帰代入系について完全に記述して、その性質 を調べる必要があります。
構文モジュールからソフトウェア・コンポネントが作り出せるかというと、 そんなうまい話があるわけないですね。構文モジュールから自動的に、まと もなソフトウェア・コンポネントは作れません。ですが、構文モジュールの 全体を、ソフトウェア・コンポネント全体のなかの骨格のような形に埋め込む ことができます。
この埋め込みを構成することは、けっこうな作業を要するのだけど、 Chimairaの主要な背景になるハズのものなので、避けて通ることはできません。 作業的に面倒ではあるけれど、前例というかお手本はあります。 P. Katis, N.Sabadini, R.F.C. Walters の3人組による論文"Bicategories of processes"（1995頃、出版は1997）、"Feedback, trace and fixed-point semantics" （2002くらい）に、構成法が書いてあります(*注2)。
"Bicategories .."のほうは、2005年4月の時点で CiteSeer.ISTから入手できます： Bicategories of Processes (1997)。"Feedback, .."は、最近探したら無料では入手困難のようです。 ただし、同じタイトルのスライドがあります： http://cometa.dimi.uniud.it/meetings/kickoff/walters.pdf。
型システム、構文論、モジュール／コンポネント、いずれに対しても、筋書 きと手法（少なくとも指針）は存在します。これらの指針は十分に信頼できる ものなので、Chimairaが想定している状況において具体化すること、細部を詰 めることが実際の作業ですね、面倒なんだけどさー。