4

フラットな XSD を使用しているため、XML でデータを保存する代わりに、データが非常に巨大になる可能性があるため、CSV 形式で保存することを考えています。XSD から CSV の各レコードの Element Type を知っていると仮定すると、Java ベースの XML Validator を使用して XSD に対して CSV の各レコードを検証する方法はありますか?

4

3 に答える 3

3

Saxon XSD バリデーターは SAX フィルターとして機能するため、入力の XML ビューを表す SAX イベントを送信することで検証を行うことができます。したがって、必要なのは、CSV ファイルを読み取り、そのコンテンツを表す SAX イベントを発行する Java プログラムだけです。SA​​X イベントは XSD バリデーターにパイプされます。

于 2013-01-09T08:50:49.163 に答える
1

「フラットな XSD」と「各レコードの要素タイプ」とはどういう意味ですか? 明らかに、XML 入力を期待するバリデーターに非 XML 形式を供給する際に、なんらかの変換または適応プロセスが関与します。したがって、関連するすべての名前が使用可能である必要があります。

特に、追加の列 (通常は行の先頭) がない限り、行全体に対応する要素の名前をエンコードする余地はありません。これは、最初の行の他の列の名前が子要素 (上位) であるか属性 (下位) であるかに関係ありません。

次に、この名前がアダプターで使用可能であると仮定すると、「フラット XSD」はどのように見えるでしょうか? この要素がスキーマのルートまたは最上位要素である場合 (つまり、スキーマが 1 つの行のみを記述している場合)、一連の行のコンテナーとして機能する新しい最上位要素でスキーマを拡張する必要があります。あなたのCSVファイルは何ですか。つまり、各行を個別の XML ドキュメントとして検証するのではなく、CSV ファイル全体を変換または適合させて、単一の XML ドキュメントとして検証する必要があります。

バリデーターがパイプ入力を受け取ることができる場合は、便利なスクリプト言語で記述された CSV から XML へのコンバーターがあれば十分です。

于 2013-01-10T19:33:47.793 に答える
1

それを行う1つの方法は、次のことを行うことです。

  • JAXB コンパイラを使用して、XSD から Java クラスを作成する
  • Flatwormに似た製品を使用して、レコード (またはファイル全体) を上記で作成した Java クラスに自動的/宣言的に解析するか、単に手動で解析します。
  • ここ SOに投稿されているようなアプローチを使用して、グラフを検証します。適切にキャッシュするようにしてください。つまり、バリデーターと JAXBContext オブジェクトを再利用してください。

要求の性質を考えると、たとえ JAXBSource であっても、XML へのマーシャリングによって発生するオーバーヘッドは避けられません。あなたができることはそれを最大限に活用することです... CPU帯域幅が問題にならない場合は、スループットを向上させるために並列化を試みることができます（スレッドごとに1つのバリデーターが必要になります.JAXBContentは前回使用したときにスレッドセーフでした. ）。そして、すべてのレコードの XSD (レコードに一致する要素が maxOccurs="unbounded" のパーティクルになるように) がより効率的な検証方法であると考えている場合は、ファイル全体をロードすることは避けます...大きなファイルの場合、おそらくメモリ不足になります...

大量のデータの場合、XSD の使用は洗練されていると言えますが、それほど効率的ではありません。.NET ソリューションを探しているときにこの投稿に出くわした人にとっては、代わりにXmlSchemaDatatype.ParseValueへの呼び出しを行うことで、個々のフィールドを検証する方がはるかに効率的です (XSD にフィールド間の制約などがないことを前提としています) 。

于 2013-01-08T19:54:21.643 に答える