Re: [basex-talk] Shoud 'addraw' work as parameter with db:create?

2020-01-24 Thread Christian Grün
Hi France, I just ran a little 'test.bxs' command script with the following contents on command line: xquery file:create-dir('test') xquery file:write('test/dummy.png', ()) xquery db:create('db', 'test', '/', map { 'addraw': true() }) xquery db:list('db') It outputs 'dummy.png' as expected.

Re: [basex-talk] How to escape/encode a search term using BaseX REST XQ

2020-01-24 Thread Christian Grün
Hi Ivan, hi Gerrit, Thanks for your assessments. Most design decisions in RESTXQ have been taken from Java’s JAX-RS API [1]. The semantics for accessing paths is a bit more complex, though: JAX-RS provides two annotations @Path and @PathParam to access the full path and segments of the path, and

[basex-talk] Shoud 'addraw' work as parameter with db:create?

2020-01-24 Thread France Baril
Hi, I have this function that loads all the indexable content, but leaves the .png behind. Am I missing something? declare %rest:path("/demo/create-db") %rest:GET %rest:query-param('db', '{$db}', 'new-name') %rest:query-param('dir-src', '{$dir-src}', '') %output:method("html")

Re: [basex-talk] How to escape/encode a search term using BaseX REST XQ

2020-01-24 Thread Imsieke, Gerrit, le-tex
On 24.01.2020 14:36, Imsieke, Gerrit, le-tex wrote: So I agree, BaseX should not interpret escaped slashes as if they were regular slashes, thereby disallowing them as part of RESTXQ path pa …rameters.

Re: [basex-talk] How to escape/encode a search term using BaseX REST XQ

2020-01-24 Thread Imsieke, Gerrit, le-tex
While moving the URI parameter to the query string seems like an acceptable workaround, I, too, suggest that if *reserved* URI characters such as '/' appear percent-encoded, they should not be converted to their decoded character prior to analyzing the URI, in line with Sect. 2.2 of RFC 3986

Re: [basex-talk] How to escape/encode a search term using BaseX REST XQ

2020-01-24 Thread Ivan Kanakarakis
Hi Christian, thanks for the quick reply. It definitely helps, but it still keeps this behaviour in the "weird" domain. I do not see a reason to be decoding the URI before it gets to match a route. What is the reason for this? What you propose works, but if I have a route like