I suspect problems with processing documents that use the xinclude mechanism in the xslTNG stylesheets pipeline. To get to the bottom of this, I created a test scenario as simple as possible (see attachment). All transformations are done outside of Oxygen, using the xslTNG jar File (Version 2.1.9)
xinclude-issue.zip
The starting point was the sample directory of the xslTNG distribution, where I put a book with one chapter, which is included via xi:include (book.xml and chapter.xml). It contains two graphics with relative URLs. It is well-formed and valid. When i transform with the standard stylesheet docbook.xsl, everything is as expected. The img/@src values for Images are correct.
To check the pipeline idea i created the xslt/driver.xsl file as a customization layer which imports docbook.xsl. The only thing it does is to define a step in the pipeline by setting $transform-original to preprocessor.xsl. This preprocessor does nothing but shallow-copy. So i would expect the same output as before. But when i use the xslTNG jar file setting the stylesheet parameter to xsl:../xslt/driver.xsl i get an Runtime Error because xslTNG/xslt/chapter.xml is not found.
You can see that the URI of the included chapter is wrong. It is given as an URI relative to book.xml, but is calculated relative to the static base uri of the stylesheet.
To check whether it depends on xinclude i made a second book in book-monolith.xml with the same content, but without xi:include. Applying the driver.xsl Stylesheet leads to a different error message: Can't find the image file inxslTNG/xslt/media/lamb.png. Again, the relative URI is calculated wrong: not against the base-uri of the Input Document, but against the static base uri of the stylesheet.
My conclusion is that the base uri of the input document is absent when it is processed by an $transform-original pipeline, and that the static-base-uri is used instead, which in turn leads to File not Found Errors. To check this, i changed the preprocessor.xsl so that it adds the xml:base attribute:
I suspect problems with processing documents that use the xinclude mechanism in the xslTNG stylesheets pipeline. To get to the bottom of this, I created a test scenario as simple as possible (see attachment). All transformations are done outside of Oxygen, using the xslTNG jar File (Version 2.1.9) xinclude-issue.zip
The starting point was the sample directory of the xslTNG distribution, where I put a book with one chapter, which is included via
xi:include
(book.xml
andchapter.xml
). It contains two graphics with relative URLs. It is well-formed and valid. When i transform with the standard stylesheetdocbook.xsl
, everything is as expected. Theimg/@src
values for Images are correct.To check the pipeline idea i created the
xslt/driver.xs
l file as a customization layer which imports docbook.xsl. The only thing it does is to define a step in the pipeline by setting$transform-original
topreprocessor.xsl
. This preprocessor does nothing but shallow-copy. So i would expect the same output as before. But when i use the xslTNG jar file setting the stylesheet parameter toxsl:../xslt/driver.xsl
i get an Runtime Error becausexslTNG/xslt/chapter.xml
is not found.You can see that the URI of the included chapter is wrong. It is given as an URI relative to book.xml, but is calculated relative to the static base uri of the stylesheet.
To check whether it depends on xinclude i made a second book in
book-monolith.xml
with the same content, but withoutxi:include
. Applying thedriver.xsl
Stylesheet leads to a different error message: Can't find the image file inxslTNG/xslt/media/lamb.png
. Again, the relative URI is calculated wrong: not against the base-uri of the Input Document, but against the static base uri of the stylesheet.My conclusion is that the base uri of the input document is absent when it is processed by an $transform-original pipeline, and that the static-base-uri is used instead, which in turn leads to File not Found Errors. To check this, i changed the
preprocessor.xsl
so that it adds thexml:base
attribute:This time it works without errors, and correct
img/@src
values in the HTML result.Greetings, Frank