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

["Joe Hildebrand (jhildebr)" <[e-mail]>]

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

-- 
Joe Hildebrand