Re: [Json] fun with streaming, was The names within an object SHOULD be unique.

[Tatu Saloranta <[e-mail]>]

On Sat, Aug 3, 2013 at 4:09 PM, Joe Hildebrand (jhildebr) <
[e-mail]> wrote:

> On 7/30/13 7:56 PM, "Tatu Saloranta" <[e-mail]> wrote:
>
> >This is a common use case for processing large JSON files; either output
> >as JSON arrays, or just sequences of space-separate objects. Typical data
> >sets are log output, processing from map/reduce style jobs and batch jobs.
>
> You're saying that you either produce
>
> {"a": 1, "b": 2} {"a": 3, "b": 4}
>
> or:
>
> [{"a": 1, "b": 2},{"a": 3, "b": 4}]
>
> right?  In neither of those cases does the producer have a problem
> ensuring name uniqueness.  If you've got a programming language
> description the objects in either of those cases, they are known to have
> unique names.  If you're parsing either of those as a stream and
> generating 2 events each, you'll have to deal with unique names in one of
> the four ways we've seen(*), but not when acting as an eventing parser,
> only when creating the programming language construct to hold the objects
> from the events fired.
>

Yes.


>
> >Separation between streaming part and higher layers is for good
> >separation of concern, as well as practical matter for reusing components.
>
> That is a perfectly valid design, yes.  I even like it.  It doesn't get
> away from the fact that when you reduce the events to objects in your
> programming language, you'll need to deal with duplicate names in one of
> the four ways.  Therefore, you SHOULD NOT send duplicates, since you don't
> know how they are going to be treated by the receiver.  If you control
> both ends of the conversation, then it doesn't matter what the standard
> says, and you can send any data you want, including duplicates.
>
>
(*) Reminder: error, first, last, all
>

Yes to all of above as well.

-+ Tatu +-