There are some unresolved issues with separately-compiled query libraries, which distracted my attention from the problem as reported, but I think that's a red herring in this case. The query library contains a number of functions with this general form:

declare function acord-zag:tester() as element() { let $rootXPath as xs:string := "/ACORD/InsuranceSvcRq/CommlAutoPolicyQuoteInqRq/CommlAutoLineBusiness/CommlDriver[1]" return saxon:evaluate($rootXPath) };

There's no difference here between using saxon:evaluate and using the XPath expression directly; saxon:evaluate uses its own context as the context for evaluating the dynamic XPath expression. Inside a function, the dynamic context has no context item. When there is no context item, evaluation of a path starting with "/" will fail with this error. You need to pass the document being processed as an argument to the function, or reference it as a global variable. (It's global variables that account for the known problems with separate library compilation, so that might be best avoided).

Thank you Michael. This makes sense, but I have one question.

Given the fact that the source document is dynamically determined in my Java code and given to Saxon using @XQueryEvaluator.setSource@, what would you say is the most elegant/performant way to deal with this? I have to use @saxon:evaluate@ because otherwise the code I previously used:

let $rootNode as element(CommlDriver)* := /ACORD/InsuranceSvcRq/CommlAutoPolicyQuoteInqRq/CommlAutoLineBusiness/CommlDriver
return  idcp-func:nodesToDelimited($rootNode,  ())

will fail during Saxon compilation since the source document doesn’t exist at that point.

Thus, since it appears that I have to use saxon:evaluate to postpone evaluation of the XPath, are you saying that I should just pass the entire document (about 100K) as a String to @acord-zag:getDelimitedCommlDriver@ which then, in turn, passes it as the second parameter to @saxon:evaluate@? Doesn’t this obviate the @XQueryEvaluator.setSource@ call entirely, since once the XPath (/ACORD/InsuranceSvcRq/CommlAutoPolicyQuoteInqRq/CommlAutoLineBusiness/CommlDriver) has been evaluated, the function that is invoked (@nodesToDelimited@) has no need to refer to the source document? Sorry to be so painfully explicit, but I still consider myself an XQuery newbie.

Thanks again.

You're mistaken about the need to use saxon:evaluate. The expression (let l$rootNode as element(CommlDriver)* := /ACORD/....) fails for exactly the same reason that your call on saxon:evaluate fails - there is no context item for the path expression. It just fails a bit earlier, because the compiler can see what's wrong. The fix is the same - you have to supply a parameter to the function to tell it what document to search within.

When you use setSource() from the API, that determines the context node passed to the query. Typically the body of your query will then call a function passing "." as a parameter, for example f:acord-tester(.), and the function in question will declare a parameter to accept this node, and use it as the root of the path expression, something like

declare function acord-zag:tester($root as document-node()) as element() { $root/ACORD/InsuranceSvcRq/CommlAutoPolicyQuoteInqRq/CommlAutoLineBusiness/CommlDriver1 };

I'm afraid I'm not answering your questions very well, because it's clear you have some mind-picture of what's going on that needs to be corrected, and I'm having trouble understanding where the conceptual blocks are.

I reread your prior response more carefully and now understand how conceptually muddy my last response was: the whole problem is that within a function there is no context item to evaluate paths against, whether that's recognized early or late. So is it therefore not possible to directly pass a context node to a function in a library (where there is no query body)? This means there's no way to directly invoke a function that operates on a context?

That's correct: in the body of a function, you have no access to the context item outside the function (either the initial context item passed when invoking the query, or the local context item at the point of the function call). You have to pass this information explicitly as a function argument.

Is it possible (and desirable) with Saxon to construct a context (XPath evaluated node) in my Java code and then pass that context directly to the desired function in my compiled library? The other approach is to change my library to a regular module and then have the query use the equivalent of a Java switch statement to invoke the appropriate function based on the value of an external variable. I suspect the latter approach is the only way to accomplish my goal.

Sorry for continuing to parse this topic :-)

Both approaches are possible. I think that while direct calling of an XQuery function from Java might seem more elegant, it's territory that's less well charted, and I think my advice would be to stick to the more orthodox approach of executing the query via its main module, even if this requires use of a switch to decide which function to execute.

Perfect. That was the direction I was leaning. Thanks again for your help.