空白問題と内容モデル 3 （解決編）

この記事は、月刊『JavaWorld』誌（IDGジャパン）連載「XMLボキャブラリの理論と実践」第30回、31回、33回に付属のコラム（本文外）をまとめて、わずかに変更したものである。

1. はじめに

前々回の記事において、空白問題とその周辺事情に関し紹介し、前回記事では空白処理に関してより詳しく分析した。今回は、それらをふまえて一応の解決策を示そう。前回／前々回回の復習も織り交ぜながら話を進める。

これから以下に示す方法は、空白問題に対する1つのアプローチにすぎない。これが唯一の解だとか最良の解だとか主張する気は毛頭ない。だが、何もしないで手をこまねいているよりは、状況が改善されるとは思う。この対処案の応用として、最初の記事で触れた“奇妙な内容モデル”に正当な地位を与えることにする。つまり、“奇妙な内容モデル”でも何の困難もなく扱えることを示す。

2. 空白問題と派生する問題群

空白問題とは、「空白が文字データなのか、それとも区切り記号／整形用詰め物なのか、判断ができない」ことに起因するさまざまな困難を指している。この問題に関係して次のような問題も引き起こされる。

・「スキーマとの照合」と「空白の解釈」が互いに絡み合う

例えば、「要素<numberOfItem>の内容データ型がpositiveInteger（正の整数）である」とスキーマで指定されているとき、インスタンスの正しさは空白の解釈に依存する。次の3つの事例の正しさ（内容がpositiveIntegerであるか）は、そこに含まれる空白の取り扱いを決めない限りは判断できない。

・あたりまえに見える内容モデルが禁止されてしまう

次の2つの内容モデル（DTD構文で示す）は、直感的には納得できるものだが、実際には禁止されている。その理由は、文字データ（#PCDATAの部分）に空白を含めて良いかどうかが曖昧なためである。

もし、出現する空白がデータなのか無視すべき空白なのかを判断できれば、上のような内容モデルにも合理的な意味が与えられるはずである。

3. テキストチャンクの空白処理

ここで、後の説明のために、「テキストチャンク」という概念を導入しよう。テキストチャンクとは、XML文書中で、マークアップを含まない極大な（それ以上は伸ばせない）文字列範囲のことである。正規化されたDOMツリーで考えれば、1個のテキストノードがテキストチャンクを表すと考えてよい。ただし、正規化されてないDOMツリーでは、複数のテキストノードが連続したり、文字を含まないテキストノードが出現するので、「テキストノード＝テキストチャンク」とは限らない -- この点は注意する必要がある。なお、文字参照／実体参照／CDATAセクションは前もって展開しておくことにする。

以上の仮定のもとでは、どんなXML文書も、マークアップとテキストチャンクの列に、一意的に分解できることになる。主なマークアップは、開始タグと終了タグである。空内容タグは、連続した開始タグ、終了タグのペアに直せるし、コメントとPIは無視してよい。XML宣言やDOCTYPE宣言も考慮からはずそう。つまり、話を単純化するため、XML文書を「開始タグ、終了タグ、テキストチャンクが混ざったもの」と解釈する。

さて、このように単純化した設定で、空白問題をもっと追いつめよう。まず、開始タグと終了タグでは空白問題は生じないことが分かる。なぜなら、タグのなかの空白は区切り記号だし、属性値内の空白は属性値正規化（DOMの正規化とは別物）で処理されるからだ。よって、テキストチャンク内の空白にだけ注目すればよい。理論上は、テキストチャンクに対する空白処理は無限の多様性があるが、経験上は次の4種に分類される。

上から順に、空白保持、空白トリミング、空白圧縮、アプリケーション固有処理と呼ぶことにしよう。特別な知識やルールを仮定せずに行えるのは、空白保持、空白トリミング、空白圧縮の3種となる^(*注1)。

注1

テキストチャンクを行に分割して、行ごとにリーディング空白、トレーリング空白、行の内部に出現する空白の処理をそれぞれ指定し、さらに行の連結方法なども指定すれば、細かな空白制御が行える。ここでは、話を単純にするために、そのような細かな処理は、アプリケーション固有処理に分類している。

4. 要素ごとの空白処理指定

