Fwd: [XSLT2.0] Binding of a local xsl:variable or xsl:

Thought this would be interesting to the readers of xsl-list:

http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0111.html


--- Dimitre Novatchev <dnovatchev@xxxxxxxxx> wrote:
> Date: Thu, 5 Feb 2004 07:02:00 -0800 (PST)
> From: Dimitre Novatchev <dnovatchev@xxxxxxxxx>
> Subject: [XSLT2.0] Binding of a local xsl:variable or xsl:param by
> another local xsl:variable/xsl:param
> To: public-qt-comments@xxxxxx
> 
> [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

 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list