Multiple query modules with the same target namespace

[michaelhkay]

The test metadata does not provide an adequate way of testing import module declarations with location hints. The test suite documentation says, for example: it can be argued that the language specification does not require a processor to allow multiple modules with the same module URI This may have been true in XQuery 1.0, but it is not true in 3.1, where §4.12.2 explicitly addresses this. This scenario seems to be untested in the current test suite, and recent email correspondence suggests that different processors are handling things in different ways, even where the spec is clear.

See also Saxon issue https://saxonica.plan.io/issues/4803

[michaelhkay]

I propose to add an optional locatiion attribute to the module element in the test metadata, with the semantics:

The location attribute should be used only for XQuery 3.0 or later.

If the import module declaration has no location hints, the location attribute in the test metadata is ignored.

If the import module declaration has a location hint then the test driver attempts to identify a module element in the environment that matches both the module namespace URI and the location attribute (where the location match uses URIs after absolutization). If a match is found then the library module referenced by the file attribute is loaded. If no match is found then a "module not found" error occurs. If there are several location hints, then each one is matched independently, and all the corresponding modules are loaded.

[michaelhkay]

I have pushed a commit to implement the proposed change, and a simple test modules-30 that exemplifies it. Comments still welcome....

[adamretter]

For reference the commit @michaelhkay mentions is: 9aaa368

[benibela]

OMG. Who would possibly need that?

The XQuery 1 way was perfect, load the module from the first location that is available. An user could download the module, save it to a file as local cache, and then put the file url and the original http url in the locations, and when the file was there it could always load the file efficiently and ignore the http url.

[michaelhkay]

Unfortunately XQuery 1.0 allowed multiple location URIs on a module import but never said what it was intended to achieve or how it was supposed to work.

During 3.0 development the WG tried to plus this interoperability gap, and although it's still implementation-defined to an extent, there's now fairly strong guidance that if there are multiple locations given, you're expected to load them all.

Yes, it's a pretty sorry state of affairs. A one-to-one mapping of URIs to modules would have been much cleaner. Indeed, making namespace URIs of functions/variables completely orthogonal to module structure, as it is in XSLT, would probably have been much cleaner.

Michael Kay Saxonica

On 25 Oct 2020, at 23:33, Benito van der Zander notifications@github.com wrote:

OMG. Who would possibly need that?

The XQuery 1 way was perfect, load the module from the first location that is available. An user could download the module, save it to a file as local cache, and then put the file url and the original http url in the locations, and when the file was there it could always load the file efficiently and ignore the http url.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/qt3tests/issues/31#issuecomment-716231251, or unsubscribe https://github.com/notifications/unsubscribe-auth/AASIQIWMOZNIUNGUGOPMHYLSMSYVXANCNFSM4S5SEJLA.

[adamretter]

@benibela This came about due to code I found in the wild designed for different processors. @joewiz also just reminded me that this had been opened as an issue with eXist-db in the past too https://github.com/eXist-db/exist/issues/1174

[michaelhkay]

As there have been no alternative suggestions for over a year, I am closing the issue.