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

Hi Michael,

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

As someone else said it: it's a shame.

Until now I believed that XSLT 2.0 could be an elegant language. Thank you
for showing to me and to everybody that this was not a realistic belief.

I do not agree with at least two of the points in the WG reply:

> Addressing the specific points made:

 . . . . . . . .

> 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

This is not subjective argument and the answer above shows that the WG did
not understand at all the issue raised.

In the case of a local variable shadowing a global one there is absolutely
no problem to identify the variable declaration -- it is the only one
declaration for the variable with this name in the current template.

The case when shadowing is allowed between two local variables is
completely different. There may be many variable declarations for
variables with the same name within a template. In order to determine
which is the corresponding declaration for "this" variable (note the
naming difficulty! it will be necessary to stick one's finger to the
variable reference in order to identify it! One cannot just say variable
"abc", nor even variable "abc" - occurrence N) one will have to print the
file, then stick a finger at the variable reference and scroll backwards
(not releasing the finger pointing to the reference) until the first
preceding variable declaration for this name is found.

Then use a coloured pen to hi-light the scope of exactly "this" variable.

Imagine the case when two or more different variables are used in an
expression and these variables have overlapping scopes. It would be
necessary to manually determine the scope of each variable and then the
intersection of all scopes -- isn't this a real programmer's hell?



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

It is perfectly clear that allowing shadowing of one local variable by
another does not provide a solution to this "cut and paste" "use case".

The pasted text may not contain a definition for a variable reference and
then the one in the first text will be used with potentially catastrophic
results.

Or the pasted text (containing all necessary variable declarations) may be
inserted in the middle of the scope of a variable declaration, thus
leaving some of the last references to the original variable refer to the
variable declaration of the pasted text and not to its original variable
declaration. The results again would be catastrophic.

Not even to speak about the real usefulness of such use case...

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

Michael, it is not for my own pleasure that I am writing these comments.

What we are talking about is the new XSLT 2.0 language and whether it
would be elegant or ugly, easy and intuitive to use or supporting mistakes
and difficult for the programmer to use and understand.

This will be the "XSLT designed by committee". Isn't it time for people,
who love XSLT to design their own language?

Best regards,

Dimitre Novatchev.


	
		
__________________________________
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs  
http://hotjobs.sweepstakes.yahoo.com/careermakeover

Received on Monday, 10 May 2004 03:06:18 UTC