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 Omar.Siam@oeaw.ac.at 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

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" emchateau@laposte.net:

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 christian.gruen@gmail.com 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 Omar.Siam@oeaw.ac.at 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

Hi Omar, hi Emmanuel,

BaseX 9 will provide support for server-side quality factors [1,2]: With these extensions, it will eventually be possible to handle cases in which a client provides no content types, and in which multiple RESTXQ conflicting functions exist for that request.

Hope this helps, Christian

[1] https://github.com/BaseXdb/basex/issues/1220 [2] http://docs.basex.org/wiki/RESTXQ#Content_Negotiation

On Sun, Jul 9, 2017 at 5:23 PM, Emmanuel Chateau emchateau@laposte.net wrote:

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 :

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.

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 christian.gruen@gmail.com 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 Omar.Siam@oeaw.ac.at 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