Mimo が指摘したように、customertype (または別の他の要素) を XSD 名前空間の要素を含むものとして定義しても問題はありません。これは、あなたが尋ねているようです。
しかし、顧客要素 (または例のスキーマが宣言する職業要素) を検証できるようにすることが目標である場合、それが最善の方法 (または実行可能な方法) である検証アーキテクチャを想像するのは困難です。それについて。理由の 1 つは、検証対象のインスタンスによって提供されるスキーマ情報に対してドキュメント インスタンスを検証しても、既知のスキーマに対して検証する場合と同じように、データのクリーン度に対する信頼が得られないことです。(あなたの検証を覆し、偽のデータを有効なものとして受け入れるようにシステムを説得しようとする敵対者の立場になってみてください。敵対者が有効なドキュメント インスタンスとしてカウントされるものを指定できるようになった場合、ドキュメントが有効であることを知ることはどれほど有用でしょうか。 ?)
スキーマを書き、それを通常の方法で使用することを妨げているのは何ですか?
[追加、2012 年 10 月 15 日、OP のコメントの後]
今日のあなたのコメントを正しく理解していれば、あなたの要件は、あなた以外の人が customer好きなように要素のタイプを指定できるようにすることです。ただし、そのタイプには Source という名前の子要素が含まれている必要があります。するxsd:int。彼らが使用している型定義へのアクセスが必要かどうかは指定しないので、必要な場合と必要でない場合の両方を考慮してみます。
この状況を機能させる 3 つの方法を以下に説明します。あるという共通点があります。
- スキーマの基本バージョンを定義する「メイン」スキーマ ドキュメント、および
- さまざまな状況で使用するための 1 つ以上の「補助」スキーマ ドキュメント。
一般に、XSD に関する優れた教科書を見つけて、いくつかのスキーマ ドキュメントの宣言からスキーマを作成する方法について説明されていることを確認すると役立つ場合があります。
(1) 1 つのアプローチは を使用しxsi:typeます。customer要素が名前付きの型を持つメイン スキーマ ドキュメントを定義します。タイプの名前はCustomer. このCustomer型は、最初の子要素が という名前の任意の要素を受け入れますSource。例えば：
<xs:element name="customer" type="Customer"/>
<xs:complexType name="Customer">
<xs:sequence>
<xs:element name="Source" type="xs:int"/>
<xs:any minOccurs="0"
maxOccurs="unbounded"
processContents="lax"/>
</xs:sequence>
<xs:anyAttribute processContents="lax"/>
</xs:complexType>
要素のより具体的なタイプが必要customerな人 (私はそれらを「ユーザー」と呼びます) は、ターゲット名前空間に補助スキーマ ドキュメントを提供し、その中で を制限する他の複雑なタイプを宣言しますCustomer。たとえば、customer要素に名前、住所、電話番号という要素を 含めたい場合があります。
<xs:complexType name="Customer-for-us">
<xs:complexContent>
<xs:restriction base="Customer">
<xs:sequence>
<xs:element name="Source" type="xs:int"/>
<xs:element ref="name"/>
<xs:element ref="address"/>
<xs:element ref="phone"/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
これは Customer 型の法的な制限であるため、customer要素はそれを使用できます。したがって、ドキュメント インスタンスには次のような要素が含まれる場合があります。
<customer xsi:type="Customer-for-us">
<Source>83760273</Source>
<name>Willy Wonka</name>
<address> ... </address>
<phone> ... </phone>
</customer>
ドキュメントは、メイン スキーマ ドキュメントとともに、補助スキーマ ドキュメントから構築されたスキーマに対して検証されるため、型の定義はCustomer-for-us通常の方法で適用されます。
最初の子の名前が Source で型が int である限り、Customer 型はワイルドカードと緩い検証を使用することにより、ユーザーが自分のバージョンの型で好きなことを実行できることを保証します。
(2) 2 番目のアプローチでは、メイン スキーマ ドキュメントの穴を使用します。
customertype を持つ要素の宣言を含め、以前と同じようにメイン スキーマ ドキュメントを記述しますCustomer。しかし、メイン スキーマ ドキュメントには、その型の宣言が含まれていません。代わりに、通常の方法で検証時にメインのスキーマ ドキュメントと結合される補助スキーマ ドキュメントで Customer 型を宣言します (ドライバーとして機能し、他の 2 つを含む 3 番目のスキーマ ドキュメントを用意することをお勧めしますが、機能させる方法はたくさんあります）。
一方、より具体的な Customer 型が必要なユーザーは、Source という名前の最初の子に関する互換性制約などに従って、Customer 型の独自の宣言を記述します。ユーザーは独自のドライバー ファイルを使用します。このドライバー ファイルには、メイン スキーマ ドキュメントと独自のバージョンの補助スキーマ ドキュメントが埋め込まれており、Customer 型の独自の宣言が含まれています。
この方法では、xsi:type属性を使用する必要はありません。
(3) 3 番目のアプローチでは、xs:redefineor (XSD 1.1 では)xs:override機能を使用します。
解決策 (1) で説明されているように、メイン スキーマ ドキュメントを記述します。ユーザーはxs:redefineorxs:overrideを使用して、必要に応じて Customer を再定義します。この回答はすでにかなり長いので、再定義またはオーバーライドの使用に関するチュートリアルを含めることは提案しません。