第30回の本コラムで、DOMツリーをテキストストリーム（キャラクタ列）に書き出すとき、要素ごとの整形ルールに基づき空白を追加することがあると述べた。そうであるならば、テキストストリームから読み込むときに、追加した余分な空白を削除すべきだろう。その削除（場合によっては何も削除しない）処理は、要素ごとに指定される。

例えば、要素<numberOfItems>にトリミング処理を行えば次のようになる。

この例（要素<numberOfItems>）においては、空白処理をした後で、内容文字列がpositiveIntegerの構文パターンと一致するかどうかをチェックすれば、直感に一致した結果が得られる。

5. 「奇妙な内容モデル」はもはや奇妙ではない

テキストストリームとしてのXML文書は、かなりの雑音が含まれる。“雑音” とは、どうでもいい非本質的な情報である。区切りや整形のための空白は典型的な雑音なのだが、困ったことに、雑音であるかどうか判定できない状態にある。目の前の空白をいくら眺めても何の印もついてないのだから、判定は絶対に不可能である。そうであるなら、メタ情報にたよるしかない。

とはいえ、空白処理のメタ情報はスキーマ定義から与えられる必要はない（もちろん、スキーマ定義に由来してもいいが）。例えば、書き出しのときに空白を追加するルールがあるなら、それに対応して、読み込みのときに空白を削除するルールが必要になる。これは、単にラウンドトリップ性を保つ対処であり、特に構文構造を制約するものではない。

スキーマが存在する場合でも、まず空白処理のルールを与え、スキーマとの照合はその空白処理ルールの適用後に行うほうが合理的である。そのようにすれば、「奇妙な内容モデル」問題は解消する。

空白処理が既に終わっているという前提だと、バリデータは非常に単純な動作をすればよい。要素<名前>の内容の最初が文字であれば（その文字がなんであっても）、内容モデル(#PCDATA)を選択すればよいし、そうでなければ、(姓, 名)という内容モデルでチェックすればよい。

実は、DTD構文の「#PCDATA」は、無視可能な空白も含む文字データの意味で、もともとが曖昧なのである。空白処理の後に残った文字は、すべてデータ文字（無視できない文字）となる。いまここで、データ文字を#CHARと書くことにしよう。#CHARを使って、要素<名前>を再定義すれば次のようになるだろう。

もうひとつの“奇妙な内容モデル”も書き直してみると次のようになる。

段落と節において、無用な空白は取り除いてあると仮定すれば、この内容モデルはもはや奇妙でも何でもない。何の問題もなく照合（パターンマッチング）できる。

6. まとめと考察

空白問題に対処するには、バリーデーションとは独立に空白処理を考えるべきなのだ。バリデーションをする場合でも、それに先だって空白処理が済んでいるほうが話がスッキリする（実際、“奇妙な内容モデル”はこれでスッキリした）。また、何にでも通用するような普遍的な空白処理を期待してはいけない。ありもしない理想の方法を求めても徒労に終わる。空白処理は、テキストストリームへの書き出し／テキストストリームからの読み込みのルールに依存して決まる。つまり、応用領域ごとに個別に考えるしかない。

ところで、今回の考察を進めるうえでいくつかの単純化をしている。例えば、「コメントとPIは無視してよい」と書いているが、「ほんとに無視可能なのか」「どうやって無視するか」までは踏み込んでない。実のところ、これは微妙な問題を含む。無視するには削除してしまえばいいのだが、単純に完全削除するか、コメントやPIを単一の間隔文字で置き換えるかによって結果が変わってくる。今回、大筋を述べたアイディアの細部まで詰めるのはそれなりの作業が必要になる。だが、この方針で十分に実用的な空白処理が得られると筆者は考えている。

空白問題のように、一見構文の問題に見えるものでも、構文の議論だけではまったく解決できないことがある。結局、適切な解は構文の使用状況に依存するのである。繰り返し強調するが、XML文書の同値性は応用領域に依存する。空白問題が解けないのは、個々の応用領域を無視して、普遍的／絶対的な処理を求めたからだったのだ。応用領域ごとの空白処理（同値性定義の一部）に基づけば、そこにもはやミステリーはない。