Thanks for the resolution hint and the clue that there is no error when running locally.

I dug a bit deeper. It seems running modules via http shines a light on some less common codepaths #[2091]

 I get an error from just:
inspect:xqdoc("https://raw.githubusercontent.com/acdh-oeaw/vleserver_basex/main/vleserver/changes.xqm")
[XQST0049] Duplicate declaration of static variable $_:basePath.

I note that:
  1. "changes.xqm" imports "utils.xqm" and "data/changes.xqm"
  2. "data/changes.xqm" imports "../utils.xqm"

So utils.xqm is imported with two different paths and BaseX fails to spot it is the same file when the transport is https
but it does spot they are the same when these are local files. I think this is correct, BUT it is not the true problem.

I believe the true problem is the raising of error XQST0049, regardless of whether the imports of utils.xqm are the same file or not.
Because: Module imports are not transitive #[2048]  and in particular:
"module A does not have access to the variables declared in module C"

There is no "Duplicate declaration of static variable" in this case because  "changes.xqm" should not be able to see what is imported by  "data/changes.xqm"
The variables are defined in different scopes. Saxon XQuery runs with no error.

/Andy

[2091] https://github.com/BaseXdb/basex/issues/2091
[2048]  https://github.com/BaseXdb/basex/issues/2048








On Sat, 23 Apr 2022 at 17:11, Christian Grün <christian.gruen@gmail.com> wrote:
Hi Andy,
 
(: hack to scrape  module names from github :)
let $mods:=fetch:xml("https://github.com/acdh-oeaw/vleserver_basex/tree/main/vleserver",map{"parser":"html"})
//a[@data-pjax="#repo-content-pjax-container"][ends-with(.,".xqm")]
/concat("https://raw.githubusercontent.com",replace(@href,"/blob/","/"))

(: get namespace prefixes in use :)
return $mods!( try{ inspect:xqdoc(.)/*:namespaces } catch * {$err:description})

I was surprised to see that this expression even triggers an exception if only the first module is inspected. If the repository is cloned and if it’s invoked on the local files, it runs smoothly, so maybe it’s a bug in the resolution of the remote URIs that a module that’s imported multiple times is not detected as already parsed.

I didn’t have time yet to track this down.