W3C home > Mailing lists > Public > www-ql@w3.org > April to June 2005

RE: Re: Variable references in path expressions

From: Michael Kay <mhk@mhk.me.uk>
Date: Wed, 27 Apr 2005 09:02:45 +0100
To: "'Henry Luo'" <henryluo@vibrasoft.net>, <www-ql@w3.org>
Message-ID: <E1DQhVu-0004rS-VJ@lisa.w3.org>

> 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
Received on Wednesday, 27 April 2005 08:03:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:43:44 UTC