After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 151795 - Several inclusions of a template
Several inclusions of a template
Status: VERIFIED FIXED
Product: libxslt
Classification: Platform
Component: general
1.1.8
Other Linux
: Normal normal
: ---
Assigned To: Daniel Veillard
libxml QA maintainers
Depends on:
Blocks:
 
 
Reported: 2004-09-03 22:17 UTC by Vincent Lefevre
Modified: 2009-08-15 18:40 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Vincent Lefevre 2004-09-03 22:17:25 UTC
Section 6 of the XSLT specification says:

It is an error if a stylesheet contains more than one template with the same
name and same import precedence.

But xsltproc doesn't report any error when a same named template is included
twice (via xsl:include). I don't know if this is allowed or not (contrary to
libxslt, xalan complains about that).

Now, in case this is allowed, xsltproc mysteriously removes the space of a
  <xsl:text> </xsl:text>
in the generated text, when I use xsl:include's instead of xsl:import's. If I
replace the space by a "+", I get the "+" in the generated text as expected,
whether I use xsl:import's or xsl:include's.
Comment 1 John Fleck 2004-09-03 22:33:42 UTC
It would be helpful to the debugging crew if you could include a simple test 
case that triggers the problem.
Thanks.
Comment 2 Vincent Lefevre 2004-09-03 23:19:52 UTC
Here's an example:

==> test.xsl <==
<?xml version="1.0"?>
<xsl:stylesheet version="1.0"
                xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:include href="included.xsl"/>
<xsl:include href="included.xsl"/>
</xsl:stylesheet>

==> included.xsl <==
<?xml version="1.0"?>
<xsl:stylesheet version="1.0"
                xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template name="included"/>
</xsl:stylesheet>

xsltproc doesn't return any error for
  xsltproc test.xsl test.xsl

Both xalan and sablotron return an error.

Concerning the space problem, it seems to be completely related to multiple
inclusions. As multiple inclusions seems to be forbidden, this is in fact a
non-problem. If you think that it is still interesting to see where it comes
from (if libxslt was designed to support multiple inclusions though it is not in
the spec), I could try to provide a simple example, but this would be quite
difficult.
Comment 3 Vincent Lefevre 2004-09-03 23:49:01 UTC
I've tried with xsltproc -v, and I even get a segmentation fault.
Comment 4 Vincent Lefevre 2004-09-04 00:08:51 UTC
Hmmm... that was eventually quite easy:

==> test.xsl <==
<?xml version="1.0"?>
<xsl:stylesheet version="1.0"
                xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:include href="included.xsl"/>
<xsl:include href="included.xsl"/>
<xsl:template match="/">
  <xsl:call-template name="included"/>
</xsl:template>
</xsl:stylesheet>

==> included.xsl <==
<?xml version="1.0"?>
<xsl:stylesheet version="1.0"
                xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template name="included">
  <xsl:text>+</xsl:text>
  <xsl:text> </xsl:text>
  <xsl:text>+</xsl:text>
</xsl:template>
</xsl:stylesheet>

ay:~> xsltproc test.xsl test.xsl
<?xml version="1.0"?>
++

If I modify test.xsl to have only one xsl:include line, I get

<?xml version="1.0"?>
+ +

as expected.
Comment 5 William M. Brack 2004-09-06 21:45:48 UTC
I added some code to detect the presence of a duplicate template name which took care of your first 
problem.  The second part was caused by some code which tried to improve efficiency under some 
conditions.  Basically, when the first include was encountered the included document was parsed and 
"pre-processed", with the "pre-processing" including removing unneeded space elements and 
converting xsl:text nodes to plain text nodes.  When the second include was encountered, the "pre-
processed" document was then "pre-processed" another time, with the effect you described.  I added a 
couple of flags which (I hope) will prevent this from happening (in the [unlikely] event the include is 
present multiple times without a template import-priority name conflict).

Thanks for the report and the good test cases.

Bill
Comment 6 Daniel Veillard 2004-09-30 12:08:53 UTC
  The release of libxslt-1.1.11 should fix this,
                                                                                
   thanks,
                                                                                
Daniel