andrew welch wrote:

> I can see how its possible - the variable will always come
> after the parameter, so it will always 'win' when it comes
> to scope.  My concern is that this sort of thing would
> usually end up from a mistake, and then get silently
> handled by the code - it's shadowing, and its well known
> how many problems that can cause.

> I've only tried this with Saxon 8.7.1 so I'm assuming it's
> intentional?

  It seems to be.  '9.2, Parameters:

    Local variables may shadow template parameters and
    function parameters: see 9.7 Scope of Variables.

  '9.7, Scope of Variables:

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

> Is there a good reason for this - something that I'm not
> seeing at the moment?

  I don't know the idea of the members of the WG.

  Personaly, I used this in generated XSLT.  In some case,
it's clearer than the 1.0 version, where it is an error to
have two variables of the same name in the same template
rule (even in different "scopes", for example outside and
inside an xsl:if).

  But in such a case, I can usualy use generate-id().

  Regards,

--drkm

























	

	
		
___________________________________________________________________________ 
Faites de Yahoo! votre page d'accueil sur le web pour retrouver directement vos services prifiris : virifiez vos nouveaux mails, lancez vos recherches et suivez l'actualiti en temps riel. 
Rendez-vous sur http://fr.yahoo.com/set