「構造化文書とは何か」をプライベートで訊かれたら、hidarumaはこう答えるだろう[1]。
「何も分からない。俺は雰囲気で構造化文書をやっている」
参考文献
挙げた文献については、記事中で著者名を省略することがある。
- 『なんでドキュメントといったらXMLが出てくるのか - golden-luckyの日記
- ライトウェイト構造化文書 - - golden-luckyの日記
- 『構造化文書とは - アンテナハウス』
- 『箇条書きの使い方と箇条書きの7タイプ - アンテナハウス』
- 『文体の科学』 山本貴光, 新潮社
- 『Structured Writing: Rhetoric and Process』 Mark Baker, XML Press
概要というか
構造化文書という表現は、筆者の界隈ではXMLと≒であるように扱うが、いざ定義を述べよと問われれば答えに窮する概念である。会社の見解のようなものはあるが、個人的な視座はそことは微妙に異なるからして。
とはいえ、曖昧なままであると執筆中の原稿の完成が遠のくので、現在の筆者の見解メモをまとめんとする。
テクニカルライティングの射程
テクニカルライティング指南に於いては文章の書き方と文書の書き方が混在する、というのがこのトピックでの主張である。
テクニカルライティングについての書籍・資料は多くある。実用の上では肌に合うものを探してもらえば良い。しかし構造化文書の資料として扱うにあたっては、書き方の仔細について論じるべきだろう。
ライティングの、所謂指南書ではグラデーション上の異なる位置にある話題が一息で語られることがある。テクニカルライティングについての本で、次のような記述に覚えはないだろうか[2]：
- 用語を統一せよ
- 文を短くせよ
- 主語と述語を明確にし、一対一で対応させよ
- 話題毎に段落を分けよ
- 箇条書きをせよ。項目はnつにせよ
- 最初に～を書け。次に～を書け
- 必要が無い限りは機序の順に書け
異物というには馴染んでいるが、トーンの異なるものが1つあった。「箇条書きをせよ」である。他は概ね「文」の話であるが、これは文以外の話と言えなくもない。「話題毎に段落を分けよ」は二者の中間くらいにある。この点は補足する。
文章について、「文を並べたもの」とする。仮に上の2つの差異について次の区分をするとしよう：
- 箇条書きを省いたものを技術的な文章の書き方、
- 箇条書きを含めたものを技術文書の書き方
文を並べる作業を、ある文の後に次の文、その文の後に更に次の文、と愚直に行っていけば、文字列で構成される長大な線が出来上がる。この文章を読んでいけば、執筆者が示したかったことは理解できる（ことが期待される）だろう。
では何のために箇条書きを使うのか。役割の詳解については各々の指南書に譲るが、本記事で示すところとしては「箇条書きで表される内容であることを示すため」である。つまり、箇条書きという構造を通して、その内容を見てもらうことを意図する故なのである。
一次元と二次元の境
『文体の科学』では、文を一次元的な存在であると看過し、その後に組版を経た書籍について二次元的存在として論じている。
「本の形」になる前と後で二者を異なるものとして見做す、（HTML出力とPDF出力、等々の話については別の機会に譲るとして、）ここでは一次元存在である文章と二次元存在化した本の差異について、構造に着目する。
本は一般に本文の他、表紙や裏表紙、目次といった付加物（これを付加物と見做すかは異論もあろう）、章や節などの区分けがある。或いはこれらも原稿状態で既に存在しているという主張もあるだろうが、本文に対して補助的な存在であることについては了解してもらいたい。
補助的な存在としてこれらは何の働きを負っているのか。表紙や裏表紙、背表紙は物理的に目に入る本全体のラベルである。章節・見出しは本文内容を階層化し箇所ごとのラベルを与える。目次はこの階層へのナビゲーションを、巻末索引はより細かな文脈へのレファレンスを与える。
表紙などは扱いがまた面倒であるが、章節は本文内容を、腑分けし、ラベルを付け、階層構造に嵌め込んだものである。
扨、本文以外は補助的な存在と述べた。そして、補助的な存在を補った本は二次元的であると書いた。やや三段論法めいているが、では、この補助的な存在、一時的存在を二次的存在に至らしむるこれこそが構造の役割なのではないだろうか。
妥当なXML文書と構造化文書
XML文書には妥当な（valid）XMLという概念がある。これは、「整形式（well-formed）かつ文書のスキーマに適合する」ことを示す。訳語として、スキーマに適合するかの検証（validation）を通るものであるから「有効な」などでも良さそうであるが、中々どうして「妥当な」という表現がよくできている。
文書スキーマは、そのXML（のインスタンス）が取り得る構造を規定するものである。「強調を示すstrongは段落文を示すpの中でしか書けない」といった具合。そしてこのスキーマはインスタンスとともに提供され（、ときに公開識別子として宣言されるが）、文書のインスタンスと合わせて渡される。文書の中身と、その設計図を合わせてのWeb用文書交換様式なのである。
そしてインターネット上の文書形式として普及に至らなかった理由の1つには、設計図が無いと読めないものと、設計図なしでなんとかなる範囲で書けるものの差があったのではないか。
この節の話と『構造化文書とは』の記事では、既に確たる構造が存在するという前提を取り回した。一方、「文書スキーマの交換・検証」という作業は、それ自体が「構造は文書に無条件に存在するものではない」ということを示唆している。
ライトウエイト構造化と解釈一意性
//TODO
組版・ドキュメントに関連する記事を投稿するコミュニティ、を予定しています。 文章表現よりはマークアップ・文章構造・自動組版に焦点を絞れると他コミュニティと差別化できると思っていますが如何。
Discussion