Re: [basex-talk] oXygen XML, content negotiation and #1220

[Emmanuel Chateau]

I thought it could be done with it, but I didn’t managed with it. It’s because 
I didn’t figure out the parameter bring back the whole string and not only the 
matching part of the regex.

Thanks for your message because I tried again, and it works very fine. 
Marvelous !

I’ll try to give a working exemple in the doc.

Best regards,
Emmanuel

> Le 9 juil. 2017 à 11:39, Christian Grün  a écrit :
> 
> Hi Emmanuel,
> 
> Thanks for you mail. Indeed I believe that the path extensions are already 
> covered by the regex syntax [1]; did you already try it out?
> 
> Cheers,
> Christian
> 
> [1] http://docs.basex.org/wiki/RESTXQ#Paths 
> 
> 
> 
> 
> Am 09.07.2017 17:23 schrieb "Emmanuel Chateau"  >:
> Hallo Christian,
> 
> As you know I’m really interested by this issue.
> 
> On this topic, I was wondering if it could be possible to implement something 
> to deal with path extensions in RESTXQ.
> It would then be possible to perform later transparent content negotiation in 
> the function.
> 
> For exemple :
> ```xquery
> 
> declare
>   %restxq:path('/path/{$path}')
> function works() {
>   ' '
> }
> 
> declare
>   %restxq:path('/path/{$path}.json')
> function works() {
>   ' '
> }
> 
> (: basex shouldn’t consider it like a duplicated path :)
> 
> ```
> And a way to get the file extension in the path as a parameter. I’m not sure 
> that it is already possible with regex in path.
> 
> ```xquery
> declare
>   %restxq:path('/path/{$path}')
> function works() {
>   ' '
>   (: something to get the file extension back in a variable to do reason :)
> }
> 
> ```
> 
> Best regards,
> Emmanuel
> 
> 
> > Le 9 juil. 2017 à 11:10, Christian Grün  > > a écrit :
> >
> > Hi Omar,
> >
> >> Thanks for the answer. There is one thing I want to point out: My problem 
> >> is
> >> not the quality measure. I have problems because my client lacks them.
> >
> > Right, that’s what I understood. If quality factors are given, a
> > function should be chosen, but in your case,
> > BaseX doesn’t seem to be able to give preference to one of the two
> > given content types.
> >
> > For more details, I’ll definitely have to check how content type
> > negotiation works in JAX-RS [1]. In nearly all cases, it was a good
> > choice to adopt the rules that had been specified in this API. If it
> > turns out that the given case is implementation-defined, it may be a
> > good decision to prefer the first given content type.
> >
> > Cheers,
> > Christian
> >
> > [1] https://jcp.org/en/jsr/detail?id=339 
> > 
> >
> >
> >> sends 'application/xml,*/*' which is interpreted as: any function that
> >> either satisfies application/xml or any other mime type. Of course any othe
> >> mime type alone weill select more than one function if there is more than
> >> one function specified for a path only differentiated by mime/type in
> >> %rest:produces. The BaseX answer to this is a BASX0003 error and therefore
> >> no meaningful result.
> >>
> >> Although it is correct to assume */* does not really select any funtion in
> >> particular I find that bahavior not helpful. I should be able to specify
> >> what should be executed on */*.
> >>
> >> Furthermore when some mime type is specified alongside */* I think that */*
> >> should be ignored and that mime type used instead.
> >>
> >> Another solution would be to automatically assign a mime type more to the
> >> left in the list a slightly higher quality measure so the problem of a 
> >> equal
> >> mime types can be solved. I even think there is some standard about
> >> processing the Accept header in this manner but I may be wrong.
> >>
> >> Best Regars
> >>
> >> Omar
> >>
> >>
> >>
> >> Am 04.07.2017  um 19:36 schrieb Christian Grün:
> >>>
> >>> Hi Omar,
> >>>
> >>> Thanks for the reminder. Yes, we still plan to improve support for
> >>> quality factors in our RESTXQ implementation. We’ll probably need to
> >>> find out how this has been resolved in JAX-RS, and define an
> >>> equivalent solution for RESTXQ. I have updated the initial comment in
> >>> Issue 1220 [1].
> >>>
> >>> I am also passing this on to Adam Retter, the initiator of RESTXQ:
> >>> Adam, did you think about adding support for quality factors in the
> >>> RESTXQ implementation of eXist-db?
> >>>
> >>> And, Omar, I assume you would like to have chosen the function that
> >>> matches the first content types given in the Accept header?
> >>>
> >>> Thanks everyone,
> >>> Christian
> >>>
> >>> [1] https://github.com/BaseXdb/basex/issues/1220 
> >>> 
> >>>
> >>>
> >>>
> >>> On Tue, Jul 4, 2017 at 1:17 PM, Omar Siam  >>> > wrote:
> 
>  Hi list!
> 
>  I like my oXygen editor to request raw XML data from my RESTxq endpoints

Re: [basex-talk] oXygen XML, content negotiation and #1220

[Christian Grün]

Hi Omar,

> Thanks for the answer. There is one thing I want to point out: My problem is
> not the quality measure. I have problems because my client lacks them.

Right, that’s what I understood. If quality factors are given, a
function should be chosen, but in your case,
BaseX doesn’t seem to be able to give preference to one of the two
given content types.

