付論 報告書等のネットワーク公開へ向けて

1 報告書公開の新しい方法

 本報告書は,従来からの紙での印刷による公開に加え,ネットワーク(WWW)上で「電子化文書」としても公開する。

 こうした報告書公開の試みは,本委員会だけでなく,電子協の他の委員会でも行われている。

 例えば,本年度の電子決済システム専門委員会では,ネットワーク上の報告書から紙上の報告書を制作する形態をとった。先ずクローズドなWWWを設定し,そこに委員各自が担当する報告書の内容をHTMLコンテンツとして書き込み,それを委員同士で査読した。査読が完了した後,それを公開[http://www.jeida.or.jp/を参照]し,そこから紙上の報告書を制作した。

 本委員会でも,先ずクローズドなWWWを設定し,そこにヒアリング調査の速記録をHTMLコンテンツとして書き込み,委員はそれを参照しながら原稿を執筆した。原稿の査読はメーリングリストを介して電子メールで行い,紙上の本報告書を制作した。その後にネットワーク上の報告書を制作した。

 この二つの対照的な出版形態はどちらもワンソース・マルチメディア(又は,ワンソース・マルチユース)であるが,技術的には同じではなく,一長一短がある。

2 本報告書の制作手順

 本報告書の制作に当たってワンソース・マルチメディアのベースとなるSGML文書型定義(DTD)を設計した。これは本報告書の文書型を反映し,かつ紙への印刷とHTMLコンテンツへのタグ変換が容易になるように設計した。

 原稿データにSGMLタグを付与しソースにする処理がテキスト処理系Perlにより自動的に行えるように,あらかじめ執筆要領を決めて委員に徹底した。またスタイルタグによる自動流し込みができるDTPソフトウェアを使用し,そのスタイルタグをSGMLタグからPerlにより自動的に変換した。同様に,HTMLタグもSGMLタグからPerlにより自動的に変換した。結果として,手作業は原稿データの正規化作業に集中したが,昨年度の報告書作成時に比べると,作業量はかなり軽減したと思う。

 本報告書の制作手順は,おおよそ次のとおりであった。

  1. 委員による原稿執筆
  2. 電子メールによる,電子メーリングリストへの入稿
  3. グループ単位による査読
  4. 電子メールによる,編集者への入稿
  5. 原稿データの整理
  6. 現行のHTMLやDTPソフトの機能分析,DTDの設計,DTPスタイルタグの設計
  7. 原稿データの正規化,不要な空白の検査・除去,外字や半角仮名文字などの検査・置換
  8. ソースの作成(SGMLタグ付け),DTPスタイルタグ付け,HTMLタグ付け
  9. 図表の清書・デジタル化
  10. SGML検証用パーザ(sgmls)によるタグ付けの検証
  11. DTPソフトウェアによる割り付け
  12. WWWブラウザ(NetScape Navigater)によるタグ付けの検証
  13. WWWサーバのデータベースへの本報告書の登録,実際のアクセスによる検査

3 原稿データの問題

 本委員会の制作方法とは対照的な制作方法(つまり,ネットワークから紙への展開)においては原稿データに多くの問題があると思われる。

 第一の問題は,原稿データに構造情報や意味情報が正しく,かつ十分に含まれていない点である。HTMLでタグ付けされたコンテンツは構造情報や意味情報を十分持っているように見える。電子決済システム専門委員会の事例では,多くの執筆者はワープロで原稿を書いて,プラグインのHTML出力ソフトを使ってコンテンツを作り出している。確かに,ディスプレイの表示では執筆者の意図したであろう割付けがされているが,コンテンツを見るとHTMLのタグ付けは不十分である。それはプラグインソフトの問題も少なからずあるが,大半はスタイル定義の不統一によるものだと思われるので,うまく運用すれば,この問題は解決できるだろう。現状では,HTMLソースではなく,テキストデータとして取り込んで再編集する方が紙への展開の近道である。

 第二の問題は,コンテンツに含まれる画像データの解像度が粗い点である。WWWにおけるGIFやJPEGといった形式の画像の解像度はディスプレイの解像度に合わせてあるために,紙への出力では粗く感じられてしまう。テキストデータはブラウザで取り込めるが,画像データは取り込んでも使えない場合が生じる。この問題はソースのそのものに関わることなので簡単に解決できない。

 第三の問題は,画像データに含まれている文章の書体が紙への印刷書体と異なったり,解像度が粗くなってしまう点である。これは画像の種類にもよるのだろうが,画像の制作については何らかの指針が必要であると思われる。

 第四の問題は,コンテンツに外字が含まれることがある点である。コンテンツを作るワープロやエディタに外字検出の機能がないことも手伝って執筆者は気付いていないようである。またコンテンツの査読を担当する者も同じような環境で画面を見ているせいかやはり気付いていないようである。標準字としての約物(記号類)の不足は以前より指摘されているところだが,執筆者の表現を抑えることは難しいので,この問題はワープロやエディタの機能で解決するしかないと思われる。

 結論として,現時点では,紙からネットワークへ展開する制作方法の方が問題が少ないと考えられるが,今後もこうした出版形態を続けるのであれば,あらかじめマルチメディアの目的を満足するようなソースを持つように制作方法を変える必要があるだろう。

4 ワンソース・マルチメディアへのアプローチ

 1996年サンフランシスコで開催されたSeybold会議[http://www.sbforums.com/を参照]では,ワンソース・マルチメディアの技術の動向を次のように説明した発表があった。すなわち,WWWが盛んになった1994年頃は印刷用に加工されたデータをWWWやCD-ROMに流用するリパーパシング(repurposing)が主流であったが,最近では最初からマルチユースの目的に合わせた情報の持ち方やワークフローを考えておくプレパーパシング(prepurposing)へ変わりつつあるという。

 プレパーパシングの方法論としてSGML+DSSSL+SPDLの図式があるが,現時点では実用的な処理系は見当たらない。

 ここでArchtype社から発表されたNuDocという方式[http://www.atype.com/nudoc.htmを参照]に注目したい。NuDocは,文書をコンテンツオブジェクト,フォーマットオブジェクト(文書設計の意図),表示オブジェクト(実際のページ要素)に分け,それらをNuDocエンジンと呼ぶ応用プログラムインタフェース(API)で管理・制御する。このエンジンは,マルチプラットフォーム(Windows95,WindowsNT,MacOS)で動く。ちなみに,NuDocの実現にはApple社,Nynex社,SII社が参画している。

 NuDocは,より運用しやすいSGML+DSSSL+SPDLの図式を従来の印刷と電子出版の分野で実現しようというものである。つまり,ワンソース・マルチメディアは,ワープロにプラグインするHTML出力ソフトのようなアプローチでは実現しにくいと言える。

5 本委員会における原稿執筆要領とSGML文書型定義

 本報告書の制作に当たって設計したワンソース・マルチメディアのベースとなる原稿執筆要領とSGML文書型定義(DTD)を参考までに紹介する。

(1) 原稿執筆要領

 この原稿執筆要領は,執筆者があまり負担を与えないで,しかも意図するスタイルが指定できるように考慮されている。

(a) 見出し
  1. 章節の見出しは行頭から書き出し,その番号付けは次のように3段階までとする。
  2. それより下位は(1),(2),...,さらにそれより下位は(a),(b),...とする。
  3. 番号,全角のスペース,見出しの語句の順に書く。

 例

 第1章 総論
 1.1 規格の社会学への視座
 1.1.1 「役割」という視点の導入
 1.1.2 どのような役割があるか
 1.1.3 役割に注目した分析
 (1) 基本
 (2) 規格が先にある場合(デジュア)

(b) 箇条書

 箇条書きのブレット記号は中黒(全角)を使い,ブレット,全角のスペース,箇条書きの順に書く。

 例

 ・ 作る人
 ・ 使う人
 ・ かつぐ人

(c) 段落

 段落の始まりには,全角のスペースを置き,段落の最後で改行する。

 例

 先ず「作る人」は,文字通り,規格なり製品なりを開発する人である。規格制定者の中には,公的規格を作るために企業や学術関係から集まってできた機関もあれば,規格作りを専門とするヨーロッパの「規格屋」のような人もいるし,共通のドメインに属するいくつかの企業が集まって規格を決めるコンソーシアム形式もある。

(d) 句読点

 句点はマル(。),読点はピリオド(,)を使う。

(e) 文字
  1. 標準字を使う。
  2. 欧文,数字は半角文字を使う。(全角の英数字は,できる限り使わない。)
  3. 英単語の前後のスペースは付けない。
  4. 半角のカタカナ,半角の句読点,半角のかぎかっこ,半角の中黒点は使わない。
  5. 外字は原則的に使わない。どうしても使う場合は,別途FAXにて字形を知らせる。

(f) 図表
  1. 図データは,TIFFかEPSF形式で表わし,電子メールの「添付書類」で送る。
  2. 表データは,原稿中にテキストで表わす。

(g) その他
  1. メールの「題名」についての取り決め
  2. 原稿の取扱い表記についての取り決め

(2) SGML文書型定義

 このDTDは,HTMLに似た型をしている。次の記述で明らかなように,あまり制約のない構造をしている。なお,このDTDは原稿執筆要領で記述できる文書型よりも拡張されている。

<!-- 文書型定義  REPORT -->
<!ENTITY	amp	CDATA	"&#38;"	-- データ実体参照すべき文字“&” -->
<!ENTITY	gt	CDATA	"&#62;"	-- データ実体参照すべき文字“>” -->
<!ENTITY	lt	CDATA	"&#60;"	-- データ実体参照すべき文字“<” -->
<!ENTITY	copy	CDATA	"(c)"	-- 著作権表示 -->
<!ENTITY	% heading	"(H1|H2|H3|H4|H5|H6|H7|H8|H9)"	-- 章節の見出し,Hの添字はレベル -->
<!ENTITY	% olist	"(OL1|OL2|OL3|OL4)"	-- 番号付き箇条書,OLの添字はレベル -->
<!ENTITY	% ulist	"(UL1|UL2|UL3|UL4)"	-- 番号なし箇条書,ULの添字はレベル -->
<!ENTITY	% paragraph	"(P0|P1|P2|P3|P4)"	-- 段落,Pの添字はレベル -->
<!ENTITY	% block	"(%heading;|%paragraph;|%olist;|%ulist;|(PRE, F?)|(G, F?)|(TG, G)|(T?, TABLE)|R|X)"	-- 報告書の本文 -->
<!ELEMENT	REPORT	- -	(TITLE?, AUTHOR?, (%block;)+)	-- 報告書 -->
<!ELEMENT	TITLE	- O	(#PCDATA)	-- 表題 -->
<!ELEMENT	AUTHOR	- O	(#PCDATA)	-- 著者名 -->
<!ELEMENT	%heading;	- O	(#PCDATA)	-- 章節の見出し -->
<!ELEMENT	%paragraph;	- O	(#PCDATA)	-- 段落 -->
<!ELEMENT	%olist;	- O	(#PCDATA)	-- 番号付き箇条書 -->
<!ELEMENT	%ulist;	- O	(#PCDATA)	-- 番号なし箇条書 -->
<!ELEMENT	X	- O	EMPTY	-- 単なる行空け -->
<!ELEMENT	R	- O	(#PCDATA)	-- 参考文献の表題 -->
<!ELEMENT	PRE	- -	(#PCDATA)	-- 割付け済みのテキスト -->
<!ELEMENT	F	- O	(#PCDATA)	-- 図の表題 -->
<!ELEMENT	G	- O	EMPTY	-- 図 -->
<!ATTLIST	G	G	CDATA	#REQUIRED	-- 画像データファイル名 -->
<!ELEMENT	T	- O	(#PCDATA)	-- 表の表題,表データTABLEが後続する場合 -->
<!ELEMENT	TG	- O	(#PCDATA)	-- 表の表題,画像データGが後続する場合 -->
<!ELEMENT	TABLE	- -	(TR+)	-- 表 -->
<!ATTLIST	TABLE	BORDER	CDATA	#IMPLIED	-- 罫線幅 -->
<!ELEMENT	TR	- O	(TH | TD)+	-- 表の行 -->
<!ELEMENT	(TH | TD)	- O	(#PCDATA)	-- 見出し欄と明細欄 -->
<!ATTLIST	(TH | TD)	ALIGN	(LEFT|CENTER|RIGHT)	LEFT	-- 欄内の行揃え --
	ROWSPAN	NUMBER	1 	-- 後続の行数 --
	COLSPAN	NUMBER	1	-- 後続の列数 -->

(c)1996 JEIDA