2

「first.xsd」と「second.xsd」の 2 つの xsd ファイルがあります。

second.xsd 内で、first.xsd で定義された要素 (別の名前空間) を参照したい。
私の second.xsd は次のようになります。

<xs:schema ... xmlns:schema1="http://www.schema.org/schema1" targetNamespace "http://www.schema.org/schema2   ...  >
<xs:import namespace = "http://www.schema.org/schema1" schemaLocation = "first.xsd" />

<xs:element name = "complex1">
<xs:complexType>
.........
<xs:element ref="schema1:name2"/>
.........
</xs:complexType>
</xs:element>

ここで、first.xsd 内に second.xsd をインクルードしてインポートしたいので、first.xsd で次のようにします。

<xs:schema ... xmlns:schema2="http://www.schema.org/schema2" targetNamespace "http://www.schema.org/schema1  ... >
<xs:import namespace="http://www.schema.org/schema2" schemaLocation="second.xsd">
<xs:element name = "name1"/>
<xs:element name = "name2"/>
<xs:element name = "name3"/>

スキーマを正常に検証できないため、これは正しい方法ですか。
いくつかの循環的な名前空間の包含が原因で問題ですか??
私は酸素 xml 開発者を使用してスキーマ ファイルを検証していますが、検証時の first.xsd は次のように述べています。
E[Xerces] src-resolve: Cannot resolve the name to a(n) type definition component. (秒.xsd)

しかし、second.xsd ファイルを個別に検証すると、スキーマが有効であると表示されます。

私の実際のケースでは、非常に複雑なシナリオがあるため、上記のように簡単な例にまとめました。
誰か助けてください。

4

1 に答える 1

3

この種の循環依存関係を持つことは完全に有効です (議論の余地はありますが)。スキーマ セットが検証されない理由はそれではありません。スキーマ プロセッサが生成するエラーを調べて、それぞれを理解しようとする必要があります。一般に、最初のエラー メッセージから始めるのが最善であると考えられています。

schema1element2にリストしなかった (second.xsd 内の) を参照しているため、スニペットは無効です。これは検証に合格しない種類のものなので、それらに注目してください。

実際の問題が何であるかを理解するのに助けが必要な場合は、実際のエラー メッセージで投稿を更新することから始めてください。

于 2012-05-25T16:52:29.140 に答える