Re: [Json] Counterproposal #2 on work items

[Tim Bray <[e-mail]>]

I’m actually pretty sure about that one, for use in protocols.  If in some
protocol I'm going to send you 3 data items called “size”, “date”, and
“uid”, if I put them in a hash, then when for a later version we need to
add “ttl”, assuming a MUST-IGNORE policy, you can just do it.  If you’ve
put them in a tuple or some such, you have much less flexibility.  -T


On Wed, Feb 20, 2013 at 11:41 AM, Francis Galiegue <[e-mail]>wrote:

> On Wed, Feb 20, 2013 at 7:01 PM, Tim Bray <[e-mail]> wrote:
> [...]
> > - always make the top-level construct an object
>
> Why?
>
> I have the totally opposite view -- right now only arrays and objects
> are dubbed as legal JSON texts. And I have never seen a parser raise
> an error if it were fed with anything else -- nor fail to produce
> anything else, for that matter.
>
> Restricting the top level construct to objects and arrays is "bad"
> enough, but restricting it even more? I think the _opposite_ should be
> done. JSON is flexible, restricting its flexibility would be a mistake
> imho.
>
> --
> Francis Galiegue, [e-mail]
> Try out your JSON Schemas: http://json-schema-validator.herokuapp.com
>