On Sat, Jun 12, 2021 at 04:23:23PM -0400, Liam R. E. Quin scripsit:
> On Sat, 2021-06-12 at 15:38 -0400, Graydon wrote:
> > This test is meant to test only that no words have been lost or
> > re-ordered; that the transformation is semantically correct is out of
> > scope for it.
>
>
On Sat, Jun 12, 2021 at 10:36:13PM +0200, Christian Grün scripsit:
> Thanks. Here’s one way how you could handle that:
[snip]
This is similar to the word-level recursive approach I am currently
taking. (though there is something to learn in the double function
approach for sure; thank you!)
>
Thanks. Here’s one way how you could handle that:
declare function local:correct($old, $new) {
empty(local:compare($old, $new))
};
declare function local:compare($old, $new) {
if(head($old) = head($new)) then (
(: skip identical lines :)
local:compare(tail($old), tail($new))
) else
On Sat, 2021-06-12 at 15:38 -0400, Graydon wrote:
> This test is meant to test only that no words have been lost or
> re-ordered; that the transformation is semantically correct is out of
> scope for it.
Somerandomwitterings...
So, i'd probably consider
(1) make a sequence of words from
Hello!
On Sat, Jun 12, 2021 at 07:11:00PM +0200, Christian Grün scripsit:
> Could you share exemplary and minimized input documents with us?
I have created some text documents and attached them. (The "remember to
throw away some metadata markup, etc." step on the way to getting text
to compare
Hi Graydon,
Could you share exemplary and minimized input documents with us?
Can the structure of the documents (hierarchy of nodes, element names,
etc.) be completely ignored?
Best,
Christian
On Sat, Jun 12, 2021 at 6:09 PM Graydon wrote:
>
> On Fri, Jun 11, 2021 at 09:15:02AM +0200, Martin
Hello,
should perm force authentication and only the user "admin" would be
authorised?
Best regards Frank
module namespace page = 'http://basex.org/test';
declare
%rest:path("basex-rest/test/check-rest-perm")
%perm:allow("admin")
%rest:GET
%output:method("xml")
function
…and exceptional kudos! ありがとう.
Hans-Juergen Rennau schrieb am Sa., 12. Juni 2021, 16:56:
> Indeed - common sense & top flexibility!
>
> Am Samstag, 12. Juni 2021, 16:45:05 MESZ hat Marco Lettere <
> m.lett...@gmail.com> Folgendes geschrieben:
>
>
> Thank you! I didn't want to disturb your
Indeed - common sense & top flexibility!
Am Samstag, 12. Juni 2021, 16:45:05 MESZ hat Marco Lettere
Folgendes geschrieben:
Thank you! I didn't want to disturb your weekend though Top quality BaseX
service! 朗
Il sab 12 giu 2021, 16:37 Christian Grün ha scritto:
Grazie, Marco.
Thank you! I didn't want to disturb your weekend though Top quality
BaseX service! 朗
Il sab 12 giu 2021, 16:37 Christian Grün ha
scritto:
> Grazie, Marco.
>
> You convinced me there is no benefit in keeping the restriction (and
> it we didn’t add it to the draft of version 2 of the spec
Grazie, Marco.
You convinced me there is no benefit in keeping the restriction (and
it we didn’t add it to the draft of version 2 of the spec either [1]).
I’ve just uploaded a new snapshot [2]; I hope it keeps you going.
Ciao, Christian.
[1]
So I guess you’ve stumbled upon an API that expects a payload with DELETE?
Yes Christian, trying to delete an application role association to a
user on the Keycloak REST APIs requires the role to be passed as JSON
object in the DELETE body [1].
So at the moment I'm able to add roles to a
Hi Marco,
The error is basically raised because that's required by the spec [1].
But it's right that the RFC2616 doesn't explicitly forbid DELETE requests
with bodies, so we could possibly get rid of the check.
So I guess you’ve stumbled upon an API that expects a payload with DELETE?
Cheers
Dear all,
I have to call an API which model an HTTP DELETE operation based on the
body of the request.
It looks like currently http:send-request is not allowing body to be
present ("Body not expected for method DELETE.").
I feel that this is bit too restrictive interpretation of the spec
14 matches
Mail list logo
