[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: [xsl] Re: Incrementing a Global variable


Subject: Re: [xsl] Re: Incrementing a Global variable
From: David Carlisle <davidc@xxxxxxxxx>
Date: Thu, 28 Aug 2003 15:51:01 +0100

> Why would introducing a incrementable variable, change
> *the way templates process presently* ? If I have a
> variable at a xsl:stylesheet level say <xsl:variable2
> name="a" select="0" />
> and I use it in a xsl:template as below --
> <xsl:template matche="something">
>   <xsl:variable2 name="a" select="$a + 1" />
> </xsl:template>
> 
>   This incrments variable *a* at a global place. I
> agree that this template is producing side effect, but
> does this model change the way templates are being
> processed presently? variable *a* is being
> incremented, its values can be used after this
> statement, and the execution of rest of xsl:template
> proceeds as usual.

This would mean that  if you use $a in another template
it would have  value 1 or 0 depending on the order that the two
templates were evaluated. Currently an XSLT system can evaluate
templates in _any_ order (and in particular, it can evaluate them in
parallel) so long as it assembles the result tree in teh specified way.
This is why saxon:assign isn't so bad it makes visible the order saxon
used which might be useful for debugging saxon but given
<x>
 <a/>
 <b/>
 <a/>
</x>
a system might evaluate  the templates matching <a/> first then 
all the template matching <b/> and assemble the result tree
from these three results. You can not assume that it first evaluates the
template on teh first a then the b then the second a
so if your template matching a increments a variable and the template
for b uses it, b coul dsee th evalue 0 1 or 2 depending on when teh b
template was executed, so this value is really only any use for
debugging internal xslt engine behaviour, the value is no use at all as
a reliable result.

>  are we not trying to justify the
> functional nature of XSLT from a pure computer science
> point of view..

Not really, the functional description of problems is the more natural
one. It is the "computer science" view of the 60's and 70's that 
made procedural descriptions of problems more popular as that was
necessary to make problem descriptions less natural but more easily
implemented on a machine.

> IMHO, I would ask -- what is the purpose of XSLT..? I
> believe, to aid transformations of XML documents. That
> is its sole objective.. Having it functional
> definetely produce optimizations, side effect free
> behaviour and other benifits which are required in
> time critical -- real world applications.

I don't believe a functional style was chosen to improve optimisation
(no functional language is as fast as C for example)  it was chosen
because it leads to a natural human-oriented way of coding problem
descriptions.

David

________________________________________________________________________
This e-mail has been scanned for all viruses by Star Internet. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk
________________________________________________________________________

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



Current Thread
Keywords