OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: [xml-dev] Bad programmers use recursion, xslt (Offtopic...)

[ 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




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS