XML Schema: やるべきこと、やってはいけないこと

Kohsuke KAWAGUCHI 著
なんばりょうすけ訳

原文はこちら。

[]内は訳者による注である。

はじめに

XML Schema は学ぶのも使うのも簡単だ … 落とし穴をよける方法を知っていればね。「やるべきこと」はこれだ。最低これだけおぼえておけばいい。

これを使え!: 要素宣言、属性グループ、モデルグループ、単純型
可能な限り XML 名前空間を使え! そしてその正しい使い方を学ぶべし。

何を言ってるかわからない? そういう人はチュートリアルを読んで欲しい。

そして「やってはいけないこと」がこれだ。

XML Schema を使いこなそうとするな! そんなことは不可能だ。
こんなものは使うな!: 複合型(その理由)、属性宣言(その理由)、記法(その理由)
ローカル宣言は使うな! (その理由)
置換グループは使うな! (その理由)
targetNamespace 属性のないスキーマ (いわゆるカメレオンスキーマ)を使うな! (その理由)

長くておぼえられない? それならこの一行バージョンをおぼえてほしい。

「XML Schema = DTD + データタイプ + 名前空間」だと思え!

実際「やってはいけない」ことをやらないことで失うものは何もない。信じて欲しい。ここに書いたルールに従うなら XML Schema と一緒でもハッピーに暮せるはずだ。

この文書を書いた動機

すでにWeb上には似たような文書がいくつかある。しかし僕はそれらの文書は特殊な人たちによって書かれている、ということ気が付いた。彼らはものごとの限界に挑戦する素晴らしい人たちだ。彼らは XML Schema ワーキンググループのメンバーでさえ想像もしなかったようなクールな裏技を発明せずにはいられないんだ。

彼らにしてみれば XML Schema は新しい素敵なオモチャというわけだ。

そういうのとは違う文書が必要だ。ビジネスのためにXML Schema を使う人たち、使おうとしているが途方にくれている人たち、のための文書が。

そういうわけで、この文書の目的は、あなたがなにをすべきで、なにをすべきでないかについての堅実なガイドラインを示すことにある。

コメントはいつでも歓迎。一つでもあれば是非しらせて欲しい。
[ Kohsuke KAWAGUCHI は日本語をとてもよく理解するので彼に直接メールするのがいいだろう。日本語が変だとか誤字脱字の類いを見つけた場合はなんばりょうすけまでどうぞ。]

なぜ複合型を避けるべきか

あなたが複合型が何か知らないなら幸いである。なぜならあなたが書きたいスキーマには複合型なんて必要ないからだ。実際、複合型を使って書かれたスキーマはいつでも複合型を使わずに書くことができる。
だとすれば、そんな役に立たないものを学ぶために貴重な時間を費やす必要などあるのだろうか?

納得した? それならここから先は読まなくていい。。。

複合型はモデルグループに継承を足し算して使いやすさを引き算したものだ。どちらも内容モデルを定義するのに使われるという意味では兄弟みたいなものだ。複合型は他の複合型やモデルグループの中から使えないので使いやすさの点で難がある。一方モデルグループはそういう制限なしで使える。

複合型のアドバンテージは「継承」だけだ。そこで、なぜあなたが継承を使わなくてよいか、を説明しよう。継承には二種類ある。 拡張(extension)と制限(restriction)の二つだ。

拡張によって基底型の内容モデルの後ろに要素を追加することができる。ということは、こんなモデルグループを書けば拡張と意味的に同じことができるんだ。


<xs:group name="extendedType">
  <xs:sequence>
    <xs:group ref="baseType"/>
    
    <!-- append things that you want -->
    ....
  </xs:sequence>
</xs:group>

制限によって基底型の内容モデルを制限することができる。しかし、複合型[と制限]を使っても、内容モデル全体を書かなくてはいけないことに変りはないんだ[差分で書けるわけではないということ]。基本的に複合型を使おうがモデルグループを使おうが、同じものを書かなくてはならない。

それなら制限を使うと何が嬉しいんだろう。嬉しいのはたった一つ、エラーチェックができることだ。バリデータは内容モデルが正しく制限されていなければ、おそらくエラーを報告するだろう。

しかし不幸なことに、これはほとんどアドバンテージにはならないんだ。

第一に、バリデータにとってこのチェックを厳密に実施することは大変なことなんだ。仕様書のこの制約を定義している箇所をちょっと見て欲しい。何が許され何が許されないかを指定するのに 3.9.6 章が丸ごと割かれている。[バリデータを実装する]開発者がこの制約チェックを実施しないで済ませたい、という強い誘惑に駆られたとしても不思議じゃないのがわかるだろう。このあたりは XML Schema ワーキンググループのメンバーが開発した XSV でさえ、部分的にしかサポートしていないんだ。

