JIS X 4151:1992 文書記述言語SGML | ページ 19

84
X 4151-1992
注(3) このモデルは,実際のプログラムの作り方を制限するものではない。例えば,単語の処理は,
単語や文の認知を行う主反復の中に組み込むこともできるだろうし,そうすることで,効率が
上がるかもしれない。
単語とか文とかといった低位の要素では,たいていの場合,利用者がその処理について制御できること
は少ないし,認知についてはほとんど関与のしようもない。段落ぐらいに高位の要素になると,書式付き
プログラムによってはもっと利用者に自由度を認めているし,強力なマクロ言語を備えたものなら,相当
程度に記述的マークにも対処してくれる。上の(4)(6)のモデルでいうと,記述的マーク付けの利点は,書
式付けプログラムが知らないような属性(つまり,要素の“型”)を利用者が定義して,その処理を指定す
ることができるようになることにある。
例えば,例2.では,ごく普通の“段落”という要素に加えて,“箇条書き”や“箇条”といった要素型を
使っていた。こうした要素の認知や処理がシステムに組込みになっていることはまずない。そこで,明示
的にマーク付けしておくことで,これらを認知させ,そのときの処理目的に応じた手続きにそれぞれを対
応付けさせるのである。この,手続きとその共通識別子への対応付けとは,そのシステムでのマクロ言語
を使って書くことになるだろう。対応付けは,処理目的が変われば切り替えることになるし,一つの処理
の中でも部位ごとに切り替えることもあるに違いない。
例えば,本文では箇条を(1),(2),···と番号付けるが,付録では(ア),(イ),···とするといった具合であ
る。
ここまでの議論では,単一の属性,すなわち,共通識別子だけを扱ってきた。この属性は,その値とし
ての名前が,その要素の意味の上での役割ないし目的を特徴付けているのであった。記述的なマーク付け
方式の中には,属性として共通識別子だけを考えて,そのマーク付けを“共通符号化”と呼んでいるもの
がある[5.(6)参照]。共通符号化方式では,その共通識別子で手続きの名前を制御するという簡単な仕掛け
を使って,認知,対応付け及び処理を一度に済ましてしまうことができる。別の形での書式付けをしたい
場合にも,マーク付けを変えることなく,同名の手続きの中から望むものを選び出しさえすればよい。こ
のやり方は非常に有効なものであり,この方式の著名なシステムであるSCRIBE[5.(2)参照]では,実際,
手続き的なマーク付けを一切許していないほどである。
共通符号化は,実用の上で手続き的なマーク付けに比べて大幅な改善となってはいるものの,概念構成
の上からみ止るとまだ欠けるところがある。文書は複雑な対象物であり,多くの属性をもつから,これを
マーク付け言語で記述できる必要がある。例えば,文書の中に図を要素として置けるようにし,それぞれ
の図を名前で参照できるようにしたとしてみよう。 “angelfig” (天使図)という名前の図を要素とするに
は,次のような開始タグを書くことになる。
<fig id=angelfig>
“fig” は,もちろん “figure” (図)のつもりの名前であり,属性としての共通識別子の値として指定し
てある。この共通識別子は,その要素が同じ役割をもつ要素の集まりに属していることを示す。これに対
して,識別子属性 “id” は,その要素を他の要素と区別するための一意的な名前を値としてとる。もちろ
ん, “fig” の他の要素ともこの名前で区別する(識別子属性の値は “id=” に続けて与えるが,共通識別
子は “GI=” などを置かずに直接その名前だけを書く。これは,SGMLが開始タグの最初にくるものを,
属性としての共通識別子の値と定めているからである。)。
この共通識別子と識別子の二つの属性は,“1次”属性という。どの要素でももつことができるからであ
る。もちろん,要素によっては,このほかに“2次”属性をもつこともある。例えば,図の中に画家の描
いた挿絵も入れて出力できるようにしたとして,この要素型を “artwork” と命名したとしよう。この外部

――――― [JIS X 4151 pdf 91] ―――――

                                                                                             85
