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

--- Michael Kay <mhk@mhk.me.uk> wrote:
> 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.

I should have given an example:

  <xsl:variable name="xxx" select="1"/>

  <!-- many siblings here -->

  <xsl:variable name="xxx" select="2"/>

  <!-- many siblings here -->
  
  <xsl:variable name="xxx" select="1.5"/>

  <!-- many siblings here -->

  <xsl:variable name="xxx" select="1.3"/>

  <!-- many siblings here -->

  <xsl:variable name="xxx" select="1.7"/>

  <!-- many siblings here -->

  <xsl:value-of select="$xxx"/>

Regardles whether we use the word "visible" or any other word here (let's
say "in force"), none of the bindings of "xxx" is in force for all of its
following siblings with the possible exception of the last one, but even
this we don't know -- we must scan visually the document to the last
sibling to see if there isn't any new binding of "xxx", which shadows the
last one listed above.

ANother important point: there are no syntactical markers of the scope of
the bindings above -- their visibility is determined only by their
position.


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

No. 

In a block structured language I can have:

  int i = 0;

  {
     int i = 2 * i;

  }

Even in this case C# raises an error, and VC++ gives a warning (if in the
internal scope we had just:

 int i = 2;

then VC++ fully accepts it, but C# still raises an error).

The lexical markers (the curly braces terminal symbols) above make it
acceptable and visually intuitive as to which variable definition is in
scope.

However, this is in error:

  int i = 0;

  int i = 2 * i;

in both C# and VC++ (multiple re-definition error) and will be an error in
most block structured languages I'm aware of.

The reason is that there is a duplicate declaration of the same variable
in the same lexical scope.

But exactly this is OK with the XSLT 2.0 specification!

In the XSLT 2.0 example given above we do not have any curly brackets or
any lexical markers whatsoever to help us determine the correct variable
binding that is in scope -- we have to just go backwards and we may skip
the right definition -- no visual or structural clue can help us.

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

Not exactly the same. Here I correctly point out the main cause of concern
-- that multiple definitions are allowed even when there are no
syntactical or structural markers to separate them -- a situation, which
as we saw above is flagged as error in block-structured languages.

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

Yes, a really messy compromise.


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

So, we actually don't need shadowing of local variable binding? No XSLT
2.0 use-case for such a feature!

But then, o lord, why should we have it? As a present?

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

  XPath and XSLT are different languages and have orthogonal functionality
-- shall we make XSLT non-XML just "for consistency" with XPath?

No wonder taking such a decision "for consistency" with XPath did have bad
consequences.

> The XQuery group
> was strongly in favour of allowing this in XPath, 

My primary concern is XSLT -- not XPath. We are, hopefully, not going to
copy the XPath's "for expression" in order to define an xsl:variable.

> and the XSL Working
> Group was fairly evenly divided, so that's the way the decision went.

So the reason for introducing the shadowing of local
xsl:variable/xsl:parameter bindings was not any real need (use-cases) but
just a wish to make "more consistent" two such very different languages as
XPath and XSLT and also the mood of the WG.

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

Thank you very much, Mike.

Once again, in the light of the facts how this decision was taken in the
past, I hope that now the working group will see more clearly and take the
right decision.


Best regards,

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 12:31:47 UTC