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

Thank you for the comment, Dimitre. We will look at it in the working
group, of course. Let me try to give you some explanation as to how we
got to this situation, which I certainly regard as less than
satisfactory.

> 
> 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.

I agree the word "visible" is probably a poor choice. If a word with
fewer connotations were substituted, for example "manifest", and we made
it clear that we were defining the term for use later, then I think this
problem would go away. But we should probably find a better way of
specifying it.

> 
> 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.

But surely it's very similar to the rule used in many block-structured
languages? Apart from the question of shadowing, do you have any
different suggestions for the scope of a local variable? (One
possibility, of course, would be to allow forwards references to local
variables just as we allow forwards references to global variables. But
I'm not sure who would benefit from this.)
> 
> 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.

Isn't this essentially the same point as (2) above, or have I
misunderstood?
> 
> 
> 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."

Politics. Sometimes this sort of messy compromise is the only way you
can get out of a deadlock when people don't agree. There are a lot of
very clever people on the working groups and clever people have a
tendency to feel strongly about things like this.

> 
> 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?

No, there was no use case. What happened was that we decided that if
multiple local variables with the same name were allowed in XPath, then
they should also be allowed in XSLT, for consistency. The XQuery group
was strongly in favour of allowing this in XPath, and the XSL Working
Group was fairly evenly divided, so that's the way the decision went.
> 
> 3. Which other programming language is popular for allowing 
> multiple identically named variables in the same lexical scope?

Jerome Simeon did a survey of half a dozen languages and found them
fairly equally divided on this question, but I don't recall the details
of what he found out. 
> 
> 4. Was there a single WG member, who uses XSLT regularly in 
> his/her work, who voted positively for this feature?

Yes.
> 
> 
> 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.
> 

We will review it, both in XSL WG as to the rules for XSLT, and in the
joint working groups as to the XPath/XQuery rule. But I don't promise
anything: there were people who argued passionately against having any
restrictions in this area, and when people argue passionately, they
aren't easily persuaded to change their minds.

Michael Kay

Received on Thursday, 5 February 2004 11:06:30 UTC