X 4151-1992
で作られた挿絵の要素ではその寸法が重要になるので,この要素には2次属性 “depth” をもたせることに
しよう(4)。この結果,縦が24パイカ(pica,標準的な活字の大きさの一つ)分の挿絵に対する開始タグは,
次のようになる。
<artwork depth=24p>
図に対するマークには,更に,その内容を記述しておく必要がある。“内容” (conent) は,もちろん,1
次属性であり,その要素の2次属性で記述しておく対象ともなる。内容は,下位の要素を組み合わせてで
きている。その下位の要素は,また,その下位の要素を内容に含んでいる。こうして,いずれ,それ以上
は分割できなくなるところにまでたどり着くことになる(5)。SGMLが共通符号化と違っている点の一つが,
この階層的な構造を扱うための,概念構成や記述を行う道具をきちんと提供していることにある。これは,
一般化マーク付けの第2の主張[5・(7)参照],すなわち,マーク付けは厳密であるべきだとの主張に基づ
いている。
注(4) “depth” というのは,縦送りの制御を表す語と同値なわけではない。完全なページ割付けを行う
プログラムでは実際にその余白を作り出すであろうが,校正用の書式付けプログラムなら割付
け担当者向けにその表示を出すだけであろうし,情報検索プログラムなら図の索引付けを行う
だけでこの属性を無視してしまうであろう。
(5) したがって,文書と要素とは,同列に話すことができる。実際,文書とは,その処理での一番
高位の要素にすぎない。例えば,“技術報告”は,それ単独で文書として印刷することもあれば,
雑誌の一つの要素として印刷することもある。
3. 厳密なマーク付け さて,この図 “angelfig” が,図本体 (figure body) と図説明 (figure caption) の二
つの要素からできているとしてみよう。図本体の内容には挿絵が入り,図説明の内容には文としての文字
が(もはや何のマークもなしで)並ぶとしよう。すると,この図に対するマーク付けば,例えば,例1.の
ようになる(6)。
例1. <fig id=angelfig>
<figbody>
<artwork depth=24p>
</artwork>
</figbody>
<figcap> 3天使の舞い
</figcap>
</fig>
注(6) 内容を示す “content=” などというものは,共通識別子がそうであったように不要である。そ
の内容が外部で作られたものならもとより不必要であるし,タグの付いた要素だけからできて
いるならそのままで分かる。データの文字がその内容なら,開始タグの終わりの “>” と終了タ
グの始まりの “</” とでそれが区分できる。
例1.のマークは,その構造を厳密に表現する。それぞれの要素の開始と終了とを古典的な入れ子の形で
示している。
この構造を解釈するのにこれ以上は何の情報も要らない。だから,前に出てきたマクロ呼出しを使って
必要な処理を行わせることだって可能である。代わりに,この単純さの代償として,すべての要素に終了
タグを書かなければならない。

――――― [JIS X 4151 pdf 92] ―――――

