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(_at_)nag(_dot_)co(_dot_)uk> 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