PS-Formatting wise, where are we now on CSV in and out and header handling? (And round tripping?) On Sep 11, 2015 6:58 AM, "Mike Carey" <[email protected]> wrote:
> Very nice!! I would be inclined to switch the default, yes. Then for ADM > it would be cool to have two options as well, one "wrapped" and one > "unwrapped" (the latter being the default, and not having the outermost [ > ]). > On Sep 11, 2015 2:14 AM, "Chris Hillery" <[email protected]> wrote: > >> The current proposed "clean JSON" solution works as follows: >> >> You still request JSON output from the HTTP API via the Accept: HTTP >> header >> or via a "output" CGI query parameter, and the default output format from >> the HTTP API is still JSON. >> >> If you do nothing, you will get the same lossless JSON that we have >> provided for some time. However I have now added a parameter "clean", >> which >> if set to the value "true", selects the new "clean JSON" output. You can >> specify this parameter either via a CGI parameter or via a parameter on >> the >> MIME type specified via the Accept: HTTP header (ie., "Accept: text/csv; >> clean=true"). This is directly parallel to the ways you can request a >> header line when selecting CSV output. >> >> *Question #1: *Should "clean JSON" be the new default? If so I would >> introduce a "lossless=true" parameter for selecting the old format. >> >> *Question #2:* Is this parameter-based approach (using the same output >> format for both kinds of JSON) OK? Or should we invent a different MIME >> type to represent one of them in the Accept: header? (I think probably the >> resulting Content-Type: header in the response should be text/json in >> either case, however.) >> >> As for the actual content of clean JSON, I went with all the >> non-controversial choices for numerics, strings, boolean, records, and >> ordered/unordered lists. I went with what I believe are non-controversial >> choices for UUID, binary, and date/time types (the obvious string >> representations in all cases). Finally, for the controversial spatial >> types, I went with the simplest representation: simple arrays of numbers. >> This jibed with Mike's last comments on the lengthy thread a few weeks ago >> and with my own feelings on the matter. It also seemed like the least >> work, >> which is relevant since it also seems like we may need to change our >> spatial support anyway. >> >> You can see a hopefully self-describing example of all types in the result >> of the test case I added: >> >> https://asterix-gerrit.ics.uci.edu/#/c/362/4/asterix-app/src/test/resources/runtimets/results/scan/alltypes_01-cleanjson/alltypes_01.1.json >> >> *Quesiton #3: *Anyone want to make a last-ditch proposal for something >> different for spatials? >> >> Anyway, these changes are ready for review; have been for a couple weeks, >> in fact. >> >> Ceej >> aka Chris Hillery >> >
