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.gruen@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