asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hillery <>
Subject Re: json vs. JSON
Date Wed, 05 Aug 2015 07:23:17 GMT
I could take a look at this as well - it would be a natural extension of
the work I did earlier to clean up the existing JSON output. It probably
wouldn't be very difficult to do this in a relatively "dumb" way, but there
also is some amount of duplicated code between the various output formats
and it would be tempting to try and tidy that up a bit as well.

Three issues need to be addressed regardless of who does it or how:

1. We'd need to decide how to "strip down" all ADM types. In most numeric
cases it's pretty clear. For spatial types, it deserves a little bit of
thought. (It may be that the current "lossless" form is concise enough. For
example, the ADM instance { "foo" : point("5,5") } gets rendered in JSON as
{ "foo" : { "point" : [5.0, 5.0] } } . Is there something that would be

2. How would the user select this format vs. the current JSON form? When
using the HTTP interface, the main way to select the returned serialization
is via the HTTP Accept: header, and you select the "lossless JSON" form
with the MIME type application/json. If we have two different JSON
serializations, we'd need to invent a new MIME type, or introduce some kind
of additional flag, or something.

3. When using the HTTP interface, the current lossless JSON is in fact the
default output type. Should that remain the case, or should the "lossy"
JSON type be preferred?

aka Chris Hillery

On Wed, Aug 5, 2015 at 12:05 AM, Mike Carey <> wrote:

> Cool.  Sattam + Wail are going to sign up to do this, I believe!   (They
> want/need it first....)
> On 8/1/15 9:38 AM, Till Westmann wrote:
>> Only a few thoughts:
>> 1) Yes, we should definitely have that!
>> 2) For the non-numeric extended atomic types we should find a reasonable
>> string serialization and we need to provide functions to parse that
>> serialization back to the extended atomic type (and I think that we already
>> have that e.g. for the datetime types).
>> 3) I think that we already had that discussion a few times (I remember
>> arguing for it when I first joined the project) and it’s time to do it :)
>> Cheers,
>> Till
>> On Aug 1, 2015, at 9:17 AM, Mike Carey <> wrote:
>>> Hey - our JSON output format is currently designed to be non-lossy, in
>>> the sense that it encodes all the details of the source types (since ADM is
>>> JSON++ and there's quite a bit in that ++ section).  We really also need an
>>> option for "normal application users" that's lossy but produces the kind of
>>> JSON that would be expected by consuming applications that "don't
>>> appreciate" the many different kinds of numeric data, the existence of
>>> spatial data, etc.  I.e., it'd be nice to have a default lossy
>>> serialization into JSON as well....  (Note that if someone doesn't want to
>>> suffer the loss, they can always do their own out-conversions of the data
>>> in the return section of their AQL query to bridge the gap.)  Thoughts?

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