validation - ある XSD スキーマが別の XSD スキーマのサブセットであることを確認するにはどうすればよいですか?

Question

ある XSD スキーマが別の XSD スキーマのサブセットであることを確認するにはどうすればよいですか?

「ブループリント」XSD ​​スキーマのコレクション (サブコンポーネントで使用可能なすべての入力または出力を定義する) を使用して、System-of-Systems アプリケーションを作成しています。多くのサブコンポーネントが実装されており、これらのサブコンポーネントは XML ファイルを使用して相互にデータを渡します。各サブコンポーネントは、関連するブループリント XSD スキーマのサブセットを作成します (可能な入力または出力のどれを実装するために選択したかを示すため)。サブセット XSD スキーマに対して検証する XML データファイルは、ブループリント XSD スキーマに対しても検証する必要がありますが、その逆は当てはまりません (サブセット XSD スキーマには、ブループリント XSD スキーマからのすべての「オプション」または「選択」XML 要素が含まれていない可能性があるため、また、既存の XML タグで許可されているデータ値をさらに制限することもできます)。

テスト中に、各サブコンポーネントのサブセット XSD スキーマが、関連付けられたブループリント XSD スキーマのサブセットであることを確認する予定ですが、この検証を実行する自動化された手段はありません。これらの XSD スキーマは、このテストを手作業で行うにはかなり大きくて醜いです。Java が XSD スキーマに対して XML ファイルの検証を実行する方法と同様に、一種の「XSD ファイル 1 に対して XSD ファイル 2 を検証する」コマンドがあると便利です。各サブコンポーネントのサブセット XSD スキーマが、ブループリント XSD スキーマに違反するような XML 入力/出力の組み合わせを許可しないことを確認したいと思います。このスキーマ間機能により、

役立つ情報: このアプリケーションは、OSGi バンドルとして実装され、Maven 2.2.1 を使用してコンパイル/実行される Java 6 アプリケーションのコレクションです。特定の開発 IDE を使用するための要件はありません。システムは Microsoft Windows XP 環境でテストされていますが、このシステムを他の環境でも実行する計画があります (したがって、クロスプラットフォーム ソリューションが推奨されます)。

Answer 1

必要な関係を確保する最も簡単な方法は、ブループリント スキーマの型から制限によってサブセット スキーマの型を導出することです。しかし、その船はすでに出航しているように聞こえます。

ここにいる他の人たちと同じように、私はこれをすぐに実行できるツールを知りません (ただし、Petru Gardea が QT Assistant でできると言った場合は、フォローアップする価値があります)。

複雑なことの 1 つは、検証したいサブセット/スーパーセットの関係を表示する方法が 2 つあることです。 (2) スキーマ 1 と 2 に対する検証 (仕様ではスキーマ検証後の情報セットと呼ばれるもの) によって生成された型付きドキュメントは、互いに適切な関係にあります: 要素または属性が有効である場合ツリー 1、ツリー 2 で有効です。ツリー 1 で割り当てられたタイプは、ツリー 2 で割り当てられたタイプの制限です。など。スキーマ 1 と 2 が個別に開発された場合、それらの型が派生によって関連付けられる可能性は低いため、質問に対する最初のアプローチを念頭に置いていると思います。

ただし、問題はどちらの形式でも間違いなく決定可能です。どのスキーマでも (この用語を慎重に使用しています)、定義により、有限数の型と有限数の要素名が宣言されます。したがって、要素名/型のペアは有限数 (場合によっては大きい) 存在することになります。

アルゴリズムは次のようになります。

1. 予想されるルート要素から始めます。(可能性のあるルート要素が複数ある場合は、一般的に、それらのそれぞれについてこのチェックを実行する必要があります。) 予想されるルート要素が E で、スキーマ 1 の型が T1 で、スキーマ 2 の型が T2 である場合、タスク「タイプ T1 と T2 の比較」をオープン タスクのキューに配置します。すでに完了したタスクのリストは空になります。

