RE: mapping (Was: Re: Re: . in for)

> J.Pietschmann wrote:
> We could then write select ='map(xf:lower-case, $departments)'.

Well, there is a major problem: the function must take exactly
one parameter. If hou have a my:grumbulate function which takes
two parameters and you want tor grumbulate a sequence, you'll have
to write a projection function first. While this is already a
significant inconvenience, it gets worse if say the second parameter
is not a constant value:

 <xsl:template match="stuff">
   <xsl:parameter name="grumbulation-value"/>
   <xsl:copy-of select="map(my:grumbulation-projektor,stuff-childs)"/>
 </xsl:template>

How to pass the grumbulation-value? Two possible solutions:
- Local function definitions:
 <xsl:template match="stuff">
   <xsl:parameter name="grumbulation-value"/>
   <xsl:function name="my:grumbulation-projektor">
      <xsl:param name="arg"/>
      <xsl:item select="my:grumbulation($arg,$grumbulation-value)"/>
   </xsl:function>
   <xsl:copy-of select="map(my:grumbulation-projektor,stuff-children)"/>
 </xsl:template>
- Dynamically scoped variables

I don't like either very much.

Another possibility is having map() take a variable number of arguments,
the first is the function, all following sequences which supply the
parameters in parallel (like in most LISP variants)
 select="map(my:grumbulation,stuff-children,my:build-sequence($grumbulation-value,count(stuff-children)))"

Specifying the exact behaviour of the map function, especially for
the cases of having sequences of different length supplied, is tedious
but it should be possible to lift it almost literally from some LISP
specification.

Oh no, i just saw the problem with using QNames for passing functions:
they are already XPath expressions for accessing nodes :-/
Let's have a function for converting Strings which are actually QNames
of functions to function objects, like the well known LISP 'function
(I mean as in (mapcar (function cdr) list) ).
This means writing
 select="map(xf:funref('my:grumbulation'),$departments)"
The argument of such a generic function object constructor could be made
a literal for the sake of optimizations. I think however some people will
consider the standard crippled if they can't read their function names
from the source XML :-)

Regards
J.Pietschmann

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