Saxon

Any chance you could supply a repro, so we know exactly what you are trying to do? (I could try to create one myself, but I might well find quite different problems...)

There's a lot of fuzziness in the spec in this area, so the outcome might turn out to be clarification of the documentation to explain what the restrictions are. But I'll investigate first before coming to that conclusion.

Michael Kay wrote:

Any chance you could supply a repro, so we know exactly what you are trying to do? (I could try to create one myself, but I might well find quite different problems...)

There's a lot of fuzziness in the spec in this area, so the outcome might turn out to be clarification of the documentation to explain what the restrictions are. But I'll investigate first before coming to that conclusion.

Hi, I'll have few days of vacation now so it will take some time but I can prepare it afterwards.

In general there are (at least) two issues. One with global variable and second with function duplicates.

Regarding functions it's related to XQueryFunctionLibrary.declareFunction(XQueryFunction function) method.

When we're compiling a library that refers to a function that was already compiled there is a check to prevent registration of different function with the same name.

Check is done by "!=" instead of some better approach to check systemId + namespace + module name + maybe row number in file (just a suggestion, I'm sure there is better solution).

Thanks. I've created a unit test (9.6/TestXQueryCompiler/testAbleToCompileWithCompileLibraryMethod()) which reproduces the problem. It seems that what is happening is that the "top level" library module loaded by compileLibrary() isn't included in the list of modules that the "import module" code checks for when looking for cycles, so this module is processed twice, leading to the "duplicate declaration" error.

More specifically, the top level module is only added to the list of known modules on completion, which means it isn't present in the list while the import module declarations are being processed.

I tried a patch and it didn't work, so I'm going to have to come back to it. I'm away for a week, but since this has been lingering for some while can I assume it's not especially urgent?

I suspect the problem is related to module location URIs, and the unfortunate provision in the XQuery spec (XQ3.0, section 4.12.2) "Several different modules with the same target namespace can be used in the same query. The names of public variables and public functions must be unique within the module contexts of a query: that is, if two modules with the same module URI are used in the same query, the names of the public variables and functions in their module contexts must not overlap."

The problem is that when you do compileLibrary(), the module you compile has no known location URI, and so when you import that module again via a cyclic module import, the module you are importing has a different "location" from the top-level module, and is therefore assumed to be a different module with the same module URI.

How else should we decide whether two query files with the same module URI are the same module or different modules? Perhaps we should do it by comparing the textual content of the module, rather than its location URI. Perhaps we should have an option to disallow multiple modules with the same module URI, and set this by default, especially when compiling a library module. This area of the spec is murky territory. But our failure to detect the cycle here, with no obvious workaround available, is certainly unfortunate.

The test case supplied uses a single compileLibrary() of a library with cyclic imports. The original problem description talks of multiple compileLibrary() calls of modules that import a common module. Either way we have similar problems: how do we define module identity, given that the spec allows multiple modules with the same URI?

Another little issue here: the text I cited says "the names of the public variables and functions in their module contexts must not overlap". In this case the variable is private. But I suspect Saxon isn't allowing for two modules with the same target namespace both having private variables with the same name.

There's no big rush with this issue. As one of background tasks I'm working on reducing compilation time and memory overhead of saxon modules we're using.

For now I can work on reproducing rest of the issues I found.

As a workaround I may be able to get rid of circular dependencies as there shouldn't be any at first place.

Thanks for your support.

Solution provided in https://saxonica.plan.io/issues/2456 (setting baseUri) seems to help.

I'll analyze it further.

Essentially the resolution to this is that if two references to modules with the same module URI use different location URIs, then you can expect to get the error; and this applies also if there is no known location URI. The remedy is to ensure that the module has a known location URI, which can be achieved by calling setBaseURI() before doing compileLibrary(). For 9.6 I'm going to leave it at that.

For 9.7 I'm thinking of introducing a configuration option XQUERY_MULTIPLE_MODULE_IMPORTS based closely on the existing MULTIPLE_SCHEMA_IMPORTS. If set to false, any "import module" for a module URI is resolved to an existing known module with that module URI (without even calling the module URI resolver), ignoring an location URI that might be present.

Thanks