HI Chris, Actually, it would be great if you can fix this since as you mentioned have touched this part of the code. Please confirm.
Cheers, Sattam On Wed, Aug 5, 2015 at 10:23 AM, Chris Hillery <[email protected]> wrote: > 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 > better?) > > 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? > > Ceej > aka Chris Hillery > > On Wed, Aug 5, 2015 at 12:05 AM, Mike Carey <[email protected]> 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 <[email protected]> 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? > >>> > >> > >> > > >