86
X 4151-1992
この代償は,すべてのタグを利用者が書くのであれば,とても耐えられないものになる。利用者にとっ
てみれば,新しい段落が始まればその前の段落がそこで終わるはずのものであるから,そのことをシステ
ムに伝えるためにだけ,すべての段落の終わりに終了タグを書くという労力などはかけたくない。その要
素が自分で定義したもので,しかも頻繁に出てくるものであれば,強くそう思うに違いない。
SGMLでは,そこで,利用者が要素の型について構造や属性を定義してシステムに知らせておくことで,
こうしたタグを省略できるようにしてある。これには,SGMLが定めた“要素宣言”と呼ぶ構文単位を使
って,その“文書型定義”を与えればよい。文書の中のマークが個々の要素を記述するのに対して,文書
型定義は,その型の要素に付けることのできるすべてのマークを定義する。
要素宣言には,その要素として認める内容を,変形した正規表現を使って記述しておく。例えば,図の
定義を拡張して,図本体の中に挿絵を置くか,ある種の文要素を置くかのどちらかにできるようにしたと
しよう。すると,その要素宣言は,例えば,例2.のようになる(7)。
例2. <!−− 要素 最小化 内容 −−>
<!ELEMENT fig −− (figbody, figcap・)>
<!ELEMENT figbody −O (artwork| (p|ol|ul) +)>
<!ELEMENT artwork −O EMPTY>
<!ELEMENT figcap −O (#PCDATA)>
注(7) 疑問符 “・” は,その要素が任意選択であることを示す。カンマ “,” は,その前後の要素がその
順に現れることを示す。アステリスク “*” はその要素が任意選択反復(0回以上)することを,
正符号 “+” はその要素が必ず反復(1回以上)することを示す。縦棒 “|” は,選択項目を区
切る。かっこは,数学での使い方と同じで,式をまとめる。
例2.の最初の宣言では,要素 “fig” (図)には “figbody” (図本体)と “figcap” (図説明)がこの順に
並ぶが, “figcap” はないこともある,ということを意味している(負符号の意味は,すぐ後で述べる。)。
2番目の宣言では,図本体が, “artwork” (挿絵)となっているか,又は, “p” (段落), “ol” (箇条
書き)及び “ul” (unoredered list,項目列挙)の混在したものとなっているかのいずれかであることをい
っている。“最小化”の欄に書いた “O” は,図本体の終了タグが,それに続く開始タグで紛れなく兼用で
きるときには,省略できることを示している。これに対して,その左の負符号は,図本体の開始タグが省
略“できない”ことを示している。
挿絵に対する宣言では,その内容が空 (empty) であるとしている。これは,外部で作られて,そこには
り込むものだからである。したがって,文書の中にその内容がくることがないので,その終了タグを書く
必要はない。
最後の宣言では,図説明が勝手な文字列(長さ0でもよい。)であるとしている。文字は終端であり,そ
れ以上分割できないものである。“最小化”の欄の “O” は,図説明の終了タグが省略できることを示して
いる。図説明の終了タグは,前に述べた場合に加えて,この図説明を下位の要素とする上位の要素の終了
タグが紛れなく図説明の終了タグを兼用できる場合にも,省略することができる。
もちろん,ここでは, “p”, “ol” 及び “ul” に対する宣言がどこか別のところに書いてあるものとして
いる。
図の要素に対するこの形式的な定義に従うと, “angelfig” は,新たに例3.のようにマーク付けできるこ
とになる。
例3. <fig id=angelfig>
<figbody>

――――― [JIS X 4151 pdf 93] ―――――

                                                                                             87
X 4151-1992
<artwork depth=24p>
<figcap> 3天使の舞い
</fig>
マークは40%も減少した(8)。三つの要素の終了タグが,次の(1)(3)の理由で要らなくなったからである。
(1) 図説明は,要素宣言から図の一部であり,したがって,その終了タグは図の終了タグが兼用するので
要らない。
(2) 図説明は図本体と同じ水準にあり,したがって,図説明の開始タグが図本体を終わらせるので,図本
体の終了タグは要らない。
(3) 挿絵は,その要素宣言で内容が空であるとしているから,それ自身で完結しているので,挿絵の終了
タグは要らない。
注(8) GMLでは,実際のところ,ここに示す以上にマークを減らすことができるようになっている。
文書型定義には,属性をもつ要素があれば,そのそれぞれに“属性定義並び宣言”を書いておく。この
宣言では,それぞれの属性がとり得る値のほか,その属性が任意選択でしかも文書の中でその値を与えな
かったときにとる省略時値も定義しておく。
例えば,図と挿絵とに対する属性定義並び宣言は,例4.のようになる。
例4. <!−− 要素 名前 値 省略時値 −−>
<!ATTLIST fig id ID #IMPLIED>
<!ATTLIST artwork depth CDATA #REQUIRED>
図に対する宣言では,その値として一意的な名前をとる (“ID”) 属性 “id” をもつとしている。この属性
は,任意選択であり,その値を指定しなかったときは値をもたない (“IMPLIED”) と指定してある。
これに対して,挿絵の属性 “depth” は,必ず (“REQUIRED”) であり,必ず値を指定してやらなければ
ならない。その値は,勝手な文字列 (“CDATA”) であってよい。
文書型定義は,マークの最小化に役立つ(9)だけではなく,ほかにも用途がある。文書の具体的な処理に
かかる前に,その文書のマーク付けが正当なものかどうかを検査するのに使うことができるし,その文書
型に不慣れな利用者に対して,必要な情報を表示しながらその入力を手助けするのにも使うことができる。
例えば,文書入力の応用を考えてみよう。応用は,この図の定義を読み取るとそれぞれの要素に対する手
続きを動かす。その手続きは,それぞれ,“図の名前を入力して下さい”,“挿絵のdepthを指定して下さい”,
“図説明の文面を入力して下さい”,などと表示を出して利用者からの応答を得ていく。それぞれの手続き
は,また,作り出す文書の中にそれぞれのマークを自動的に書き込んでいくことだろう。
注(9) 実用的で完全な文書型定義の例は,5.(5)に示す文献に見ることができる。ただし,この文献は,
SGMLそのものに従っているわけではない。
SGMLでの文書型定義によれば,利用者は,文書を作る際の手間を最小に抑えることができる。これは,
“賢い”文書編集プログラムや文書処理システムに頼るまでもないのである。更に,文書の可搬性を最大
のものとすることができる。文書は,人間が読んで理解できるし,何百万台にも及ぶ既存の“間の抜けた”
けん盤を使ってでも簡単に編集できるからである。それでいて,文書型定義と文書に付けたマークとで,
機械処理に耐えるだけの厳密さを備えた文書を構成しているのである。

――――― [JIS X 4151 pdf 94] ―――――

88
X 4151-1992
4. 結論 一般化マーク付けが文書記述をどれほどに正確で自在性に富んだものにしたかとはよそに,出
版のために文書を準備する利用者にとっての関心は,次のことにある。すなわち,SGMLにしろ,どんな
記述的マーク付け方式にしろ,本当に手続き的なマーク付けに匹敵するだけの版組結果が得られるのか,
ということに尽きるのである。この実用的な関心についていえば,Prentice−Hall社刊の書籍[5.(7)参照]
が,一般化マーク付けの有効性の経験的な証左となる。
この書籍は,ソフトウェア開発についての教科書であって,その著者が編み出した記法に従う何百とい
う数式が出てくる。その組版の複雑さ(実際,1行の中で字体を10回も20回も変えることがしばしばで
ある。)にもかかわらず,この本の文には,ただの一つも手続き的なマークを使う必要がなかった。そのマ
ーク付けに使ったのは,一般化マーク付けの原理に立脚した言語であって,しかもSGMLほどの自在性も
完成度もないものだったのである[5.(5)参照]。
そこで使えた手続きは,計算機の出力装置を動かすだけのものであった。それでも,授業の教材として
用意した初版用としては,十分であった。出版の話がまとまるまで,その著者は,組版についての考慮を
まったく払っていなかった。話がまとまった時点で,350ページもの原稿を打ち直し校正するための時間
と手間とを考えて,著者は愕然とし,ほかの方法を探し始めた。折しも,C. F. Goldfarbが,一般化マーク
付けの商用出版への適応性を検証するに足る実例を求めているところであった。
こうして,二つの探しものがうまく出会い,まれにみる実験が始まった。元の処理系には,写植機を直
接に動かす手続きがなかったので,写植機用の既存の組版プログラムで処理できるように,手続き的なマ
ーク付けに直した文書を作り出す手続きをまず用意した。書式の仕様は,出版社が決めてきた。それでい
て,この一般化マーク付けを生かすのに何も後退する必要は生じなかった。文書は,仕様が与えられる前
に一般化マーク付けしておいたものであるにもかかわらず,何の手入れも要らなかったのである。
この実験は,期限内に完了し,出版社も完全な成功と認めてくれた[5.(8)参照]。このときに作った手続
きは,書式に応じて若干の手直しを施すことで,様々な内部出版に今なお使っている。
したがって,一般化マーク付けは,実用目的にも学究目的にも便益を与えてくれる。出版においては,
マーク付けに要する原価を引き下げてくれるし,書籍製造に要する時間を減らしてもくれる。更に,文書
データベースに入れておいてもその自在性を失なうことがない。研究室においても,異なる種類の文書処
理システム間での文書交換が,様々な機能を失なうことなくできるようになるし,電子メールの一覧とい
った補助的な“文書”が,電子メールの要約といった,主体となる文書の関係する要素から自動的に作れ
るようにもなる。
同時に,SGMLの厳密な記述的マーク付けによって,文章が計算機を使って容易に分析できるようにも
なる。手続き的なマーク付けをした(又は,全くマーク付けしていない)文書は,意味の解析をしない限
り何の構造ももたない文字の列にすぎない。これに対して,一般化マーク付けをした文書は,よく知られ
た正規表現に還元できる構造をもっている。これによって,計算言語学や翻訳系設計での技法が,自然言
語処理やその他の文書処理応用に使えるようになるのである。
5. 参考文献 この参考で使った文献は,次のとおりである。
(1) . F. Goldfarb, “Generalized Approach to Document Markup”, SIGPLAN Notices, the Association for
Computing Machinery, June 1981.
(2) . K. Reid “The Scribe Document Specification Language and its Compiler”, Proceedings of the International
Conference on Research and Trend in Document Preparation Systems, 56-62 (1981)
(3) onald E. Knuth, TAU EPSILON CHI, a system for technical text, American Mathematical Society, Providence,

――――― [JIS X 4151 pdf 95] ―――――

次のページ PDF 96

JIS X 4151:1992の引用国際規格 ISO 一覧

  • ISO 8879:1986(MOD)
  • ISO 8879:1986/AMENDMENT 1(MOD)

JIS X 4151:1992の国際規格 ICS 分類一覧

JIS X 4151:1992の関連規格と引用規格一覧