[Bug 22732] New: [F+O 3.0] Function-lookup and the dynamic context

https://www.w3.org/Bugs/Public/show_bug.cgi?id=22732

            Bug ID: 22732
           Summary: [F+O 3.0] Function-lookup and the dynamic context
    Classification: Unclassified
           Product: XPath / XQuery / XSLT
           Version: Candidate Recommendation
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Functions and Operators 3.0
          Assignee: mike@saxonica.com
          Reporter: mike@saxonica.com
        QA Contact: public-qt-comments@w3.org

Under function-lookup we say:

If the function that is retrieved by fn:function-lookup has dependencies on the
static or dynamic context, the context that applies is the static and/or
dynamic context of the call to the fn:function-lookup function itself. The
context thus effectively forms part of the closure of the returned function.

(We say this in a Note, surely it should be in normative text?)

Have we considered all the implications? I suspect not.

Let's say there is a public function f with a reference to a private global
variable v:

declare %private variable v := 3;

declare %public function f() {$v};

And now suppose that we find f by means of a call to function-lookup(), and
then invoke the returned function item. What does it return?

Given the spec as written, the answer is that the reference to $v is resolved,
both statically and dynamically, by reference to the variables in scope for the
call to function-lookup(). If that call is in a different module there will
typically be no $v variable in scope, so the result is an error. If the call is
written like this:

let $v := 5 return function-lookup("f", 0)()

then the result should be 5.

This appears to me quite unacceptable, because it means that when compiling
function f, we cannot make any assumptions about what the reference to $v
means. We can't even make assumptions about its type.

Similarly: consider namespaces. If the body of the function is {<p:local/>}, do
we really expect the namespace prefix p to be resolved using the namespaces in
the static context of the call to function-lookup()? 

I can't imagine this is what we intended. The performance implications (not
being able to make assumptions about global variables and namespaces when
compiling f, just in case there is a dynamic call) are horrible. If we had
intended this, someone would surely have written some tests to demonstrate the
effect.

What is the alternative? I'll make some suggestions in another comment.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Friday, 19 July 2013 07:38:34 UTC