[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

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

Subject: Re: mapping (Was: Re: Re: . in for)
From: Jeni Tennison <jeni@xxxxxxxxxxxxxxxx>
Date: Wed, 9 Jan 2002 13:56:23 +0000
tennison map
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

  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

  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.



Jeni Tennison

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

Current Thread


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.