What about characters that outside the UTF-8 scope? I think that still makes the internal parser to fail. I thought that was intended behaviour so I never mentioned it. On 09/30/2016 03:10 PM, Christian Grün wrote:

By default, XML documents with invalid characters should be rejected; but if you turn on the internal parser in the parsing tab of the Database Creation dialog, all invalid characters will be replaced with FFFD. Maybe that’s what you have done?

I also noticed that the QUERYPATH has been removed from latest builds, how can I set the Docker image to find xq modules? I was using the QUERYPATH to map them.

I pass this on to the Docker aficionados on the list…

Christian

Thanks and sorry for responding on a month old post about the xml parser, I just noticed my email filters were not working. About the QUERYPATH, I think the issue isn't specifically about docker. Maybe I'm missing something, but how can a basexclient execute XQUERY "import module namespace test = "test" at "test.xq" if there isn't a querypath to define the directory for the modules? I'm trying this on a local server instance and it searches for the test.xq in the BaseX bin directory. I hope there is an alternative way to declare the path, because I won't be able to use BaseX any more from my java application, using the BasexClient query method. Specifically about Docker, the older images can't run because of the .m2 permissions, and the latest one is missing QUERYPATH.

One way is to specify the base URI in your query [1]. If you frequently import server-side modules, the approach we recommend is to move the modules into the repository.

Hope this helps, Christian

[1] https://www.w3.org/TR/xquery-31/#id-base-uri-decl [2] http://docs.basex.org/wiki/Repository While the base uri works, it isn't very convenient, because it forces you to know the modules directory path beforehand, which means I can't deploy it in two different systems and expect it to work without changes.

I will also take a better look at the repository later, but from what I understand I need to remove all relative location uri from the module import of every xquery script? Beucase I tried just copying the files in the repo and it didn't work. I have a large amount of scripts (maybe over 500), that will need manual changes. Finally, I think the querypath option was very useful, so please don't remove it :)

Could you give me some details what went wrong?

Well even if I copy the modules in the repo directory, the main module still has a relative path in the import declaration, so basex is searching for the modules in "/srv/" directory in the docker container, or in the /bin directory if I run the basexserver from the terminal. If I remove the 'at "file.xq"' it is trying to do something different, but I still get this error: [XQST0059] Module not found: "namespace" both on docker container and on normal basex server.

You’ll indeed need to remove the location specifier in your main module; after that, it should work (see our documentation for more details). I understand. However, this won't do for my use case. Let's say hypothetically I have about 500 modules, most of them library and some of them main modules. All of them are in the same directory, and some of them share the same namespace. Most of the library modules also import other library modules, so I will have to manually remove all location specifiers from every file. Also currently, most of the same scripts can also work with Saxon without any changes, but if I remove the specifiers this will probably make Saxon stop working. So I guess I will have to use base-uri for now.

PS, out of interest: How did you solve the URI problem with Saxon? On Fri, Oct 28, 2016 at 1:55 PM, George Sofianos <gsf.greece@gmail.com> wrote:

...

You’ll indeed need to remove the location specifier in your main module; after that, it should work (see our documentation for more details).

I understand. However, this won't do for my use case. Let's say hypothetically I have about 500 modules, most of them library and some of them main modules. All of them are in the same directory, and some of them share the same namespace. Most of the library modules also import other library modules, so I will have to manually remove all location specifiers from every file. Also currently, most of the same scripts can also work with Saxon without any changes, but if I remove the specifiers this will probably make Saxon stop working. So I guess I will have to use base-uri for now.

Hi, I'm trying to use a most recent version of BaseX server (I'm stuck with 8.4.4 now), and I'm trying to use base-uri to import my modules (BaseX latest snapshot). However, I can't seem to make this work. While declaring the base-uri works for the XQuery scripts that runs on BaseX GUI, basexserver and basexhttp seems to be giving errors. Unless I'm doing something very wrong, I get this error from my library module: lineNumber: 1; columnNumber: 1; Content is not allowed in prolog. Also I'm declaring the base-uri in the main module only, like: declare base-uri "file:///home/user/directory/"; without the final slash it gets resolved to the previous directory, I guess that's intentional? I only found a reference in this closed issue: https://github.com/BaseXdb/basex/issues/1454 The alternative would be to bring QUERYPATH back, somehow :) I will then be able to upgrade without compatibility issues. Thanks, George On 10/28/2016 02:06 PM, Christian Grün wrote:

Well, this will be difficult… We had to do numerous rewritings, and the QUERYPATH option was kind of hacky (seen from today’s perspective). We may be able adding something similar for specific use cases like yours, but I can’t promise anything yet.

Sorry for the delay, I want to make sure first there is nothing wrong with my system. I noticed these scripts also fail on a local server (8.4.3) with file not found error (while the file exists), but they run fine on a BaseX GUI. I will reply again when I find out what's wrong - or not. George On 06/12/2017 08:09 PM, Christian Grün wrote:

...

Unless I'm doing something very wrong, I get this error from my library module:

lineNumber: 1; columnNumber: 1; Content is not allowed in prolog. Hi George, do you have a mini example that I can test out-of-the-box? Thanks in advance.