@Michaelを言い換えると、No you can't do it.
仕様の読み取りに興味がある場合は、ここで説明されています。
なぜ誰かがそれをやりたがるのかについて、私がよく目にする例を挙げることができます。それがあなたのシナリオに当てはまるとは主張しませんが、理由を知りたい人には役立つはずです。
すべては、ほとんどの人がスキーマに期待することから始まります。必要なものを正確に検証することであり、それ以上ではありません。したがって、XML のスキーマが有効である場合、コード ビハインドで行われる検証はまったくまたはほとんど行われないと想定することになります。これがおそらく、人々が XSD でやりたいことを推進しているように見えるあらゆる種類の検証シナリオに対処する、ここ SO でさえ、非常に多くの質問を見ることができる理由です。
私がかなり頻繁に遭遇するのは、これらの精巧な型階層と置換グループを自分自身で構築したり (業界標準など) 参照したりする人々です。企業内の個々のシステムは、そのタイプの階層のサブセットのみをサポートします。
XSD がオープン コンテンツの特定のパターン(抽象要素または抽象型付き要素を介して) に従うように作成されている場合、これらの余分な型または要素を含むスキーマは、間違った型を参照するか、または置換グループのメンバーが間違っています。
説明のために、基本抽象型を考えてみましょうAddress
。具体的な住所: カナダ、米国、メキシコ、英国。たとえば、特定のビジネス サービスでは、カナダ/米国/メキシコの代わりに英国の住所を使用することは無効です。
あなたの場合、 typeがand/or にa
依存していないと仮定すると、それを行う唯一の方法は、A.xsdをA'とA''に分割し、B.xsdでA'を参照することです。これを自動的に行う方法があるため、メンテナンスの観点からのオーバーヘッドは非常に低くなります。自動 XML スキーマ リファクタリング (XSR) を介して行うと、A.xsdの将来のリリース(あなたのものではないものだと思います) は、ソリューションの残りの部分と簡単に統合できます。b
c
a