I have gained some more understanding of the problem: XInclude elements contained in dblatex XSLT stylesheets like
<xi:include href="{$filename}" parse="text" encoding="{$encoding}"/>
lead to warnings like:
/usr/share/xml/docbook/stylesheet/dblatex/xsl/common/mklistings.xsl:104:
element include: XInclude error : encoding {$encoding} not supported
/usr/share/xml/docbook/stylesheet/dblatex/xsl/common/mklistings.xsl:104:
element include: XInclude error : could not load
/usr/share/xml/docbook/stylesheet/dblatex/xsl/common/%7B$filename%7D, and no
fallback was found
when dblatex calls xsltproc.
Background:
xsltproc seems to consist of (at least) two separate components: an "XML
parser", responsible for parsing the XSLT stylesheets, and an "XSLT
processor", responsible for executing them. When executing an XSLT
stylesheet, first the parser does its work, passing its results
afterwards to the XSLT processor.
Before debian xsltproc version 1.1.17-4 only the XSLT processor resolved
XInclude elements. The XML parser left XInclude elements alone and
passed them unchanged to the XSLT processor.
This behaviour is exploited by the dblatex stylesheets regarding two
aspects:
XInclude resolving as executed by the XSLT processor is conditional,
that is XInclude elements get only resolved when the containing template
is executed. Furthermore, at the point an XInclude element is resolved,
the XSLT variables making up the values of the XInclude element's
attributes already have been resolved to meaningful values
(e.g. 'encoding="{$encoding}"' has been replaced by 'encoding="UTF-8"').
With version 1.1.17-4, already the parser tries to resolve the XInclude
element. This fails due to two reasons:
The resolving takes place unconditionally, even when no replacement is
intended (the template won't be invoked as the source document does not
contain appropriate elements). Furthermore at the parsing phase the
XSLT variables have not been resolved yet, thus the parser won't find
the right document and won't know the intended encoding.
Luckily the parser only emits warnings and continues to work, it just
passes the XInclude elements unchanged to the XSLT processor, which
succeeds in resolving them.
Possible solutions:
1)
xsltproc gets enhanced by an new command line option with the meaning:
Disable XInclude resolving in the parser, but enable it in the XSLT
processor. IMHO the best solution, but one would have to convince
upstream...
2)
dblatex filters out the warnings.
3)
dblatex abandons XInclude processing and uses another mechanism.
One final remark:
It seems possible that the next upstream release of xsltproc will
include this problematic patch already included in Debian version
1.1.17-4, then also native dblatex installations will suffer from the
warnings.
________________________________________________________________________
Andreas Hoenen <[EMAIL PROTECTED]>
GPG: 1024D/B888D2CE
A4A6 E8B5 593A E89B 496B
82F0 728D 8B7E B888 D2CE
pgpRlu0Qki7WB.pgp
Description: PGP signature
