ウィンドウシェルRUNSP2
RUNSP2は，Richard Light氏が開発した，Windows95のためのユーザーフレンドリなウインドウズシェルです。RUNSP2は，James Clark氏のSPをコマンドラインからではなく，シェル［図1を参照］を介して起動でき，エラー表示と同期が取れるエディターを備えています。RUNSP2によってSGML文書の解析・検証段階での操作性は向上するでしょう。このプログラムは“
http://www.light.demon.co.uk/runsp/runsp2.zip”からダウンロードできます。
|
▲図1 RUNSP2の専用シェル
RUNSP2の現在のバージョン（0.42）では，nsgmlsとsgmlnormだけの起動しかできません。又，カーソルの動きやウインドウの表示に少々おかしいところがありますが，実用上，基本的な機能や日本語の表示には問題はありません。
RUNSP2が起動できるSPは，SP1_1_1（Windows 3.1の場合はSP1_1）でなければなりません。それより前のバージョンでは動作しませんので，注意して下さい。
先ずRUNSP2を起動すると，専用のシェルが表示されます。次に，そのFile−Openのメニューかボタンを押して解析・検証する文書実現値のファイルを選択し開けます。ファイルの内容はシェルのウインドウに表示され，編集可能になります。［図1を参照］
ここで，Run NSGMLSボタンを押すと，別のウインドウ（つまり，nsgmlsのウインドウ）でパーザーが実行します。RUNSP2は，SGMLSTMP.BATという名前の小さなバッチファイルと，文書実現値のファイル名に“.CAT”という拡張子を付けたカタログ記述ファイルを生成すると，直ちにnsgmlsを起動します。
パーザーが終了した時，RUNSP2は，ログファイル（文書実現値のファイル名に“.LG$”という拡張子を付けたもの）を分析します。
ログファイルでエラーを検出した場合は，その旨を通知し［図2を参照］，エラーを含んでいるすべてのファイル（例えば，SGML宣言や文書型定義）を読み込み，ウインドウに表示します［図4を参照］。
シェルの下部でエラーメッセージを表示します。エラー（最初，次，前，最後）を見ながら動けるように，移動用のボタンがあります。そのボタンを押すと，ウインドウの行と同期が取られ，エラー箇所へ移動しますので，効率良く修正作業ができます［図4を参照］。
必要な修正を行なった後に，再びパーザーを実行すると，それまでの編集結果は，最初に自動的に保存され，何もエラーがなければ，その旨が通知されます［図3を参照］。
|
▲図2 エラーの通知
|
▲図3 検証完了の通知
|
▲図4 文書の修正
そして，現在の文書でsgmlnormが実行できることをボタンで示します。それを押すと，直ちにsgmlnormが別のウインドウで実行します。
そうした一連の実行を設定するために，Optionsメニューでは，SPの実行プログラム，SGML宣言，SGMLカタログ記述ファイルの格納場所やコマンドラインでのオプションを設定できます［図5を参照］。
|
▲図5 optionの設定
RUNSP2によって，nsgmlsによる解析・検証とsgmlnormによる正規化を実行した結果，文書実現値のファイル名に“.NRM”という拡張子が付けられた，正規化された文書実現値［図6を参照］が得られますが，ESISを得ることはできません。RUNSP2では，正規化された文書実現値以外の出力として，コマンドラインの-tオプションによってRAST［図7を参照］出力を指定できますが，二つを比べると明らかなように，内容的には，正規化された文書実現値と変わりありません。このことは不思議なので，私（岸 和孝）は作者のLight氏へ問い合わせてみました。
<HTML> <HEAD> <TITLE>ŠJ•■Œ■•■‘ ‘■Œn(ODA)‚■—˜—p‚■ •‹y‚■Š■‚■‚■ ’■■•■#141;‘ </TITLE> </HEAD> <BODY> <DL> <DT>•\‘■ <DD>95-Œv-5 </DD> </DT> <DT>Ž■#145;■ <DD>ŠJ•■Œ■•■‘ ‘■Œn(ODA) 注）■はASCIIに該当する文字ですが，半角仮名文字に相当する部分を置き換えました。
▲図6 正規化された文書実現値
[HTML] [HEAD] [TITLE] #138 |J| #149 #250 #140 |^| #149 #182 #143 #145 #145 #204 #140 |n(ODA)| #130 #204 #151 #152 #151 |p| #130 #198 #149 #129 #139 |y| #130 #201 #138 #214 #130 #183 #130 #233 #146 #178 #141 #184 #149 #241 #141 #144 #143 #145 [/TITLE] [/HEAD] [BODY] [DL] [DT] #149 |\| #145 #232 [DD] |95-| #140 |v-5| [/DD] [/DT] [DT] #142 #229 #145 #232 [DD] #138 |J| #149 #250 #140 |^| #149 #182 #143 #145 #145 #204 #140 |n(ODA)|
▲図7 RAST表現の文書実現値
その回答によると，第一に，RUNSP2はコマンドのパイプ処理をサポートするように設計していないとのことです。つまり，Windows95では標準出力がありませんので，ESISを出力したい場合は，出力ファイル名をコマンドラインで指定しなければなりません。ところが，RUNSP2はその設定ができません。第二に，RUNSP2は，正規化された文書実現値だけを得ることを目標にしたとのことです。したがって，ESISは得られないわけです。正規化された文書実現値を得た後の処理は応用次第ということになります。
したがって，RUNSP2では，ESISを介して他の処理へつなぐというワークフローは構築できないことになります。
もちろん，正規化された文書実現値からESISへ変換するコンバーターを作れなくもありません。その場合には，sgmlnormの出力よりも，省略された属性値などを含んだ形で正規化し出力するspamの方が，一層楽に作れるでしょう。しかし，RUNSP2ではspamを起動することはできません。
やはりESISにこだわるのであれば，コマンドラインによる起動しか当面選択できそうにありません。
ところで，ESISの扱いは，今後は大きく変わるでしょう。それは，文書体裁意味指定言語DSSSLが国際標準として1996年に制定され，すでに幾つかの実用的なツールが登場してきたからです。SGMLからDSSSLという流れでは，ESISは不要なのです。例えば，James Clark氏の開発したDSSSLエンジンjadeでは，パーザー（前処理）は内蔵され，フォーマッター（後処理）と一体化しており，二つの処理の間はgroveと呼ぶ内部的な表現でつないでいます。
顧みれば，SGMLが国際標準になったのが1986年ですから，二つの規格の間には十年という，コンピューター界としては異例の長い空白期間がありました。そのために，今まではSGML文書の後処理はESISを介して行なうというワークフローが構築されてきたわけです。
ESISはSGMLデータを線型に表現していますが，groveは，SGMLデータを木型に表現しています。内容的には同じものですが，後処理の合理性から見れば，後者のほうが優れています。
（1998年1月記）
