Bug #2641
closed
Indirect module imports do not work anymore in Saxon 9.7 HE
100%
Description
Hi,
As I tried to upgrade from Saxon 9.6 HE to Saxon 9.7 HE, I have found out that indirect importing of modules no longer works. I have prepared a minimal reproducer (please see below), and I would appreciate your feedback as to whether this could really be a bug in Saxon 9.7 HE, or maybe I'm overlooking something obvious.
Assume the following test setting:
test.xq
(:
import module namespace f="http://saxon.zaytsev.net/test/functions" at "test-direct.xqm", "test-indirect.xqm";
:)
import module namespace f="http://saxon.zaytsev.net/test/functions" at "test-direct.xqm";
f:wrapEchoString("Hello, wolrd!")
test-direct.xqm
module namespace f="http://saxon.zaytsev.net/test/functions";
import module namespace i="http://saxon.zaytsev.net/test/functions" at "test-indirect.xqm";
declare function f:wrapEchoString($s as xs:string) as xs:string {
i:echoString($s)
};
test-indirect.xqm
module namespace f="http://saxon.zaytsev.net/test/functions";
declare function f:echoString($s as xs:string) as xs:string {
$s
};
test.sh
#!/bin/bash
for version in 9.6 9.7; do
echo "Saxon $version:"
java -cp saxon-$version/saxon9he.jar net.sf.saxon.Query test.xq
echo
done
The output of test.sh when run on my machine is reproduced below:
$ ./test.sh
Saxon 9.6:
<?xml version="1.0" encoding="UTF-8"?>Hello, world!
Saxon 9.7:
Static error on line 5 at column 18 of file:/home/zaytsev/src/saxon/test-logical.mod.xq
XPST0017: Cannot find a matching 1-argument function named
{http://saxon.zaytsev.net/test/functions}echoString()
Static error(s) in query
As soon as I import test-indirect.xqm directly (see the first commented out line in test.xq), the test succeeds for both versions of Saxon. I'm thoroughly perplexed by this behavior, since it appears that in Saxon 9.7 HE the importing module should know about all of the dependencies of the imported modules and import them directly, which, obviously, hinders modularization.
Many thanks!
Files
Updated by Michael Kay about 8 years ago
- Status changed from New to In Progress
- Assignee set to Michael Kay
Thanks for reporting it. I have reproduced the problem.
Updated by Michael Kay about 8 years ago
The two modules both have the same module namespace. This is allowed by the spec, but it's not something I would recommend, because the effect of doing it is left very implementation-defined by the spec. (Section 4.12 of the XQuery 3.1 spec: "Each module import names a target namespace and imports an implementation-defined set of modules that share this target namespace." and "A module may import its own target namespace (this is interpreted as importing an implementation-defined set of other modules that share its target namespace.)"
Saxon 9.7 is adopting the same rule for XQuery modules that it does for XSD modules: an import is ignored if the set of loaded modules already contains a module with the required namespace URI.
The change is documented here: http://www.saxonica.com/documentation/index.html#!changes/xquery10/9.6-9.7 I don't remember offhand why we made this change; it was almost certainly a response to problems encountered by users.
According to the design and documentation, the old behaviour can be obtained by setting the configuration option FeatureKeys.XQUERY_MULTIPLE_MODULE_IMPORTS (or --xqueryMultipleModuleImports:on on the command line). However, this doesn't appear to be working. I shall investigate why, and let you know if I find a workaround. Meanwhile I would suggest using different module URIs on each module, which will give you interoperable results.
Updated by Michael Kay about 8 years ago
- Status changed from In Progress to Resolved
- Fix Committed on Branch 9.7 added
I have committed a patch which makes this test case work when the multipleModuleImports option is set.
The patch is simply to register the configuration property name in the list of recognized boolean property names in the Configuration.
Updated by Yury Zaytsev about 8 years ago
Hi Michael,
Thank you for getting back to me!
I'm sorry, I should have definitively mentioned that I've tried --xqueryMultipleModuleImports:on and it didn't have any effect, but I've got very confused and decided that most probably I've misunderstood the documentation, and this option is supposed to do something else. Now, of course, your explanation makes total sense to me.
Unfortunately, I don't think I will be able to convince our developers to refactor the codebase to use different target namespaces for the modules, but I'll be very happy to try --xqueryMultipleModuleImports:on with the next release and see if we can go forward with the migration.
Many thanks!
Updated by O'Neil Delpratt about 8 years ago
- Status changed from Resolved to Closed
- % Done changed from 0 to 100
- Fixed in Maintenance Release 9.7.0.4 added
Bug fix applied in the Saxon 9.7.0.4 maintenance release.
Please register to edit this issue
.