1249 2005-04-14 17:26:45 +0000 [XQuery] Is it too restrictive to only allow last path step to return atomic values? 2005-04-18 15:40:57 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XQuery 1.0 Last Call drafts All Windows 2000 CLOSED WORKSFORME P2 normal --- 1 henryluo chamberl public-qt-comments oldest_to_newest 3746 0 henryluo 2005-04-14 17:26:45 +0000 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. 3747 1 mrys 2005-04-14 18:10:56 +0000 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. 3752 2 mike 2005-04-14 20:23:34 +0000 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 3754 3 henryluo 2005-04-14 20:47:01 +0000 Thanks Michael, for the detailed explaination. I can accept your answer.