Hi David,
  Thanks for your ideas.. I agree that introducing
incrementable variables will cause problems and would
need a drastic change in XSLT processing model. The
side effects will be very difficult to manage.

  Thanks to all for giving insightful ideas..

Regards,
Mukul

--- David Carlisle <davidc@xxxxxxxxx> wrote:
> 
> > 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
> 


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

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