This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 1249 - [XQuery] Is it too restrictive to only allow last path step to return atomic values?
Summary: [XQuery] Is it too restrictive to only allow last path step to return atomic ...
Status: CLOSED WORKSFORME
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XQuery 1.0 (show other bugs)
Version: Last Call drafts
Hardware: All Windows 2000
: P2 normal
Target Milestone: ---
Assignee: Don Chamberlin
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-04-14 17:26 UTC by Henry Luo
Modified: 2005-04-18 15:40 UTC (History)
0 users

See Also:


Attachments

Description Henry Luo 2005-04-14 17:26:45 UTC
Under Section 3.2 Path Expressions,

There's a Note specifying that:
Since each step in a path provides context nodes for the following step, in 
effect, only the last step in a path is allowed to return a sequence of atomic 
values.

Is it too restrictive to only allow atomic values returned in last step?
It might be enough just require that Axis Steps preceed Filter Steps.

So that several steps of atomic value sequences can be used to create useful 
value sequences.
For example, (1, 2)/(.+1, .+2)/(.*2, .*3) gives a result sequence of
(4,6,6,8,6,9,9,12).
It'll be more tedious to write that in for expressions.
Comment 1 Michael Rys 2005-04-14 18:10:56 UTC
We have had many discussions on this topic. The semantics of / does duplicate 
node elimination and document ordering, which is probably not what you want 
for atomic values. Since XQuery allows heterogeneous sequences of values and 
nodes, the question becomes what the semantics should be. The WG felt that 
this was not needed in v1 and I personally do not see a reason to revisit this 
if we want to ship XQuery in time.
Comment 2 Michael Kay 2005-04-14 20:23:34 UTC
As Michael Rys responded, the WGs spent a lot of time on this issue. A number of
people felt that there was a need for a "simple mapping operator" equivalent to

for . in SEQ1 return SEQ2

One syntax that was proposed was SEQ1!SEQ2. Overloading "/" to perform this
function is difficult because of the rule that "/" causes nodes to be delivered
in document order with duplicates eliminated. Allowing atomic values on the left
would also have the effect that the value of 10/5 is 5, which some WG members
found abhorrent. Hence the suggestion to use a different operator; but others
thought the very subtle distinction between the two operators would be too
confusing, and in any case, the new operator would offer insufficient usability
benefit over writing "for $x in S1 return S2($x)". The decision to allow atomic
values on the right of "/" while still requiring nodes on the left is something
of a compromise but it happened to be the solution that got the most support.

Michael Kay
Comment 3 Henry Luo 2005-04-14 20:47:01 UTC
Thanks Michael, for the detailed explaination.
I can accept your answer.