asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Carey <>
Subject Re: "Clean JSON" proposal
Date Fri, 11 Sep 2015 13:59:40 GMT
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" <> 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" <> 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:
>> *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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message