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 <christian.gr...@gmail.com> 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 > <http://docs.basex.org/wiki/RESTXQ#Paths> > > > > Am 09.07.2017 17:23 schrieb "Emmanuel Chateau" <emchat...@laposte.net > <mailto:emchat...@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.gr...@gmail.com > > <mailto:christian.gr...@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 > > <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 <tel: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 > >>> <https://github.com/BaseXdb/basex/issues/1220> > >>> > >>> > >>> > >>> On Tue, Jul 4, 2017 at 1:17 PM, Omar Siam <omar.s...@oeaw.ac.at > >>> <mailto:omar.s...@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 > >>>> <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 > >>>> > >>>> > >> > >
