This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
UpdatingFunctionCall is defined in Update Facility 3.0 as: [207] UpdatingFunctionCall ::= "invoke" "updating" PrimaryExpr "(" (ExprSingle ("," ExprSingle)*)? ")" However, PrimaryExpr contains FunctionCall. This means that for: invoke updating test() 'test()' will be interpreted as FunctionCall. That is: UpdatingFunctionCall: 'invoke updating' PrimaryExpr/FunctionCall: 'test()' [error]: missing token '(' It also does not make sense for this to be an OrderedExpr or Constructor (which are valid according to the grammar). It would make more sense to define this similar to the XQuery 3.1 ArrowFunctionSpecifier: [127] ArrowFunctionSpecifier ::= EQName | VarRef | ParenthesizedExpr For example: UpdatingFunctionCall ::= "invoke" "updating" UpdatingFunctionCallSpecifier "(" (ExprSingle ("," ExprSingle)*)? ")" UpdatingFunctionCallSpecifier ::= EQName | VarRef | ParenthesizedExpr
(In reply to Reece H. Dunn from comment #0) > UpdatingFunctionCall is defined in Update Facility 3.0 as: > > [207] UpdatingFunctionCall ::= "invoke" "updating" PrimaryExpr "(" > (ExprSingle ("," ExprSingle)*)? ")" > > However, PrimaryExpr contains FunctionCall. This means that for: > > invoke updating test() > > 'test()' will be interpreted as FunctionCall. That is: > > UpdatingFunctionCall: 'invoke updating' > PrimaryExpr/FunctionCall: 'test()' > [error]: missing token '(' Yes, that looks like the correct behaviour to me. What do you think is ambiguous? > It also does not make sense for this to be an OrderedExpr or Constructor > (which are valid according to the grammar). (Note to others: "this" = "the PrimaryExpr of an UpdatingFunctionCall".) E.g., if you used a Constructor there, you'd get a type error. But it's not the grammar's job to only derive type-safe queries. > It would make more sense to define this similar to the XQuery 3.1 > ArrowFunctionSpecifier: > > [127] ArrowFunctionSpecifier ::= EQName | VarRef | ParenthesizedExpr > > For example: > > UpdatingFunctionCall ::= "invoke" "updating" > UpdatingFunctionCallSpecifier "(" (ExprSingle ("," ExprSingle)*)? ")" > UpdatingFunctionCallSpecifier ::= EQName | VarRef | ParenthesizedExpr It's possible that might make more sense to some people. But note that UpdatingFunctionCall is fairly explicitly modelled after XQuery's DynamicFunctionCall, which also uses a PrimaryExpr to specify the function to be invoked.
(In reply to Michael Dyck from comment #1) > (In reply to Reece H. Dunn from comment #0) > > It would make more sense to define this similar to the XQuery 3.1 > > ArrowFunctionSpecifier: > > > > [127] ArrowFunctionSpecifier ::= EQName | VarRef | ParenthesizedExpr > > > > For example: > > > > UpdatingFunctionCall ::= "invoke" "updating" > > UpdatingFunctionCallSpecifier "(" (ExprSingle ("," ExprSingle)*)? ")" > > UpdatingFunctionCallSpecifier ::= EQName | VarRef | ParenthesizedExpr > > It's possible that might make more sense to some people. But note that > UpdatingFunctionCall is fairly explicitly modelled after XQuery's > DynamicFunctionCall, which also uses a PrimaryExpr to specify the function > to be invoked. Thanks for the clarification. I was thinking of things like: invoke updating fn:put(...) However, if I understand correctly, the 'invoke updating' here is not needed as fn:put has the updating annotation (and any other updating function). Likewise, it would be an error to use `$f(...)` if `$f` references an updating function -- 'invoke updating' should be used here -- and `invoke updating $f(...)` would be an error if `$f` does not reference an updating function.
(In reply to Reece H. Dunn from comment #2) > > Thanks for the clarification. I was thinking of things like: > > invoke updating fn:put(...) > > However, if I understand correctly, the 'invoke updating' here is not needed > as fn:put has the updating annotation (and any other updating function). Right, a FunctionCall can reference a simple function or updating function, making it a simple expression or updating expression respectively. > Likewise, it would be an error to use `$f(...)` if `$f` references an > updating function -- 'invoke updating' should be used here -- That true if none of the args is "?": "If the function returned by the PrimaryExpr [of a dynamic function invocation] is an updating function, and the dynamic function invocation is not a partial function application, a dynamic error is raised [err:XUDY0038]." > and `invoke updating $f(...)` would be an error if `$f` does not > reference an updating function. No, a dynamic updating function call "can invoke either an updating function or a simple function".
The Working Group decided today to close this bug as "Works For Me". Please reopen if there are unresolved matters.