Re: [xsl] Preferred declarative approach for outputting tallies based on complex triggers

[David Rudel <fwqhgads@xxxxxxxxx>]

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.