RE: Re: Variable references in path expressions

IF you want the working group to finish, I strongly recommend that we
stop asking for new functionality for XQuery 1.0/XPath 2.0 (you can
always ask for it for the next version).

Best regards
Michael

> -----Original Message-----
> From: www-ql-request@w3.org [mailto:www-ql-request@w3.org] On Behalf
Of
> Michael Kay
> Sent: Wednesday, April 27, 2005 1:03 AM
> To: 'Henry Luo'; www-ql@w3.org
> Subject: RE: Re: Variable references in path expressions
> 
> 
> > 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 16:30:46 UTC