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

[Stefan Drees <[e-mail]>]

On 2013-10-03 20:24 +02:00, Nico Williams wrote:
> On Thu, Oct 3, 2013 at 12:51 PM, Stefan Drees <[e-mail]> 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"]