2. 2 つの複合型 T1 と T2 を比較するには、次のようにします。

   • T1 および T2 に対して宣言された一連の属性をチェックして、それらの名前の間のサブセット/スーパーセットの関係を確認してください。意図したスーパーセットに必要な属性が、意図したサブセットに存在しないか、オプションであることを確認してください。

   • T1 と T2 の両方に対して宣言された各属性 A には、タイプが割り当てられます (それらを ST1 および ST2 と呼びます)。ST1 = ST2 の場合、何もしません。それ以外の場合は、タスク「単純型 ST1 と ST2 を比較する」を、既に完了した比較のリストにない限り、開いているタスクのキューに追加します。

   • ここで、T1 と T2 で可能な子のシーケンスを確認します。13ren がコメントで示唆しているように、コンテンツ モデルは基本的に要素名のセットをアルファベットとして使用する正規表現であるため、これは扱いやすいです。したがって、それらが定義する言語は規則的であり、サブセット/スーパーセットの関係は規則的な言語に対して決定可能です。

   • 可能な各子要素 C には、親型 T1 および T2 によって要素宣言と型定義の両方が割り当てられます。それらを ED1、ED2、CT1、および CT2 と呼びましょう。同じ名前のすべての子は同じ型になりますが、異なる子は異なる要素宣言に一致する場合があります。したがって、可能な名前については、タイプ CT1 と CT2 のペアは 1 つだけですが、ED1 と ED2 のペアが複数存在する可能性があります (分析では、それらが正しく一致していることを確認するように注意する必要があります。自動化します）。

   • CT1 = CT2 の場合は何もしません。それ以外の場合は、比較が既に実行されていない限り、"Compare types CT1 and CT2" をオープン タスク キューに入れます。

   • ED1 と ED2 が構造的に同一である場合、何もしません。それ以外の場合は、それらを比較するタスクをタスク キューに入れます (既に実行されていない場合)。

3. 2 つの単純型 ST1 と ST2 を比較するには、それらの字句空間 (スキーマのサブセット/スーパーセット関係の最初の定義が必要な場合) または値空間 (2 番目が必要な場合) を比較します。ST1 と ST2 の両方が同じプリミティブ タイプの制限である場合、それらの有効なファセット ベースの制限のセットを簡単に比較できる場合があります。pattern ファセットは問題を複雑にする可能性がありますが、正規表現のセットを定義するため、サブセット/スーパーセットの関係は決定可能です。

4. 2 つの要素宣言を比較するには、要素宣言の各プロパティを比較し、必要なサブセット/スーパーセットの関係を確認する必要があります。

ご覧のように、この分析を本当に自動化したいほど複雑で退屈であり、すぐに使える機能として広く提供されていない理由も簡単にわかるほど複雑です。しかし、コーディングすることは確かに興味深いでしょう。

Answer 2

@13ren さん、「ビープ音」をありがとう :)

これは答えではなく、長いコメントです。13ren との以前のやり取りから始めます。more precise, it provides to a user all that is needed to define such an analysis model.つまり、QTAssistant (これ) には XSD 比較機能があるということです。XSD 対応であるため、テキストまたは XML 対応の diff ツールでは実行できない多くのことを既に実行しています (たとえば、XSD ファイルの数、バージョン間でのレイアウトの変更などは気にしません)。提供された UI については、差分エンジンは、PSVI モデルではなくソース モデルに対して機能します。代わりに PSVI を使用するようにカスタマイズできます。後者は実際に必要なものに 1 歩近づいているからです。また、「ベース」と「リビジョン」の間の比較を強化するカスタム ルール セットを持つ機能を含めることもできます。つまり、ユーザーが現在使用している「=」演算子をオーバーライドできるようにすることもできます。

xsd:pattern ファセットの比較をオーバーライドできるように、すぐに使用できるものは何もないことを認識しています。xsd:positiveIntegerまた、 vs .など、人間が認識しやすいものについても同様xsd:integer + xsd:minInclusive=1です。または をまたはと比較しxsd:allます。同じように、XSD 制約のセレクターとフィールドを解析しません。これは、正規表現と同様に、扱いが容易ではありません。xsd:choicexsd:sequence

「不一致」を完全に除外するのではなく、できるだけ多くの「不一致」を見つけることが目標であると仮定すると、QTAssistant にはさらに 3 つの便利な機能があります。

• 特定のルート要素について、単純な XPath の完全なリストを作成します。これは、「不正な」データをすばやく見つける方法として適用できます。そのままでは、この比較方法は構造パターンを考慮していません。つまり、XPath1 と XPath2 がインスタンス XML 内の 2 つの兄弟を表す場合、XPath1 は XPath2 より前になければならないなどです。
• Query XSD Analyzerが組み込まれています。SQL を使用して、セットの XSD メタモデルを照会して、比較ツールが (実現可能性のために) 無視するように設計されている可能性があるものを「特定」することができます。したがって、決定するには人間へのレポートが必要になります。
  • XSD リファクタリング (XSR)。これは、XSD のリファクタリングと分析を念頭に置いて一から構築された、業界で唯一の (少なくとも私が知っている) エンジンです。xsi:type と、理想的には置換グループの使用も除外できれば (これについてはまだ考えなければなりません)、「正規化変換」と呼ばれるものを利用できるようになると思います。代わりに PSVI モデルに依存して、スキーマ セットをロシア人形のデザイン スタイルに変換します。id 属性の使用、余分なシーケンスの縮小、単一オプション xsd:choices の置き換えなど、さまざまな可能性があります。これが、開発中ですが、まだ公開されていない理由です。

