Bug #6209
closed
Saxon functions not available via function-lookup() in module loaded via load-xquery-module()
0%
Description
I have a module where the call to a Saxon function is encapsulated via function-lookup() (portability)
When I call the encapsulated function directly, it works. If I call the Saxon function directly, it works. But if I load the module via load-xquery-module() then the function-lookup() fails even though the direct call works. The function here is saxon:xquery FWIW, although I don't believe that matters.
Attached code has all four cases: direct.xqy just imports the module and calls things; indirect.xqy uses load-xquery-module() and then tries to call things.
saxon.sh direct.xqy saxon.sh indirect.xqy
(with appropriate mods to paths in saxon.sh and config.xml)
Files
Updated by Michael Kay about 1 year ago
I don;t think there's anything in the spec that says fn:load-query-module() changes the dynamic context for a subsequent call on function-lookup(). (Indeed, it's not clear what "subsequent" might mean).
Updated by Michael Kay about 1 year ago
- Tracker changed from Bug to Support
- Status changed from New to Closed
- Assignee set to Michael Kay
I'm closing this with no action: load-query-module` is not intended to modify the static or dynamic context. I've proposed a clarification in the 4.0 specification.
Updated by Mary Holstege about 1 year ago
I respect your decision, although don't you think it is strange that
lookup-function() cannot even find built-in F&O functions just because
it is called from within a function loaded with load-xquery-module?
Seems that the context has been modified: to truncate it in a weird way.
On 9/30/23 15:37, Saxonica Developer Community wrote:
Updated by Michael Kay about 1 year ago
- Status changed from Closed to In Progress
don't you think it is strange that function-lookup() cannot even find built-in F&O functions
Yes, that certainly is strange. Perhaps I need to look at your examples more carefully.
I wouldn't expect the static or dynamic context of the caller of load-xquery-module to be affected by the call. But I would expect the dynamic context of the functions that are loaded from the library module to contain the usual stuff. The spec says:
The static and dynamic context of the library module are established according to the rules in Section C Context Components XQ31.
It is ·implementation-defined· whether constructs in the library module are evaluated in the same ·execution scope· as the calling module.
We should add a statement at https://www.saxonica.com/documentation12/index.html#!functions/fn/load-xquery-module about exactly what we do in this regard. We do create a new Controller which effectively means a new execution scope.
Updated by Michael Kay about 1 year ago
- Tracker changed from Support to Bug
OK, sorry, I misunderstood the problem.
There is a bug that in the dynamic context for evaluation of user-written functions loaded using fn:load-xquery-module, the set of dynamically-known functions (as revealed by the fn:function-lookup() function) is empty.
Updated by Michael Kay about 1 year ago
I have added QT4 test cases fn-load-xquery-module-075 | 076 | 077.
Updated by Michael Kay about 1 year ago
When compiling a query main module, the run-time function library used by function-lookup() (an instance of ExecutableFunctionLibrary) is created by XQueryParser.makeXQueryExpression(), and this becomes a property of the Executable so it is shared by all query modules.
The loadXQueryModule function calls StaticQueryContext.compileLibrary() to compile the library module. This in turn calls XQueryParser.parseLibraryModule(). This doesn't include the same logic for initializing a run-time function library. There's a question mark as to whether it should: the same path is used by the s9api interface XQueryCompiler.compileLibrary(), and I suspect a library obtained that way will always inherit the run-time function library of the query that invokes the library. So the initialization of the function library probably needs to happen at the level of the loadXQueryModule function itself.
Updated by Michael Kay about 1 year ago
Fix committed and tested (but not yet pushed) on the 12.x branch. Extracted the code for creating an ExecutableFunctionLibrary from makeXQueryExpression() and reused it in loadXQueryModule.
Also made some tweaks to Javadoc and error messages as part of the same commit.
Updated by Michael Kay about 1 year ago
- Category set to XQuery conformance
- Status changed from In Progress to Resolved
- Priority changed from Low to Normal
- Applies to branch 11, trunk added
- Fix Committed on Branch 11, 12, trunk added
- Platforms .NET, Java added
Updated by O'Neil Delpratt 12 months ago
- Fixed in Maintenance Release 12.4 added
Bug fix applied in the Saxon 12.4 Maintenance release. Leaving it marked as 'Resolved' until fix applied on Saxon 11.
Please register to edit this issue
.