Re: Re: Should variable resolution be done at compile-

> > Among other things lazy evaluation means not to report an
> > error, which does not actually affect the evaluation.
>
> This is one reason why in XSLT 2.0 we have distinguished very clearly
> between static errors and dynamic errors. If an error is defined as a
> static error then the processor must report it, even if the code is
> never executed. Referring to an undeclared variable is a static error in
> XSLT 2.0.
>
> However, I am surprised that any 1.0 processor should fail to report an
> error on the example submitted, where the reference to the undeclared
> (or out-of-scope) variable does actually appear to be evaluated.

The original example, submitted by Eric Promislow:

source.xml:
========
<x>special contents</x>


xslt stylesheet:
==========
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
version="1.0">
<xsl:output method="xml" />

<xsl:template match="/">
    <xsl:variable name="v1">bupkis</xsl:variable>
    <xsl:apply-templates />
</xsl:template>

<xsl:template match='x2'>
  <output>
    First, var v1 = <xsl:value-of select="$v1"/>.
    Text = <xsl:value-of select='.' />
  </output>
</xsl:template>
</xsl:stylesheet>


Here I did replace

   <xsl:template match='x'>

with

  <xsl:template match='x2'>

as Eric said he did.

The template matching "x2" will never be instantiated, because there isn't
any "x2" element in the source.xml

So, why do you think that:

>  the reference to the undeclared
> (or out-of-scope) variable does actually appear to be evaluated.

Now, as I think of it, JIT (just in time) compilation of templates does make
sense.



=====
Cheers,

Dimitre Novatchev.
http://fxsl.sourceforge.net/ -- the home of FXSL








 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list