asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hillery <>
Subject "Clean JSON" proposal
Date Fri, 11 Sep 2015 09:14:25 GMT
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.

aka Chris Hillery

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