Re: [Json] Call for WG Consensus to Adopt I-JSON as a WG Item in the Charter

[Nico Williams <[e-mail]>]

On Mon, Mar 17, 2014 at 6:56 AM, Phillip Hallam-Baker <[e-mail]> wrote:
> On Sun, Mar 16, 2014 at 11:51 PM, Nico Williams <[e-mail]>
> wrote:
>> My main complaint is with the recommendation/requirement that JSON
>> texts be objects at the top-level.
>>
>> Instead I would say that if there's reason to need to signal "schema"
>> metadata in-band then a) application should specify how they do that,
>> b) here's a few ways in which they might, and all their pros and cons.
>>
>> Note too that there are many apps where there's no need to signal
>> schema metadata in-band because they always have some way to
>> communicate relevant metadata out of band.
>
>
> I have no problem with this as a convention in a protocol. But I don't see
> the need for that restriction in I-JSON.

If the purpose is to signal schema metadata then I'd like to explore
other conventions and go for a "you must provide such metadata"
statement in order to make yours an I-JSON usage.

> In a protocol design the spec is going to say something like 'the encoding
> is in the I-JSON subset of JSON'. Then its going to describe the format of
> the data which for a protocol is almost always gonna be an object per
> message at the top level. Though it could be an array of objects if multiple
> requests per message are supported.

Right, imagine wrapping an array of objects in an object just to
denote schema metadata.  What a pain.  You're probably streaming the
array, so now you gotta add an object around it -- and remove it -also
in a streaming manner- on the parser side.

Or perhaps you have a sequence of objects to return... should you mark
up every one of those objects?  While streaming them?  More pain.

We should consider how this markup happens.

Incidentally, we could say that the first text in a JSON text sequence
should denote schema metadata for the rest...  That would not be so
painful.  (although it would still interfere with existing usage).

Nico
--