Hi Christian, I pulled it via the Maven repo using Gradle. It says BaseX 8.3 beta 7f8299f. Maybe that doesn't carry the latest?
Re format name suggestions: format=item (not good, includes XML nodes), format=function (correct per http://www.w3.org/TR/xpath-datamodel-31/#types-representation as it includes array and map) but confusing. format=native (maybe?) I agree fully that the server should have the last say in how to process the content so I would definitely be in favor of prioritizing server parameters. Not sure if that breaks something out there though. --Marc On Tue, Aug 4, 2015 at 10:31 AM, Christian Grün <christian.gr...@gmail.com> wrote: > Hi Marc, > >> I can get this to work with %input:json format=direct/format=basic but >> when I change to format=map I still get >> >> [bxerr:BASX0003] Input could not be converted: "POST.xml" (Line 1): No >> text allowed before root element. > > Hm, it seems to work on my machine. Here is again the minimized > version (I also tried the function you sent to me; I removed the > %rest:consumes and %rest:produces annotations, because they only serve > as filters, and do not influence the conversion of $query): > > declare %rest:POST("{$query}") %rest:path("/json") > function local:json($query) { > $query > }; > > curl -XPOST -H"Content-Type:application/json;format=map" > -Tinput.json "http://localhost:8984/json"; > > Are you sure you tried the latest snapshot? > >> A second point regarding format=map. Not sure if this is the correct >> name as I could be posting "[1,2,3]" which is valid JSON. Does this >> mean there should be a format=array or would it be better to give a >> different name for this format. > > This is a valid point. It stems from the beginnings of that feature, > where the top object was always a map. Do you possibly have a > suggestion for a better name? > >> A last point I would like to make is that I still find it dubious that >> the client can specify things in a header (Content Type) that override >> the way it's porcessed on the server. > > I think it's basically a good idea to allow a client to specify > content-type parameters. But it's true that the server parameter > should probably be priorized and overwrite a client parameter, instead > of the other way round. Do you agree? > > Christian -- --Marc
