AntのXSLTタスクで実行するSaxonにconfigファイルを食わせる
DITA-OTでXSLT処理系を使う場合、通常はSaxonをAntのXSLTタスクから使用することになります。ここで、configファイルを弄ったものを使用する必要があるときの読み込ませ方を紹介します。Saxonのドキュメントに書いてあったのに長らく見つけられなかったので。
追記。先人のブログにもありました。 https://toshi-xt500.hatenablog.com/entry/2020/03/24/072313
この記事内容については今後同人誌にもほぼそのまま同様の情報を載っける可能性があります。
DITA-OTでのAntとXSLTタスクの立ち位置
現代の有名ツールでApache Antを使っているものはそう多くないでしょう。その数少ない内の1つがDITA Open Toolkitです。DITA-OTは入力について、JavaのアプリケーションとXSLTスクリプトの処理のパイプをAntで記述していきます。ユーザによるカスタムプラグインも例外ではなく、Antで処理を書いていきます。ですので、XSLT処理については、<xslt>
として用意されたXSLTタスクを使うのが通常の流れ[1]です。DITA-OTにはSaxon-HEがバンドルされているため、XSLTタスクを使うプラグインは大抵Saxon前提で組まれます[2]。
Configファイルの調整が必要になるのはどんなときか
典型的な例は次です:
- Javaライブラリなどとして独自関数を定義してスタイルシートで利用しているとき
-
xsl:package
を使うとき
筆者の必要は後者によるもので、xsl:packageの参照解決は処理系側で行うことになっており、XMLCatalogでは行えない[3]からです。
一応、configを適宜指定していくこともできるのですが、まあファイルを読み込めた方が早いことも多いです。
該当箇所の記述例
<!-- build.xmlのtarget内など -->
<xslt in="input.xml"
style="stylesheet.xsl"
out="output.xml">
<factory name="net.sf.saxon.TransformerFactoryImpl">
<attribute name="http://saxon.sf.net/feature/configuration-file"
value="custom-config.xml"/>
</factory>
</xslt>
<factory>
の@name
はSaxonのエディションによって変わります。上の例はHE用。
2024-09-06 追記。net.sf.saxon.BasicTransformerFactory
はHE用なんですが、ここはnet.sf.saxon.TransformerFactoryImpl
で大丈夫みたいなので修正。
というか、「XSLT transformations from Ant」の情報が答えなんですが「Configuration when running Ant」と離れた配置になっていて今迄見つけられなかったという……。
参考資料
- Adding Saxon customizations: https://www.dita-ot.org/dev/topics/implement-saxon-customizations
- Saxon configuration file: https://www.saxonica.com/documentation12/index.html#!configuration/configuration-file
- Configuration when running Ant: https://www.saxonica.com/documentation12/index.html#!configuration/config-interfaces/config-ant
- XSLT transformations from Ant: https://www.saxonica.com/documentation12/index.html#!using-xsl/xsltfromant
-
バンドルのSaxon-HEを使わない場合も大抵Saxon-PEやSaxon-EEなどSaxonを使う。新生Apache Xalanの3.0対応は未だ半ばだし、Altovaは単体エンジンの利用例全然聞かないんだよな ↩︎
-
Saxon9の途中からHE版のAPIがJAXP廃止になったので、HEではSaxonとべったりなs9apiを使わなければならないというのも地味にあるのではないかと疑っている。まあXDM 3.0に対応するの大変そうだしJAXP用の負債サポートをPE・EEとして支払う構造はそれなりに正当性がある、気がする ↩︎
-
パッケージのバージョン、パッケージ用パラメータの注入などの機能が必要になるためだろう ↩︎
Discussion