昨日は、ドキュメントにおける構造というのはセマンティックな構造である、という話をしました。 今日は、そのセマンティックな構造をどう扱うか、という話です。
ドキュメントの構造は一般にXMLを使って表されている
結論から言うと、ドキュメントの構造は、XMLで扱うのが一般的です。 ドキュメントの構造を表すのにXMLがよく使われているのには理由があって、それは、ドキュメントが木構造だからです。
本当はここで「XMLとは何か」みたいな話をする必要があると思うんですが、ここではXMLというのは「木構造のデータを表現するときの標準的な構文」くらいの意味で使います。 つまり、表現する「木構造のデータが具体的にどんなか」については別の問題ということにして、木構造で表せるようなデータにとって共通で必要そうな構文だけを定めたものが、（ここでいう）XMLです。
ちなみに、「木構造のデータが具体的にどんなか」のほうは、「XMLアプリケーション」と呼ばれます。 XMLアプリケーションとしては、HTML（正確にはXHTML）とかMathMLとかDocBookとかがあります。 XMLアプリケーションを定義するには、一般にはDTDとかXML SchemaとかRELAX NGとかいった「スキーマ」を使います。 上の段落で言いたいことは、そういったスキーマを使って定義されたXMLアプリケーションが何であるかを本記事では気にしない、ということです。
ドキュメントの木
よくわからないと思うので、ドキュメントの木構造を例に説明します。 ドキュメントの木構造といって想像するのは、たぶんこんなのでしょう（適当に描いたのでツッコミはなしで）。
緑色の葉に相当するのがインライン要素、そのインラインの要素が集まったものが茶色の節に相当するブロック要素、ブロック要素が集まってドキュメントになる、という感じです。
ただ、この単純なイメージだと、「インライン要素にどんなものがあるか」、「ブロック要素にどんなものがあるか」、「それらをどう組み合わせていいか」といった具体的な木の形状までは説明できてません。 実際に必要な要素が何であるか、要素の組み合わせとして何を認めるかは、ドキュメントの用途や種類によってまちまちです。
とはいえある程度までは、ドキュメントが必要とされる分野ごとに「汎用性のある要素の組み合わせ」みたいなものは考えられるでしょう。 そういう「汎用性のある要素の組み合わせ」を考えるということは、木構造を制限するということです。 その手段がXMLアプリケーションです。
言い換えると、ドキュメントがどんな形状の木になりうるかをXMLアプリケーションとして制限する、という世界観です。 たとえば、技術書のために必要な制限を課したXMLアプリケーションとしては、DocBookがあります。
（木構造ではないドキュメントもありうるとは思うんですが、それはここではドキュメントではないものとします。どう考えても木構造とみなすのが適切でなさそうなドキュメントがあったとして、それをコンピューターでどう扱えばいいかという話も面白そうだけど、そういう話はどこかにあるのかなあ。）
XMLは山かっこでなくてもいい
ここまでの話を整理すると、こうなります。
どうでもいい話に聞こえるかもしれませんね。 なんでわざわざこんなことをくどくど書いてるかというと、これらの話にはXMLの象徴である「山かっこの記法」が出てこないことを強調したいからです。 実際、こういう枠組みを実現するのに、記法が山かっこタグである必要はありません。
XMLで表せる木構造は、文字通り「構造」であり、記法とはレイヤが違います。 XMLの世界観だと、「XMLアプリケーションごとにスキーマで定義した構文」のほうが記法に相当します。
もっとも、この「XMLアプリケーションごとにスキーマで定義された構文」もXMLと見た目は同じ、つまり、通常は山かっこタグになります。 記法についてはドキュメントの構造とは別に考えるべきだけど、XMLでは両方とも同じ記法を採用している、みたいな感じです。 ドキュメント屋さんとして、XMLを使うときはこの辺りの事実からは逃れられない感じです。
ただ、ぶっちゃけ木構造を表すなら、山かっこタグよりも優れたシンタックスがあります。そう、S式です。 S式をシンタックスとするXMLをSXMLといいます。
というわけで、明日はLispの時間です。