そういうわけで、あなたが使うバリデータがこの[制限による継承に関する] 制約チェックを完全に実施しないということは、多いにありそうなことだ。これで制限の持っていた唯一のアドバンテージは消え去ってしまったわけだ。

第二に、せっかく制限を正しく書いても、あなたの使うバリデータではエラーになることがあるんだ。次の例で考えよう。


基底型:
<xs:all>
  <xs:element name="a" />
  <xs:element name="b" />
  <xs:element name="c" />
</xs:all>

制限による派生型:
<xs:all>
  <xs:element name="b" />
  <xs:element name="a" />
</xs:all>

後者は前者の正しい制限のように見える。しかし XML Schema はこれを禁止している。こんなのは氷山の一角だ。この件に興味があるならMSL の最後のページにあたって欲しい。

モデルグループを複合型のかわりに使っていればこんな問題とは無縁でいられるんだ。

なぜ属性宣言を避けるべきか

正確に言うと、避けるべきなのはグローバル属性宣言であって、 ローカル属性宣言は使ってよい。グローバル属性宣言というのは例えばこういうものだ。


<xs:schema xmlns:xs="http://www.w3.org/2001/XMSchema"
      targetNamespace="http://best.practice.com">
  <!-- attribute whose name is foo -->
  <xs:attribute name="foo" type="xs:float" />
  
  <xs:element name="root">
    <xs:complexType>
      <!-- content model -->
      ....
      
      <xs:attribute ref="foo" />
    </xs:complexType>
  </xs:element>
</xs:schema>

実は、このスキーマはこんな文書インスタンスを受理しない。

<root xmlns="http://best.practice.com" foo="5.12">
   ...
</root>

属性グループならこんな問題はない。だから属性宣言のかわりに属性グループを使うべきだ。


<xs:schema xmlns:xs="http://www.w3.org/2001/XMSchema"
      targetNamespace="http://best.practice.com">
  <xs:attributeGroup name="root.attributes">
    <!-- attribute whose name is foo -->
    <xs:attribute name="foo" type="xs:float" />
  </xs:attributeGroup>
  
  <xs:element name="root">
    <xs:complexType>
      <!-- content model -->
      ....
      
      <xs:attributeGroup ref="root.attributes" />
    </xs:complexType>
  </xs:element>
</xs:schema>

属性グループからは他の属性グループを参照できる。こうやって、共通属性を一つの属性グループに書いて、よそから参照することができるんだ。

なぜ記法宣言を避けるべきか

記法のことなんて聞いたことなかったとしても大丈夫。それによってあなたは何も失ってはいないんだから。記法は[SGMLとの]後方互換性のためだけにある。いまさら学ぶ必要なんて全くない。

敢えて記法のことを知りたいなら、XML Schema の記法は DTD のそれとは互換性がないことは知っておいた方がいい。なぜ互換性がないかといえば、XML Schema の記法は QName なんだ。

仕様書にある例を見てみよう。


<xs:notation name="jpeg"
             public="image/jpeg" system="viewer.exe" />

<xs:element name="picture">
 <xs:complexType>
  <xs:simpleContent>
   <xs:extension base="xs:hexBinary">
    <xs:attribute name="pictype">
     <xs:simpleType>
      <xs:restriction base="xs:NOTATION">
       <xs:enumeration value="jpeg"/>
       <xs:enumeration value="png"/>
       . . .
      </xs:restriction>
     </xs:simpleType>
    </xs:attribute>
   </xs:extension>
  </xs:simpleContent>
 </xs:complexType>
</xs:element>

<picture pictype="jpeg">...</picture>

この例はオッケーだ。しかし次の例は上のスキーマには受理されない。たとえプレフィクス "pic" が正しく宣言されていてもダメだ。


<pic:picture pictype="jpeg"> ... </pic:picture>

頭が混乱してきた? 記法は QName だから正しくはこう書かなくちゃいけないんだ。


<pic:picture pictype="pic:jpeg"> ... </pic:picture>

明らかにこれは唯一の存在意義[後方互換性]を失わせている。

記法にこだわる理由なんて全く何もない。記法は SGML のためのものだ。

なぜローカル宣言を避けるべきか

XML Schema では要素宣言の内側にさらに要素宣言が書ける。


