Saxon

Thanks for asking. This will need a bit of research - I haven't used separately-compiled query modules in anger myself, and I'm not sure that many people do.

ok, thanks for the reply.

Could you give me a high level idea on the design, how it would work better -

1. Top Down - Start compiling the xquery and create QueryLIbraries for modules encountered along the way.
2. Bottom Up - Figure out modules that can be put into QUeryLibraries, construct them and then compile the main Query.

Ideally we would like approach 1 to work, but from the Saxon code, I get the idea that you expect it to work by 2nd way - QueryLIbraries should be present already in the static context if need to be reused. Is that understanding correct?

I don't think it's possible to handle cyclic imports this way. I believe that when you compile a module, the modules it depends on must already be available, and that implies an ordering. (The original XQuery 1.0 specification forbade cycles, and our design in this area probably dates from that time.)

It's definitely a bottom-up model: the imported library modules should be present in the XQueryCompiler before the importing module is compiled. If you use a ModuleURIResolver to handle "import module" declarations as they are encountered, you could in principle attempt a recursive call on the XQueryCompiler to compile that library module, but I don't think it would be picked up by the current "import module" declaration.

The theory is that if the same module URI is encountered more than once in the import tree, whether through a cycle or through a diamond structure, the module is only compiled once: so you only get one set of functions and variables, with no duplicates. This is complicated by the fact that the spec allows more than one module to share the same module URI. In this case the configuration option Feature.XQUERY_MULTIPLE_­MODULE_­IMPORTS comes into play: if it is set, then Saxon effectively uses the location URI of the module rather than the module URI to decided whether two modules are the same. Furthermore, if you write your own ModuleURIResolver, then Saxon's ability to detect that you are importing the same module twice may depend on the way you set the SystemId property in the returned StreamSource objects.

I've described this in terms of the s9api (XQueryCompiler) API. If you use the internal, now deprecated, StaticQueryContext API the rules are rather similar but there are variations in detail. If you use XQJ, I don't believe you can use separately compiled modules.

Thanks for the detailed analysis. Its a little difficult to share a sample code here, I will try to explain at a high level

• Yes we are trying to create a custom cache, since the XqueryCompiler and StaticQueryContext cannot be kept common for all of our xquery executions for various reasons such as high number of queries.
• We are using the s9api, XqueryCompiler with a customer StaticQueryContext.
• We are trying to plugin the QueryLibrary cache by overriding the getCompiledLibrary(namespace) method of StaticContext, which is checked before importing a module - it would return a QueryLibrary from cache, or else build one.

From what you described, at a high level, it looks like it would work for normal case, with the exception of cyclic import?

If you need more details let me know, I could share the POC code privately via saxon support email.

Overriding system classes with your own versions means that you're outside the scope of what we test and support, but that doesn't mean it won't work. It does mean you're more exposed than most people to anything that we change from one release to the next, and it means that you're going to need to acquire a pretty deep understanding of some of the Saxon internals in this area.

Got it, will be careful and try to minimize the overriding. Thank you for your help!