proposal about character inheritance and some features

2004年 2月 18日 (水) 15:45:21 JST

仕事ひとつ片付けて、ぼけー mode な今日この頃の守岡です（まずい）。

>>>>> In [chise-ja : No.00326] 
>>>>>	"守岡" = tomo ＠ m17n.org (守岡知彦 / MORIOKA Tomohiko) wrote:

守岡> そういう訳で、毎度おなじみ現実逃避なんですが、今回は懸案のひとつ
守岡> の文字定義の継承をやってみようということで、以下の提案をします。

守岡> (1) ->unified

守岡> 派生する文字を表す文字素性として ->unified を新設する。値の型は
守岡> char-ref の list とする。

守岡> 文字 P に対し、文字素性 ->unified の値として (C_0 C_1 ... C_i ... 
守岡> C_n) を設定した時、C_i が未定義文字に対する char-spec であれば、
守岡> C_i の定義に従った文字が定義され、C_i の位置に置き換えられる。ま
守岡> た、C_i ないしはそれに対応する文字は P から派生する文字と見倣さ
守岡> れ、(P) を値とする文字素性 <-unified が設定される。

g新部さんのご意見に基づき ->subsumptive として XEmacs CHISE に実装しま
した。(*1)

;; 実は、今の所、Unicode の unification の表現にしか使ってないので、
;; ->unified の方が良かったかもという気もしないではないですが。

守岡> (2) <-unified

守岡> 派生元の文字を表す文字素性として <-unified を新設する。値の型は
守岡> char-ref の list とする。

守岡> <-unified を持つ文字 C がある文字素性 f（但し、f は CCS 素性でな
守岡> いこととする）を持たない時、<-unified の値で指定される派生元の文
守岡> 字が f を持っていれば、その値を C の値と見倣すこととする。また、
守岡> この性質は再帰的に成立することとする。

守岡> <-unified を持つ文字は define-char 形式での独立したエントリーを
守岡> 設けないこととし、親文字における ->unified の要素として表現する
守岡> こととする。

(1) と同様、g新部さんのご意見に基づき <-subsumptive として XEmacs
CHISE に実装しました。(*1)

守岡> (3) ->inherited, <-inherited

守岡> ->unified, <-unified と同じセマンティクスとする。

守岡> 但し、<-inherited を持つ文字に対して define-char 形式での独立し
守岡> たエントリーを設けることとする。

->denotational, <-denotational として XEmacs CHISE に実装しました。(*1)

守岡> (4) =CCS 素性

守岡> CCS 素性 =FOO を設定した時、必ず =>FOO も設定することにする。

守岡> 但し、define-char 形式では、=FOO が存在する時の =>FOO は省略する。

=>FOO を設定する代わり、(*1) で述べる関数 char-feature で =>FOO を取り
出せることにした。

なお、将来的には、この処理は文字素性の継承として一般化することを提案す
る。

守岡> (6) =ucs の扱い

守岡> UCS で統合されているにもかかわらず、文字定義を分離しているものに
守岡> 対し、現在、Unicode の例示字形にもっとも近い文字定義に対し =ucs 
守岡> を与え、それ以外に =>ucs を与えているが、今後はこれらの文字定義
守岡> を ->unified 要素として持つ文字に対し =ucs を設定することとし、
守岡> 従来、=ucs を設定していたものには =ucs ＠ unicode (BMP) もしくは 
守岡> =ucs ＠ iso (Ext-B) を設定することにする。

守岡> 同様に、他の要素に関しても ->unified や ->inherited を用いること
守岡> で、適切に包含関係を表現することとし、これにより、さまざまな抽象
守岡> 度の文字を表現・操作しやすくする。

CHISE 文字データベースにおいて、試験的に一部実施しました。

守岡> また、->FOO, <-FOO の要素に対応する文字が存在する時、文字データ
守岡> ベース中では char-spec を文字に正規化して格納するようにすること
守岡> も提案します。

->simplified, <-simplified に関して実施しました。

(*1) XEmacs CHISE の関数 get-char-attribute では
     {->|<-}{subsumptive|denotational} による文字定義の継承および
     (4) で述べたような文字素性の継承をサポートせず、新設した関数
     char-feature でこれらのサポートを行いました。

     なお、関数 char-feature の引数は

	(文字 文字素性名
	&optional 文字素性値の既定値 FEATURE-REL-MAX CHAR-REL-MAX)

     で、関数 get-char-attribute と同様な最初の３引数に、省略可能な引
     数 FEATURE-REL-MAX および CHAR-REL-MAX を追加したものになっていま
     す。なお、これらの仕様は

	FEATURE-REL-MAX は文字素性の継承を辿る最大数を意味し、0 の場合
	は文字素性の継承を無視することを意味する。この引数が省略された
	場合、無限に文字素性の継承を辿る。

	CHAR-REL-MAX は文字定義の継承を辿る最大数を意味し、0 の場合は
	文字定義の継承を無視することを意味する。しかし、現在の実装では 
	0以外の数値の場合は無限に文字定義の継承を辿る。また、この引数
	が省略された場合も同様である。なお、先祖に自分自身を見付けた場
	合、その時点で探索を中止し、文字素性値の既定値を返す。

     となっています。

このように現状では継承の実現はとりあえず XEmacs CHISE で行いましたが、
libchise で実装しなおしたいと思っています。

この時、現状の XEmacs CHISE のように一般的な新設関数を追加する(a)のと、
既存の関数の界面を変更する(b)のとどっちが良いですか？なお、後者の場合、
APIが非互換となります。前者は API が上位互換になります。

また、一般的な新設関数を追加する場合、既存関数 (chise_ds_get_feature,
chise_char_load_feature_value, chise_char_gets_feature_value) の挙動は
継承付き(a-1)にするのと継承無し(a-2)にするのとどちらが良いでしょうか？

;; 現時点では (a-1) 案が良いかなと思っています。

ご意見お待ちしております。
-- 
===『幾千億の分子に分かれても ========================================
     決して忘れない。    
     この宇宙が終るまで』              守岡 知彦 (MORIOKA Tomohiko)
====================== Email: <tomo ＠ kanji.zinbun.kyoto-u.ac.jp> ======