Re: [Json] Parser and encoder options (Re: The names within an object SHOULD be unique.)

["Pete Cordell" <[e-mail]>]

Original Message From: "John Cowan"

> Nico Williams scripsit:
>
>> I think we should formalize the concept of options for parsers and 
>> encoders.
>>
>> For example, it's common to have options for pretty printing JSON.
>> And there's been talk of extensions, so why not have some useful
>> extensions (like comments, or string join, like in C, for
>> pretty-printing purposes)?
>>
>> We should also have a taxonomy for describing an implementation.
>> We've seen the need to distinguish between streaming and non-streaming
>> parsers.  (For now that's my only contribution to such a taxonomy.)
>
> While all these things are nice-to-haves, they are why specs balloon up
> to dozens or even hundreds of pages, and become impossible for anyone
> but large, well-funded organizations to implement.  I do most strongly
> urge this group NOT to go there.


+1

Surely we don't want to go down the path of protocol specs say "This 
protocol requires a JSON streaming parser" or "This protocol requires a JSON 
non-streaming parser" etc.  We just want to use JSON.

Douglas said the text "The names within an object SHOULD be unique" should 
have been "The names within an object MUST be unique".  IMO by defining a 
fall-back mechanism we're justifying having non-unique names and we're 
actually weakening the requirement to something like "The names within an 
object MAY be unique".  Is that the direction we want to go in?

Pete Cordell
Codalogic Ltd
C++ tools for C++ programmers, http://codalogic.com
Easily read & write XML in C++, http://www.xml2cpp.com