[XSLT2.0] Binding of a local xsl:variable or xsl:param by another local xsl:variable/xsl:param

[XSLT2.0] Binding of a local xsl:variable or xsl:param by another local
xsl:variable/xsl:param

The section "9.7 Scope of Variables" at
http://www.w3.org/TR/xslt20/#scope-of-variables contains the following
text:

<quote>
For any variable-binding element, there is a region of the stylesheet
within which the binding is visible. The set of variable bindings in scope
for an XPath expression consists of those bindings that are visible at the
point in the stylesheet where the expression occurs.

A global variable binding element is visible everywhere in the stylesheet
(including other stylesheet modules) except within the xsl:variable or
xsl:param element itself and any region where it is shadowed by another
variable binding.

A local variable binding element is visible for all following siblings and
their descendants. The binding is not visible for the xsl:variable or
xsl:param element itself.

[Definition: A binding shadows another binding if the binding occurs at a
point where the other binding is visible, and the bindings have the same
name. ] It is not an error if a binding established by a local
xsl:variable or xsl:param shadows a global binding. In this case, the
global binding will not be visible in the region of the stylesheet where
it is shadowed by the other binding.

Example: Local Variable Shadowing a Global Variable 
The following is allowed:
<xsl:param name="x" select="1"/>
<xsl:template name="foo">
  <xsl:variable name="x" select="2"/>
</xsl:template>

It is also not an error if a binding established by a local xsl:variable
or xsl:param element shadows another binding established by another local
xsl:variable or xsl:param. However, such shadowing is discouraged and
implementations may output a warning when it occurs.

Example: Local Variable Shadowing a Local Variable 
The following is not an error, but is discouraged, because the effect is
probably not what was intended. The template outputs 
<x value="1"/>, 
because the declaration of the inner variable named $x has no effect on
the value of the outer variable named $x.

<xsl:template name="foo">
  <xsl:variable name="x" select="1"/>
  <xsl:for-each select="1 to 5">
    <xsl:variable name="x" select="$x+1"/>
  </xsl:for-each>
  <x value="{$x}"/>
</xsl:template>

Note:
Once a variable has been given a value, the value cannot subsequently be
changed. XSLT does not provide an equivalent to the assignment operator
available in many procedural programming languages.
This is because an assignment operator would make it harder to create an
implementation that processes a document other than in a batch-like way,
starting at the beginning and continuing through to the end.

As well as global variables and local variables, an XPath expression may
also declare range variables for use locally within an expression. For
details, see [XPath 2.0].
Where a reference to a variable occurs in an XPath expression, it is
resolved first by reference to range variables that are in scope, then by
reference to local variables and parameters, and finally by reference to
global variables and parameters. A range variable may shadow a local
variable or a global variable. XPath also allows a range variable to
shadow another range variable.
</quote>

I. Problems
There are several problems with this text and especially with the proposed
shadowing of a local xsl:variable or xsl:param element by another local
xsl:variable or xsl:param element:

1. The statement 
"A local variable binding element is visible for all following siblings
and their descendants. The binding is not visible for the xsl:variable or
xsl:param element itself".

is not true.

In case a local variable binding element is shadowed by another local
variable binding element, then it is not visible by all of its following
siblings and their descendents. The first local variable binding element
is only visible by those of its following siblings (and their
descendents), which are preceding siblings of the second local variable
element, which shadows the first.

2. In all cases of a local variable binding being shadowed by another
local variable binding the XSLT programmer can only manually try to
identify the correct variable binding for a given variable reference -- a
manual backwards text analysis is required in order to find the last
xsl:variable or xsl:parameter definition with the same name as the name of
the variable being referenced. This manual process is difficult,
error-prone and unreliable.

3. The lack of syntactic markers of the scope (called region!?! in the
draft) for a local variable binding is in violation of a number of
good-programming principles:

  - abstraction
  - encapsulation
  - consistent naming and elimination of ambiguities and redundancies.
  - the ability to easily and unambiguously identify the corresponding
variable definition from a given variable reference.


This leads to difficulties in understanding the code of a stylesheet. 
With the need to manually track and identify one of a many possible local
variable bindings that may or may not be referenced by a reference to a
given variable, the process of understanding, maintaining or debugging an
XSLT application becomes essentially difficult, error-prone and
unreliable, which in general will lead to increasing the costs of
development of an XSLT application.


II. Questions

Based on the facts listed above a number of questions do arise:

1. Why was it necessary to include a feature and immediately after
describing it to warn that use of this feature should be discouraged:

"It is also not an error if a binding established by a local xsl:variable
or xsl:param element shadows another binding established by another local
xsl:variable or xsl:param. However, such shadowing is discouraged and
implementations may output a warning when it occurs."

2. Was there any XSLT 2.0 use-case for the need to shadow a local
xsl:variable or xsl:param binding with another local xsl:variable or
xsl:param binding? Which one?

3. Which other programming language is popular for allowing multiple
identically named variables in the same lexical scope?

4. Was there a single WG member, who uses XSLT regularly in his/her work,
who voted positively for this feature?


III. Proposal

Taking into acount the harmful effects of local shadowing as listed above,
the specification should be corrected to explicitly state that it is
illegal in XSLT 2.0 for a local variable binding to shadow another local
variable binding, which is its sibling.


I hope that the respected members of the XSLT 2.0 WG will analyze the
facts, conclusions and proposal contained in this comment and will take
the correct decision.


Dimitre Novatchev.

__________________________________
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html

Received on Thursday, 5 February 2004 10:02:18 UTC