Hi Rolf,
Thanks very much for your very eleborate reply! So what is the correct
method of changing a variable's value? I can't find anything on that
subject myself.
But when it did run (without the "hasPrev" chacking) and I put a time {}
around it, the first thig that came to mind was "Holy F***ing Sh*t!" This
thing does in ~2ms what the Java parser takes almost half a second to do!
I am starting on this project, where I need templates that customers can
edit (without gaining access to server functions!) and I though it best to
use a standard, at least they can't come b*tchin' to me that I am using
something stupid that way. So I chose xslt. I wanted to do it in Java, but
was so dissapointed with XSLT speed I gave good ol' AOLserver a go again.
Glad I did, now I don't need a massive server park to support 10 requests
a second! ;-)
Thanks again!
Bas.
>
> Hi Bas,
>
> Zoran has forwarded your problem to me.
>
> On 23 Oct, Bas Scheffers wrote:
>> Zoran Vasiljevic said:
>>> You mind giving us test.xml and test.xsl to look at?
>> Sure,
>>
>> They are both quite simple (for me to figure out how XSLT works...)
>> and work fine in the standard Java 1.4 "javax.xml.transform".
>>
>> Also: You may want to update the instructions for building it using
>> AOLserver 3.5:
>> As the source is not in the aolserver directory (i think it was
>> pre-3.5?), you need to symlink to it:
>> $ ln -s /usr/src/tcl8.4.4 /usr/local/aolserver/tcl8.4.4
>> (so now the tcl source is below the aolserver dir)
>
> Short version:
> You're using a dubious construct in your stylesheet -
> setting the variable 'hasprev' in the inner for-each, although there is
> already a variable with that name. Don't do that!
>
> Long version:
> Hey, you've the gift! You stumbled over one of the rare cases in which
> the xslt recommendation doesn't gives a really clear answer, what is
> right and what is wrong. Basically, it is not allowed, to 're-set' a
> variable, which is already declared in scope. That's the basic rule and
> there is not debatte about this. E.g. a template like this
>
> <xsl:template match="/">
> <xsl:variable name="var" select="'first valule'"/>
> <xsl:variable name="var" select="'second valule'"/>
> <xsl:value-of select="$var"/>
> </xsl:template>
>
> is simply and undebatable wrong. The one crucial nuance in your
> example is, that you re-declare the variable 'hasprev' inside a
> for-each. The xslt implementors in fact doesn't agree about this
> case. For example, the currently (and for quite a while) most
> respected XSLT processor saxon (the '101 percent compliant XSLT
> processor) raises the same error for your stylesheet, as tDOM does. I
> suspect, you use the xalan processor (or one build on the code base of
> xalan). I know, that xalan accecpt this construct. But even the xalan
> folks are aware (and notice) that this is a dubious case. See the
> xalan test cases (part of the xalan source ball):
>
> variable/variable20.xsl:
> <!-- Purpose: Verify that a variable in a for-each can take on a new
> value --> <!-- It's unclear whether the spec allows this. XT does;
> Saxon doesn't. -->
>
> variable/variable56.xsl:
> <!-- Purpose: Use same-named variables in inner and outer scopes,
> where inner
> is a for-each loop. -->
> <!-- This may need to become an error case. -->
>
> Although I also confess, that it seems not to be possible, to *proof*
> from the XSLT rec, that to raise an error is the only possible correct
> behavior in this case - this is a rare case, the xslt and xpath
> recommendations are masterpieces (at least compared to some other XML
> related recommendations), which normally let not much room for
> discussion - I think this is completely in accordance of the spirit and
> basic principles of the XSLT 1.0 recommendation. Or in short: I'd say
> saxon and tDOM are right, in rasing an error in this case. BTW: The
> upcomming XSLT 2.0 clarifies this point without any doubts: your
> stylesheet *must* raise an error in XSLT 2.0.
>
> Back from theoretical discussions, to real live. Since there is in fact
> no consensus between the XSLT engine implementators, even not the
> 'important' ones, in this case, the best is, to avoid this
> construct. This is good pratice anyway, since re-declarating of a
> variable, which is already in scope, is, as said, in all other cases
> clearly an error.
>
> rolf
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of
your email blank.
