Way too often I saw myself and my colleagues write huge, very hard to understand deeply nested if () then else code to handle any control path but the complete success one in RestXQ code. [1] is an example of such code even though it uses the module I want to introduce here. It seems I didn’t have time to refactor it yet. To add insult to injury the code producing a 500, 404, 403, 401, 302 or maybe even 201 response code was * neither short nor very uniform and * would respond to the browser with XML/XHTML or JSON or text but in most situations the format the browser side had the hardest time to handle
For example [2] delivers an XHTML message no matter what the Accept header says and although it is an accurate message to a user, very similar XML snippets are found throughout that unit and maybe need to be adapted each separately if the HTML needs to updated.
My XML snippets CRUD API started as a port of an apigility (now laminas api-tools [3]) API working with a relational backend to store XML snippets to something that does the same but just uses BaseX for any data storage and is much better at querying using sophisticated XPaths. So from that previous API I learned about RFC 7807. [4]
RFC 7807 “Problem Details for HTTP APIs” [5] is one of several specification now available for reporting errors from REST APIs. This specification explicitly states how the errors should look like in XML as well as in JSON.
Maybe this is a bit bold, but I used the URL of that very RFC 7807 as the resolved URI for my module. [6] Please note: I have to admit my modules have something unusual in common: I use the namespace prefix “_” within the module and only use a more talking prefix when I use a module elsewhere. So, the “_” prefix can map to numerous URIs in my code. I am not 100% sure if there are down sides to this style but I use it for a while now and no problems come to mind.
I really dislike to get an error, especially during development of some service, without any indication of where that actually occurred. That is to say: I like stack traces in my errors. It also would be great if any runtime error in my code would be reported as XML or JSON, depending on the format the browser asked for, just as errors I explicitly raise.
A few parts provided by BaseX greatly help in getting all of this packaged in some xqm-file. * A stack trace is always available in “$err:additional” when catching errors [7] * One catch-all error handler can be installed (“declare %rest:error('*') function”, although there are minor downsides to this catch-all handler) [8] * The XML based direct format BaseX uses to store JSON by default makes it very easy to transform RFC 7807 XML to JSON [9] * It is easy to query the request header anywhere in RestXQ XQuery code running on BaseX [10]
I tried to have easy to remember function names that make the code readable as if it was a sentence. Therefore for example, I created a function wrapping the users code that says “return api-problem:or-result(user_function#x, [params, …])”[11]. Another example would be “return api-problem:result(<problem>[…]</problem>)”.
I also wanted to come up with an “intuitive way” to send standard HTTP response codes. What I came up with is a special namespace and a mapping of status codes to standard messages that is part of my module. So for example a status code 404 can be returned like this: “error(xs:QName('response-codes:_404'), $api-problem:codes_to_message(404), 'A custom message')” [12]. Something similar is probably possible with “web:response-header()” but with the error function something like if
let $check_file_exists := if (not(file:exists($path))) then error(xs:QName('response-codes:_404'), $api-problem:codes_to_message(404), 'A custom message')
at the top of a more complex RestXQ function is possible. There is no need to wrap custom code in one or several “if () then else” blocks. This helps readability in my opinion very much, especially if you have to check quite a few things before, say, writing something to the database.
The idea also works great with permission checks that use %perm:check annotations. My first use of my api-problem module predates the addition of these helpful annotations. [13]
A while before we had a HTTP header parameter that gave us the execution time, I wanted to measure execution time. So the functions take an xs:integer that should be obtained using “prof:current-ns()” [14] as the very first variable in a RestXQ function and I try to execute a second “prof:current-ns()” as late as I can imagine in my module [15]. That way I think I get a reasonably accurate timing result in my outputs as long as the respective error does not come from the catch-all handler.
I also incorporated a quick and dirty HTML page rendering function that displays an error in detail if someone needs that [16]. As a small addition this error page can link to error descriptions in the W3C standards. [17]
By the way: developing this started on BaseX but then we had similar needs in another open-source XML database existing today so I tried to port the code. Not only worked that rather well (probably also because I know the XQuery needed there rather well too), I also had a few new ideas and added them back to the BaseX version. May be there is some left over code in the module at the moment that reimplements some helpful, non-standard XQuery functions for this reason. The code is somewhat portable.
A few thoughts: * Some say that it is necessary for security purposes to disable any stack traces in production environments. I am not really believing this does much good. But if one does not want to hard code a Boolean switch in the modules source code: What would be the fastest external source one could use in terms of compile, optimizing and execution time? Are stack traces not available as “$err:additional” when RESTXQERRORS are switched off? * Is there any sane way to get a QName with an unknown prefix of an error as a string like in the catch all handler and resolve it against all prefix-URI mappings known in some XQuery program?
[1] https://github.com/acdh-oeaw/vleserver_basex/blob/main/vleserver/users.xqm#L... [2] https://github.com/acdh-oeaw/vicav-app/blob/master/http.xqm#L24-L55 [3] https://api-tools.getlaminas.org/ [4] https://api-tools.getlaminas.org/documentation/modules/api-tools-api-problem [5] https://datatracker.ietf.org/doc/html/rfc7807 [6] https://github.com/acdh-oeaw/api-problem4restxq/blob/master/api-problem/api-... [7] https://docs.basex.org/wiki/XQuery_3.0#Try.2FCatch [8] https://docs.basex.org/wiki/RESTXQ#Catch_XQuery_Errors [9] https://docs.basex.org/wiki/JSON_Module#Direct [10] https://docs.basex.org/wiki/Request_Module#request:header [11] https://github.com/acdh-oeaw/api-problem4restxq/blob/master/tests/api-proble... [12] https://github.com/acdh-oeaw/api-problem4restxq/blob/master/tests/http.xqm#L... [13] https://github.com/acdh-oeaw/api-problem4restxq/blob/master/tests/http.xqm#L... [14] https://github.com/acdh-oeaw/vleserver_basex/blob/main/vleserver/dicts.xqm#L... [15] https://github.com/acdh-oeaw/api-problem4restxq/blob/master/api-problem/api-... [16] https://github.com/acdh-oeaw/api-problem4restxq/blob/master/tests/api-proble... [17] https://github.com/acdh-oeaw/api-problem4restxq/blob/master/api-problem/api-...
Best regards
Hi Omar,
Thanks for this. I also enjoyed your earlier message re:
I tried to get creative at finding a way to optimize querying the data
without having many long lasting global lock situations I have been in a similar situation and discovered how alternative code approaches using different builtin functions can have very different lock profiles. I am hopeful that #[2063] will greatly reduce locking issues.
Is there any sane way to get a QName with an unknown prefix of an error as
a string like in the catch all handler and resolve it against all prefix-URI mappings known in some XQuery program?
Maybe using inspect:xqdoc can help to get the prefix to namespace map. e.g.
inspect:xqdoc(" https://raw.githubusercontent.com/acdh-oeaw/vicav-app/master/http.xqm ")/*:namespaces <xqdoc:namespaces xmlns:xqdoc="http://www.xqdoc.org/1.0%22%3E <xqdoc:namespace prefix="_" uri="https://tools.ietf.org/html/rfc7807%22/%3E <xqdoc:namespace prefix="req" uri="http://exquery.org/ns/request%22/%3E <xqdoc:namespace prefix="cors" uri=" https://www.oeaw.ac.at/acdh/tools/vle/cors%22/%3E <xqdoc:namespace prefix="admin" uri="http://basex.org/modules/admin%22/%3E <xqdoc:namespace prefix="rfc7807" uri="urn:ietf:rfc:7807"/> <xqdoc:namespace prefix="response-codes" uri=" https://tools.ietf.org/html/rfc7231#section-6%22/%3E <xqdoc:namespace prefix="rest" uri="http://exquery.org/ns/restxq%22/%3E <xqdoc:namespace prefix="http" uri="http://expath.org/ns/http-client%22/%3E <xqdoc:namespace prefix="ann" uri="http://www.w3.org/2012/xquery%22/%3E </xqdoc:namespaces>
Although this can run into issues like #[1194]. For example trying to do all modules...
(: 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%22,replace(@href,%22/blob/%22,%22/"))
(: get namespace prefixes in use :) return $mods!( try{ inspect:xqdoc(.)/*:namespaces } catch * {$err:description})
I feel the solution to this must be related to the scoping of names, and in some way depend on #[2048]
/Andy
[2063] https://github.com/BaseXdb/basex/issues/2063 [1194] https://github.com/BaseXdb/basex/issues/1194 [2048] https://github.com/BaseXdb/basex/issues/2048
On Tue, 12 Apr 2022 at 18:58, Omar Siam Omar.Siam@oeaw.ac.at wrote:
Way too often I saw myself and my colleagues write huge, very hard to understand deeply nested if () then else code to handle any control path but the complete success one in RestXQ code. [1] is an example of such code even though it uses the module I want to introduce here. It seems I didn’t have time to refactor it yet. To add insult to injury the code producing a 500, 404, 403, 401, 302 or maybe even 201 response code was
- neither short nor very uniform and
- would respond to the browser with XML/XHTML or JSON or text but in
most situations the format the browser side had the hardest time to handle
For example [2] delivers an XHTML message no matter what the Accept header says and although it is an accurate message to a user, very similar XML snippets are found throughout that unit and maybe need to be adapted each separately if the HTML needs to updated.
My XML snippets CRUD API started as a port of an apigility (now laminas api-tools [3]) API working with a relational backend to store XML snippets to something that does the same but just uses BaseX for any data storage and is much better at querying using sophisticated XPaths. So from that previous API I learned about RFC 7807. [4]
RFC 7807 “Problem Details for HTTP APIs” [5] is one of several specification now available for reporting errors from REST APIs. This specification explicitly states how the errors should look like in XML as well as in JSON.
Maybe this is a bit bold, but I used the URL of that very RFC 7807 as the resolved URI for my module. [6] Please note: I have to admit my modules have something unusual in common: I use the namespace prefix “_” within the module and only use a more talking prefix when I use a module elsewhere. So, the “_” prefix can map to numerous URIs in my code. I am not 100% sure if there are down sides to this style but I use it for a while now and no problems come to mind.
I really dislike to get an error, especially during development of some service, without any indication of where that actually occurred. That is to say: I like stack traces in my errors. It also would be great if any runtime error in my code would be reported as XML or JSON, depending on the format the browser asked for, just as errors I explicitly raise.
A few parts provided by BaseX greatly help in getting all of this packaged in some xqm-file.
- A stack trace is always available in “$err:additional” when catching
errors [7]
- One catch-all error handler can be installed (“declare
%rest:error('*') function”, although there are minor downsides to this catch-all handler) [8]
- The XML based direct format BaseX uses to store JSON by default makes
it very easy to transform RFC 7807 XML to JSON [9]
- It is easy to query the request header anywhere in RestXQ XQuery code
running on BaseX [10]
I tried to have easy to remember function names that make the code readable as if it was a sentence. Therefore for example, I created a function wrapping the users code that says “return api-problem:or-result(user_function#x, [params, …])”[11]. Another example would be “return api-problem:result(<problem>[…]</problem>)”.
I also wanted to come up with an “intuitive way” to send standard HTTP response codes. What I came up with is a special namespace and a mapping of status codes to standard messages that is part of my module. So for example a status code 404 can be returned like this: “error(xs:QName('response-codes:_404'), $api-problem:codes_to_message(404), 'A custom message')” [12]. Something similar is probably possible with “web:response-header()” but with the error function something like if
let $check_file_exists := if (not(file:exists($path))) then error(xs:QName('response-codes:_404'), $api-problem:codes_to_message(404), 'A custom message')
at the top of a more complex RestXQ function is possible. There is no need to wrap custom code in one or several “if () then else” blocks. This helps readability in my opinion very much, especially if you have to check quite a few things before, say, writing something to the database.
The idea also works great with permission checks that use %perm:check annotations. My first use of my api-problem module predates the addition of these helpful annotations. [13]
A while before we had a HTTP header parameter that gave us the execution time, I wanted to measure execution time. So the functions take an xs:integer that should be obtained using “prof:current-ns()” [14] as the very first variable in a RestXQ function and I try to execute a second “prof:current-ns()” as late as I can imagine in my module [15]. That way I think I get a reasonably accurate timing result in my outputs as long as the respective error does not come from the catch-all handler.
I also incorporated a quick and dirty HTML page rendering function that displays an error in detail if someone needs that [16]. As a small addition this error page can link to error descriptions in the W3C standards. [17]
By the way: developing this started on BaseX but then we had similar needs in another open-source XML database existing today so I tried to port the code. Not only worked that rather well (probably also because I know the XQuery needed there rather well too), I also had a few new ideas and added them back to the BaseX version. May be there is some left over code in the module at the moment that reimplements some helpful, non-standard XQuery functions for this reason. The code is somewhat portable.
A few thoughts:
- Some say that it is necessary for security purposes to disable any
stack traces in production environments. I am not really believing this does much good. But if one does not want to hard code a Boolean switch in the modules source code: What would be the fastest external source one could use in terms of compile, optimizing and execution time? Are stack traces not available as “$err:additional” when RESTXQERRORS are switched off?
- Is there any sane way to get a QName with an unknown prefix of an
error as a string like in the catch all handler and resolve it against all prefix-URI mappings known in some XQuery program?
[1]
https://github.com/acdh-oeaw/vleserver_basex/blob/main/vleserver/users.xqm#L... [2] https://github.com/acdh-oeaw/vicav-app/blob/master/http.xqm#L24-L55 [3] https://api-tools.getlaminas.org/ [4]
https://api-tools.getlaminas.org/documentation/modules/api-tools-api-problem [5] https://datatracker.ietf.org/doc/html/rfc7807 [6]
https://github.com/acdh-oeaw/api-problem4restxq/blob/master/api-problem/api-... [7] https://docs.basex.org/wiki/XQuery_3.0#Try.2FCatch [8] https://docs.basex.org/wiki/RESTXQ#Catch_XQuery_Errors [9] https://docs.basex.org/wiki/JSON_Module#Direct [10] https://docs.basex.org/wiki/Request_Module#request:header [11]
https://github.com/acdh-oeaw/api-problem4restxq/blob/master/tests/api-proble... [12]
https://github.com/acdh-oeaw/api-problem4restxq/blob/master/tests/http.xqm#L... [13]
https://github.com/acdh-oeaw/api-problem4restxq/blob/master/tests/http.xqm#L... [14]
https://github.com/acdh-oeaw/vleserver_basex/blob/main/vleserver/dicts.xqm#L... [15]
https://github.com/acdh-oeaw/api-problem4restxq/blob/master/api-problem/api-... [16]
https://github.com/acdh-oeaw/api-problem4restxq/blob/master/tests/api-proble... [17]
https://github.com/acdh-oeaw/api-problem4restxq/blob/master/api-problem/api-...
Best regards
-- Mag. Ing. Omar Siam Austrian Center for Digital Humanities and Cultural Heritage Österreichische Akademie der Wissenschaften | Austrian Academy of Sciences Stellvertretende Behindertenvertrauensperson | Deputy representative for disabled persons Wohllebengasse 12-14, 1040 Wien, Österreich | Vienna, Austria T: +43 1 51581-7295 omar.siam@oeaw.ac.at | www.oeaw.ac.at/acdh
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%22,replace(@href,%22/blob/%22,%22/"))
(: 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.
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/c... ") [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%22,replace(@href,%22/blob/%22,%22/"))
(: 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.
XQuery Compiler Life would be so easy if there was only one module per URI … Thanks for your analysis and the minimized example.
On Sun, Apr 24, 2022 at 2:05 PM Andy Bunce bunce.andy@gmail.com wrote:
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/c... ") [XQST0049] Duplicate declaration of static variable $_:basePath.
I note that:
- "changes.xqm" imports "utils.xqm" and "data/changes.xqm"
- "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%22,replace(@href,%22/blob/%22,%22/"))
(: 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.
It is hard...Working on the scope chain gang :)
https://www.songlyrics.com/sam-cooke/working-on-the-chain-gang-lyrics/
On Sun, 24 Apr 2022 at 13:26, Christian Grün christian.gruen@gmail.com wrote:
XQuery Compiler Life would be so easy if there was only one module per URI … Thanks for your analysis and the minimized example.
On Sun, Apr 24, 2022 at 2:05 PM Andy Bunce bunce.andy@gmail.com wrote:
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/c... ") [XQST0049] Duplicate declaration of static variable $_:basePath.
I note that:
- "changes.xqm" imports "utils.xqm" and "data/changes.xqm"
- "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.
Although this can run into issues like #[1194]. For example trying to do all modules...
(: 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%22,replace(@href,%22/blob/%22,%22/"))
(: get namespace prefixes in use :) return $mods!( try{ inspect:xqdoc(.)/*:namespaces } catch * {$err:description})
The upper code snippet can be evaluated with the latest snapshot, as all URLs will now be normalized similar to local file paths [1,2]. Work on the scope chain gang still in progress ;)
[1] https://github.com/BaseXdb/basex/issues/2093 [2] https://files.basex.org/releases/latest/
I imagine reworking the scopes will be very much non-trivial. (I am just happy I found that "simple" example - XQST0049 has been troubling me for years)
Thanks, for this and all your great work on BaseX.
/Andy
On Mon, 25 Apr 2022 at 15:13, Christian Grün christian.gruen@gmail.com wrote:
Although this can run into issues like #[1194]. For example trying to do
all modules...
(: 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%22,replace(@href,%22/blob/%22,%22/"))
(: get namespace prefixes in use :) return $mods!( try{ inspect:xqdoc(.)/*:namespaces } catch * {$err:description})
The upper code snippet can be evaluated with the latest snapshot, as all URLs will now be normalized similar to local file paths [1,2]. Work on the scope chain gang still in progress ;)
[1] https://github.com/BaseXdb/basex/issues/2093 [2] https://files.basex.org/releases/latest/
Hi Andy, Hi Christian,
I am happy to have sparked an interesting discussion about modules.
Am 20.04.2022 um 18:47 schrieb Andy Bunce:
Hi Omar,
Thanks for this. I also enjoyed your earlier message re:
I tried to get creative at finding a way to optimize querying the data without having many long lasting
global lock situations I have been in a similar situation and discovered how alternative code approaches using different builtin functions can have very different lock profiles. I am hopeful that #[2063] will greatly reduce locking issues.
I will try my "worst case" Data with my API with new BaseX release. I will post any changes I see.
Is there any sane way to get a QName with an unknown prefix of an
error as a string like in the catch all handler and resolve it against all prefix-URI mappings known in some XQuery program?
I will try to integrate your idea, Andy, into the generic error handler. This routine just gets the string representation of the error with prefix:value and not a Clark notation like {urn:_}value I hope this is not a big performance hit. If you feel like it a PR would be much appreciated.
I will post more thoughts on my modules soon, just have to prepare some workshop right now.
Best regards
Hi Omar,
I am hopeful that #[2063] will greatly reduce locking issues.
I will try my "worst case" Data with my API with new BaseX release. I will post any changes I see.
Good to hear! Please note, however, that static and dynamic compilation (#2063) has not been finalized yet, but it will be part of BaseX.
Cheers, Christian
basex-talk@mailman.uni-konstanz.de
-
Andy Bunce -
Christian Grün -
Omar Siam