This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
3.1.6 Literal Function Items says: "The static context for evaluation of the function item [created by a literal function item expression] is inherited from the location of the literal function item expression..." First, it's incorrect to talk about "the evaluation of a function item", because a function item is already a value. Instead, you can *invoke* a function item, which then typically involves evaluation of the expression that is the function item's implementation. So, assuming that it's the latter expression whose static context is the subject of the quoted sentence, I believe the statement is incorrect. Consider: declare variable $v as xs:integer := 7; declare function f() { $v+1 }; let $v as xs:string := "foo" let $fi := f#1 return $fi() I think the result should be 8, but I think the quoted statement says that the result is a type error. At the location of the literal function item expression f#1, the static context says variable $v is of type xs:string. If you try to evaluate the function body $v+1 in such a context, you'll get a type error. (Or perhaps the result is undefined, if the value for $v is inconsistent with xs:string.) To fix, I think we should simply delete the quoted sentence. (The new function item's implementation is that of the referenced function, and that implementation's static context [if it has one] is whatever it is.) The sentence goes on to point out that the static type of the context item is initially undefined. This is worth saying, but not here. Instead, it belongs where function bodies are introduced: 3.1.7 "Inline Functions" already says it; 4.18 "Function Declarations" should add it.
I think the quoted text is trying to understand what the behaviour of static-base-uri#0 is supposed to be, as well as (for instance) the static context available to an external function - or anything else that might access the static context, without itself being defined in a module.
(Oops, I should have said f#0, not f#1.)
(I changed the Component to XPath 3.0 because this bug affects XPath as well as XQuery.)
We have decided to resolve this by not allowing function items to refer to context-dependent built-in functions. Function items can refer to context-independent built-in functions, but not context-independent built-in functions. You can create an inline function to wrap a context-dependent built-in function. We will add a note, in the STATUS section, saying that we are considering removing this restriction for some or all context-dependent functions after the Last Call period.
Note that the decision described in comment #4 doesn't directly address the original issue (the example in comment #0 doesn't involve built-in functions); rather, it addresses the question that (John Snelson thought) the original text was meant to answer. That is, I believe comment #4 describes a *replacement* for the sentence I quoted in comment #0. If that's the case, then it does provide a fix for this issue.
(In reply to comment #5) > I believe comment #4 describes a *replacement* > for the sentence I quoted in comment #0. If that's the case, then it does > provide a fix for this issue. That is how I understood our decision. I believe the sentence you quoted can be deleted.
In the editor's draft of the XQuery/XPath spec, I have carried out my suggestions in comment #0, and (with respect to comment #4) changed the triggers for err:XPST0112 from "focus-dependent" to "context-dependent built-in".