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

[Nico Williams <[e-mail]>]

On Thu, Jun 6, 2013 at 5:21 PM, Nico Williams <[e-mail]> wrote:
> Regarding comments, I thought we'd have to accept that JSON does not
> have comments, but since there's talk of extensions, and since we
> could (and many, many parsers do) have options that can default to off
> (unavailable), we might indeed want to consider a comments option.

I forgot to finish this thought, which is just as well as this one
should have a different Subject line, so now I've an excuse to change
it.

I could certainly imagine a parser that a) accepts parse options from
the application, b) has some of the following options regarding
duplicate names:

 - take first value
 - take last value
 - aggregate all the values into an array preserving the order in
which they were received
 - return an error on duplicate names
 - warn of duplicate names
 - detect duplicate names (for streaming parsers)
 - use probabilistic duplicate name detection (also for streaming parsers)

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.)

Nico
--