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

RFC 7159 already says that for interoperability, top level objects should
be objects or arrays.  At the simplest level, if all I-JSON does is forbid
all the things that 7159 calls out as interoperability problems, that would
be good enough for me.  The notion that i-json would *weaken* 7159’s
requirements by allowing a top level object to consist of just true or
"true" seems outlandish to me.

...It’s dawning on me that a piece on MustIgnore and why it’s a big deal
might be useful...

On Mon, Apr 28, 2014 at 2:03 PM, Jacob Davies <jacob@well.com> wrote:

> 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
>