Re: [Json] I-JSON Tpic #2: Top-Level

Requiring an object at the top level breaks the symmetry of JSON,
rules out many useful applications (or requires a clumsy envelope for
them), and needlessly conflicts with actual practice. It is solving a
problem I am not convinced anyone really runs into - using (say) a
JSON string instead of a JSON object and then oops not being able to
pass along some extra metadata later (and for some reason HTTP headers
or some similar mechanism won't work). In fact one of the nice things
about JSON is that if you change your mind and decide to send objects
instead of strings in some application you can know that the transport
will support them; you can even allow older senders to keep sending
strings, and new ones to send objects, and have the receiver accept
both. Requiring further future-proofing with top-level objects seems
very invasive.

On Mon, Apr 28, 2014 at 1:36 PM, Nico Williams <nico@cryptonector.com> wrote:
> On Mon, Apr 28, 2014 at 3:20 PM, Tim Bray <tbray@textuality.com> wrote:
>> Protocols with messages which are objects are better than other protocols,
>> because they are architecturally friendly to MustIgnore policies.
>>
>> Allowing top-level JSON to be a primitive - true, null, 42 - is batshit
>> crazy for anything the IETF might contemplate, and one of I-JSON’s main
>> virtues is ruling that out.
>
> What if the service outputs JSON texts output by a jq program supplied
> by the client and applied to server-side data?
>
>> I don’t think top-level arrays are actively harmful at the same level, but
>> the MustIgnore is a pretty big value-add, forcing people to sort-of
>> future-proof themselves even when they haven’t realized why that’s a good
>> idea.
>
> Why can't schema changes be communicated out-of-band?  Apps request
> JSON in a particular schema; servers report the schema when the schema
> was not requested...
>
> I can see the value in recommending the use of top-level objects in
> general, just not in requiring it.
>
> Still, I think if you want to say "so don't use I-JSON", I think
> that's mostly fine.  The only problem that comes up is the possibility
> that I-JSON would crowd out JSON to the point where non-I-JSON might
> not be usable.  I think what I'd want to see there is that JSON
> parsers should really just have an option as to this, rather than have
> I-JSON parsers that are not also JSON parsers.
>
> Nico
> --
>
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json