Subject: [xsl] Fwd: [XSLT2.0] Binding of a local xsl:variable or xsl:param by another local xsl:variable/xsl:param From: Dimitre Novatchev <dnovatchev@xxxxxxxxx> Date: Thu, 5 Feb 2004 07:14:49 -0800 (PST) |
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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] outputting unknown amount, Jeni Tennison | Thread | [xsl] msxml and perlscript, bry |
RE: [xsl] Empty Elements in .NET, Rowland Shaw | Date | RE: [xsl] template matching, Peter Flynn |
Month |