The modules-collide-var-001 test case failes due to fots-driver problem

Reassigned the bug to Chris for redistribution.

It would be helpful if you read the title of the bug. The relevant test case is stated there.

There are probably more than one ways to solve this problem. I may be wrong, but enhancing the fots driver seemed to me the most proper way, or some combination of fots driver and xqxq.

Juan, the underlying problem here is that the XQXQ URL resolver interface maps a URI to a single resource. That's my fault, I'm pretty sure, as I believe I proposed the current interface. I think a possible solution would be to change the signature for the URL resolver function item to

    as function($url as xs:string, $entity as xs:string) as item()*

with the * at the end, meaning that a URL resolver function could return multiple streamable strings for a single input URL.

If that can be done, then this bug should go back to Sorin to update the FOTS driver to make use of this functionality.

Chris, Even if the proposal was done to only use one resource, it is not as easy as changing the signature of the url resolver function. The problem is more because of the way the url resolver is implemented in the C++ API.

Since If I did that change I can actually get the 2 resources with no problem but the definition of URLResolver states that you can only return 1 Resource, so there is no way for me to return 2 resources in 1 resolver.

  virtual Resource* resolveURL(const zorba::String& aUrl,
    EntityData const* aEntityData) = 0;

So to get this done we would probably need to make changes to the URLResolver class to allow returning more than one resource.

Markos mentioned this is currently working internally on zorba, so my only guess is that the C++ API URLResolver needs to be updated to work more like the internal resolver.

Also the way how FOTs driver is currently done it doesn't return the 2 resources it just return one sicne the url resolver is described

declare function resolver:url-resolver($namespace as xs:string, $entity as xs:string)
{
switch($entity)
case 'module'
  return switch($namespace)
    case 'http://www.w3.org/TestModules/test1' return unparsed-text('file:///D%3A/ZORBA/FOTS/2011/QT3-test-suite/prod/ModuleImport/test1-lib.xq')
    case 'http://www.w3.org/TestModules/test1' return unparsed-text('file:///D%3A/ZORBA/FOTS/2011/QT3-test-suite/prod/ModuleImport/test1collide2-lib.xq')
    default return ()
default return ()
};

So it will end the function in the first case ignoring the second case.

If we changed it to

  case 'http://www.w3.org/TestModules/test1' return ( unparsed-text('file:///D%3A/ZORBA/FOTS/2011/QT3-test-suite/prod/ModuleImport/test1-lib.xq') , unparsed-text('file:///D%3A/ZORBA/FOTS/2011/QT3-test-suite/prod/ModuleImport/test1collide2-lib.xq') )

this way it will match the expected query.

As for the current implementation since there is no way of returning 2 resources what the module does is serialize the returning sequence and return it as 1 resource. This will cause the test to pass with a wrong error message. Even though this won't be correct since the error will be caused since 1 module is paste after another making zorba break.

I was completely off-base when I wrote my previous comment. Please ignore it and all the follow-ups.

The relevant test case in FOTS looks like this (trimmed):

   <test-case name="modules-collide-var-001">
      <module uri="http://www.w3.org/TestModules/test1" file="ModuleImport/test1-lib.xq"/>
      <module uri="http://www.w3.org/TestModules/test1" file="ModuleImport/test1collide1-lib.xq"/>
      <test><![CDATA[
        import module namespace test1="http://www.w3.org/TestModules/test1";
        <result>{test1:ok()}</result>]]>
     </test>

This is intended to use the functionality described in http://www.w3.org/TR/xquery-30/#id-module-handling-multiple-same . It actually is unrelated to "at" clauses as mentioned in the original bug description here.

The way Zorba implements this feature is with "component URI mappers". These look the same as normal URI mappers (referred to as "candidate URI mappers"), but Zorba treats them differently: it will attempt to pre-process the module URI through all registered component URI mappers, and any URIs that are returned by them will ALL be resolved and imported.

So, the fix for this problem is to allow FOTS driver to use component URI mappers. This will first require an XQXQ change to allow you to register a component URI mapper. This would be much cleaner if XQXQ had a concept of static contexts to register them on, but it doesn't, so the only alternative I can see is to create yet another version of xqxq:prepare-main-module() that takes a third function argument. That should be a relatively minor change in XQXQ.

Once that's there, FOTS can use it. It could just use that version all the time, or it could restrict its use to only test cases that have multiple <module> elements.