docbook / xslTNG

DocBook xslTNG Stylesheets
https://xsltng.docbook.org
MIT License
41 stars 20 forks source link

relative URIs calculated wrong when processing Documents in a pipeline (base-uri related) #427

Closed frank-steimke closed 5 months ago

frank-steimke commented 8 months ago

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 in xslTNG/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:

<xsl:template match="/*" as="element()">
  <xsl:copy>
    <xsl:attribute name="xml:base" select="base-uri()"/>
    <xsl:apply-templates select="@*, node()"/>
  </xsl:copy>
</xsl:template>

This time it works without errors, and correct img/@src values in the HTML result.

Greetings, Frank

ndw commented 5 months ago

I don't think this is a bug in the stylesheets, but I have attempted to clarify the documentation. Please let me know if you think I've misunderstood.