ｆｋｉｓｓ、補足です。

  メールで送ったことの延長で、いささか個人的な意見だと思います。きつ
く聞こえると思いますが、ｆｋｉｓｓの現状に危惧しているためだと思って
ください。

＞>　個人的な感触としては、ＫＩＳＳは今、微妙な時期だと思うのです。過
＞>去の技術的資産に支えられて fkissが広まるか、混乱の中で消滅するか。
＞>個人的には、『データは社会的資産』だと思うので、継続的に大勢が共有
＞>できる道を選択してほしいのです。
＞
＞これについては以前コメントしましたが，
＞あまりスマートとは思えないfkissの拡張機能を
＞そのまま正式採用して欲しくありません．

  このあたりの記述が誤解を招きそうですね。ボクが言わんとしているのは、
ひとえに、『早く新規格をきっちりして欲しい』ということです。ボク自身
も現ｆｋｉｓｓの記述はスマートでは無いと思っていますが、このままずる
ずる行くと、（ＫＩＳＳの分裂を避けるには）ｆｋｉｓｓの記述も互換性の
ために認めて行かなければならなくなるということです。
  現ｆｋｉｓｓによるデータが広まり、データ作者さんが増えてからでは、
互換性の無い新規格が（記述がきれいだといっても）急速に置き替わるかど
うか、そして、古い規格で作られたデータがどうなるか、難しい問題だと思
うのです。一般のユーザには、どちらが（その時点で）すばらしいデータが
多いかが関心なのです。時期を失すれば、ローダ側で、両者をサポートせざ
るを得ないような事にもなりかねませんよ！  それこそ、最もきたない結末
だと思います。


＞セルの表示/非表示をきりかえる等の基本的な機能とか
＞そのトリガとなる条件等は，どっちみち必要わけですから
＞基本的な考え方はそう変化しないだろうとも思います．

  現行の規格の条件は最低必要な線だと思います。だから、記述の方法は変
わることがあっても、プログラムの実行部分は、そう大きくは変わらないで
しょう。（最大の問題は、エラー処理でしょうね）

＞結局問題になるのがcnfの記述方法です．
＞fkissでは拡張機能の記述についてイベント駆動っぽさを強調した
＞つもりだったのですが，慣れてない人には解りにくいかなー
＞とも思いました．はたしてどんなもんでしょうか？

  指定のしかた自体は、他に良い工夫は無いでしょう。正式規格となれば、
普通のＫＩＳＳローダでの動作を気にしなくても良いので、クリックやタイ
マで map/unmapされるセルを組みにした所に条件を記述するという方式も判
りやすいですね。でも、ひとつのアクションで複数の動作をすることも考え
ると、現行の方式の方が優れていると思います。
  記述を明確にするなら、ＭＳ窓のとかのＩＮＩファイルのようにセクショ
ン別に記述する方が良いと思います。

  従来のＫＩＳＳのＣＮＦは、記号や記述順に依存したシンボリックな物で
した。マシン語やらアセンブラって、古いプログラマには、タイプ量も少な
くて、すっきりしてて好きなんですが。でも、ＨＴＭＬやらＪＡＶＡやら、
スクリプト的な物が今の流行みたいですね。ＪＡＶＡに比べれば、ｆｋｉｓｓ
の方が簡単のような。（うちのホームページのＨＴＭＬはエディタで書いて
ます。友人に話すと、あれは専用のツールが要ると思っていたようです。）
記述が面倒なら、スクリプトを生成するツールを使うのが時流なんでしょう。

  プログラム側から言うと、スクリプトのパーサよりは、機械的なデコード
の方がサイズが小さくなるでしょうが、ＫＩＳＳ自体が、すでにＤＯＳでは
辛い物になっているので、サイズよりもコーディングですね。
  スクリプト指向なら、いっそのこと、ＣＮＦ全体をスクリプト的にするの
も方法でしょうね。 orderセクションとか、locateセクションとか作って。
（この際の互換性については、ｆｋｉｓｓローダが解釈できるヘッダの付い
ていないＣＮＦを指定されると、従来のKISS.EXEを起動するという方法で簡
単に対応できますね。この点で、将来を見通して、ヘッダを記述するように
規定するのが良いですね。）

  ただし、理想を追求するあまり、時流を逃すことはいちばん避けて欲しい
点です。ＣＧで言えば、ＰＩＣ２みたいな（失礼）ことでは。


＞現時点でいちばんマシなテクニカルノートは
＞fkissの配布アーカイブにはいってる kisseve.c です．
＞といってもソース読め！ってことじゃなくて
＞最初にコメントがあるんで，それを参照して欲しいってことです．

  これをテクニカルノートと言うのは問題があると思います。これは、プロ
グラマ側の開発仕様書。これを中心に進めると、『バグも仕様』の世界です。
この上位に、ユーザ向けの規格書があるべきです。これは、『○○の機能は
このようにして使用する』といった物であるべきです。

  一方、私の言うテクニカルノートというのは、使用上、実装上のガイドラ
インのような物です。『○○とするよりも××とする方が望ましい』とか『
△△するには○○すると良い』『××は△△でうまく働かないので避けるべ
きである』といった情報です。
  これを問題が出るごとに順次リリースすることで、規格の上での灰色の部
分を少しでも避けることができ、データ作者さんも安心できるると思うから
です。

＞ソースコードの次に間違いのないドキュメントといえると思います．
＞Niftyやwebサイトでの配布よろしくお願いします．

  前述のとうりの理由で、個人的には現状でのｆｋｉｓｓの普及には懸念を
持っており、転載などを控えております。でも、Ｎｉｆｔｙでは、ローダを
探すユーザさんの書き込みとかが続いて、現在では、ローダもＵＰされてい
ます。しかし、書き込みを見ると、ｆｋｉｓｓを作ってみようかしら、でも、
規格が変わるなら待つべきか・・という感じの書き込みがいくつも見られま
す。これにどう答えるかが問題です。作ってみたいという意欲に水を差すの
もどうかと思うし・・・・
  これが相互コミュニケーションの取りにくい（ここのような論議が成りた
たない。たとえば、Ｎｉｆｔｙでも、プログラム開発者側の発言が無いので、
何人かがココの話を中継しているような状態ですから）所に、公表に近い形
で配布するというのには抵抗を感じます。たとえば、米国のサイトを見た感
じでいうと、まさに次世代ＫＩＳＳはこうなるという（すでに規格化されて
いるような）扱いで、ちょっと困惑しております。

		ほんとに、今が肝心な時だと思っています。
					ＭＡＲＳ