XSDファイルの依存関係を調べる方法

Question

特定のXSDファイルを解析するために必要なすべてのXSDファイルを保存したいと思います。 This answerは、xs:includeとxs:importの属性を検索する必要があると言います。

しかし、要素の内部で使用される名前空間はどうですか？多くの場合、ルート要素（スキーマ宣言）には複数の名前空間宣言があります。 XSDファイルにそれらのファイルがある場合、これらの名前空間にもXSDを含めるべきですか？

たとえば、このXSDファイルでは、urn:oma:xml:xdm:extensionsとurn:ietf:params:xml:ns:resource-listsとhttp://www.w3.org/2001/XMLSchemaの名前空間を定義するXSDを含める必要はありませんか？

<?xml version="1.0" encoding="UTF-8"?> 
<xs:schema 
    targetNamespace="urn:3gpp:ns:mcpttGroupInfo:1.0" 
    xmlns:mcpttgi="urn:3gpp:ns:mcpttGroupInfo:1.0" 
    xmlns:xs="http://www.w3.org/2001/XMLSchema" 
    xmlns:oxe="urn:oma:xml:xdm:extensions" 
    xmlns:rl="urn:ietf:params:xml:ns:resource-lists" 
    elementFormDefault="qualified" attributeFormDefault="unqualified"> 

    <xs:import namespace="urn:oma:xml:xdm:extensions"/> 
    <xs:import namespace="urn:ietf:params:xml:ns:resource-lists"/> 

    <!-- XSD element and type definitions --> 

</xs:schema> 

Answer 1

これらをXSDファイルに遭遇した場合、これらの名前空間にもXSDを含めるべきですか？

XSDスキーマ文書に、私たちは、名前空間Nのための名前空間宣言が発生した場合は、次のいずれかがケースになります。

1. それは、XSD名前空間だとプレフィックスが内の要素に使用宣言スキーマ
2. これは現在のスキーマ文書のターゲット名前空間であり、宣言された接頭辞はターゲット名前空間の型、要素、属性などへの参照に使用されます。
3. これは対象の名前空間ではなく、要素、型、属性などの参照に使用されます。
4. 要素、型、属性などの参照（スキーマ宣言）では使用されていませんが、 （例えば、xsd：annotation要素の内部、またはXSD要素の外部名前空間属性として）スキーマ文書自体で使用されるいくつかの要素または属性の名前空間。
5. これはスキーマ文書ではまったく使用されていません。

現在のスキーマ文書で定義されている要素、属性、およびタイプを検証するのに十分なスキーマ文書の集合を収集しようとしている場合（あるいは、間接的、明示的または暗示的に、現在のスキーマドキュメントから）、そして：

1. ケース1は無関係です：XSD名前空間のスキーマは、すべての準拠XSDバリデータに組み込まれているし、収集する必要はありません。
2. ケース2では、現在読んでいるスキーマ文書を収集する必要があります。 （おそらく私たちはすでにそれを知っていたのでしょうか、それとも最初にそれを読んでいたのですか？）
3. ケース3の場合、ネームスペースのxsd：importがあります。この場合、処理するときに注意が必要ですxsd：import要素でなければ、そのようなインポートはありません。その場合、現在のスキーマ文書は不適合であり、適合するスキーマプロセッサがそこからスキーマを構築しようとするとエラーが発生します。
4. ケース4の場合、現在のスキーマ文書（たとえば、xsd：documentation要素に含まれるHTMLパッセージ）でネームスペースが使用されます。現在のスキーマ文書の関連する要素または属性を検証する場合は、その名前空間のスキーマ文書が必要です。しかし、問題の名前空間が、このスキーマに対して検証される文書で使用される可能性がある、または使用されることはありません。これらのドキュメントで使用できる唯一の有用な指標は、xsd：import要素です。
5. ケース5の場合、名前空間宣言はcruftであり、識別可能な目的を果たさない。 （この名前空間は組織のスキーマ文書で頻繁に使用されるため、組織内で使用されるスキーマ文書テンプレートの一部である可能性があります - スキーマ文書は通常XHTML名前空間のプレフィックスを宣言しますが、この特定のスキーマ文書何らかの理由で）この名前空間のスキーマ文書は収集する必要がありません。

