alt xsd:any：教訓話

こんな連載があったとは。

ここで書かれている以外にも、パーティクルxsd:anyには面倒な問題がある。というのも、xsd:anyはUnique Particle Attribution違反を簡単に引き起こすからだ。

Unique Particle Attributionという制約は、あるXML要素に対して、複数のパーティクル（xsd:elementなど）がマッチしてはならない、というもので、たとえば、<xsd:sequence><xsd:any minOccurs='0' /> <xsd:element ref="hoge" /></xsd:sequence>があるとき、要素hogeはxsd:anyにもxsd:elementにもマッチしてしまう。これはUnique Particle Attribution違反になる。minOccurs='0'が無ければ、この場合は問題ないが、xsd:sequenceではなくxsd:choiceならやはり許されない。

これが具体的にどんな現実を生み出すかというと…

たとえば、RELAX NGの要素のほとんどは、その内容モデルとして任意の位置にforeign elementを含むことが出来るが、XML Schemaではこんな定義はまず不可能だ。だからXML Schema（schema for schemas)の要素では、外部名前空間の内容を含めるために、xsd:annotationという要素が、それぞれの要素の内容の先頭でのみ定義できる。

追記: RELAX NGに妙に期待されないように書いておくと、RELAX NGのinterleaveでも、name classが重複するような内容モデルを定義することはできない。ただし、RELAX NGにはxsd:allのような制約が無い。

XML Schemaを使うのなら、その辺は腹を括らないといけない。*1

*1:いや、まあXML Schemaを使って結果的に無理が生じてしまったとしても、NVDLなどを使えば、逃げ道が作れるだろうけど。