Saxon 9.3 HE と Java 1.6 を使用しています。インスタンスにリゾルバーを提供することで、xsl 内のステートメントをxsl:include解決できます。xsl:importsetURIResolverTransformerFactory
ただし、Source resolve(String includee, String includer)ファイルが以前に解決されている場合、メソッドは呼び出されません。includerファイルに基づいて別の方法で解決したいので、これは私にとって問題です。たとえば、<xsl:include href="foo.xsl"/>infile1.xslは in とは別のファイル<xsl:include href="foo.xsl"/>でfile2.xslあり、file1.xslおよびfile2.xslは に含まれfile3.xslます。テンプレート ファイルをオーバーライドできる「基本」コードと「顧客固有」のコードがいくつかあり、構築中のフレームワークに対して別の方法で解決する必要があります。
XSLT 仕様では、含まれる要素のベース URI に対する href 属性の相対 URI の解決は、相対 URI を処理するための標準規則に従って行う必要があることは明らかですが、結果の絶対 URI の逆参照は、実装が好きな方法で行うことができます。これを考慮して設計を再考することをお勧めします。
そのインクルードを持つ 2 つの XSL は、それぞれに対して URIResolver を呼び出す必要がある異なるベース URI を持っているため、私はそれを期待していました (それらが異なるディレクトリにある場合はどうなるでしょうか?)。
file1.xsl と file2.xsl のソースを作成する場合、それらのシステム ID は何ですか? それらが null の場合、同じディレクトリに存在する場合、またはパス情報がない (つまり、systemId が単にfile1.xsland でfile2.xslある) 場合、Saxon は、それらが同じディレクトリにあると想定して最適化を行おうとしている可能性がありますfoo.xsl。同じファイル。
ベース ファイルのソースのsystemIdを明示的に設定して、異なるディレクトリを作成してみてはいかがでしょうか。