[xml/sgml-pkgs] Bug#383408: xsltproc: problems with dblatex interaction

[benoit.guillon]

On Thu, 28 Sep 2006 22:03:17 +0200 (CEST), Andreas Hoenen  
<andreas.hoenen at arcor.de> 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