Re: [xsl] Enabling extension to counting of instances

[Dimitre Novatchev <dnovatchev@xxxxxxxxx>]

On Fri, Jan 8, 2010 at 10:00 AM, Eliot Kimber <ekimber@xxxxxxxxxxxx> wrote:
> I'm not sure how this satisfies my requirement for abitrary included XSLT
> modules to contribute to the filter function, but it's possible I'm not
> fully understanding the processing implications here since there's a bit of
> indirection.


f:filter() takes two arguments: a sequence and a predicate (actually a
node, matched by a template that produces a boolean  :)   )

f:filter(1 to 10, f:compose(f:not(),
                                    f:flip(f:mod(),2)
                                   )
         )


takes the sequence 1 to 10  (the integers 1,2,...,9,10)

and a function that is the composition of:
      1. getting the evenness of something (returns 0 if even, odd otherwise)

      2. the not() function

So, this composition is applied on any of the numbers 1 to 10 and a
sequence is returned that contains only these numbers, for which it:

                    f:compose(f:not(),
                                    f:flip(f:mod(),2)
                                   )

evaluates to true()

Here we also use the fact that boolean(0) is false() and boolean(1) is true.

So, the 2nd argument of f:compose above is first evaluated and it
returns 0 for an even number and 1 for an odd number.

Then, f:compose() applies the function not() to the result:

not(0) is true(), not(1) is false.

this means that the final result is true() for any even number in the
sequence. f:filter() returns a sequence of only those items of its 1st
argument, for which the result of applying the predicate (the 2nd
argument) is true(). As explained, this sequence will contain only the
even numbers.

This is just one example, showing that f:filter() is a general
function that can be used with any sequence that we want to filter and
with any predicate we pass to be used for the filtering.

In the case of the original problem, f:filter() will be passed a
sequence of elements and a predicate, which decides for any element if
it is a "chapter" or not.

On every call to f:filter() the sequence of elements and the predicate
can be completely different and we don't know and don't care what
these might be (and actually, it is impossible to anticipate any such
pair of arguments that someone in the future may find to be
"meaningful").


This is the power of any Higher Order Function (HOF) -- it can use any
function-parameters without knowing their "meaning" as far as these
parameters are of the specified type (are functions with a
pre-specified signature). Thus HOFs are broadly applicable in huge,
unknown in advance problem areas.


--
Cheers,
Dimitre Novatchev
---------------------------------------
Truly great madness cannot be achieved without significant intelligence.
---------------------------------------
To invent, you need a good imagination and a pile of junk
-------------------------------------
Never fight an inanimate object
-------------------------------------
You've achieved success in your field when you don't know whether what
you're doing is work or play
-------------------------------------
I enjoy the massacre of ads. This sentence will slaughter ads without
a messy bloodbath.




>
> Cheers,
>
> E.
>
> On 1/8/10 11:40 AM, "Dimitre Novatchev" <dnovatchev@xxxxxxxxx> wrote:
>
>> Here is the filter() function of FXSL (written around 2003/2004):
>>
>> <xsl:stylesheet version="2.0"
>> xmlns:xsl="http://www.w3.org/1999/XSL/Transform";
>> xmlns:xs="http://www.w3.org/2001/XMLSchema";
>> xmlns:f="http://fxsl.sf.net/";
>> exclude-result-prefixes="f xs"
>>>
>>
>> B  <xsl:import href="func-apply.xsl"/>
>>
>> B  <xsl:function name="f:filter" as="item()*">
>> B  B  <xsl:param name="pList" B as="item()*"/>
>> B  B  <xsl:param name="pController" as="element()"/>
>>
>> B  B  <xsl:sequence select="$pList[f:apply($pController, .)]"/>
>> B  </xsl:function>
>> </xsl:stylesheet>
>>
>> the $pController is a "template reference". When it is applied to an
>> item of the sequense $pList, it returns true() or false(), using
>> whatever logic is needed for that and we (f:filter() ) don't care and
>> don't know / cannot anticipate that.
>>
>>
>> Here is a simple example (testFunc-filter.xsl in the distribution of
>> FXSL 2.x) using f:filter():
>>
>> <xsl:stylesheet version="2.0"
>> xmlns:xsl="http://www.w3.org/1999/XSL/Transform";
>> xmlns:f="http://fxsl.sf.net/";
>> exclude-result-prefixes="f"
>>>
>>
>> B  <xsl:import href="../f/func-filter.xsl"/>
>> B  <xsl:import href="../f/func-Operators.xsl"/>
>> B  <xsl:import href="../f/func-standardXpathFunctions.xsl"/>
>> B  <xsl:import href="../f/func-flip.xsl"/>
>> B  <xsl:import href="../f/func-compose.xsl"/>
>>
>> B  <!--
>>
>> B  B  B  B Expected result:
>> B  B  B  B  B  B  B  B Filtering by IsEven:
>> B  B  B  2 4 6 8 10
>>
>> -->
>>
>> B  <xsl:output indent="yes" omit-xml-declaration="yes"/>
>>
>> B  <xsl:template match="/">
>> B  B  Filtering by IsEven:
>>
>>
>> B  B  <xsl:sequence select="f:filter(1 to 10, f:compose(f:not(),
>> f:flip(f:mod(),2)))"/>
>> B  </xsl:template>
>> </xsl:stylesheet>
>>
>>
>> When the above transformation is applied (on any source xml -- not
>> used) the expected result is produced:
>>
>> "
>> B  B  Filtering by IsEven:
>>
>>
>> B  B  2 4 6 8 10
>> "
>
> --
> Eliot Kimber
> Senior Solutions Architect
> "Bringing Strategy, Content, and Technology Together"
> Main: 610.631.6770
> www.reallysi.com
> www.rsuitecms.com