Re: Variable references in path expressions

While many people does not like the idea of '/' to become a merely iterator.
But myself is on the opposite camp and like the idea very much. Because then
the semaintic of '/' is very clear.

If we introduce a 'foreach' expression under XQuery like in XSLT,
then 'expr1/expr2' would be equivelent to   'foreach expr1 return expr2'.
We can even have dual syntax.
Then '/' becomes an abbreviation, just like '//' is the abbreviation of
'/descendant-or-self::node()/'.

For those who want to keep path expression path like, they can use the
'foreach' syntax.
And for those who like to save a few keystrokes, '/' plays the trick.

Current WG's decision to allow atomic value only in latest step is the half
way between two sides,
which makes the '/' semantic very strange, and can cause a lot of confusion.

Personally I would strongly suggest either no atomic values to returned in
path expression or atomic values to returned in any step of the path.
The middle way is not a good choice.

----- Original Message ----- 
From: "Xavier Franc" <xfranc@online.fr>
To: <www-ql@w3.org>
Cc: "Michael Kay" <mhk@mhk.me.uk>
Sent: Thursday, April 28, 2005 3:37 AM
Subject: 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 Thursday, 28 April 2005 03:17:07 UTC