Alberto:

I think the thing to do here is document other options available during test
suite execution.  Andrew can we add this to Thursday's agenda?

Thanks,
Carmelo

Alberto:

The guidelines for running the test suite were modified to document the
fact that implementations can handle the location hints in an implementation dependent mannner.

Thanks,
Carmelo

Can someone clarify on how this is going to be fixed? 
The queries:
modules-collide-var-001
modules-collide-var-002
modules-collide-fn-001
modules-collide-fn-002

look like this:
import module namespace test1="http://www.w3.org/TestModules/test1";
declare variable $input-context external;
(: insert-end :)

<result>{test1:ok()}</result>

I really don't see how this query could possibly cause an error? I think the test case targets that it references two modules that have the same namespace URI in the catalog xml. However this does not mean the query imports those modules. The spec does not mandate a way to store modules or more specifically that modules have to parsed when loading them into a database or that namespace URIs have to be checked in that case, that is completely application dependent. "modules-two-import" is a correct test case though.

I don't think there's an issue.
 
The notion that multiple location hints are equivalent to a single
merged module is just flat out wrong, as each separate module has
its own static context. Module import is for one _or more_ library
modules.
 
Whatever the instructions say about these tests, they need to
require that the named library modules are the ones imported in the 
execution of the test.  I thought the instructions said that, so I
don't think its correct to say that the tests assume that you are 
importing both is also wrong: the tests are (I believe) requiring that.
 
Dropping the explicit location hints seemed like a wrong step to me,
just because it makes it very mysterious, without a reference to the
catalog entry and the instructions, why some things are ok and some
things aren't, and brings up these kinds of comments.
 
But the point of the tests is to verify that multiple library
modules get handled correctly, and to provide the mimimal pair
of test cases for the error where having two separate lines 
with location hints was an error and one line with two location
hints was OK.
 
If implementations don't support multiple library modules in the same
namespace, I don't think it is a terrible thing for the testsuite to
notice that fact in an optional section of the suite.
 
 

(In reply to comment #4)
> I don't think there's an issue.

> Whatever the instructions say about these tests, they need to
> require that the named library modules are the ones imported in the 
> execution of the test.  
The test suite can only require that XQuery expressions are evaluated acording to the specification. Xquery has no way of specifying this, so the test suite can not require it.

> I thought the instructions said that, so I
> don't think its correct to say that the tests assume that you are 
> importing both is also wrong: the tests are (I believe) requiring that.

The instructions used to just say that if two modules were specified for the same namespace then that had to be taken as being two location hints in the same declaration, but since the meaning of that is implementaton defined, that instruction didn't really mean anything. Now (in current.zip in cvs) they explictly allow you to put a location hint to a manually merged module.


> But the point of the tests is to verify that multiple library
> modules get handled correctly, 

But "correctly" can only mean "as defined by the spec" and in the case of location hints that's explictly undefined. I don't think there is any way in XQuery to force the loading of two modules in the same namespace is there?

> 
> If implementations don't support multiple library modules in the same
> namespace, I don't think it is a terrible thing for the testsuite to
> notice that fact in an optional section of the suite.

If by "notice" you mean "systems fail the test" you need to say what part of the XQuery specification isn't being followed correctly if the system returns a value (rather than an error condition) because it loaded the module at the first hint, and ignored the second hint.


Personally I'd much prefer it if the XQuery specification defined multiple location hints as meaning that multiple modules were included, rather than it being implementation defined whether to load all or some or none of them, which seems to be an interoperability nightmare, but the test suite has to work with the spec as it is.



David

I think Alberto's and my miss-understanding was that the spec is not all too clear about it's model of how modules should be organized and imported. Especially the fact that modules may be split up in multiple files but imported with a single import statement and multiple location hints has been surprising, at least to me. Contrast that to schema imports where multiple location hints are processed in order and the first hit is used. Maybe the spec should be clarified there.

> Personally I'd much prefer it if the XQuery specification defined multiple
> location hints as meaning that multiple modules were included, rather than it
> being implementation defined whether to load all or some or none of them, which
> seems to be an interoperability nightmare, but the test suite has to work with
> the spec as it is.

That is the way I understand the spec by now (multiple location hints = multiple modules) and what I think Mary was trying to tell me, too.

I do agree with David that this should be clarified, maybe in XQuery 1.1, but the spec should really define cleanly what a module is, what a group of modules in the same namespace is, and what an implementation is supposed to do with an import statement. And the location hints should not be called hints, as this resembles the schema import stuff, which works differently if I understand it correctly.

I agree that a clean-up of the spec on modules should be a high priority for 1.1. The challenge is to achieve abstraction (over the varied implementation possibilities) without resorting to fuzziness. Deliberately fuzzy language ("hints") doesn't help: they just betray confusion over whether a URI is a name or an address. The current rules on cyclic imports and forward references are also very inconsistent at the moment: they were designed to make life easier for implementations, but I think they only succeed in making life more complicated. 

However, it's not clear to me that reopening a bug on the test suite is helpful. The reopening doesn't seem to say clearly where the bug is, or how it needs to be fixed.

All:

Based on the feeback provided by the variuos parties, I think the best thing to do (AT THIS point) is to leave the tests as they are and perhaps more
clarfications/discussions can take place for the next version of the specs.

As it was suggested, this bug will be marked as "WONTFIX" for now.

Thanks,
Carmelo