よく知られているように、ドキュメントには「構造」があります。 WebページではHTMLとCSSにより構造とスタイルを分離するべきとか、Wordでは書式設定をスタイルとして定義して使うことで構造とスタイルを分離するべきとか、ドキュメントの「べき」論で必ず言及される「構造とスタイルの分離」における「構造」です。
昨日までの話ではPDFにもドキュメント構造というのが出てきました。あれは、この「構造とスタイルの分離」というときの「構造」とは別物なので注意してください。 たぶん、PDFのドキュメント構造には、「ドキュメントを表すデータ構造」くらいの意味合いくらいしかありません。
一方、ドキュメントの話において「構造とスタイルの分離」というときの「構造」は、もうちょっとこうなんていうか、セマンティックな話です。 データをどう構成するかではなく、ドキュメントで表したい意味をどう構成するか、という話。
したがって、ドキュメントの話をするときは、「ドキュメントで表したい内容」を「ドキュメントの最終的な見た目」みたいなフワフワから切り離すことで、前者の可搬性を高めていくことが目指されます。
話はちょっとずれるんですが、コンピューターで扱うドキュメントの話をするときって、「可搬性を持たせたい部分がどこか」という点がわりと曖昧なままになってることがあるので、その点に注意して聞くといいと思います。 PDFは、見た目の可搬性から出発していました。 「構造とスタイルの分離」の話では、構造の可搬性を目標にします。まあ、あんまりこっちの話をするときは「可搬性」という用語は使わず、再利用可能性とかいうことが多いので、混乱はないと思うけれど。
構造とスタイルと記法
コンピューターでドキュメントを扱う話をするときは、「構造とスタイルの分離」がどれくらいかっちりできてるかで、技術の素性の良さみたいなのが語られがちです。 つまり、構造とスタイルの分離っていうのは、ドキュメント技術においてはある種の金科玉条です。
まあ最近だと、「金科玉条でした」と過去形で書くほうが正解なのかもしれませんね。 いまの流行りは構造とスタイルの分離でなく、書式とか記法、つまりシンタックスに移っているようなので。
しかしドキュメントにおけるシンタックスって、結局のところ、ドキュメントのセマンティックな構造を暗に埋め込むためにどんな表現を使うか、という話なんですよね。
ドキュメントの構造を暗に表現するシンタックスの話については、このアドベントカレンダーでいつか話す予定です。 いまは何が言いたいかというと、構造とスタイルの分離を重視する立場だと、「人間の直観を裏切らない記法」みたいな観点はそれほど重視されません。 一方で、人間が編集しやすい記法が何かという話に注力してしまうと、それはそれでドキュメントにおける構造とスタイルの分離の伝統とは違う話をしてしまう可能性が高い。
なにが言いたいかというと、これからのドキュメント技術について語るときの前提は、「記法」「構造」「見た目」の3つのレイヤを意識したモデルに依拠するといいのかな、ということです。
ドキュメント技術の3階層モデル
だんだん与太話っぽくなってきましたが、「シンタックス（記法）」→「セマンティクス（構造）」→「スタイル（見た目）」という3つの階層でいろんなドキュメント技術を考えるのは、わりと建設的なモデルなんじゃないかなと個人的には考えています。
個人的にこのモデルが特に気に入ってるのは、プログラミング言語における「ソースコード」→「抽象構文木」→「実行ファイル」の関係によく似ている点です。 プログラミング言語に似ているということは、コンピューターでドキュメントを扱う方法について考察するときに都合がいい。
たとえば、プログラミング言語だと、この階層の矢印を逆方向にたどるのが無理筋だということをみんながよく知っています。 ふつうの人が直接触れるのは最下層のみだけど、階層を下にいくにつれて、その中身は人間が理解しにくいモノになっていく。 これがドキュメント技術の話になると、どの階層を見ても人間が読む文字が見えるので、似たような階層があることに気が付きにくい。 意識的に層の違いを強調してあげる必要があると思うんですが、そこで「プログラミング言語における「ソースコード」→「抽象構文木」→「バイナリ」の階層みたいな感じ」といえば、なんとなく伝わりそうな気がします。
階層を下に降りるほど編集の自由度がなくなるという点も、ドキュメントの3階層がプログラミング言語に似ているところだと思います。 PDFを直接いじることが煩雑かつ（ドキュメントの可搬性にとって）危険であることは何となく昨日までの記事で伝わってると思うんですが、これはドキュメントの「シンタックス（記法）」→「セマンティクス（構造）」→「スタイル（見た目）」という階層で考えれば「プログラムの実行ファイルを直接いじる」のと同じ話なわけで、なんとなく当然の成り行きであることが伝わりやすい気がします。 大変かつ危険だけど、条件によっては安全に実行するすべがないわけでもないので、その必要がある場合にはそのためのPDF編集ツールを導入してください、という話がしやすいでしょう。
編集者の仕事は各階層をそれぞれがんばること
この見方でポジショントーク的に説明しやすいことがもう一つあって、それは、プログラミング言語で実行環境に相当する部分はドキュメント技術では人間の脳である、という点です。 そう考えると、編集者の仕事っていうのは、「人間の脳におけるドキュメントの実行を最適化するために各階層で手を尽くすこと」に見えてこないでしょうか？
プログラミングにおいては、シンタックス、セマンティクス、スタイルの各階層だけでなく、その上、つまりアルゴリズムの改良とかデータ構造の工夫も重要です。 たぶん、ドキュメントの仕事でそれに近いのは、文章のリライトとか、いわゆるトンマナの調整、それに校正なんかなんでしょう。
さらに上の階層、そもそも現実の問題をどんなアプリケーションとして作ればいいのかを含めた設計に相当する部分は、ドキュメントでいうと企画ですね。
最後はちょっと強引に編集者の仕事論っぽい話をしてみました。 明日は構造化文書の本丸、XMLの話です。
