XSLT: Is the variable scope of <xsl:if> local?

[Hoi Wong]

With the XSLT 1.0 engine that I was forced to use, I have to parse old XML
scripts where the number (to be parsed and saved into $EPISODE_NUMBER_RAW)
that I want to parse is written with a comma seperator if it goes beyond 3
digits. i.e. the variable might be parsed as a string '1,324' or a number
56, depending on which XML file I have.

I was trying to get rid of the comma seperator by breaking the string into
two parts (that number will never go beyond 5 digits), like this:


<xsl:choose>
<xsl:when test="contains($EPISODE_NUMBER_RAW, ',')">
<xsl:variable name="EPISODE_NUMBER"
select="concat(substring-before($EPISODE_NUMBER_RAW,','),
substring-after($EPISODE_NUMBER_RAW, ',') )"/>
</xsl:when>

<xsltherwise>
<xsl:variable name="EPISODE_NUMBER" select="$EPISODE_NUMBER_RAW"/>
</xsltherwise>

</xsl:choose>

<xsl:value-of select="$EPISODE_NUMBER"/>


However, the XSLT throws an error saying that $EPISODE_NUMBER is not found.
Does <xsl:choose> has its own variable scope? If so, can anybody give me a
pointer on how to solve the problem?

Thanks a lot in advance.

Cheers,
Hoi

 

[Pavel Lepin]

With the XSLT 1.0 engine that I was forced to use, I have
to parse old XML scripts where the number (to be parsed
and saved into $EPISODE_NUMBER_RAW) that I want to parse
is written with a comma seperator if it goes beyond 3
digits. i.e. the variable might be parsed as a string
'1,324' or a number 56, depending on which XML file I
have.

I was trying to get rid of the comma seperator by breaking
the string into two parts (that number will never go
beyond 5 digits), like this:

640K of memory will be enough for anybody.

<xsl:choose>
<xsl:when test="contains($EPISODE_NUMBER_RAW, ',')">
<xsl:variable name="EPISODE_NUMBER"
select="concat(substring-before($EPISODE_NUMBER_RAW,','),
substring-after($EPISODE_NUMBER_RAW, ',') )"/>
</xsl:when>
<xsltherwise>
<xsl:variable name="EPISODE_NUMBER"
select="$EPISODE_NUMBER_RAW"/>
</xsltherwise>
</xsl:choose>

However, the XSLT throws an error saying that
$EPISODE_NUMBER is not found. Does <xsl:choose> has its
own variable scope? If so, can anybody give me a pointer
on how to solve the problem?

Works:

<xsl:variable name="number">
<xsl:choose>
<xsl:when test="contains($raw-number,',')">
<xsl:value-of select=
"
concat(substring-before($raw-number,','),
substring-after($raw-number,','))
"/>
</xsl:when>
<xsltherwise>
<xsl:value-of select="$raw-number"/>
</xsltherwise>
</xsl:choose>
</xsl:variable>

Better:

<xsl:variable name="number"
select="translate($raw-number,',','')"/>

Even better - stuff it into a named template and invoke
that. You never know when you might need this again.

 

[Joseph Kesselman]

_All_ XSLT variable scopes are local.

 

[Hoi Wong]

translate() works perfectly! Thanks.

640K of memory will be enough for anybody.


Works:

<xsl:variable name="number">
<xsl:choose>
<xsl:when test="contains($raw-number,',')">
<xsl:value-of select=
"
concat(substring-before($raw-number,','),
substring-after($raw-number,','))
"/>
</xsl:when>
<xsltherwise>
<xsl:value-of select="$raw-number"/>
</xsltherwise>
</xsl:choose>
</xsl:variable>

Better:

<xsl:variable name="number"
select="translate($raw-number,',','')"/>

Even better - stuff it into a named template and invoke
that. You never know when you might need this again.

 

[Pavel Lepin]

_All_ XSLT variable scopes are local.

Ah, but what about xsl:variable children of xsl:stylesheet
element? Besides, I think it's not about lexical/dynamic
scoping, but about what a variable's scope is. This is
rarely if ever mentioned in tutorials, so you've got to
shuffle through the spec to get a precise definition, and
we all know how averse your J. Random Developer is to that.

Yes, the scope of a local variable is limited by the nearest
enclosing block in many of the modern languages. But XSLT
doesn't really have blocks; and, say, PHP does not adhere
to that convention. Compare:

pavel@debian:~/dev/php$ a scope.pl
use warnings; use strict;
sub tst {
my $foo = 1;
if ($foo) {
my $bar = 2;
}
print($foo . ' ' . $bar . "\n");
}
tst();
pavel@debian:~/dev/php$ perl scope.pl
Global symbol "$bar" requires explicit package name at
scope.pl line 7.
Execution of scope.pl aborted due to compilation errors.
pavel@debian:~/dev/php$ a scope.php
<?php error_reporting(E_ALL | E_STRICT);
function tst() {
$foo = 1;
if ($foo) {
$bar = 2;
}
print($foo . ' ' . $bar . "\n");
}
tst(); ?>
pavel@debian:~/dev/php$ php scope.php
1 2
pavel@debian:~/dev/php$

(Perl also has dynamic scoping, using which would produce
the same behaviour as observed in the PHP script above -
but the point is that in PHP, the scope of $bar is limited
by the body of the function it's defined in, not by the
nearest enclosing block.)

I've also had some trouble with this in my first days with
XSLT, so I can sort of sympathise with the OP.

 

[Joseph Kesselman]

Ah, but what about xsl:variable children of xsl:stylesheet
element?

They're local to the stylesheet element and its content.

scoping, but about what a variable's scope is.

A variable's lexical scope in XSLT -- the area within which that
variable can be referenced by name -- is the xsl:variable element's
following siblings and their descendants, unless the same name is used
for another variable within that scope. Its dynamic scope is the
execution of the element which encloses the xsl:variable element.

Putting it another way: An XSLT variable is created at the xsl:variable
element, is directly visible only within the element that element
appears within.

 

[Pavel Lepin]

They're local to the stylesheet element and its content.

The spec seems to disagree [11.4]:

A top-level variable-binding element declares a global
variable that is visible everywhere.

I believe this affects also affects imports and includes,
but gotta test that on a real processor or shuffle through
the spec some more to see if there's an explicit
description of those cases.

 

[Joseph Kesselman]

I believe this affects also affects imports and includes,

.... I think that's right. One can quibble about the details of how this
interacts with import/include -- whether those "become part of the same
stylesheet element" in some reasonable sense -- but I don't think it's
worth debating.

In practical terms, it's a difference that rarely, if ever, makes a
difference.

 

[P. Lepin]

... I think that's right. One can quibble about the details of how this
interacts with import/include -- whether those "become part of the same
stylesheet element" in some reasonable sense -- but I don't think it's
worth debating.

In practical terms, it's a difference that rarely, if ever, makes a
difference.

I apologise for displaying the symptoms of my Compulsive Nitpicking Syndrome
in public yet again.