[xsl] Re: Re: mapping (Was: Re: Re: . in for)

Subject: [xsl] Re: Re: mapping (Was: Re: Re: . in for)
From: Dimitre Novatchev <dnovatchev@xxxxxxxxx>
Date: Mon, 14 Jan 2002 10:09:22 -0800 (PST)
Joerg Pietschmann <joerg dot pietschmann at zkb dot ch> wrote: 
> Dimitre Novatchev <dnovatchev@xxxxxxxxx> wrote
> > > 3. Higher order functions. I'm walking on thin ice here but i
> > >  believe this requires the possibility to compose lambda expressions
> > Wrong.
> 
> Thank you for the correction, as you and others pointed out i was
> seriously confused here. 
> 
> Now when you introduced your functional programming techniques you
> used it in conjunction with the term "generic template", which got
> stuck. Let me repeat the essentials of this technique from my point
> of view here, so we may discuss differences later:

Generally you got it right, there are only small things to point out:

> 
>    <xsl:stylesheet version="1.0"
>       xmlns:xsl="http://www.w3.org/1999/XSL/Transform";;
>       xmlna:fp="some.uri.for.private.use">

Here I use absolute uri -- something like "f:myFunction".

> 
>      <!-- Artificial element used to refer to a function -->

This is not artificial -- this is ***the*** template reference.  

>      <fp:ref-to-myfunc/>
> 
>      <!-- The function "myfunc", implemented as template -->

It is more exact to say that this is the code of the function, the function is
completely defined by the context of the template reference. This is the way to
create new functions dynamically.

>      <xsl:template match="fp:ref-to-myfunc">

It is more compact to use:
      <xsl:template match="fp:*">


>        ...
>      </xsl:template>
> 
>      <!-- The "generic template" which takes a function
>         reference as parameter -->
>      <xsl:template name="some-framework-template">
>        <xsl:param name="funcref"/>
>

This one is more serious -- the template reference is a node(set) and this must be
reflected in the definition of the parameter. Therefore:

        <xsl:param name="funcref" select="/.." />


        ...
>        <!-- invoke the function passed as parameter -->
>        <xsl:apply-template select="$funcref"/>
>        ...
>      </xsl:template>
> 
>      <!-- Random sample template ... -->
>      <!xsl:template match="stuff">
>       ...
>        <!-- ... for demonstrating how to call the "generic
>          template", passing a specific function as parameter -->
>        <xsl:call-template name="some-framework-template">
>          <xsl:with-param name="funcref"
>              select="document('')/*/fp:ref-to-myfunc/>

It is better and more reliable to have it like this:

              select="document('')/*/fp:*[1]" />

Because you may have (by mistake) more than one fp:* or fp:ref-to-myfunc node.


>        </xsl:call-template>
>        ...
>      </xsl:template>
>      ...
>   <xsl:stylesheet>
> Am i on the right track (perhaps apart from nomenclature)? I know
> that the mechanism for invocation could be varied somewhat.
> 

Yes, with the above small adjustments.

> The usual use case is that the "generic template" implements
> some algorithm, often in a recursive form. You presented
> sorting, summation+running totals for orders and some other
> stuff; it could also be used for example for numeric integration.

It is actually used, but please, just wait for a few more days. An article
containing these is due to be published in the next few days.

I have a library of more than 40 very general and useful list-processing,
tree-processing, function-processing etc. functions, implemented in XSLT 1.0.
Actually they are the Haskell Prelude (list-processing + some other useful)
functions, implemented in XSLT.

> Actually this shows that functional programming on the XSLT
> level is already reality in XSLT 1.0 to some extend (with the
> caveat that for functions returning function references,
> the xx:node-set() extension function is necessary; is this
> correct?).

Yes.

> 
> The interesting point is now: how could we profit from functional
> programming elements on the XPath level? Your generic sort template
> is probably a good candidate. Most of the generic solutions for
> iterating over a node set are probably covered by other new standard
> stuff, so they're not as convincing as they used to be.

There's a big area for improvement in XPath 2.0 (some areas were pointed out to me
by Jeni and David) and I've prepared a rough draft of a document on this. I hope to
be able to bring it to satisfactory form during this week and I'll post it here.

> 
> For others: Unless i'm mistaken there is still no easy way to sort
> order positions by price*quantity (or price*key('exchange-rate',currency))
> in XSLT 2.0, so the generic sort template is still useful.   
> 
> > And to say that the "FP stuff" is not usable means not to understand what FP
> > is.
> It was meant in the sense that for many people "more compact" is
> also "more usable". Imagine you could pass an expression as parameter
> to your generic sort template without having to encapsulate it in a
> template first.

You miss the real case here -- 99% of these functions are part of a de-facto
standard library, people will mostly use them and much more rarely write their own.

In case you had nothing and had to write everything from scratch, then yes, you'd be
right. When you have a library of the most needed and useful building blocks, then
usability is factors of magnitude higher.

Sometimes I'm writing new templates (by re-using the ones in the library) just in
two minutes, when otherwise it could be more like half to one hour. Although I know
that this should be so, I cannot stop feeling amazed what a big difference it makes.

Cheers,
Dimitre Novatchev.


__________________________________________________
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/

 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Current Thread