Hi Dimitre,

> > Absolutely. I suggested a simple mapping operator as a replacement
> > for the more complex for expression that is currently defined in
> > XPath 2.0. I fully recognise the fact that a simple mapping
> > operator gains in simplicity, but loses in completeness - it cannot
> > achieve everything that the for expression can achieve (it can't do
> > joins). I'm sure that you're right that it also cannot achieve
> > everything that a full mapping operator would achieve (perhaps you
> > can give some examples?).
> 
>  Anything that cannot be achieved by a single XPath expression, but
>  can be produced by a template.

Right, so the comment that a simple mapping operator as I suggested
isn't a full mapping operator also applies to the for expression (and
indeed any expression in XPath), since XPath can only do the things
that XPath can do.

>  I hope even in XPath 2.0 / XSLT 2.0 this set is still non-empty?

It depends on whether you view calls to extension functions as being
part of XPath 2.0 or not. You can call/apply templates within
extension functions written in XSLT, so you can construct expressions
that work just like calls to/applying templates.

[snip great explanation of how the functions involved in a functional
composition must be written to take into account the fact they are
part of that composition when working on sequences.]

> > My second question is, whether the above issue is manageable or
> > not, whether implementations could be clever enough to spot where
> > the use of simple mapping operators is equivalent to functional
> > composition, in order to optimise these expressions? Perhaps an
> > implementation could recognise that given:
> > 
> >   $coordinates -> (. * 2)
> >                -> if (position() mod 2) then . + 50 else .
> > 
> > it could compose the two steps on the right hand side of the first
> > -> into a single operation, and use that to give added efficiency?
> 
>  In the general case if an XSLT processor optimizes your previous
>  example, replacing it by a single map with the composition of the
>  expressions, it will yield the wrong result as your detailed example
>  above shows.
> 
>  Anyway, if one designs his algorithm having the single mapping in
>  mind, such an error will not occur -- it only happens when trying to
>  mechanically convert a composition of map-s into a single map, and
>  only if the mapping functions depend on the cardinality of their
>  inputs.
> 
>  A more correct answer is that a function like position() must not be
>  allowed as an argument of a map function/operator. By definition,
>  such a function must have as its ***single*** input only an item of
>  the sequence. position() goes beyond the single item and actually
>  uses the whole sequence as its input.

I see your point about position(). This kinda ties into one of the
points that came out of my reply to Mike's comment about being able to
call user-defined functions from within for expressions, where I
compared:

  <xsl:for-each select="row"> 
    <row num="{position()}"> ...</row>
  </xsl:for-each> 

to:

  <xsl:copy-of
    select="for $i in (1 to count($rows))
            return my:create-row($rows[$i], $i)" /> 

with:

<xsl:function name="my:create-row"> 
  <xsl:param name="row" type="element row" /> 
  <xsl:param name="position" type="xs:integer" /> 
  <xsl:result> 
    <row num="{$position}"> ...</row>
  </xsl:result> 
</xsl:function> 

This illustrates how the value returned by the position() function has
to be replaced by an explicit counter; the same thing goes for the
other information provided by the evaluation context at the point the
function is called - the context size, dynamic variables and so on.
Pure functions only know what they're passed.

Note that replacing the position() function with an explicit counter
means that the $rows sequence has to be traversed several times - once
to count how many items there are in it, and then once for each item
in the $rows sequence in order to retrieve the relevant item for the
function call.

I think that this is likely to be quite inefficient compared to a
single traversal of the $rows sequence, as in xsl:for-each, where
counters are supported by the position() function. So I think that
banning the position() function would be a mistake.

I imagine that a processor would be able to spot situations where the
position() or last() function had been called and only compose the
steps that were composable.
  
> > Fortunately, with the simple mapping operator this works, because
> > in XPath 2.0 individual values are treated exactly the same as
> > single-item sequences.
> 
>  Where did you read it? I read in 2.1.2 (Type conversions) the
>  following:
> 
>  "1. If the required type is anything other than a simple type or a
>  single node, an error is raised."

The second paragraph of Section 6 of the data model WD
(http://www.w3.org/TR/query-datamodel/#sequences) reads:

  "An important characteristic of the data model is that there is no
   distinction between an item (i.e., a node or a simple typed value)
   and a singleton sequence containing that item, i.e., an item is
   equivalent to a singleton sequence containing that item and vice
   versa."

> > I *think* that if you view the series of operations on the right
> > hand side of the simple mapping operator as being functionally
> > composed, then you have the functional composition operator that
> > you're looking for?
> 
>  If it is allowed to perform on a single item a function defined on a
>  sequence, then yes -- because the mapping operator as defined by you
>  is just a functional composition of map-s and a map will (if the
>  assumption that this is allowed is right) operate on a simple value
>  or a node exactly like its argument-function.

Cool :)

Cheers,

Jeni

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


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