This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
modules-collide-var-001 and modules-collide-fn-001: expect duplicated something error. How can that be, when the main module does not declare anything and only imports an one module? Well, the test xml has two modules with the same namespace, but that would rather be a two modules with the same namespace error. modules-collide-var-001 has <a>{local:test()}</a>, but there is no local:test() function. So it could throw XPST0017 instead the expected error.
Unfortuntely (in my view) it is not an error to have two modules with the same namespace, in fact it is explicitly allowed by the specification, though almost everything about it is implementation defined, and one could certainly challenge the test on that basis. The spec says: Each module import names a target namespace and imports an implementation-defined set of modules that share this target namespace. To make modules testable at all, the test driver documentation has to impose some rules. As always the test suite documentation isn't quite as specific as it should be. It says (of test-case/module): Defines an XQuery library module imported by a test case. The module element gives the module URI and the location of the module. The query will contain an "import module" declaration referencing the same module URI, with no "at" location (except where the "at" attribute is being specifically tested, in which case the results are undefined.) The unstated assumption is that if there is more than one test-case/module element with the same uri value, you are expected to import them all. This does raise the question whether it would be conformant for an implementation to have no support for multiple modules with the same URI (and thus be unable to run this test). I think this would indeed be conformant. The spec says that the implementation loads "an implementation-defined set of modules" and it would be conformant for this set to be always of size one (arguably it would also be conformant for it always to be empty, but then no-one would buy your product...). The reason Saxon allows multiple modules with the same namespace is for interoperability with other implementations that allow it, not because it is required for conformance. So one could argue that (a) these tests should have a dependency "multiple_modules_for_uri", and (b) that the documentation for test-case/module should be more explicit.
I actually had not read that part of the spec again; I assumed I would know it all by now Still the description of err:XQST0033 could be more precise
The WG agreed that it was appropriate to improve the documentation describing the test suite's expectations of how module import is handled. Since so much of the detail of "import module" is implementation defined, it is difficult to write tests that will be executable on every implementation. However, we can state our expectations, and if a processor is not able to be configured in a way that enables the tests to be run, then it should not run these tests. The only alternative is to have no tests for module import (or to make the spec more prescriptive, which the WG does not wish to do.)
I have updated the documentation in the catalog schema. The HTML will be updated when the next build is done.