For more details, I’ll definitely have to check how content type
negotiation works in JAX-RS [1]. In nearly all cases, it was a good
choice to adopt the rules that had been specified in this API. If it
turns out that the given case is implementation-defined, it may be a
good decision to prefer the first given content type.

Cheers,
Christian

[1] https://jcp.org/en/jsr/detail?id=339


> sends 'application/xml,*/*' which is interpreted as: any function that
> either satisfies application/xml or any other mime type. Of course any othe
> mime type alone weill select more than one function if there is more than
> one function specified for a path only differentiated by mime/type in
> %rest:produces. The BaseX answer to this is a BASX0003 error and therefore
> no meaningful result.
>
> Although it is correct to assume */* does not really select any funtion in
> particular I find that bahavior not helpful. I should be able to specify
> what should be executed on */*.
>
> Furthermore when some mime type is specified alongside */* I think that */*
> should be ignored and that mime type used instead.
>
> Another solution would be to automatically assign a mime type more to the
> left in the list a slightly higher quality measure so the problem of a equal
> mime types can be solved. I even think there is some standard about
> processing the Accept header in this manner but I may be wrong.
>
> Best Regars
>
> Omar
>
>
>
> Am 04.07.2017 um 19:36 schrieb Christian Grün:
>>
>> Hi Omar,
>>
>> Thanks for the reminder. Yes, we still plan to improve support for
>> quality factors in our RESTXQ implementation. We’ll probably need to
>> find out how this has been resolved in JAX-RS, and define an
>> equivalent solution for RESTXQ. I have updated the initial comment in
>> Issue 1220 [1].
>>
>> I am also passing this on to Adam Retter, the initiator of RESTXQ:
>> Adam, did you think about adding support for quality factors in the
>> RESTXQ implementation of eXist-db?
>>
>> And, Omar, I assume you would like to have chosen the function that
>> matches the first content types given in the Accept header?
>>
>> Thanks everyone,
>> Christian
>>
>> [1] https://github.com/BaseXdb/basex/issues/1220
>>
>>
>>
>> On Tue, Jul 4, 2017 at 1:17 PM, Omar Siam  wrote:
>>>
>>> Hi list!
>>>
>>> I like my oXygen editor to request raw XML data from my RESTxq endpoints
>>> to
>>> test XSL stylesheets. When I do this with RESTxq paths that have
>>> different
>>> %rest:produces it fails with the BASX0003 multiple functions error.
>>>
>>> Turns out oXygen sends application/xml, */* as Accept header without any
>>> quality.
>>>
>>> I understand that as documented in
>>> https://github.com/BaseXdb/basex/issues/1220 this is known not to work.
>>>
>>> My/our workaround is to branch in a single XQuery function using sth.
>>> like:
>>> if (some $a in tokenize(request:header("ACCEPT"), ',') satisfies $a =
>>> ('text/xml', 'application/xml')) then $xml else $xhtml
>>>
>>> I hope this is still on the agenda for 8.7.
>>>
>>> Best regards
>>>
>>> Omar Siam
>>>
>>>
>

Re: [basex-talk] Some timeDate arithmetic fail

[Christian Grün]

Hi Jan,

Thanks for the hint, this has been fixed [1,2].

Best,
Christian

[1] http://files.basex.org/releases/latest/
[2] 
https://github.com/BaseXdb/basex/commit/88a143f70efc74b1f4e917ab5085fa9b2af256b7



On Fri, Jul 7, 2017 at 6:52 PM, Jan Dölle  wrote:
> Hi,
>
> please try this:
>
> xs:dateTime("2017-07-07T18:30:00.1") - xs:dayTimeDuration("PT1S")
> = 2017-07-07T18:30:59.1 ?
>
> or that:
>
> xs:dateTime("2017-07-07T18:00:59.1") - xs:dayTimeDuration("PT1M")
> = 2017-07-07T18:00:59.1 ?
>
> I think, there is a bug :(
>
> Best Regards
>
> Jan
>
>
> --
> Jan Dölle
> E-Mail: basex-l...@id1.de Telefon +49-69-244502-0 Home: www.id1.de
>
> Information Design One AG, Baseler Straße 10, 60329 Frankfurt am Main
> Registereintrag: Amtsgericht Frankfurt am Main, HRB 52596
> Vorstand: Robert Peters, Aufsichtsrat: Christian Hecht (Vorsitz)
>
>

Re: [basex-talk] CG 40

[Christian Grün]

Gerrit, Marco, vielen Dank
per gli auguri.

Looking back, my decision
to reduce night shifts and
stop smoking in my 30’s
has severely impaired my
productivity. Now that I’ve
finally got g’scheid, let’s
see what will happen next!

Grüße, saluti, et merci à
tous por el apoyo, Christian



On Sat, Jul 8, 2017 at 10:43 AM, Marco Lettere  wrote:
> Auguri di buon compleanno!
>
> Only 40?  a youngster I'd say! :-D
>
> M.
>
>
>
> On 08/07/2017 08:28, Imsieke, Gerrit, le-tex wrote:
>>
>> “You’ll become smart at the age of forty,” a Swabian saying goes („Mit 40
>> wird man g’scheid.“, see also [1]).
>>
>> If this is true, and if the (excellent) current system is the product of
>> Christian’s pre-40 dabbling, how much more sophisticated will BaseX become
>> from now on?
>>
>> Happy birthday, Christian! Enjoy your holidays.
>>
>> —Gerrit
>>
>>
>> [1] https://de.wikipedia.org/wiki/Schwabenalter
>
>
>