XQuery 中的范围和静态已知名称空间

lin*_*e-o 6 xquery exist-db

考虑一个库模块ctx

xquery version "3.1";

module namespace ctx="module/ctx"; 

declare function ctx:resolve (
    $ctx as function(xs:string) as xs:QName
) as function(xs:string, xs:integer) as function(*)? {
    function ($name as xs:string, $arity as xs:integer) as function(*)? {
        function-lookup($ctx($name), $arity)
    }
};
Run Code Online (Sandbox Code Playgroud)

和一个库模块a

xquery version "3.1";

module namespace a="module/a"; 

declare function a:f () { "a:f" };
Run Code Online (Sandbox Code Playgroud)

和一个主模块

xquery version "3.1";

import module namespace a="module/a" at "a.xqm";
import module namespace ctx="module/ctx" at "ctx.xqm";


ctx:resolve(xs:QName(?))("a:f", 0)()
Run Code Online (Sandbox Code Playgroud)

是否可以安全地假设返回的函数引用xs:QName(?)将保留声明名称空间的上下文a,以便主模块输出“a:f”?

这在 eXist-db 中确实有效(在 5.3.0 上测试),但我不确定此代码是否可移植到其他 XQuery 3.1 处理器。

- - 更新 - -

在 eXist-db 5.3.0 中不起作用的是

import module namespace ctx="module/ctx" at "ctx.xqm";

declare namespace app = "app";
declare function app:f () { "app:f" };

ctx:resolve(xs:QName(?))("app:f", 0)()
Run Code Online (Sandbox Code Playgroud)

Mic*_*Kay 6

这是一个很好的问题。

\n

如果您使用命名函数引用 xs:QName#1,那么您将在 \xc2\xa73.1.6 中找到答案:

\n
\n

此外,如果由 NamedFunctionRef 计算返回的函数具有依赖于实现的实现,则此函数的实现与此 NamedFunctionRef 表达式的静态上下文以及计算 NamedFunctionRef 的动态上下文相关联。

\n
\n

这是相当晦涩的语言,但它的意思是您返回的函数使用命名函数引用本身的静态和动态上下文(而不是实际调用函数时的上下文)。

\n

对于部分函数应用程序,xs:QName(?)该语言更加难以理解:

\n
\n

实现:F 的实现。如果这不是 XQuery 3.1\n表达式,则新函数的实现通过以下两种方式之一与\n静态上下文和动态上下文关联:如果 F 的\n实现已与上下文关联,则那些被\n使用;否则,使用 SC 和 DC。

\n
\n

我认为规范假设(没有理由)类似的内置函数xs:QName将具有不是 XQuery 3.1 表达式的实现,因此第二句话适用。我真的不太清楚“已经与上下文相关联”这句话的含义是什么——也许它与 F 已经是部分应用函数的情况有关。但无论如何,我相当确定其意图是“使用 SC 和 DC”——也就是说,xs:QName(?)工作原理与 完全相同xs:QName#1,它在计算表达式时使用静态和动态上下文xs:QName(?)

\n

您担心不能假设现有产品所做的事情就是规范所说的必须发生的事情,这是完全正确的。但在这种情况下,我认为他们做得对。

\n