Re: [Json] Proposed minimal change for duplicate names in objects

[Tatu Saloranta <[e-mail]>]

On Sat, Jul 6, 2013 at 7:57 PM, Nico Williams <[e-mail]> wrote:

> On Sat, Jul 6, 2013 at 8:44 PM, Tim Bray <[e-mail]> wrote:
> > This feels like a no-brainer to me, but that’s probably because (as I’ve
> > said before) I’m an API guy, and the only use for JSON objects in my
> world
> > is to transfer a hash table or database record or whatever from here to
> > there, and there, and in such a situation dupes can never be useful or
> > intended and can only be a symptom of breakage (or, in the JOSE case, a
> > symptom of a malicious attack on my crypto).
>
> I agree.  As a security guy I would prefer if one way or another we
> end up with no dup names, but as an "API guy" myself I think of the
> streaming parsers (they offer an API after all).  Just say the magic
> words: "to hell with minimal state streaming parsers" or perhaps
> something to the effect that *some* component of a layered application
> MUST reject objects with dup names.  It's either or.  Let's choose.
>
> I'm happy with "some component of a layered application MUST reject
> objects with duplicate names" -- I prefer this to the "no minimal
> state streaming parsers" alternative.
>
> I will assume that in general objects rarely have lots of names, so
> that parsers need not keep that much state in order to check for dups.
>  Requiring parsers to reject objects with dup names is my second
> choice.
>

Just to make sure: I also do not have any use for duplicates, and consider
them flaws in processing. I have never used duplicates for anything, nor
find that interesting approach.
The only concern really is that of mandating (or not) detection and/or
prevention at lowest level components of commonly used processing stacks
(low-level push/pull parser, higher-level library or app code that builds
full representations), since this is significant cost, based on extensive
profiling I have done at this level.

Case of application code directly using streaming parser/generators is not
nearly as common as that of frameworks using them to produce higher level
abstractions.
These higher level abstraction (JSON tree representation, binding to native
objects) do either report errors such as duplicates, and at very least can
detect it and use consistent handling. They can do it much more efficiently
than low-level components since they have to build representations that
then serve as data structures for detecting/preventing duplicates.

Specific concern for me is this: if specification mandates detection and/or
prevention for parser, generators, without any mention that 'parser' and
'generator' are logical concepts (thing that reads JSON, thing that writes
JSON), I will have lots of users who promptly demand low-level components
to force checks.
And then I get to spend lots of time discussing why such checks can (and
IMO should) still be pushed to higher level of processing. It is amazing
how much FUD can be generated based on cursory reading of specifications.

This concern extends to suggested "Internet JSON messages" specification.

I would like simple suggestion that some component of the processing
should/must detect and report duplicates; and prevent producing of same;
or, lengthier explanation of what "parser" and "generator" mean (parser is
such a horrible misnomer -- there is very very little parsing involved,
it's just a lexer, and optional object builder -- but I digress).

-+ Tatu +-