This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
<quote> The %fn:updating annotation can also be used as an assertion on a FunctionTest to change the kind of function item matched by the test. If the %fn:updating assertion is specified on a FunctionTest, then it matches both simple function items and updating function items. Otherwise the FunctionTest only matches simple function items. </quote> I want to be able to test for all three of the following: * A non-updating function - perhaps %fn:non-updating? * An updating function - perhaps %fn:updating? * Any function, whether or not it is updating. You don't need updating assertions for this. The current syntax doesn't seem to meet that criteria.
I need to use cases for why you want to match only an updating function. After all, a simple function is just an updating function that happens to return an empty pending update list. I guess what I'm saying is that the only interesting case is "never returns a pending update list". If you disagree, I'd like to see motivational use cases so I can understand better.
(In reply to comment #1) > I need to use cases for why you want to match only an updating function. After > all, a simple function is just an updating function that happens to return an > empty pending update list. Not according to our own definitions: [Definition: A simple expression is any XQuery expression that is not an updating expression.] That definition is used in both XQuery Update Facility 1.0 and 3.0. I'm not sure we need use cases to say that %fn:updating should not match a function that is not an updating function. Especially since we use the annotation %fn:updating to say that a function is an updating function. Most users would expect the annotation assertion %fn:updating to match those functions that have the assertion %fn:updating. > I guess what I'm saying is that the only interesting case is "never returns a > pending update list". If you disagree, I'd like to see motivational use cases > so I can understand better. If the only interesting case is "never returns a pending update list", then perhaps we only need the annotation assertion %fn:non-updating. That name is a lot less surprising to me. But I can imagine scenarios in which updating functions would be handled differently, e.g. they might require some form of authentication before they are allowed, or they may fail gracefully. We currently define functions like fn:doc-available() so users can write code to handle the case in which fn:doc() will fail - similar kinds of code might be useful if passing an updating function as a parameter to another function would fail.
In today's meeting, we agreed to allow these three possibilities: %updating("allowed") %updating("prohibited") %updating("required") e.g. declare function local:foo($x as %updating("allowed") function()) { }; declare function local:foo($x as %updating("prohibited") function()) { }; %updating("allowed") means the same thing as the current %updating function assertion. (Note that we need to change the term to "function assertion" in the update spec.) The meaning of "prohibited" and "required" is obvious, matching only if the function is non-updating or updating respectively.