Re: [basex-talk] RESTXQ %input:csv annotation
Sorry for the duplicate post.
From: Kendall Shaw
Date: Sunday, August 20, 2017 at 9:00 PM
To: BaseX
Subject: RESTXQ %input:csv annotation
The example produces an error saying it can’t convert string to document node:
declare
%rest:path("/store.csv")
%rest:POST("{$csv}")
%input:csv("header=true,encoding=CP1252")
function page:store-csv($csv as document-node()) {
"Number of rows: " || count($csv/csv/record)
};
I can just change the function signature and parse the string with csv:parse,
but is the example missing a detail (or am I missing a detail)?
I used this to store CSV data in the default format.
curl –XPOST –H’Content-Type: text/csv’ –data @some.csv
http://example.com/basex/store.csv
Kendall
[basex-talk] %input:csv annotation
Trying to use the example, in the RESTXQ section of the documentation:
declare
%rest:path("/store.csv")
%rest:POST("{$csv}")
%input:csv("header=true,encoding=CP1252")
function page:store-csv($csv as document-node()) {
"Number of rows: " || count($csv/csv/record)
};
Using:
curl -i -XPOST –data @test.csv -H’Content-Type:
text/csv’ http://blah/basex/store.csv
The result is [XPTY0004] Cannot cast xs:string to document-node()
I can just invoke csv:parse but, is the example missing a detail?
Kendall
[basex-talk] RESTXQ %input:csv annotation
The example produces an error saying it can’t convert string to document node:
declare
%rest:path("/store.csv")
%rest:POST("{$csv}")
%input:csv("header=true,encoding=CP1252")
function page:store-csv($csv as document-node()) {
"Number of rows: " || count($csv/csv/record)
};
I can just change the function signature and parse the string with csv:parse,
but is the example missing a detail (or am I missing a detail)?
I used this to store CSV data in the default format.
curl –XPOST –H’Content-Type: text/csv’ –data @some.csv
http://example.com/basex/store.csv
Kendall
Re: [basex-talk] RESTXQ custom response
I must confess I’ll need some time to get through this (I haven’t spent too much time with the Custom option so far). If everything works out, I’ll be able to do so in the upcoming week. If you manage to provide me with an SSCCE that show exactly what would need to happen, that would be great! Thanks, Christian On Sat, Aug 19, 2017 at 4:54 AM, Tim Thompson wrote: > Actually, I was wrong. The issue seems to be with the 401 Unauthorized > status needed with Digest authentication. I can control the header value > using both methods when the status is 200 OK, but BaseX does not allow me to > modify the WWW-Authenticate header when the status is 401. Is this something > that could be changed? > > > -- > Tim A. Thompson > Discovery Metadata Librarian > Yale University Library > > > On Fri, Aug 18, 2017 at 10:26 PM, Tim Thompson wrote: >> >> Christian, >> >> Here is a minimal example to try to illustrate what I am referring to: >> >> https://bibfram.es/basex/static/header-test.xhtml >> >> The first case (using the web:response-header() function) produces the >> desired response. You should see something like this after clicking "Test" >> (at least the first time, before caching): >> >> WWW-Authenticate Digest realm="BaseX", >> nonce="35B2F3011682300F36AD37048B7B8560" >> >> The second case (using custom elements) does not produce the desired >> response. You should see something like this after clicking "Test": >> >> WWW-Authenticate Custom realm="BaseX" >> >> >> So the two methods are not producing the same output. >> >> >> -- >> Tim A. Thompson >> Discovery Metadata Librarian >> Yale University Library >> >> On Fri, Aug 18, 2017 at 7:28 PM, Christian Grün >> wrote: >>> >>> Hm, I still need to understand: Why can't you set WWW-Authenticate via >>> standard response elements if you can do it with web:response-header (which >>> simply generates elements that you could write by yourself)? >>> >>> >>> >>> Am 19.08.2017 1:04 vorm. schrieb "Tim Thompson" : >>> >>> Yes, but that brings me back to my original issue. The standard RESTXQ >>> response headers let me set the HTTP status, but they don't let me override >>> some default header values: namely, WWW-Authenticate when BaseX is >>> configured for "Custom" authentication. The web:response-header function >>> does let me modify the header, but it does not let me set the HTTP status. >>> >>> So, there are two different solutions here; each solves part of my >>> problem, but neither one solves the whole problem :( >>> >>> Tim >>> >>> -- >>> Tim A. Thompson >>> Discovery Metadata Librarian >>> Yale University Library >>> >>> >>> On Fri, Aug 18, 2017 at 4:46 PM, Christian Grün >>> wrote: True. In many cases, you are probably more flexible by using the standard RESTXQ response headers. On Fri, Aug 18, 2017 at 4:37 PM, Tim Thompson wrote: > Right, the status can be set when using the http:response element > directly, > but the web:response-header function does not seem to provide access > to > that. It only allows one to set new headers, not set the status of the > response. > > > > > -- > Tim A. Thompson > Discovery Metadata Librarian > Yale University Library > > > On Fri, Aug 18, 2017 at 9:23 AM, Christian Grün > > wrote: >> >> Hi Tim, >> >> That should be possible as well: >> >> >> >> >> >> Cheers, >> Christian >> >> >> >> On Fri, Aug 18, 2017 at 3:20 PM, Tim Thompson >> wrote: >> > Hi, Christian, >> > >> > Yes, it does. The only issue is that there doesn't seem to be a way >> > to >> > set >> > the HTTP status and message via web:response-header, is that right? >> > This >> > would be a great feature to have :) >> > >> > Tim >> > >> > -- >> > Tim A. Thompson >> > Discovery Metadata Librarian >> > Yale University Library >> > >> > >> > On Fri, Aug 18, 2017 at 4:25 AM, Christian Grün >> > >> > wrote: >> >> >> >> Hi Tim, >> >> >> >> I am glad to hear the response header output does its job. >> >> >> >> As the function does nothing else than creating a response header >> >> (unfortunately with this standard caching directive – I think I >> >> will >> >> remove it along with BaseX 8.7), you could try to replace your >> >> response elements with the function’s result. Does this help? >> >> >> >> Christian >> >> >> >> >> >> >> >> On Thu, Aug 17, 2017 at 9:21 PM, Tim Thompson >> >> wrote: >> >> > Using the web:response-header() function from the BaseX Web >> >> > Module >> >> > seems >> >> > to >> >> > work for overriding default headers >> >> > (http://docs.basex.org/wiki/Web_Module#web:response-header). I >> >> > do >> >> >
Re: [basex-talk] bug in XPath evaluation
Hi Nikos,
I had a look at the optimized query plans. Apparently, one of the
index rewriting rules composes the inversed path in a wrong way:
db:open('bug')//@a/..[@* = "x"]
…is rewritten to…
db:attribute("bug", "x")/..[a/..]
…while it should be…
db:attribute("bug", "x")/..[@a/..]
…or (further optimized)…
db:attribute("bug", "x")/..[@a]
I have created a new issue [1], maybe I can fix it tomorrow.
Thanks,
Christian
[1] https://github.com/BaseXdb/basex/issues/1490
On Sun, Aug 20, 2017 at 3:29 PM, nikos dimitrakas wrote:
> Hi!
> I discovered a strange behavior i BaseX (8.6.5):
> I evaluate
> //S/@k/parent::*
> or
> //S/@k/..
> and it works
> I evaluate
> //S[.//@m="V"]
> and it works
> But when I evaluate
> //S/@k/parent::*[.//@m="V"]
> or
> //S/@k/..[.//@m="V"]
> it does not work. There is no error, just no result.
> At first I thought that there was an error with going to a parent of an
> attribute node, but that works. Then I thought the problem was with ".//@"
> in the predicate, but that also works. It appears that it is the combination
> that confuses the engine.
>
> Here is an xml to test the above expressions:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> I hope you can find the problem and fix it in a new version soon.
>
> Regards
> /nikos
Re: [basex-talk] bug in XPath evaluation
On 20.08.2017 15:29, nikos dimitrakas wrote: I discovered a strange behavior i BaseX (8.6.5): But when I evaluate //S/@k/parent::*[.//@m="V"] or //S/@k/..[.//@m="V"] it does not work. There is no error, just no result. When I run your path expression directly against your posted sample with //S/@k/..[.//@m="V"] in the BaseX GUI I get the following result So how do you run your query when you say you get an empty result?
[basex-talk] bug in XPath evaluation
Hi! I discovered a strange behavior i BaseX (8.6.5): I evaluate //S/@k/parent::* or //S/@k/.. and it works I evaluate //S[.//@m="V"] and it works But when I evaluate //S/@k/parent::*[.//@m="V"] or //S/@k/..[.//@m="V"] it does not work. There is no error, just no result. At first I thought that there was an error with going to a parent of an attribute node, but that works. Then I thought the problem was with ".//@" in the predicate, but that also works. It appears that it is the combination that confuses the engine. Here is an xml to test the above expressions: I hope you can find the problem and fix it in a new version soon. Regards /nikos
