「共通」スキーマのコレクションから 1 つ以上の要素を継承するスキーマがいくつかあります。この特定の例では、これらのスキーマの 1 つをインポートして、その中で定義された単一の複合型を利用しています。
スキーマから Java オブジェクトを生成すると、スキーマ タイプと参照した要素が期待どおりに取得されますが、共通スキーマから30 以上の他のタイプに対して生成されたオブジェクトも取得されます。
共通スキーマが変更されたときにスキーマを更新するために自動ビルドに依存したいので、共通スキーマを使用したいのですが、余分な Java クラスを生成したくありません。
提案？
あなたが望むものを達成するためのすぐに使えるアプローチはありません。私がここで意見を述べている理由は、どちらのルートをたどっても考慮に入れる必要があるいくつかの問題を (おそらく他の人のために) 指摘するためです。
「余分な」ラベルは必ずしも簡単ではありません。代替グループのメンバーは興味深いです。Java では、インターフェイス (I) を使用するクラス (A) と (I) を実装するクラス (B:I) について考えます。A と B の間に依存関係はないと言う人もいれば、ディストリビューションで B を必要とする人もいます。(I) を具体的なクラスに置き換えると、状況はさらに明確ではなくなります。置換グループのヘッドは抽象的である必要はないと考えてください。または、置換グループ ヘッドのタイプが anyType (Java のオブジェクト) の場合。
さらに言えば、XML 処理がxsi:typeに対応するように設計されている場合、 (スキーマを見て) 何がどこで機能すると予想されるかを判断することはさらに難しくなります。
QTAssistant (私はそれに関連付けられています)などのツールには、すべての厳密な依存関係 (上記の A および I) を取り込むデフォルト設定があります。そして、機能する可能性のあるすべて（上記のB）か、それ以外は何もありません。その中間の場合、ユーザーはリリースに含まれるものを手動で定義する必要があります。これは自動 XSD リファクタリングと呼ばれ、シナリオで簡単に使用できます。