問題タブ [schematron]

スキーマの検証だけでなく、XML ファイルのチェックを行う方法を探しています。興味深い Schematron への参照をいくつか見つけましたが、これをすべて組み合わせる方法を理解するのに苦労しています。

問題の背景

私たちは、大量の XML ファイルを生成するだけの Oracle OSB を扱っています。また、統合テスト用の Soap-UI テスト スイートも作成しています。

コード レビューを実行する際のガイドとなる、コーディング標準と開発ガイドラインの正式化を開始したところです。ただし、これらのチェックの多くは、自動化できると感じています。checkstyle が Java コードでチェックを行う方法とよく似ています。

たとえば、Soap-UI テストでは、すべての SOAP リクエストにスキーマ コンプライアンスと SOAP レスポンスのアサーションがあることを確認したいと考えています。この「チェック」は、非常に単純な xpath として記述できます。

OSB で生成された XML で同様のチェックを行います。たとえば、変数がキャメルケースの命名法に準拠していること、リソース パスがプロジェクト外のファイルを参照していないこと、トップ レベルのエラー処理が存在することなどです。

理想的なソリューション

ビルドは Maven で実行されており、soap-ui テストは確実にフォーマットされたレポートを吐き出しています。私たちは CI サーバーとして jenkins を使用しています。jenkins はこれらの確実なレポートを取得できるため、テスト結果を簡単に表示し、ビルドが失敗する理由を確認できます。

これらのチェックを実行できるものを見つけて、それらをジェンキンできれいに報告したいと考えています。

私がこれまでに把握できる最高のもの：

• スキーマトロン チェックを実行する Ant タスクを Maven に実行させる
• スキーマトロン出力を確実な出力に変換する方法を見つける
• jenkins maven-runner を変更して、生成された確実なレポートを取得します

しかし、ここのうさぎの穴に行き詰まっているように感じます。これが正しい方法である場合、他の誰かがすでにこれに対処していると思いますが、schematron を CI ツールまたは maven と統合するのに役立つものを見つけるのに苦労しています。

スキーマトロンは調査する価値がありますか?

既存のセットアップとより密接に統合され、より適した他のツールはありますか?

Schematron 内で xPath を使用しています。タイプがターゲットタイプと等しいことを確認できます。たとえば、「xsd:string eq xsd:string」。

ユーザーが定義した型が xsd:string から派生したものかどうかを確認するにはどうすればよいですか? 私はもう試した：

しかし、うまくいきません。

XMLファイルを自分が持っているschematronファイルに対して検証したいと思います。Visual Studio 2010を介してそれを行うことは可能ですか？

Visual StudioでXMLファイルを開くと、スキーマが定義されているXSDファイルを追加できますが、別のschファイルにあるschematronルールに対して検証したいと思います。

スキーマトロンを使用して、テスト ドキュメントで指定されたファイルが実際に存在することを検証したいと考えています。ドキュメントとファイルは常に同じディレクトリに存在します。例えば：

検証中のドキュメントと同じディレクトリ内に「bar.png」という名前のファイルが存在する場合は、パスする必要があります。

これまでの私の調査では、これは不可能かもしれないと確信しています。

XSLT 2.0 で oXygen XML を使用していますが、Saxon EE 9.3 を使用しています。

schematron を使用してインスタンス ドキュメントを検証しようとしていますが、Java XSLT プロセッサの実装に問題があります。スキーマトロンから XSL を生成しようとすると、単純なものであっても、予想とは異なる結果が得られます。

xsltproc (cygwin) を使用して変換を行う場合、すべて問題ありません。しかし、Saxon-B 9.1.0.8、デフォルトの Java 1.6 実装、または Saxon-PE 9.3.0.5 での Oxygen IDE の XSLT デバッガーを使用すると、無効な XSL ファイルが生成されます。原因は、名前空間がどこにも宣言されていないプレフィックスを含む要素のextension-element-prefixes属性です。このようなスタイルシートは、使用すると必ず失敗します。xsl:stylesheetexsl

