Re: [xsl] Re: . in for

Subject: Re: [xsl] Re: . in for
From: Jeni Tennison <jeni@xxxxxxxxxxxxxxxx>
Date: Sat, 5 Jan 2002 12:35:42 +0000
Hi Dimitre,

> Maybe something like this:
>
> ( (x, y) | x -> (1,2) | y -> (3,4) )

I think that you're introducing a new syntax here, with x and y being
stand-ins for range variables? I think that you intend it to be
equivalent to:

  for $x in (1, 2),
      $y in (3, 4)
  return ($x, $y)

Note that this uses "->" (the mapping operator that I suggested) in a
different way from the one I was advocating. For example, the example
I gave of:

  ancestor::* -> name()

would be:

  ( name(x) | x -> ancestor::* )

In the current XPath 2.0 WD syntax, this is:

  for $x in ancestor::* return name($x)
  
It would also prevent the nice 'piping' aspect of a mapping operator.
Rather than:

  $coordinates -> (. * 2)
               -> if (position() mod 2) then . + 50 else .

You would have, I think:

  ( if (position() mod 2) then a + 50 else a |
    a -> ( (b * 2) | b -> $coordinates )

In the current XPath 2.0 WD syntax, this is:

  for $b in $coordinates
  return for $a in $b * 2
         return if (position() mod 2) then $a + 50 else $a

[Actually, you can't use position() like that - I will have to the
xpath-comments list to point that out...]
    
If it's really important to support these kinds of operations, where
you generate every possible combination of the items from two
sequences, within a single XPath, then I think that the for expression
as it's currently defined is a reasonably good means to do it.

However, my argument is that in XPath these operations are very rarely
necessary, that even when they are in XSLT they are doable with
xsl:for-each or recursive templates, or in XQuery with a full FLWR
expression, and therefore that they are not appropriate use cases for
XPath and XPath should not attempt to support them.

Cheers,

Jeni

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


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


Current Thread