You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@xalan.apache.org by "Voytenko, Dimitry" <dv...@sectordata.com> on 2002/12/25 01:15:10 UTC
variable/parameter shadowing
Hi,
I just ran across one paragraph 11.5 Variables and Parameters within
Templates of XSLT 1.0 specification.
http://www.w3.org/TR/xslt#local-variables
It states:
<quote>
It is an error if a binding established by an xsl:variable or xsl:param
element within a template shadows another binding established by an
xsl:variable or xsl:param element also within the template. .... Thus, the
following is an error:
<xsl:template name="foo">
<xsl:param name="x" select="1"/>
<xsl:variable name="x" select="2"/>
</xsl:template>
</quote>
I just checked with Xalan J 2.4.1: cases similar to the one described in
this paragraph are executed fine, just as I would expect. Moreover, I found
a bunch of XSL's in our system with the similar code. I'd actually prefer
the way Xalan works now, but if this is a conformance issue, we'd have to
change our XSL's eventually to avoid problems with the future versions.
Has anyone considered this issue? Is this really a conformance issue? Is it
gonna be changed?
Thanks,
Dmitry E Voytenko
_____________________________________________________
Sector Data, LLC, is not affiliated with Sector, Inc., or SIAC
Re: variable/parameter shadowing
Posted by Chris McCabe <Ch...@choicehotels.com>.
You will find that you get errors with other XSLT processors like Saxon
for example.
Chris
Voytenko, Dimitry wrote:
>Hi,
>
>I just ran across one paragraph 11.5 Variables and Parameters within
>Templates of XSLT 1.0 specification.
> http://www.w3.org/TR/xslt#local-variables
>
>It states:
>
><quote>
>It is an error if a binding established by an xsl:variable or xsl:param
>element within a template shadows another binding established by an
>xsl:variable or xsl:param element also within the template. .... Thus, the
>following is an error:
><xsl:template name="foo">
> <xsl:param name="x" select="1"/>
> <xsl:variable name="x" select="2"/>
></xsl:template>
>
></quote>
>
>I just checked with Xalan J 2.4.1: cases similar to the one described in
>this paragraph are executed fine, just as I would expect. Moreover, I found
>a bunch of XSL's in our system with the similar code. I'd actually prefer
>the way Xalan works now, but if this is a conformance issue, we'd have to
>change our XSL's eventually to avoid problems with the future versions.
>
>Has anyone considered this issue? Is this really a conformance issue? Is it
>gonna be changed?
>
>Thanks,
>Dmitry E Voytenko
>
>
>
>_____________________________________________________
>Sector Data, LLC, is not affiliated with Sector, Inc., or SIAC
>
>
>
--
Chris P. McCabe - Principle Engineer
Choice Hotels International - Information Technology
chris_mccabe@choicehotels.com - 602-953-4416
Re: variable/parameter shadowing
Posted by Chris McCabe <Ch...@choicehotels.com>.
You will find that you get errors with other XSLT processors like Saxon
for example.
Chris
Voytenko, Dimitry wrote:
>Hi,
>
>I just ran across one paragraph 11.5 Variables and Parameters within
>Templates of XSLT 1.0 specification.
> http://www.w3.org/TR/xslt#local-variables
>
>It states:
>
><quote>
>It is an error if a binding established by an xsl:variable or xsl:param
>element within a template shadows another binding established by an
>xsl:variable or xsl:param element also within the template. .... Thus, the
>following is an error:
><xsl:template name="foo">
> <xsl:param name="x" select="1"/>
> <xsl:variable name="x" select="2"/>
></xsl:template>
>
></quote>
>
>I just checked with Xalan J 2.4.1: cases similar to the one described in
>this paragraph are executed fine, just as I would expect. Moreover, I found
>a bunch of XSL's in our system with the similar code. I'd actually prefer
>the way Xalan works now, but if this is a conformance issue, we'd have to
>change our XSL's eventually to avoid problems with the future versions.
>
>Has anyone considered this issue? Is this really a conformance issue? Is it
>gonna be changed?
>
>Thanks,
>Dmitry E Voytenko
>
>
>
>_____________________________________________________
>Sector Data, LLC, is not affiliated with Sector, Inc., or SIAC
>
>
>
--
Chris P. McCabe - Principle Engineer
Choice Hotels International - Information Technology
chris_mccabe@choicehotels.com - 602-953-4416