DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14628>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14628 Invalid handling of top-level variables declaration together with stylesheet include/import Summary: Invalid handling of top-level variables declaration together with stylesheet include/import Product: XalanC Version: 1.2.x Platform: All OS/Version: All Status: UNCONFIRMED Severity: Normal Priority: Other Component: XalanC AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I have performed test of how different XSLT processros handle top-level <xsl:variable> declarations together with <xsl:import>/<xsl:include>. Results are pretty confusing for me... Following XSLT processors are being tested: - Sablotron 0.96.1 - Xalan 1.2 - LibXSLT 1.0.22 - MSXML 3.1 SP1 All tests was performed on Windows 2000, but o think they will be give same results for any other platform. I prepare 6 tests, here is first of them as an example: t.xml ===== <?xml version="1.0"?> <root/> 1.xsl ===== <?xml version="1.0"?> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform";> <xsl:include href="2.xsl"/> <xsl:variable name="test">[1]</xsl:variable> <xsl:template match="/"> <xsl:value-of select="$test"/> </xsl:template> </xsl:stylesheet> 2.xsl ===== <?xml version="1.0"?> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform";> <xsl:variable name="test">[2]</xsl:variable> </xsl:stylesheet> t.xml and 2.xsl are the same for all tests, only 1.xsl changes. I'll put full test results togher with contents of 1.xsl into next comment to make it easier to read. About Xalan it looks like it fails to confirm XSLT specification (http://www.w3.org/TR/xslt#top-level-variables): "It is an error if a stylesheet contains more than one binding of a top-level variable with the same name and same import precedence." but from other side it is better for practical usage, so this bug is more dedicated to let you know about this specification break.
