スタイルシートで変換したXHTML文書は、整形性は大抵保っているものの、バリデータにかけると悲惨な状態であることがしばしばあります。また大量の文書を処理する際、妥当でない文書を考慮に入れると大量のエラー検証用のコードを紛れ込ませなければならず非効率です。色々と必要性が出てきましたので、自家製XML用の妥当性を検証するためのXML Schema文書を書き始めました。
自家製XMLを書く際、このように別々の異なる名前空間をもった要素間で多重に入れ子関係を作るのは……
<body>
<j:dl>
<dt>foo</dt>
<dd>bar</dd>
</j:dl>
</body>スキーマを書く際に死ねるので止めておいた方がいいです（自戒）。
その一端をメモしておきますと、上の例ではまずデフォルトの名前空間に関するスキーマの中で、jという接頭辞で表される名前空間のスキーマをインポートしなければなりません。さらに、そのjのスキーマの中で、内容モデルに使用する要素に関するスキーマをインポートしなければなりません。入れ子の数だけインポート。
targetNamespace属性で名前空間を決定するやり方が何となく糞っぽく思えてきたのですけど、気のせいでしょう、多分。
ルート要素直下に見出し要素を並べた「フラットな」文書の構造をチェックします。
<xsd:group name="Section1.class">
<xsd:sequence>
<xsd:element ref="h1" minOccurs="1" maxOccurs="1" />
<xsd:group ref="Text.class" minOccurs="0" maxOccurs="unbounded" />
<xsd:group ref="Section2.class" minOccurs="0" maxOccurs="unbounded" />
</xsd:sequence>
</xsd:group>
<xsd:group name="Section2.class">
<xsd:sequence>
<xsd:element ref="h2" minOccurs="1" maxOccurs="1" />
<xsd:group ref="Text.class" minOccurs="0" maxOccurs="unbounded" />
<xsd:group ref="Section3.class" minOccurs="0" maxOccurs="unbounded" />
</xsd:sequence>
</xsd:group>
<!-- 以下同様にSection6.classまで定義 -->このSection1.classというグループを、ルート要素の型定義に含めて完成です。XSLTでの構造化に比べれば天国でした。尚、Text.classには、heading要素（h1?h6）以外のブロック要素（への参照）が含まれています。
自分で書いたのは殆どこれだけです。他は、Modularization of XHTML in XML Schema（W3C Working Draft 9 December 2002）のスキーマを修正（改ざん）して全体を仕上げました。所謂テキストノードの部分や属性値については、データ型がかなり緩いものが多いのでまだ調整中です。例えばこのようなもの：
<!-- a character encoding, as per [RFC2045] -->
<xsd:simpleType name="Charset">
<xsd:restriction base="xsd:string" />
</xsd:simpleType>
これでは制約が無いといっているに等しいわけです。
グローバルな位置にあるgroup要素の子要素（chice|sequence|all）にmaxOccurs属性かminOccurs属性が現れるとエラー。コンテクストに依存したエラーなのかどうか……。お陰でXHTMLのXML Schema文書を大幅に書き換えなければなりませんでした。定型的な作業なので面倒はありませんでしたが。
最も恐れていたのが検証の速度です。最も多い10kb程度のXML文書を検証するのに0.5秒くらい、最も大きい39kbのファイルで2秒弱でした。一括して検証するには遅すぎですが、新規作成時や更新時にチェックする分には問題無いレベルで一安心。
所謂「カメレオンスキーマ」を書いたのだけれども、やはり名前空間を持たせた方が長期的には良かったかもしれない。今のところメリットしか感じていないけれども、それはMSXML4のDOMがlevel1にしか対応していないからだろうなあ。