[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[mhc:00678] Re: Re-structuring of existing header grammer ( was: High-speed and improved MHC )



おおっと。そうですね、完全に混乱してました。では改めて。


>> On Thu, 1 Jun 2000 14:35:30 +0900
>> "nom" == nom@xxxxxxxxxxxxxxxxxxx (Yoshinari NOMURA) said as follows:

nom> X-SC-Schedule:
nom> X-SC-Record-Id: xxx
nom> X-SC-Schedule:
nom> X-SC-Record-Id: yyy

nom> と書くとどうなるのかということです。
nom> X-SC-Record-Id: は 1 *ファイル中* に 1個のみなのかということです。

私は X-SC-Record-Id: は1つのファイルに対して1つだけで良いと、考えてい
ます。理由としては、X-SC-Record-Id: はスケジュールファイルの同期のため
に存在していると思うからです。


nom> (5) X-SC-Subject: は 1ファイル中に 複数書いてもいいのか?
nom> これは OK のようですが、何か本体の目的と違って来そうではないか?

1つのスケジュール内に複数書いても、単に上書きされる、というのでいいん
じゃないでしょうか。


nom> # こっちは、1 X-SC-Schedule: 中に の話。
nom> なるほど。 `,' がまずいのは、納得です。 では、';' は? :-)

単なる癖と言えないこともないですが、英文の中で , よりも ; の方が意味的
な分離の度合いは大きくないですか?


nom> & がなぜないんだ? に関しては 「いらないから」 ではだめでしょうか。

| があるのに、& がないのは、私としては、文法の設計に直交性が欠けている、
と感じます。で、直交性が欠けた構文規則はユーザーにとって覚えやすいもの
ではないと思うので、出来るだけ直感的な直交性のある設計にしておくべきで
はないでしょうか。


nom> 1つの X-SC-Schedule: 内で、

nom> Record-Id:         -- 1個しか書けない (1 File 中でも 1個のみ)

nom> Cond,Day,Duration: -- 複数書ける (or と取る)

nom> Time: Category:   --  1個しか書けない (書いてもいいが、
nom> Cond: Duration:       どれが採用されるか保証しない)
nom> Alarm:

nom> となるので、「全部1個しか書けない」 の方がいいと判断したのですが。

むう。

えっと、1個しか書けないヘッダは全てスケジュールの内容を規定するヘッダ
であるのに対して、複数書けるものはスケジュールの条件を規定するものです
から、性質が違うのは当然なんじゃないかと。

設計上の問題としては、ヘッダ内に更に構造を規定する必要が生じると、ヘッ
ダの構造解析がややこしくなるので、これも避けたい。

## X-SC-Schedule: に関しては、やむを得ないので、楽をする方法を思案中。


>> On Thu, 1 Jun 2000 14:44:04 +0900
>> "nom" == nom@xxxxxxxxxxxxxxxxxxx (Yoshinari NOMURA) said as follows:

土> X-SC-Cond: At Wednesday, 2nd week, March
nom> 面白いけど、サービス過剰じゃないかな :-)

そうかなぁ。乃村さんも、以前のメールで「理想的なのは自然言語」って言っ
てらっしゃるじゃないですか。もうちょっといじると、

    X-SC-Cond: In the last week of May

なんてのも可、なんですけど。


nom> 変にこのへんの許容範囲を広げるのは止めませんか。
nom> 内部データ構造から、Dump したりして逆変換したら、消えちゃうので、

これに関しては、設計次第で切り抜けられると思います。

例えば、TSU_SPEED 枝の実装は、内部データ構造から元々のヘッダを復元でき
るようにする、という考え方を全面的に捨てて、「とにかく速く解析できる内
部データ構造にする」という思想で設計されています。

この方針では、ヘッダを変更する必要が生じた場合は、逐一、もともとのファ
イルを参照する必要が生じるためにちょっと面倒ですが、既存のスケジュール
ファイルを編集するという作業に対して、スケジュールファイルを表示すると
いう作業の方が圧倒的に多いので、速度という観点では有利になります。


nom> 「何で突然 At が {消え|付い} たりするんじゃ」
nom> 「俺は、Wednesday と書いたのに、Wed に戻すな」
nom> という苦情が出そうだし。絶対、Wednesday の綴りを間違えるから。:-)

これは、M-TAB とかで completion が効くように、mhc-draft-mode を改善す
れば大丈夫でしょう。


-- 
土屋 雅稔  ( TSUCHIYA Masatoshi )
    http://www-nagao.kuee.kyoto-u.ac.jp/member/tsuchiya/