スキーマトロンは実行時にアプリケーションで生成されるため、生成されたファイルを手動で編集することは問題外です。私は何か間違ったことをしなければなりませんよね？問題を に追跡しましたiso_schematron_skeleton_for_saxon.xsl(またはiso_schematron_skeleton_for_xslt1.xsl、使用されている実装によっては、はい、両方を試してみましたが、最終結果は同じでした)。スケルトンは名前空間が欠落している適切なスタイルシートを明確に作成しますが、後でどういうわけか魔法のように削除されます。私は XSLT の専門家ではないので、ここで何が間違っているのかわかりません。私がどこかで見逃したばかげたものだと確信しています。以下の入力の出力が異なる理由を知りたいです。

これは、いくつかの名前空間を定義するだけのサンプル スキーマトロンです (これが有効なスキーマと見なされることを願っています)。

Java XSLT プロセッサから取得したスニペットを次に示します (これは Oxygen からのものです。xslt1 または xslt2 の iso が使用されているかどうかは関係ありません。問題は解決しません)。

xsltproc が生成するものと、Java にも生成してほしいものは次のとおりです。

ご覧のとおり、Java 出力には、対応するプレフィックスの exsl 名前空間がありません。名前空間を処理することになっている iso スケルトンの部分に実験的なフラグが立てられていることに気付きました.必要に応じて、これを機能させるために汚いハックを適用するつもりです (schematron を詳細に学習していないために恥ずかしいことを尋ねている場合を除きます)。 ）。何か案は？

編集: Martin が以下のコメントで提案したように、純粋な XSLT 1.0 プロセッサを使用してみました。xalan (コンパイル済みバージョンと解釈バージョンの両方) と saxon 6.5.5 を使用しました。どちらの xalans も exsl 名前空間を追加しません。Saxon は、「属性が追加された後に名前空間を追加できません」などのエラーでスキーマトロンの処理に失敗することさえあります (xslt1 の iso スケルトンの 1534 行目)。queryBinding="exslt" でスキーマトロンを変換できる唯一のプロセッサは xsltproc のままです。また、私が試した唯一の非 Java プロセッサでもあります。問題のある XSL を少し読んだ後、変換が saxon9 でテストされているという主張が行われているコメントに気付きました。したがって、これは機能する必要があります。

PS: 長い投稿で申し訳ありませんが、この例を示すことが重要だと思います。

Schematron を使用して、すべての「signedWhen」xml 属性にタイム ゾーン情報が含まれていないことを検証するにはどうすればよいですか? XPath 1.0 を使用する .NET 実装を使用しています。

与えられたソース XML:

XSD ファイルでこの Schematron ルールを使用すると、次のようになります。

これらの不正確な結果を与える

タイムゾーン情報がないため、結果は返されません。

編集1：

私はそれを考え出した。私のテストでは、XPath 1.0 関数の "substring" を正しく使用していませんでした。

EDIT 2: W3schools の xs:date と xs:dateTime の定義では、オプションで負の符号の年の可能性について言及していませんでした。したがって、上記のコードは機能しません。以下で選択した回答を参照してください。

編集 3: 私が使用しているスキーマ (xmlns:xs="http://www.w3.org/2001/XMLSchema" ) は、負の署名された年を受け入れず、無効であると宣言します。しかし、安全のために、これからはこのコードを使用します。

XPath 1.0 を使用して Schematron アサート テストを再利用するにはどうすればよいですか? 具体的には、見つかった属性名を使用してテストを再利用するにはどうすればよいですか。これができない場合は、テストを再利用して、名前付き属性ごとに 1 つのテストを行いたいと考えています。(変数を使用できるのは XPath 2.0 だけだと思いました)。XSD スキーマからわかるように、テストは同じですが、異なる属性名を使用しています。注: timezone のテストは簡単ではないことはわかっています。これは単なる例です。

与えられた XML:

与えられた XSD:

1 つのテストで Schematron と XPath 1.0 を使用して、XML 内の同じデータ型 (例: xs:dateTime) のすべての要素と属性を検証する方法は?