与えられたサンプルドキュメントには、4つの名前空間宣言があります。ケース2内に

xmlns:xs="http://www.w3.org/2001/XMLSchema" 

一つが低下する：一つは、ケース1に該当するケース3に

が

xmlns:mcpttgi="urn:3gpp:ns:mcpttGroupInfo:1.0" 

つ落下（あるいはケース5）、及びこれらのためにもXSDがある：インポート手順：

xmlns:oxe="urn:oma:xml:xdm:extensions" 
xmlns:rl="urn:ietf:params:xml:ns:resource-lists" 

私たちが代わりにXSDの名前空間宣言によって、当社の収集ポリシーを運転した場合：インポートおよびxsd：命令を含むが、ここでの違いは、我々は（a）は、当社のコレクションにXSDスキーマ文書のスキーマを追加することだろうが、と（b）おそらく、現在のスキーマ文書のターゲット名前空間に対する他の利用可能なスキーマ文書を検索する。 （場合によっては望ましいかもしれません;他のものでは、同じ名前空間に対して異なるスキーマを持ち、それらのすべてを収集することは、冗長でおそらく自己相反する宣言のセットを生成するため、逆効果になります）。

Answer 2

http://www.w3.org/2001/XMLSchema 

（それは必要ではないが）自動的に理解さ慣例によってれるスキーマ要素を定義するための特別な名前空間である「XS」エイリアスを使用します。

あなたのライン

xmlns:xs="http://www.w3.org/2001/XMLSchema" 

は、単にスキーマ要素のデフォルトの名前空間のエイリアスを定義します。

urn:oma:xml:xdm:extensionsとurn:ietf:params:xml:ns:resource-listsのスキーマを含めるには、schemaLocation属性を指定する必要があります。

<xs:import namespace="urn:oma:xml:xdm:extensions" 
      schemaLocation="http://yourSchemaLocation/yourSchema.xsd"/> 

N.B. schemaLocationは相対的なものにすることができます。これはおそらく私の経験では自分のスキーマにとってより適切で確かに便利です。だからおそらく

<xs:import namespace="urn:oma:xml:xdm:extensions" 
      schemaLocation="./yourSupportingSchemaLocation/yourSchema.xsd"/> 

が良い例です。

Answer 3

すべてXMLスキーマを定義する場合、インクルードタグには位置属性が必要です。それ以外の場合、スキーマは有効ではありません。 インポートとインクルードステートメントで使用されるXSDファイルが存在しない可能性がありますが、バリデーションをトリガーする可能性があります.XSDスキーマで使用するため、 を依存関係として扱う必要があります。

XSDスキーマもインスタンス・ドキュメントであるため、スキーマ・ドキュメントへの依存性もあります。しかし、この特定のケースでは、XML Validatorにハードコードされている "http://www.w3.org/2001/XMLSchema"（XML Schema Namespace）名前空間にあります。したがって、それを提供する必要はありません。

カスタムスキーマから作成された「他の」インスタンスドキュメント（これは私の質問の一部ではなく、完全性のためのものではありません）では、スキーマの場所は明示的に定義できますが必須ではありません。定義されていない場合は、XMLバリデータにスキーマをプログラムで使用するように指示することができます。また、最終的に選択されるファイルは実装によって異なります。

しかし、インスタンス・ドキュメントを検証するには、まずは名前空間宣言があるかどうかを確認するスキーマが必要です。 このスキーマにいくつかのインクルードとインポートがある場合、これらのファイルも使用可能でなければならず、location属性で指定された場所に配置する必要があります。