chise-db

[Koichi KAMICHI]

上地です。

> > > > １）featureとby_featureの対称性

> system-char-id をなるべく UCS の code point に合わせるという小細工は維
> 持し、system-char-id と =ucs の値が一致すれば =ucs の値を省略する小細
> 工はやめるというのはどうでしょうか？

素晴らしいと思います。

> API ありました。すっかり忘れてました。(^_^;;;
> 
> chise_feature_set_property_value (CHISE_Feature feature,
> chise_feature_load_property_value (CHISE_Feature feature,
> chise_feature_gets_property_value (CHISE_Feature feature,

あ、これでしたか。

> > > ;; 関数 chise_ccs_decode と関数 chise_char_load_feature_value 等で
> > > ;; 継承をサポートするか、別に継承サポート版を作るべきだと思ってい
> > > ;; るのですが、どっちの方針で行くか決心が付いてません。ご意見くだ
> > > ;; さい。

まだ使っていないのでなんともいえないのですが、この継承関係は人の主観で変
化する可能性はありますか？ないのでしたら関数に引数１つ加えて継承の有無を
選択できると便利だと思います。継承をサポートする検索は必要になってくるの
で、あると嬉しいです。

> libchise を一般化した libconcord を作ろうとしているのですが、その際、
> やってしまいます。
> 
> ;; ちなみに、文字素性の継承、文字定義の継承のサポートの問題もあり、
> ;; libchise の API をいじりたいと思っているのですが、その際、既存の 
> ;; API に対する backward compatibility はあった方が良いでしょうか？ま
> ;; たその場合、ABI も同様でしょうか？

私個人としては不要です。まだ固まっていないものだ、と考えていました。

> ;;; 文字列割当関数、文字列参照関数、文字列開放関数、object
> ;;; parser&allocator, object marshaler, object finalize を指定できるよ
> ;;; うにして、アプリケーションのメモリ管理機構や構造データ管理機構と
> ;;; 連係して、構造データを効率良く扱えるようにしたいと考えています。
> 
> ;;; 一応、libchise（ないしは concord）でも default の（標準のという意
> ;;; 味ではない、やる気のない、簡単な）文字列管理機構（といっても、限り
> ;;; なく malloc & free に近いもの）を提供するつもりではありますが。

今のままでも使えるとは思いますが、あるといいなと目先で思っているのは以下
の2点です。

１）entity reference表記　と　CCS + コードポイント表記　との変換
２）S式、リスト形式　のデータの解釈

＃ids-find（私はどちらかというとfeature-findとして使っていますが）で、関
連オブジェクト同士を昔etoさんから見せていただいたgraphvizで表現するとわ
かりやすいかと考えています。そういう意味で早く手元でids-findに相当するも
のを構築したいのですが、ちょっと足踏み中です。

--
上地宏一 Koichi KAMICHI <kamichi ＠ fonts.jp>