[
Lists Home |
Date Index |
Thread Index
]
- To: Tatu Saloranta <cowtowncoder@yahoo.com>, xml-dev@lists.xml.org
- Subject: Re: [xml-dev] Bad programmers use recursion, xslt (Offtopic...)
- From: Michele Vivoda <idmichele@yahoo.it>
- Date: Mon, 27 Mar 2006 12:12:00 +0200 (CEST)
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.it; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=WS9kRqRb4gFo+qyBuD78YNFA2z2e6Gg3SL7g4oj6jV068goF6B/HAHBjk0chldjVBn9cFYJiFTQdRkTKA5xxlOMX1oup5McQJ5oWspvXy1lQFhVbv6kVb8/t2UD1qElj/7AlGg8H0k94LH5tXq4BjWtPr228r63E6V/dH+GgJHg= ;
- In-reply-to: <20060326174233.83500.qmail@web32802.mail.mud.yahoo.com>
> Regarding xslt, what I have always wondered is
whether
> there are many (enough?) cases where having stateful
> alternative (with real variables or such to store
> state) would have benefits: it seems as if computing
> certain things just once (or cumulatively) could
yield
> significant improvements.
Not sure if related but I found in my experience
that sometimes splitting a single XSLT1.0
transformation
into two transformations could bring good if
not big performance improvements.
In the first pass you prepare the intermediate
structures you need and and in some way you
add them to the source.
In the second pass you exploit these pre-prepared
structures saving the effort of calculating
them on the fly (lookup, sort etc).
They are already prepared by you
in the first pass with the flavour you like.
Of course not always is possible.
I think is an intutive way to simulate state
in a "transformation-oriented" way ;-)
Not sure about this but I think is not
the same state one thinks normally about,
the "real variables", is a sort of snapshot
of the previous transformations.
I think multiple transformations is a different
approach than trying to do all in one shot,
that is what one tends to do normally.
IN FAVOUR : In this approach making a transformation
is like
calling a function and the input tree is the
parameter: the nice thing is that function
implementation (xslt) might be optimized. Additionally
I found that doing more transformations is faster,
especially for very complex transformations and
the single stylesheets look easier.
As in standard functional programming you decide
the order of function calling, implementation of
the function might be able to be simultanously
run by multiple cpu, I will risk saying also
that each transformation is like a barrier (that
gives some rest to your recursive thinking).
AGAINST: In my opinion is very difficult to think in
terms of multiple transformations. One reason
might be that we are not used to, an other might
be that if one does not define very well the
"xml interfaces" to communicate between stylesheets
(the structure of the xml trees input of each
stylesheet) it becomes very difficult to understand,
document and debug them.
For example if one stylesheet
depends on the output of more than one other
stylesheet you risk when touching the first
in the chain to have to change all the others and not
only the following one.
I tried to find something that allows you to
do multiple transformations in a declarative
way but I did not find much.
This might be related to the state/functions argument,
but not sure how.
http://fxsl.sourceforge.net/articles/PartialApps/Partial%20Applications.html
Greetings.
Michele
___________________________________
Yahoo! Messenger with Voice: chiama da PC a telefono a tariffe esclusive
http://it.messenger.yahoo.com
|