版数　　：V1R2

                                                  　作成日付：1995.02.09

　　　　　　　　　　　　　　　　　　　　　　　　　　著者　　：若鳥陸夫
　　
                
CALSに向けたデータ構築法

　これが，共通データ指向商品とそうでない商品の区別をするための着眼点及び 共通データに対応するための作業量と重要性とを推し量る一助になれば幸いであ る。

　　　　　　　　　　　　　　　記

1.共通データを目指すデータ構築法

1.1 序論

この目標は，現状の計算機製造者の用意している個別操作系，個別応用系などに 対応したいわゆる商品縦割りの支援では，達成できないものである。

この共通データを目指す場合，データ構築法（データアーキテクチャ）の見通し の良し悪しが，最重要になる。

　ここでは，多階層にわたるデータ構築法の中から，計算機の表面に関する層だ けを抜粋して紹介する。

1.2 操作系に依存しないデータ

　　　　　　　　
図1.共通データを扱う体系（最下層）の例

                           　　　　利用者　　　　　
           
　　　　　　  －－－－－－　利用者対計算機界面（人の言葉）－－－－－
　　　　　　　
　　　　　　　親計算機U　受注側計算機A　発注側計算機B　個人計算機S　　
              －－－－－－－－－－－－－－－－－－－－－－－－－－－
　　　　　　　U対C変換　　A対C変換　　　　B対C変換　　　S対C変換　　
　　　　　　　－－－－－－－－－－－－－－－－－－－－－－－－－－－
　　　　　　　応用系　　　操作系（狭義）　言語処理系　  通信系

　　　　　　　－－－－－－－－　共通データ界面　－－－－－－－－－－　　
　　　　　　　　－－－－－－－－－－－－－－－－－－－－－－－－
　　　　　　　｜　　　　　　　　共通データ(Cと略記）　　　　　　｜
　　　　　　　｜　　　　　　　　　　　　　　　　　　　　　　　　｜　　
　　　　　　　｜　データ構築法　構造(スキーマ，論理構造），　　 ｜
　　　　　　　｜　　　　　　　　媒体（文字，静止画，動画，音）　｜
　　　　　　　｜　　　　　　　　符号化方法　　　　　　　　　　　｜
　　　　　　　　－－－－－－－－－－－－－－－－－－－－－－－－　

　従来のプログラム作法では，対象とする当面の処理系の符号で設計文書を 書き，プログラムを書き，翻訳して，実行計算機までが管制されていた。

　しかし，プログラム文書を共通化するためには，次の(1)～(6)の事項が必 要になる。
(1)作成支援の編集系は，共通符号を対象とする（符号変換内蔵）。
　この水準の実現には，入力符号，出力符号，ファイル符号及び通信符号の4符号が個別に指定できるようにされる。それは，入力及び出力は，現物の計算機の内部符号に合わせなければならないし，ファイル符号は共通符号を対象とし，通信符号は計算機網間(internet)とのやりとりをするからである。

　この模型は，構造化編集系emacsやMuleに見ることができる。
(2)言語処理系は，共通符号を対象とする（符号変換内蔵）。
符号長さ，符号値，挿入ファイル種別，行末符号，ファイル終了などの違いを吸収する書き方になるので，プログラム作法も変更が必要となる。

　この作法によれば，異種操作系にわたって同じ原始プログラムを適用できるようになる。

　この思想に乗った例に，（社）日本電子工業振興協会のCALS情報センターの共通文書の格納のための"make_sgm.c"がある。それは，UNIXでもWindowsでも共通なデータを処理対象とし，かつ原始プログラムが両用になっている。
(3)操作系の印刷指令語は，共通符号を対象とする（符号変換内蔵）。
(4)操作系の表示指令語は，共通符号を対象とする（符号変換内蔵）。
(5)通信系は，共通符号を対象とする（符号変換内蔵）。
(6)共通符号のための各種常備品を備える。
　この例のように，客先の応用系の開発に当たっても，共通データの最下層を提供するだけでも，計算機製造者は哲学のある投資を必要とする。

　すべてを短期間で充足できなくても，長期的に同じ目標を維持していれば，いずれ，利用者の求める水準に到達できるであろう。

2.最下層のデータの共通化の案

2.1 共通符号の策定の考慮事項

(1)JIS X 0201(8単位）は，歴史的な産物である。

　計算機網間(internet)通信では，片仮名文字は2バイト符号を使うこととし，1バイト片仮名文字の使用を禁止している。

　　　備考　文字の大きさは，符号の属性ではなく，フォントの指定によって
　　　　　　決まる。
    

(2)英数字には，ASCII(米国標準情報交換用符号）が地球規模で流通性がよい。

　例えば，文面中に日本国の円記号のつもりで，符号値(05/13)を指定してもASCIIを基本とする外国には，逆斜線にしか表示しない。ASCIIの範囲が国によって違うのは，情報の地球規模の流通の阻害要因なのである。

　実際，計算機網間通信(internet)の基本符号は，ASCII文字によっている。

　UNIX（特にATT系のEUC)では，符号表の左半側には，ASCIIが呼び出されることを想定している。

　逆に漢字符号中の英数字及び間隔は，使用しない方がよい。英数字及び間隔は，ASCIIだけで表現すると，国際流通性が高い。

　哲学的に言えば，本来，同じ用途で同じ文字に複数の符号値が存在するのが誤りである。

(3)情報交換用漢字符号(JIS X 0208)は，G1集合にも呼び出せる。

　この改正によって，G0=ASCII, G1=JIS漢字（JIS(G1)漢字方式と呼ばれる。） といった使い方がJISとしても可能となった。

　 　このJIS(G1)漢字方式によれば，処理符号と交換符号との統一が可能となった。 その理由は，漢字指示エスケープシーケンスにまで逆さ呼びしなくても，漢字か否かの判断ができるからである。

　実際，ATT系のUNIXのEUCのファイル符号は，この仕掛けを先取りし，G0=ASCII，G1=JIS X 0208，G2=JIS X 0201片仮名（保守品目），G3=外字である。したがって，EUCは，G0集合及びG1集合だけの部分の使用に制約すれば，JIS(G1)漢字方式と同じである。

　SGMLのJISでも，この符号化方式によって，英数字と漢字符号との弁別を行う日本語SGML宣言の例を示している（JIS X 4151表9.参照）。

(4)シフトジスは，符号予備領域が不足し，しかも，国際規格ISO 2022違反。

　しかし，この符号構成では，輸入の言語処理系に対して構文誤りを起こす第2バイトがあるため，無修正で輸入ソフトウエアを使えるわけではない。

　しかも，同じ符号値が漢字圏で違う事態も生じてきた。したがって，ここでは，歴史的な符号と位置付けた。

(5)UCS(ISO/IEC 10646)

2.2 共通符号の案

　　　　　　ESC 02/8 04/2

            ESC 02/6 04/0 ESC 02/4 02/9 04/2