比較のために準備しなければならなかったもう 1 つのこと (および検討したい場合があります) は、XSD/XML だけでなく、XSD から生成された成果物 (JAXB を介した Java クラスなど) の同等性にも関係していました。さらに、拡張パターン、ワイルド カード (xsd:any および anyAttribute) を使用するもの。

私たち（QTAssistant）は現在、いくつかのより具体的な要件（代表的なXSD、私が推測するNDAなどの交換から始める必要があります）を通してあなたと協力して、実際にそれを実現できるかどうかを確認することに関心があります.仕事。続行したい場合は、私の SO プロファイルに関連付けられている Web サイトのサポート アドレスからお気軽にご連絡ください。

Answer 3

スキーマに対して XML を検証するツールは、これを行う方法を既に知っています<xs:complexContent><xs:restriction>。

この機能を活用したい場合は、ブループリント スキーマの型を制限する複合型を子スキーマで定義できます。

ただし、これを考慮せずに子スキーマを作成した場合でも、以下のパターンに一致するように子スキーマを変更し、検証のためにスキーマ プロセッサを介して送信することで、これを達成できる可能性があります。

ブループリント スキーマの例、blueprintschema.xsd:

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:element name="root" type="rootType"/>
  <xs:complexType name="rootType">
    <xs:sequence>
      <xs:element name="child1" minOccurs="0"/>
      <xs:element name="child2" minOccurs="0"/>
      <xs:element name="child3" minOccurs="0"/>
    </xs:sequence>
  </xs:complexType>
</xs:schema>

ブループリント スキーマのサブセットである子スキーマの例:

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:element name="root" type="rootType"/>
  <xs:complexType name="rootType">
    <xs:sequence>
      <xs:element name="child2"/>
    </xs:sequence>
  </xs:complexType>
</xs:schema>

再定義構造への変換後の子スキーマの例:

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:redefine schemaLocation="blueprintschema.xsd">
    <xs:complexType name="rootType">
      <xs:complexContent>
        <xs:restriction base="rootType">
          <xs:sequence>
            <xs:element name="child2"/>
          </xs:sequence>
        </xs:restriction>
      </xs:complexContent>
    </xs:complexType>
  </xs:redefine>
  <xs:element name="root" type="rootType"/>
</xs:schema>

スキーマ プロセッサは、再定義された「rootType」が実際に元のブループリント「rootType」のサブセットであるかどうかを通知します。

スキーマは単なる XML であるため、通常の XML 処理ツールを使用して変換を行うことができます。

Answer 4

現在、別のスキーマに対してスキーマを検証/チェックする利用可能なソリューションがないため、回避策を使用する必要があるようです。以下は私の試みです。

問題を言い換える:

サブセット スキーマで定義されているすべてのデータ型が存在し、「ブループリント」スキーマで定義されているものの (より厳密ではない) 境界内にあるかどうかを識別します。

考えられる解決策:

1. 最初の (明らかな) 情報は、Schema を使用すると XML インスタンスを作成できるということです (これはどういう意味ですか?! 2. を参照)。
2. もう 1 つの (あまり明白ではない) 情報は、XML スキーマ自体が「サブセット インスタンス」になる可能性があるということです。つまり、XML インスタンスからスキーマをリバース エンジニアリングすると、サブセット スキーマが得られるということです。 (このステートメントは、「リスト」または選択要素またはその他の「制限」がない場合、常に正しいとは限りません。その場合、リバース エンジニアリングされたサブセット スキーマは「青写真」スキーマに正確にマップされます)。

したがって、この知識を使用して、ソリューションを構築できます。

サブセット スキーマの可能なすべての XML インスタンスを作成し (この手順をプログラムで実行するのは困難な場合があります)、これらの XML インスタンスを「ブループリント」スキーマに対して検証します。

しかし、サブセット スキーマが"青写真" スキーマのサブセットであることはどのようにわかるのでしょうか? サブセット スキーマの可能なすべての XML インスタンスを作成したので、サブセット スキーマに存在するすべてのデータ型をカバーしました。これらの XML インスタンスを「青写真」スキーマに対して検証することは、本質的に、データ型が存在するかどうか、すべてが「青写真」スキーマで定義されている範囲内にあるかどうかを確認することです。したがって、サブセット スキーマが実際に「ブループリント」スキーマのサブセットであることを識別します。

理想的な解決策ではないことは承知していますが、あなたが求めていることを実行するための簡単な方法がないことを考えると、これが役立つことを願っています.