Re: [Json] Counterproposal #2 on work items

["Joe Hildebrand (jhildebr)" <[e-mail]>]

+1.  Keep in mind this BCP wouldn't be defining what the legal syntax is,
but would be helping protocol designers who use JSON make sane choices
based on what we have seen work in practice.


On 2/20/13 1:14 PM, "Tim Bray" <[e-mail]> wrote:

>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
><http://json-schema-validator.herokuapp.com>
>
>
>
>
>
>



-- 
Joe Hildebrand