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

This is an XSL WG response to the message

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

(issue qt-2004Feb0111-01)

In summary, the WG decided to make no technical change in response to this
comment. 

It's a difficult issue with arguments on both sides. There are respectable
programming languages that do it one way, and there are respectable
languages that do it the other way. There is no objective way of saying that
one group are right and the other are wrong. I therefore can't give a
convincing technical argument in favour of the decision to allow variable
shadowing. Opinions within the XSL WG are fairly evenly balanced on the
issue. Opinions in the XQuery group, however, have been strongly in favour
of allowing variable shadowing. There is therefore little prospect of
changing the rule at the XPath level, and given that fact, the XSL WG feels
it is better for XSLT and XPath to be consistent.

The technical arguments in favour of allowing variable shadowing seem to be
summarized under the heading "no needless restrictions". Things shouldn't be
disallowed if they make sense.

Addressing the specific points made:

I.1 is essentially an editorial criticism, suggesting that our use of the
word "visible" is inappropriate. We accept this criticism and will change
the way we describe the language rules.

I.2 suggests that it will be difficult for users to identify which variable
declaration a given variable reference refers to. This is a subjective
argument. It could be equally be used to justify other changes, for example
banning local variables that shadow global variables, or banning the use of
uppercase Greek letters in variable names. The choice of distinctive
variable names for distinct variables is not something that the language can
impose.

I.3 seems to be essentially a re-statement of I.2 in more technical
language, but still essentially in subjective terms.

II.1 Why include the feature and then discourage its use? I think most
people with experience of developing standards will recognize this as a
classic thing that happens when there are good arguments both ways and a
group has to reach a compromise. There are many constructs that we allow
even though we wouldn't recommend their use in most circumstances, for
example the expression "$A/$B": this is another example where some wanted to
ban it but the "no needless restrictions" argument won the day.

II.2 Was there any XSLT 2.0 use case for the need to allow shadowing? The
only use case I recall being presented is the "cut and paste" use case: it
should be possible to copy code from one place to another without renaming
all the variables. But this isn't why the decision was made: it was made
because XQuery didn't want to introduce what they saw as an unnecessary
restriction into their language, and XSLT agreed that it was desirable for
the XSLT and XPath to be consistent.

II.3 Which other programming language is popular [for allowing this
feature]? When we first debated this issue, other languages were surveyed,
and we found there was no overwhelming precedent one way or the other. I
regret I don't have this analysis to hand now. I wouldn't claim it was
comprehensive - it probably looked at 8 languages rather than 80.

II.4 Was there a single WG member who uses XSLT regularly who voted for this
feature? Dimitre, we know you feel passionately about this, but asking this
sort of ad hominem question is not going to help your case. Of course the
simple answer is yes. I would say, however, that the overwhelming majority
of the WG could live with it going either way.

I know you're not going to like this decision, but we can't please everyone
all of the time. I have to ask you if you will accept it.

Regards,

Michael Kay
for the XSL Working Group

Received on Friday, 30 April 2004 18:35:36 UTC