#1323 References with dbhtml-include PI are not interpreted relative to XML when using profiling-docbook.xsl

[Radu Coravu]

References with dbhtml-include PI are not interpreted relative to XML when using profiling-docbook.xsl.
In my Docbok 5 XML I have at some point:

      <?dbhtml-include href="test.html"?>

and I apply the "xsl\html\profile-docbook.xsl" stylesheet over the XML, the relative reference is no longer interpreted relative to the XML document.
The interpretation is done in "xsl\html\pi.xsl" in the template:

   <xsl:template name="pi.dbhtml-include">

but the profile-docbook.xsl stylesheet loses the base URI of the current transformed XML document.

[Robert Stayton]

This loss of base URI is an unavoidable artifact of single-pass profiling. In that mode, the document is first processed for profiling and the profiled result is saved in memory. But that result is no longer the original document, and does not have its base location information. This issue of unresolved relative paths in single-pass profiling also comes up with accessing an olink data file, glossary data file, and other external modules used in the doc. Since the stylesheet or document does not have the necessary information, no XSL fix is possible. I would suggest you switch to two-pass profiling, which saves the profiled document to a new file, and that new file will have base information for resolving relative paths.

[Radu Coravu]

Coming back to the XSL I mentioned earlier:

"xsl\html\pi.xsl" in the template:

  <xsl:template name="pi.dbhtml-include">

there is a place where the HTML document is read:

   <xsl:variable name="content" select="document($href,/)"/>

which indeed seems to have problems computing the base URI of the "/" document node after the profiling XSL has created a variable containing the filtered nodeset and applied the rest of the processing to it. Although the xml:base seems to be properly preserved on the node-set.

But I tested this change which seems to work though:

   <xsl:variable name="content" select="document($href,.)"/>

even when the single profiling stage XSL is applied. And it seems like a more correct approach because if the master XML document imports multiple modules and each module uses the "dbhtml-include" PI the relative location should be relative to that module and not to the master XML.

So maybe you could consider making this change whenever the "document" XSLT 1.0 function is used, to use the base location of the "." current element instead of the one of the document.

[Robert Stayton]

Yes, you are correct, that should be a "." instead of "/". The stylesheet uses "." everywhere else that document() refers to additional content. I'll fix this in the source.