On Thu, 28 Sep 2006 22:03:17 +0200 (CEST), Andreas Hoenen
<[EMAIL PROTECTED]> wrote:
[...] 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.
Thanks for the explanations.
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...
Yes, since it should be possible to create an XML tree containing some
<xi:include> nodes. BTW, even with two options, it won't solve the case
where the stylesheets want to include something with the new xinclude
feature *and* want to build xinclude nodes. But I guess that using
<xsl:element> instead of outputing directly <xi:include> could solve the
problem.
What is the behaviour of other XSLT about xinclude? Another possible issue
with this new xsltproc feature is to write XSL stylesheets that can only
work with xsltproc.
2)
dblatex filters out the warnings.
Not a good option.
3)
dblatex abandons XInclude processing and uses another mechanism.
AFAIK it's the only way with XSLT-1.0 to include an XML file as raw text.
Regards,
BG
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
