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

[Tatu Saloranta <[e-mail]>]

On Tue, Jul 2, 2013 at 11:57 PM, Eliot Lear <[e-mail]> wrote:

> Hi Nico,
>
> On 7/3/13 8:45 AM, Nico Williams wrote:
> > On Wed, Jul 3, 2013 at 1:35 AM, Eliot Lear <[e-mail]> wrote:
> >>> In short, for streaming parsers (and generators) there's nothing we
> can do.
> >>>
> >>> What we can do is RECOMMEND that a) generators not produce duplicates
> >>> (and explain how streaming ones cannot prevent dups), and b) that
> >>> parsers use the last name (and explain how streaming ones will produce
> >>> all dups).
> >> To me this isn't strong enough.  I have some sympathy for both the
> >> existing base and for parsers, but generators as an architectural
> >> component should generate unambiguous output, streaming or otherwise.
> >> And that follow's Postel's Law:
> > How can a streaming generator do that?  The API for one might look like:
> >
> > ObjectStart(context)
> > ObjectAdd(context, name, value)
> > ...
> >
> > There's no way a minimal-state streaming generator (but I repeat
> > myself; the whole point of a streaming interface is to keep minimal
> > state :) can detect duplicates with O(1) state (probabilistic
> > structures with false positives won't be acceptable either).
>
> You've got to retain state.  You don't have to retain the value, but you
> do have to retain the name.  It's O(k), and knowing you I know you're
> smart enough to approach that (because I am and so I'm using inductive
> theory ;-).  And I'll bet you a nickel that this is not going to be
> anyone's high order bit.
> >
>


There is difference between retaining parent path (names of "open" Object
properties), and retaining names of all preceding siblings. Latter is
expensive and/or complicated.
Former is indeed done by parsers that try to give useful error information
with respect to nesting problems and such.

I also think that probabilistic approaches would be problematic from user
POV: one has to allocate lots of memory -- not just for hashes for names
seen (or derivative thereof like Bloom filter(s)), but also locations for
error messages.

If spec did mandate requirement to check for dups, then both generators and
parsers would have to do it; and at least parsers would need additional
metadata to give proper error messages to indicate nature of collision
(what, where).

-+ Tatu +-