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

[Jeni Tennison <jeni@xxxxxxxxxxxxxxxx>]

Joerg Pietschmann wrote:
> Is there a reason why we can't identify and pass functions by their
> QName? We could then write select ='map(xf:lower-case, $departments)'.
> This would circumvent the lexical problems. Probably this avoids
> having functions as data type in the data model, although their
> QNames de facto are used as such.

Function names are indistinguishable from element names, and the way
XPath works, expressions that form arguments to functions are
evaluated and their values passed to the function (the name of the
function makes no difference to how the argument expressions are
evaluated).

  map(xf:lower-case, $departments)

looks to me like "call the map function with the first argument being
the xf:lower-case child of the context node and the second argument
being the value of the $departments variable.

You could do:

  map('xf:lower-case', $departments)

but of course this will only work with functions (rather than any
expression), and only with functions whose sole argument was an item.

You could pass the extra arguments within a sequence (passed as the
third argument to the map() function) but because sequences are flat,
this would not enable you to pass sequences as arguments to the
relevant function.

Or you could use one additional argument per argument to the function
(though this is frowned on, it seems, in the F&O WD), but if some of
these arguments were sequences, it wouldn't be clear which of these
arguments should be mapped over, and which should just be passed
straight to the function.

More general would be:

  map('xf:lower-case(.)', $departments)

because then the expression (the first argument) could include other
kinds of expression, references to other variables and so on, or
perhaps:

  map('my:join($1, $2)', (1, 2), (3, 4))

to allow the map() function to do joins.

Unfortunately, this brings with it all the problems of a dynamic
evaluate() function. If we get evaluate(), then I think we should also
get a map() function that works in one of the above ways.

But without a map() function (or even with a map() function, given
that if dynamic evaluation can be avoided it should be), we're left
with two choices:

 - make functions into objects within the data model
 - define a map expression (rather than a map() function)

The XPath WD goes the second route with its for, exists and some
expressions. I put forward the simple mapping expression (I won't call
it an operator any more) as an alternative to the for expression, for
simple maps (ones that don't involve joins).

But as Dimitre's explained, if we just had functions as objects in the
data model we wouldn't be banging our heads against this - we could
have a map function no problems at all.

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/


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