0

xslt 2.0 に変換する必要がある xslt 1.0 スタイルシートがあります。

ここでこの質問を見つけました:同じ問題を扱うXSLT 1.0 を 2.0 に変換します。

それによると、バージョン属性を 2.0 に変更するとうまくいきます。しかし、それだけでいいのでしょうか。

前もって感謝します

4

2 に答える 2

1

変換の戦略の選択は、一連の回帰テストがどれだけ優れているかによって決まると思います。

優れた回帰テストのセットがある場合、またはエラーの導入による結果が深刻でない場合は、次の手順をお勧めします。

（a）バージョン属性を2.0に変更します

（b）XSLT 2.0プロセッサを使用してテストケースを実行し、それらが機能するかどうかを確認します

（c）テストの不一致を調べて、その原因を特定します（おそらく、80％の確率で、不一致がなく、最初は正しく機能します）。

適切なテストがない場合、またはリスクを冒す余裕がない場合は、より慎重な戦略が必要になる可能性があります。（もちろん、最終的に注意するのは、「何も変更しない」戦略です。1.0を使用してください）。おそらく、この場合の最善のアドバイスは、より多くのテストケースを作成して変換プロジェクトを開始することです。少なくとも、現在処理しているソースドキュメントのサンプルと、これらのソースドキュメント用に生成された出力を収集し、ファイル比較ツールを使用して、変換後に取得した出力を比較します。

1.0と2.0の間にはいくつかの非互換性があります。遭遇する可能性が最も高いのは、1.0のxsl：value-of（および他の多くの構成）が最初の後に指定された入力シーケンスのすべてのノードを無視するのに対し、XSLT2.0は指定されたシーケンスのすべてのノードを出力することです。この問題に対処するには2つの方法があります。どちらか（私の推奨）は、この問題が発生する場所を特定し、通常はselect="X"をselect="X[1]"に変更して修正します。または、xsl：stylesheetのversion属性をversion = "1.0"に戻します。これにより、XSLT2.0プロセッサが下位互換モードで実行されます。下位互換モードに依存することの欠点は、XSLT 2.0でのより強力な型チェックの利点が失われることです。これにより、複雑なスタイルシートコードのデバッグがはるかに簡単になります。

私の経験では、変換で発生する問題は、W3C言語の変更よりもプロセッサ/実装の変更に依存する可能性が高くなります。コードは、2.0プロセッサでサポートされていないベンダー定義の拡張関数を使用している場合や、プロセッサごとに異なるシーケンスの照合など、実装定義の動作に依存している場合があります。たとえば、完全に実装に依存するgenerate-id（）によって生成される出力の特定の形式に依存するコードを見てきました。

于 2012-06-21T09:08:21.807 に答える
0

「XSL Transformations (XSLT) Version 2.0」、§J、「Changes from XSLT 1.0 (Non-Normative)」には、注意が必要な XSLT 1.0 と XSLT 2.0 の相違点のほとんどがリストされています。

于 2012-06-21T08:31:40.373 に答える