XSLT: variables are accessible outside of their scope

VERIFIED WORKSFORME

Status

()

Core
XSLT
VERIFIED WORKSFORME
16 years ago
16 years ago

People

(Reporter: Thomas Meinike, Assigned: peterv)

Tracking

Trunk
x86
Windows 2000
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

16 years ago
The following example uses two templates with xsl:variable definition of $test.
The called template "abc" calculates $temp * $temp. Mozilla 1.0 do the job and
gives the results 25 and 36 for the XML input data <a>5</a> and <b>6</b>.

This is a non-standards-compliant behaviour.
Other XSLT processors like MSXML3, Saxon or Sablotron interrrupt the
transformation process with an error message.


xsl_variable_test.xml

<?xml version="1.0" encoding="ISO-8859-1"?>
<?xml-stylesheet href="xsl_variable_test.xsl" type="text/xsl"?>

<wurzel>
  <inhalt>
    <a>5</a>
    <b>6</b>
  </inhalt>
</wurzel>


xsl_variable_test.xsl

<?xml version="1.0" encoding="ISO-8859-1"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

<xsl:output 
    method="html" 
    doctype-public="-//W3C//DTD HTML 4.01 Transitional//EN" 
    doctype-system="http://www.w3.org/TR/html401/loose.dtd" 
    encoding="ISO-8859-1" 
    version="4.01" 
    indent="yes" 
/>

<xsl:template match="/">

<html>
<head>
<title>Test</title>
</head>
<body>

  <xsl:apply-templates />

</body>
</html>

</xsl:template>


<xsl:template match="wurzel/inhalt">

  <xsl:apply-templates />

</xsl:template>


<xsl:template match="a">

  <xsl:variable name="test"><xsl:value-of select="." /></xsl:variable>
  <xsl:call-template name="abc" />

</xsl:template>


<xsl:template match="b">

  <xsl:variable name="test"><xsl:value-of select="." /></xsl:variable>
  <xsl:call-template name="abc" />

</xsl:template>


<xsl:template name="abc">

  <p>
    <xsl:value-of select="$test * $test" />
  </p>

</xsl:template>

</xsl:stylesheet>
(Assignee)

Comment 1

16 years ago
We need a build id.
This is a known problem with the old variables code, it should however be fixed
now that the variabels rewrite has landed.

Thomas: please download a nightly build and see if it works correctly there.
(Reporter)

Comment 3

16 years ago
Build ID: 2002053012

Comment 4

16 years ago
my trunk says
NaN

NaN

which up to lack of good error reporting is WORKSFORME.
Error reporting is a different bug.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 5

16 years ago
@Axel: What happens with select="number($test) * number($test)" instead of
select="$test * $test" [also 25 and 36 in Mozilla 1.0] or
select="concat($test,$test)" [55 and 66 in Mozilla 1.0]?
(Reporter)

Comment 6

16 years ago
Build ID: 2002081218

select="number($test) * number($test)" 

NaN / NaN

select="concat($test,$test)"

errorerror / errorerror

???

Comment 7

16 years ago
$test is "error", which number() converts into NaN.

VERIFIED per reporters comments
Status: RESOLVED → VERIFIED
(Reporter)

Comment 8

16 years ago
Ok, that's also the explanation for the "errorerror" result of the
concatenation. But the variable content "error" ist a bad idea. How can I divide
my possible own $test="error" from the error message?
You should not do this at all. Once we have proper errorhandling the
transformation will stop compleatly once we hit an undeleared variable.
(Reporter)

Comment 10

16 years ago
I want not do this in my projects, I use now xsl:call-template, xsl:width-param
and xsl:param in this way:

<xsl:template match="a">

  <xsl:call-template name="abc">
    <xsl:with-param name="test" select="." />
  </xsl:call-template>

</xsl:template>


<xsl:template match="b">

  <xsl:call-template name="abc">
    <xsl:with-param name="test" select="." />
  </xsl:call-template>

</xsl:template>


<xsl:template name="abc">

  <xsl:param name="test" />
  <p>
    <xsl:value-of select="number($test) * number($test)" />
  </p>

</xsl:template>


But the transformation of the test document should stopped with an error message
like in the IE, Saxon or Sablotron processors.
Absolutly, but that's covered by bug 112622.

The short story is: our errorhandling sucks!
You need to log in before you can comment on or make changes to this bug.