Subject: Re: [xsl] Preferred declarative approach for outputting tallies based on complex triggers|
From: David Rudel <fwqhgads@xxxxxxxxx>
Date: Thu, 10 Apr 2014 13:44:56 +0200
After I wrote that post I realized that, in some sense, I might be asking the wrong question... Might one claim that if I'm still talking about "state variables" and the like that I'm not really embracing the declarative paradigm anyway? Perhaps I should be asking myself "How do I do the analysis I want to do without resorting to a subsystem of triggers and state functions?" I suppose one step in that direction would be to reduce dependence on triggers (at least) by using different values for the @mode attribute. Perhaps this would extend to reducing the number of state variables in general that I kept track of. To give a specific example question, consider a source with the following format: <items> <item id="31" value="3"/> <item id="21" value="1"/> .... </items> Each <item> element has an @id and an @value. There can be duplicates of both. An example question to answer is: "Given a set of @id values, an item is "special" if it has one of the @ids in this set AND it is the first such item with that particular @id. Find the subsequence of <items> lying between the first "special" item (if any) and the last special item (if any). For this subsequence, return various values like "how many total items are in the subsequence?" "How many 'special' items are in this subsequence?" "What is the average @value for all items in this subsequene? What is the average @value for the 'special' values? ... (I'm not asking anyone to publish a solution for the above... but I did think people might like to see a concrete problem for context.) On Thu, Apr 10, 2014 at 1:20 PM, David Carlisle <davidc@xxxxxxxxx> wrote: > On 10/04/2014 12:12, David Rudel wrote: >> >> Another method would be to use a recursive function on a sequence: > > > The new xsl:iterate and friends can be seen (at the definitional level) > as syntactic sugar for a recursive function. So at one level these are > equivalent but (especially if you plan to use the new streaming > features) I would guess (without looking at the source of an XSLT > system) that the xsl:iterate is much easier to optimise/stream as > identifying a specific xsl construct introduced for that purpose is > going to be "slightly easier" than analysing the structure of an > arbitrary user supplied recursive function to see if it amenable for > streaming or optimisation in any way. > > > > > David > -- "A false conclusion, once arrived at and widely accepted is not dislodged easily, and the less it is understood, the more tenaciously it is held." - Cantor's Law of Preservation of Ignorance.