libchise に向けて

[守岡知彦 / MORIOKA Tomohiko]

libchise に関して今考えていることを書いてみます。

* 対象

libchise は CHISE 環境における基本的かつ（アプリケーション間で）共通性
の高い処理を提供するライブラリとする。

現在の所、具体的には、文字データベース関連とグリフ関連の処理が考えられ
る。


* 階層モデル

CHISE アーキテクチャおよび libchise に関して次のような４層モデルを想定
する。

第４層	オブジェクト層
第３層	構造データ層
第２層	バイト列層
第１層	ストレージ層

第１層は Berkeley DB や PostgreSQL, あるいはテキスト・ファイルといった
物理的なデータソースを想定している。

第２層はバイト列（C 言語における文字列）レベルのサービスを提供する層で
ある。ここでは、第１層のデータソースを抽象化を行う。現在の XEmacs
UTF-2000 でいえば、database オブジェクトに相当する。

第３層は Lisp における S 式や XML の構文木などのような複雑なデータ構造
を扱うサービスを提供する層である。ここでは第２層で扱うバイト列との変換
や記憶管理、基本的な型システムの提供などを行う。現在の XEmacs UTF-2000
でいえば、get-char-attribute や put-char-attribute のような組込み関数
で実現された API に相当する。

第４層はオブジェクト指向なサービスを提供する層である。ここでは第２層、
第３層の具体的な属性名を抽象化したサービスを提供したり、具体的な属性値
の代わりに属性値を生成するための式を書くことができる。現在の XEmacs
UTF-2000 ではこのための枠組は存在せず、Emacs Lisp プログラムで個別に実
現されている（例：char-representative-of-daikanwa, char-ucs など）。ま
た、TopicMaps はこの層のデータモデルの１つであると考えられる。


* 当面の目標

libchise 開発では当面、文字データベースを対象に第１層、第２層の実装を
行う。また、第１層の実装としては、Berkeley DB 4.* を想定する。


* 文字属性データベースの構成について

比較的近い将来において libchise が提供するサービスが第２層までに留まる
ことを考えれば、第３層で複雑なデータ構造を使うと各アプリケーションは自
前で構文解析やメモリ管理を行う必要が生じる。このため、なるべく属性値と
して複雑なデータ構造（リスト等）を用いないことが望ましい。

一方、文字オブジェクトの素性の束としての性質を活かし、これを積極的に支
援するには文字指定形式（char-spec; define-char の第１引数）間の集合演
算が容易に実現可能であることが望ましい（特に、join, union,
intersection）。

この観点で現状を鑑みれば、属性名毎によって値が１つしか取れないもの（例：
ideographic-radical）と複数取れるもの（例：<-simplified-ideograph）が
あり、まちまちである。また、値がリストの場合に、その意味が列のもの（例：
ideographic-structure）と集合を意味するもの（例：
<-simplified-ideograph）がある。こうした現状は望ましくなく、ある統一的
なルールに従って第３層の標準データ形式を定めるのが望ましい。

この際、

(a) 全ての文字属性に対し、属性値として１つしか許さないことにする。その
    代わり、ここで定義される文字定義を継承する文字属性の集合を示す特別
    な文字属性 or を導入する

(b) 全ての文字属性に対し、属性値として複数を許すことにする。

の２案が考えられる。

それぞれ define-char 形式で書くとするならば、

(a) の例

(define-char
  '((or ((ideographic-radical . 89)
	 (ideographic-strokes .	15)
	 (chinese-cns11643-7  . #x476F)
	 (ideograph-daikanwa  . 19757)) ; 実際にはオブジェクトになる
	((ideographic-radical . 9)
	 (ideographic-strokes . 17)
	 (hanyu-dazidian	1 237 5) 
	 (ideograph-hanziku-1	. #xD6F4)
	 (ucs			. #x20442)) ; 実際にはオブジェクトになる
	)
    (total-strokes	 . 19)
    (ideographic-structure ...) ; 列
    ))

(b) の例

(define-char
  '((ideographic-radical
     (:id daikanwa
      :data 89) ; ideographic-structure との対応の為に :id を書いてみた
     (:id ucs
      :data 9))
    (ideographic-strokes
     (:id daikanwa
      :data 15)
     (:id ucs
      :data 17))
    (total-strokes 19)
    (hanyu-dazidian	[1 237 5]) ; 列を [...] で書いてみた
    (ideographic-structures [...])
    (chinese-cns11643-7		#x476F)
    (ideograph-daikanwa		19757)
    (ideograph-hanziku-1	#xD6F4)
    (ucs			#x20442)
    ))

という感じになるであろう。ちなみに、現状では

(define-char
  '((ideographic-	(:radical	89
			 :strokes	15
			 :sources	(morohashi-daikanwa cns-11643))
			(:radical	9
			 :strokes	17
			 :sources	(ucs)))
    (total-strokes	 . 19)
    (hanyu-dazidian	1 237 5) ; 列
    (ideographic-structure ...) ; 列
    (chinese-cns11643-7		. #x476F)
    (ideograph-daikanwa		. 19757)
    (ideograph-hanziku-1	. #xD6F4)
    (ucs			. #x20442)
    ))

となっている。

それぞれの得失を考えると、集合演算を考えた場合、(a) 案では or を除いて
文字属性の中身を考える必要がないのに対し、(b) 案では各文字属性毎に集合
演算をする必要がある。一方、複数候補を知りたい場合、(b) の方が簡単であ
る。

なお、(a) 案を取る場合、文字定義の継承機構を導入する必要がある。

また、現状のような折衷案も考えられる。

私見を述べれば、冒頭で述べたように、なるべく属性値として複雑なデータ構
造を用いないことが望ましいといえ、おそらく (a) の方が良いと思う。


* 文字属性名の名前空間について

私見を述べれば、第３層以下では名前空間を導入しないのが良いと思う。理由
としては機構を複雑にしないことと、各計算機言語用バインディングを考えた
時に名前空間があるとは限らないことと、あっても仕様が異なっていることが
考えられる。

なお、名前空間を表現するなんらかの命名規則を導入するのは賛成である。

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