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.gr...@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.
>
>