<xs:schema xmlns:xs="http://www.w3.org/2001/XMSchema"
      targetNamespace="http://best.practice.com">
  <xs:element name="person">
    <xs:complexType>
      <xs:sequence>
        <xs:element name="familyName" type="xs:string" />
        <xs:element name="lastName" type="xs:string" />
      </xs:sequence>
    </xs:complexType>
  </xs:element>
</xs:schema>

しかし一般には可能な限りこれを避けるべきだ。なぜなら上のスキーマはこんな文書インスタンスを受理しないからだ。


<person xmlns="http://best.practice.com">
  <familyName> KAWAGUCHI </familyName>
  <lastName> Kohsuke </lastName>
</person>

かわりにこんなふうに書かなくてはいけない。


<foo:person xmlns:foo="http://best.practice.com">
  <familyName> KAWAGUCHI </familyName>
  <lastName> Kohsuke </lastName>
</foo:person>

これはタイプ量が増えるだけではなく、XML 名前空間の悪い使い方だ。この問題を避けるには、こう書くとよい。


<xs:schema xmlns:xs="http://www.w3.org/2001/XMSchema"
      targetNamespace="http://best.practice.com">
  <xs:element name="person">
    <xs:complexType>
      <xs:sequence>
        <xs:element ref="familyName" />
        <xs:element ref="lastName" />
      </xs:sequence>
    </xs:complexType>
  </xs:element>
  
  <xs:element name="familyName" type="xs:string"/>
  <xs:element name="lastName" type="xs:string"/>
</xs:schema>

他に選択肢がなくて、どうしてもローカル要素宣言を使う必要があるのなら、 elementFormDefault="qualified" を schema 要素に追加するといい。でもこれが何を意味するのか理解しようなんて思っちゃいけない。それこそ時間の無駄ってやつだ。

なぜ置換グループを避けるべきか

TBD.

なぜカメレオンスキーマを避けるべきか

XML Schema は targetNamespace 属性なしの schema 要素を許している。そしてそんなスキーマを カメレオンスキーマと呼ぶ人たちがいる。
なぜカメレオンスキーマが不適切か… いや、知らなくちゃいけないのは それを避けるべきということだ。

一つの理由は、ここでバリデータ間の相互運用性の問題がでてくる可能性が大きいからだ。

もう一つの理由はカメレオンスキーマを使ったクールな裏技を発明する人がいるからだ。だけどそんな裏技に手をだしちゃいけない。それはスキーマハッカーのやることだ。善良なる市民がやることじゃない。

それでもなお、カメレオンスキーマをなぜ避けるべきなのか正確な理由を知りたいなら、それが何かを学ぶ必要がある。

こんなカメレオンスキーマを考えてみよう。


<xs:schema xmlns:xs="http://www.w3.org/2001/XMSchema">
  <!-- note that targetNamespace attribute is absent. -->
  
  <xs:element name="person">
    <xs:complexType>
      <xs:sequence>
        <xs:element ref="familyName" />
        <xs:element ref="lastName" />
      </xs:sequence>
    </xs:complexType>
  </xs:element>
  <xs:element name="familyName" type="xs:string"/>
  <xs:element name="lastName" type="xs:string"/>
</xs:schema>

ここで他のスキーマファイルを書いて上のスキーマを include 要素を使ってインクルードするとしよう。


<xs:schema xmlns:xs="http://www.w3.org/2001/XMSchema"
           targetNamespace="http://best.practice.com">
  
  <xs:include schemaLocation="above.xsd" />
  
  <xs:element name="root">
    <xs:complexType>
      <xs:sequence>
        <xs:element ref="person" maxOccurs="unbounded" />
      </xs:sequence>
    </xs:complexType>
  </xs:element>
</xs:schema>

これでオッケーのようだが、実はこれではダメだ。赤で書かれた行を見てほしい。これは familyName 要素を参照しているように見える。しかしこれは間違いだ。
このカメレオンスキーマは targetNamespace="http://best.practice.com/" のスキーマからインクルードされているので、familyName 要素はこの名前空間の要素になっているんだ。だからこの要素宣言を参照するには、赤い行をこんなふうに書き換えなくちゃいけない。


<xs:element ref="bp:familyName" xmlns:bp="http://best.practice.com" />

ここで対象名前空間がhttp://www.foo.comのスキーマからこのカメレオンスキーマを再利用したかったらどうしたらいいだろう? 答えは「それは不可能」だ。

これでカメレオンスキーマの唯一のメリットが失われたのがわかっただろう。

さらに困るのは、このエラーを検出しないバリデータがあるということだ。そのようなバリデータは見つからない部品が後から出てくるかもしれないと考えるからだ。