Re: [Json] Call for real-world examples of how parsers deal with duplicate keys

[Tatu Saloranta <[e-mail]>]

On Thu, Jun 6, 2013 at 3:35 PM, Nico Williams <[e-mail]> wrote:

> On Thu, Jun 6, 2013 at 2:37 PM, Tatu Saloranta <[e-mail]>
> wrote:
> > On Java, Jackson library:
> >
> > - Exposes both entries (key/value pairs) at streaming parsing level
>
> I don't think we should disqualify that sort of streaming parser
> implementation.
>
> This leads me to conclude that we should distinguish between streaming
> and stateful parsers (my terms; please suggest better ones).  Stateful
> parsers MUST accept only the last value, while streaming parsers MAY
> (and probably always will) accept all duplicate keys' values.
>
> Nico
> --
>

I agree with this.

It also goes to terminology: term "parser" is being used quite liberally,
meaning anything from tokenizer, to the thing that builds higher level
object representation (JSON-centrics trees, or host language objects), or
combination of the whole thing.
In this respect, related thread that tries to divide specification into
different sections makes sense; physical structure and serialization are
most related to low-level tokenization/generation, and then optional
logical model(s) more to builders/serializers.

Same is true for encoding aspects: at logical model level, underlying
character encoding is irrelevant. But for low-level tokenization it
matters: question like how encoding is obtained; or if no encoding
information is available, what are possible encodings (only UTF-8? UTF-8
and UTF-16 since two can be auto-detected?).

To me separation of physical and logical layers makes sense, even if most
users are not aware of separation of the two: implementors can not ignore
this.

-+ Tatu +-