Re: [Json] Allow any JSON value at the top level

Lots of people do this, in my experience, including me pretty often.

The original specification has an asymmetry in what values may be sent
at the top level motivated by an encoding-detection scheme that is now
obsolete. Some people seem to like it because composite values are a
good idea for top-level payloads, but if that were the case one ought
to object on similar principle to any value that does not permit
further arbitrary sub-structure (like a number). Sometimes a number is
just a number. And arrays are a poor choice for arbitrarily complex
metadata anyway.

The big problem with the current requirement is that arbitrary
sub-values of a JSON value cannot be sent as application/json. So for
instance, if you wish to implement a form of PATCH on a JSON document,
you must demand that clients wrap their new value in a JSON object or
array instead of sending raw primitive values. If you implement a
service returning an inherently primitive value (e.g. a plain-text
document server) you must wrap your responses in a JSON object or
array even though there is nothing else that could reasonably be
added. A system designer might be justified in saying that every
response is an object, but the spec shouldn't dictate what is really a
matter of taste (use of in-band rather than out-of-band metadata).

On Sun, Jun 9, 2013 at 3:54 PM, Markus Lanthaler
<markus.lanthaler@gmx.net> wrote:
> On Sunday, June 09, 2013 11:06 PM, R S wrote:
>>> Why can't a separate media type, e.g., application/json-value,
>>> be defined allowing this?
>>
>> We could do that, but it might be a bit pointless. It won't change
>> the fact that primitive values are already sent as application/json.
>
> Who's doing that?
>
>
> --
> Markus Lanthaler
> @markuslanthaler
>
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json