21963 2013-05-08 07:57:19 +0000 Implicit iteration on dynamic function calls 2015-01-05 14:32:15 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XPath 3.1 Working drafts PC All CLOSED WONTFIX P2 normal --- 1 g jonathan.robie mike tim public-qt-comments oldest_to_newest 87409 0 g 2013-05-08 07:57:19 +0000 Last year, it was briefly discussed on the ML whether to support dynamic function calls on sequences of functions (with an implicit iteration). https://lists.w3.org/Archives/Member/w3c-xsl-query/2012Sep/0005.html Zorba does support this, on the grounds that it would be consistent with an XPath-like navigation on maps (3.1). Having the same behaviour (i) for both functions and maps/objects and (ii) for both 3.0 and 3.1 would simplify the implementation. It would be nice if we could discuss relaxing this in a call, if it is not too disruptive for the CR period? 87412 1 mike 2013-05-08 08:37:37 +0000 What is "the ML"? 87415 2 g 2013-05-08 11:38:59 +0000 The Mailing List :-) I should be more parsimonious with abbreviations. 105856 3 jonathan.robie 2014-05-13 14:59:42 +0000 I like this. It's a little tricky to fit into the current structure of the spec, and I'd like to avoid restructuring this part. My first thought is to do something along these lines: 3.1.5.1 Evaluating Static and Dynamic Function Calls 2.b. <old> If FC is a dynamic function call: FC's base expression is evaluated with respect to SC and DC. If this yields a sequence consisting of a single function with the same arity as the arity of the ArgumentList, let F denote that function. Otherwise, a type error is raised [err:XPTY0004]. </old> <new> If FC is a dynamic function call: FC's base expression is evaluated with respect to SC and DC. If this yields a sequence consisting of a single function with the same arity as the arity of the ArgumentList, let F denote that function. <add>If it yields a sequence of functions with the same arity as the arity of the ArgumentList, let F denote each of these functions in turn, in the order of the sequence. Otherwise, a type error is raised [err:XPTY0004]. </new> 106456 4 mike 2014-05-20 16:13:25 +0000 I'm against doing this. I think the main use case is for selection from an array of maps. This can be done using the "?" operator: employees[?location='Germany']?surname. An argument against is as follows: Suppose we have a map of functions (XDM's equivalent of an object); so for example $complex?multiply($c1, $c2) selects the multiply function on complex numbers. The effect of this proposal would be that if you misspell "multiply", the "?" selector selects no function and you get an empty sequence back rather than an error. 106843 5 jonathan.robie 2014-05-27 14:59:13 +0000 I agree that the main use case is selection from a sequence of maps (it also applies to arrays). A sequence of maps can occur because: * The result of a query on JSON is a sequence of maps * FLWOR expressions create sequences of maps * Maps occur in a collection * A view of relational or object data creates sequences of maps Consider the following example: let $maps := ( { "a" : 1 }, { "b" : 2 }, { "c" : 3 } ) return $maps("b") Currently, that raises an error. This does not: let $maps := ( { "a" : 1 }, { "b" : 2 }, { "c" : 3 } ) return $maps?b We currently have two syntaxes that mostly do the same thing, one iterates but can never support all keys, the other supports all keys but does not iterate. That makes the language confusing. 106904 6 g 2014-05-28 09:36:51 +0000 Hi, I agree with Jonathan's assessment. I think that resilience in case of heterogeneity in the input sequence is important (i.e., return an empty sequence rather than raise an error), and follows the XPath paradigm as well. I also think that consistency between function calls and the ? syntax would be nice. This is of course the view from a database/document-store perspective. I am afraid that this is another example where the use case scenario affects the design decision: if we reason data-oriented (NoSQL), then iterating makes sense (even with functions in the data). If we reason pure map-oriented (i.e., equivalent of objects as Mike mentions), then raising an error makes sense. I hope it helps. Kind regards, Ghislain 107111 7 tim 2014-06-02 06:19:57 +0000 Could the syntax $maps?b be extended to allow $maps?{ Expr } (a bit like element constructors). 107113 8 mike 2014-06-02 07:36:28 +0000 The syntax already allows $maps?(Expr) 107169 9 jonathan.robie 2014-06-03 00:22:18 +0000 Brief history of this issue. * JSONiq has always done iteration on sequences of maps using function call syntax. * Iteration for the "?" operator was one of the variants in https://lists.w3.org/Archives/Member/w3c-xsl-query/2014Feb/0112.html * We decided to adopt iteration for the "?" operator in meeting #564 https://lists.w3.org/Archives/Member/w3c-xsl-query/2014Mar/0020.html * That decision is reflected in the First Public Working Draft. 107945 10 jonathan.robie 2014-06-17 15:52:08 +0000 At this point, I'm inclined to think we do not need this if we extend the ? operator to both maps and arrays, as in this proposal: https://lists.w3.org/Archives/Member/w3c-xsl-query/2014Jun/0022.html (member only) Or possibly this proposal, which does not use that character: https://lists.w3.org/Archives/Member/w3c-xsl-query/2014Jun/0010.html 116788 11 g 2015-01-05 14:32:15 +0000 I agree with the WG decision that having ? do this addresses the issue at hand. Thanks!