Re: JLReq の文字クラスと Unicode の文字クラスとの関係

 shimonoです

 長らくかかってしまった、、というより、ようやく永夜っとこれに集中して片づけた、という話ではあ
るのですが、JLreq本文で、
・文字クラスが利用されているところの抽出
・文字クラスに寄らず、単独の文字で参照されているところの抽出
を行って、添付の表のようにしました。

 ただし、
・3.9 文字クラスについて、と、Appendix A. 文字クラス一覧は飛ばしました
・表の説明になっているAppendix B-Eはとりあえず表の方を解析するのでこの後で
・用語集のディセンダラインの英文字
は入っていません。D-AGのセルで'x'が入っているものが各部分で参照されている文字クラスです。Aのセ
クション番号で番号以外にうしろに伸びているのは、3.3.8.bは3.3.8節中のリストアイテムc、3.3.8.n127
は3.3.8節中のNote #n127、3.8.3-2.a-dは3.8.3節中の２つ目のリストアイテムのa-dの項目、などと読み
替えてください。
 148列目の利用回数は、文字列クラスごとにリストでxがついている回数です。
 0になっているうち、下記の通り、cl-22/23は熟語ルビ、cl-30は縦中横の文字、と、表の部分で参照さ
れているか、特有の説明の中でのみ利用されているものであるから、ということになります。

 Cの文字の行は、本文中で文字クラスに関係なく参照されている文字です。コードポイントは本文中に
出てくる文字を直接書いているだけで、U+FFxx系のものは対応関係を整約はしていません。


 とりあえずのリスト化までですが、このあと整理・解析などできればとは思っているところです。


# W3C geek weekと呼ばれる週だから合わせて、というのでなく、単純に他のWGなどのまとまった時間が吸
い取られる案件の谷間という話です。。


On 2020/02/01 03:14, 木田泰夫 wrote:
> 先日のミーティングにおいて、文字セットを Unicode に移そうよ（大賛成！）、amendment でやりたいね（うっそ ー！）と言う会話がありました。
> 
> 文字コードを Unicode 全体に拡張するには、文字クラスも拡張する必要があります。そのためには、独自に文字を列挙するのではなく、Unicode に文字が足されてもそれに応じてメンテナンスされ続けている Unicode の文字プロパティを使うべきでしょう。この変更が見かけほど単純ではなく、作業の量だけではなく、議論すべき項目がたくさん出てきそうだとの印象を持っていたので、短期的には無理だろうと思ったわけです。
> 
> ただ、ひょっとして案ずるより産むが易しだったりして？JLReq の文字クラスと Unicode の文字プロパティの間に、意外に綺麗な包含関係にあるなんてことがひょっとしてひょっとしたらあったりして？ と思ってちょっと予備的調査をしてみました。
> 
> 
> *予備的調査*
> JLReq の文字クラスを見ると、文字が本来的に持っている性質ではなく、その文字が現れたコンテキストを表しているものがいくつかあります。これらはそもそも「文字クラス」ではなく、Unicode の文字プロパティで表すことができません。故にこれらは文字プロパティとは別の方法で記述する必要があります。まずこれらのクラスを省いて考えることにします。期待通り、これらのクラスにのみ含まれる文字はありませんので、これらを省いても分類から漏れる文字はありません。
> 
>     A.20 合印中の文字（cl-20）
>     A.21 親文字群中の文字（添え字付き）（cl-21）
>     A.22 親文字群中の文字（熟語ルビ以外のルビ付き）（cl-22）
>     A.23 親文字群中の文字（熟語ルビ付き）（cl-23）
> 
>     A.30 縦中横中の文字（cl-30）
> 
>     A.24 連数字中の文字（cl-24）
>     A.25 単位記号中の文字（cl-25）
>     A.28 割注始め括弧類（cl-28)
> 
>     A.29 割注終わり括弧類（cl-29）
> 
> 
> これで JLReq 文字クラスが本来の文字クラスに近づきました。残った JLReq 文字クラスと Unicode General Category の対応を調べてみました。cl-nn が JLReq 文字クラス、アルファベット大文字と小文字の組み合わせがそこに含まれる文字の General Category です。
> 
>     cl-01Pi Ps
>     cl-02Pe Pf
>     cl-03Pd
>     cl-04Po
>     cl-05Po
>     cl-06Po
>     cl-07Po
>     cl-08Lm Pd Po
>     cl-09Lm
>     cl-10Lm
>     cl-11Lo
>     cl-12Po Sc So
>     cl-13Ll Po Sc So
>     cl-14Zs
>     cl-15Lo
>     cl-16Lo
>     cl-17Sm So
>     cl-18Sm
>     cl-19Ll Lo Lu Nd Nl No Po Sm So
>     cl-26Zs
>     cl-27Cf Ll Lm Lo Lu Mn Nd No Pc Pd Pe Pf Pi Po Ps Sc Sk Sm So Zs
> 
> 
> *やっぱりな結論*
> 多くの General Category プロパティが複数の JLReq 文字クラスに現れていますので、General Category だけを用いて JLReq 文字クラスを表すことはできないことがわかります。Unicode には他にもたくさん文字プロパティがありますのでとりあえず悲観しなくても大丈夫ですが、それほど単純でないことがわかります。
> 
> 加えて、今まで JLReq で扱ってこなかった文字たち（アラビア文字、ハングル、絵文字などなど）がどの文字クラスに入るべきなのかを議論して決め、それらを包含した定義にする必要があります。また bi-di との関わりは何か考える必要があるでしょうか？（ないといいな）
> 
> やはり、JLReq の JIS X 4051 的文字クラスから、Unicode 的な世界への移行にはそれなりの議論と作業量が必要そうです。
> 
> また、Unicode への移行は、自分の世界だけで閉じていた JLReq を、他の言語も混じる多言語処理の一部として定義し直す良いチャンスです。例えば、JLReq で添字について記述する必要はあるでしょうか？ とすると、これはデジタルテキストのための次世代 JLreq と一緒にやった方が効率が良いのではないか、とそんな風に思うわけです。
> 
> いかがでしょうね？
> 
> 木田
> 
> 
> 
> 
>