このために複数のテストを作成できることは知っていますが、すべての日付 (xs:dateTime) をテストして、どの要素または属性に問題があるかをユーザーに報告するにはどうすればよいでしょうか? 以下は、具体的に名前が付けられた属性「signedWhen」を持つすべての要素をテストする例です。ただし、属性名は常に同じとは限らず、xs:dateTime が要素である場合もあります...

XSD ファイルでの Schematron テスト:

非常に基本的な質問 - 私は xml ファイルを持っており、schematron ファイルに対して検証したいと考えています。Saxon コマンドラインを使用して行うにはどうすればよいですか?

コマンドラインリファレンスによると、schematron ファイルを指定するオプションはありません。

私は Schematron を使用して、カスタム スキーマ対応 XML エディター内でインスタンス XML ドキュメントを検証しています (Schematron 検証は単なる XSLT 変換であることに注意してください)。インスタンスには、値にパスを含む要素が含まれる場合があります (簡略化された XPath 式)。このようなパスの例は次のとおりです。

ここで、両方のプレフィックス (p と r) は、インスタンス ドキュメントで定義された名前空間にバインドされます。My Schematron は、パスが指している要素がインスタンス ドキュメントに実際に存在することを確認することで、そのようなパスを検証します。これを行うにはEXSLTに依存しています (私は XSLT1.0 を使用することを余儀なくされています)。より正確にdyn:evaluate()は、要素のテキスト値を評価するために依存しています。それは魅力のように機能します。

しかし、実際には大きな問題が 1 つあります。への呼び出しは、独自の名前空間コンテキストでdyn:evaluate()XPath 式を評価する Schematron XSLT から実行されます。これは、これが適切に機能するためには、インスタンス ドキュメントと Schematron XSLT の両方がまったく同じ接頭辞 → 名前空間を使用する必要があることを意味します。バインディング。スキーマで指定されている同じ名前空間に同じプレフィックスを使用するようユーザーに強制することはできません...これはばかげた要件です (ただし、少なくとも同じ名前空間が両方で使用されることが保証されています)。Schematron は常にインスタンスの検証が行われる前に生成されますが、これはパフォーマンス上の理由から一度だけ行われます。私が持っている唯一のオプションは、インスタンスからのパスを何らかの方法で前処理し、「インスタンス パス」から「XSLT パス」への何らかの変換を行うことです。私は XSLT が初めてで、どうすればこれを達成できるかわかりません。

このようなテキスト値を、XSLT の名前空間コンテキストで必要とされるものに変換するにはどうすればよいでしょうか? これは可能ですか？私は現在、各検証呼び出しの前に XSLT のメモリ内修正 (これはすべて Java 内で行われます) について考えています。プレフィックスの名前を変更して、新しい名前空間属性をバインドまたは注入するインスタンスと一致するようにします。しかし、これはプレフィックス名の衝突につながる可能性があり、検証のパフォーマンスにどのように影響するかはわかりません。これは、他の人も (Schematron または を使用しているときに) 遭遇したに違いないものであると想定しているため、私はどんな提案にもオープンですdyn:evaluate()。

編集：私がやろうとしていることの明確化は、これから続きます。

エディターでユーザーが編集している XML インスタンス ファイルがあります。このようなファイルの例は次のとおりです。

このようなドキュメントは、基本的に XSLT 変換であるスキーマトロン検証を通過します。パスが同じドキュメント内の既存の要素を参照している場合にのみ、有効であると宣言されns1:some-elementます (したがって、上記の例は有効です)。

スキーマトロン XSLT は次のようになります (大幅に簡略化されていることに注意してください)。

これで問題が説明できると確信しています。への呼び出しdyn:evaluate(.)は、XPath 式を評価しようとし/cfg:config/ns1:other-element/ns2:nested-elementます。これは、変換の観点からバインドされていないプレフィックスを使用します (したがって、常に false に評価されます)。

問題は、これらの XPath 式が実際に変換内で意味を持つように変換するにはどうすればよいかということでした。