Re: [Json] What is a JSON-text? [REVISITED]

I think you might make more headway if you think about the primary role of 4627 and 4627bis
as registering Internet Media Types.  Consider, for example, having two media types

text/json and text/json+

the first of which is 4627 compatible, and the second (text/json+) allowing "non-container"
top level.

Everything that is valid text/json would also be valid text/json+ with the same interpretation.

Or, you could keep the same internet media type and just declare it an extension,
like image/gif changed for GIF89a. Or Postscript changed and still kept
application/postscript. Yes, it's a change, no it fits within the convention of Internet
Media Types to accept extensions that are lexically distinguishable.

> -----Original Message-----
> From: json-bounces@ietf.org [mailto:json-bounces@ietf.org] On Behalf Of
> Stefan Drees
> Sent: Thursday, October 03, 2013 12:22 PM
> To: Nico Williams
> Cc: Matt Miller (mamille2); Tim Bray; JSON WG
> Subject: Re: [Json] What is a JSON-text? [REVISITED]
> 
> On 2013-10-03 20:24 +02:00, Nico Williams wrote:
> > On Thu, Oct 3, 2013 at 12:51 PM, Stefan Drees <stefan@drees.name> wrote:
> >> Me also very strongly against "non-container" top-level entities.
> >>
> >> Additional rationale:
> >> - Add two bytes to wrap the serialized/transported value into array or
> >>    say six bytes and use eg. {"d":my_top_level_value} should be cheap
> >>    for the benefit of producing a JSON-text.
> >
> > That's very lame; see below for rationale.
> >
> >> Even if value is king, values like strings, numbers, true, false or null
> >> just wrapped into "no clothes" make me wonder why one would serialize (or
> >> forward) them as advertised JSON-text in the first place.
> >
> > Because JSON isn't always used to transport values across networks
> > (where it'd be silly to send scalar values with all the overheade of
> > HTTP and TCP/IP, say).  JSON is often used for interop between local
> > components, where the overhead that would make laughable the use of
> > scalar values at the top-level just doesn't apply.  E.g., the Python
> > bindings to libjq.  Indeed, here your suggestion that I call "lame"
> > *adds* undesirable overhead.
> >
> > "But JSON is an interchange format for networking" is not a good
> > answer to that.  It's a good interchange format, full stop.  The train
> > with JSON used for local interchange purposes left the station.  This
> > is why parsers commonly have an option to accept scalar values at the
> > top-level.
> 
> 
>   ... and no one stops implementers nor users from parametrizing a
> parser to adapt to special situations.
> 
> Say there is a document named pi.json that contains the text /3.14/ (but
> without the slashes) that may be the (best effort) serialized
> representation of the "number" pi or just the first four bytes, as the
> file became truncated (or the local message content if you are so
> inclined). As a JSON text wraped inside array or object, the situation
> would be clear, in the above "unwrapped" case it is not anymore.
> 
> So I think, the above '[...]values like strings, numbers, true, false or
> null just wrapped into "no clothes" make me wonder why one would
> serialize (or forward) them as advertised JSON-text in the first place.'
> remains as it stands, doesn't it?
> 
> Whatever un-"lame" and un-"laughable" ;-) "train has left the station",
> I guess that without making "wrapping" mandatory for JSON-text, one
> might consider JSON-izing every binary protocol on earth into such an
> unwrapped JSON+* channel (by combining the unlimited "number" feature of
> the JSON rfc and "interpreting" some representation bilaterally
> negotiated as the underlying bit pattern for the stored/transmitted
> binary protocol message).
> 
> The set of relations, where one uses JSON as a means to communicate
> between otherwise unrelated components, that are on one hand so closely
> coupled, that no wrapping is needed, but on the other hand so far apart,
> that they cannot accept non JSON-text (as it stands now) looks similar
> to the empty set to me, but I am sure, people will let me soon know of
> exotic situations ... :-)
> 
> ["Stefan"]
> 
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json