Re: Variable references in path expressions

I personally strongly disagree with the idea of diverting Path expressions
from their original purpose:

"A *path expression* can be used to locate nodes within trees..."

I can't understand why the WG has allowed the last step to produce
atomic values, a new functionality which is in my opinion useless,
while constantly rejecting much more useful new functionalities under
the pretext that otherwise they will never be able to finish the standard...

Correct me if I am wrong, but an expression like

(1, 2, 3)/(1, 2, 3)

can as well be written with FLWR expressions:

for $i in (1, 2, 3) return (1, 2, 3)

or:

for $i in (1, 2, 3), $j in (1, 2, 3) return $j

which is more clear and as powerful.

More generally, an expression like
  /path/atomic-expression/

can be rewritten as:
 for $x in /path/ return /atomic-expression/

where '.' in atomic-expression is replaced by the iteration variable 
(here $x).




Michael Kay wrote:

>>Latest working draft of XQuery Section 3.2, does not allow 
>>atomic values to
>>be returned in the path except the last step.
>>That is expression like   (1, 2, 3)/(1, 2, 3) is not allowed.
>>I've asked this question, and the reason given by the WG is 
>>that someone found 10/5 giving 5 is useless.
>>    
>>
>
>That's not actually what I said: we allow many useless expressions, such as
>$a/$b; the objection to this one was not that it was useless, rather that it
>was confusing, because the use of "/" to mean division is so firmly rooted
>in people's minds. Also, it wasn't a reason given by the WG: it was my
>interpretation of views I have heard in the WG (you can make a technical
>decision by taking a vote; agreeing a party line on why you made the
>decision is another matter entirely). 
>
>However, we now allow @price/2 to return 2, so in my personal view, allowing
>1/2 to also return 2 isn't such a big deal.
>
>I personally wanted to use a different operator than "/" for mapping
>sequences of atomic values, but now that we allow a sequence of atomic
>values on the right of "/", I personally think it would make sense also to
>allow a sequence of atomic values on the left. If we're going to allow
>*/name() and */string-length() then we might as well also allow
>*/name()/string-length(). The semantics are perfectly well-defined - it just
>requires that (a) both operands must be homogenous sequences, and (b)
>reordering and deduplication occurs only if the rh operand is a sequence of
>nodes. It will allow some programming idioms which will look strange at
>first, such as (1 to 5)/$x[.] to select the first 5 items in $x, but strange
>programming idioms are nothing new in XPath.
>
>I would suggest you raise this as a last-call comment on the spec. There
>will probably be a reaction from the working group of "no new
>functionality", but in my view there's a strong argument based on the fact
>that it is simply removing a restriction from the language that can't be
>justified. And it's not a new comment - there have been calls for a "simple
>mapping operator" for years.
>
>Michael Kay
>http://www.saxonica.com/
>
>
>
>
>
>  
>

Received on Wednesday, 27 April 2005 19:39:02 UTC