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

[Nico Williams <[e-mail]>]

On Thu, Jul 4, 2013 at 5:17 PM, Tatu Saloranta <[e-mail]> wrote:
> On Wed, Jul 3, 2013 at 2:37 PM, Nico Williams <[e-mail]> wrote:
>> I think we're very likely to get consensus for SHOULD language with an
>> out for streaming generators/parsers pushing the MUST to the
>> application.
>>
>> We could force MUST with an out for streaming generators/parsers
>> pushing the MUST to the application, but it'd leave some implementors
>> on the rough side of consensus and unhappy.
>>
>
> One problem I have had is assumption that we only have 2 layers
> (application, parser/generator). While it simplifies language, it makes it
> difficult to define whether combination of parser and deserializer (as well
> as serializer and generator) should be considered "parser" (and "generator")
> in specifications or not.
> Perhaps "application" here would then refer to serialization library and
> application code?

There can be many layers.

One application I work with is a Ruby on Rails app with a DB
underneath.  In one client I have to read a very large subset of the
DB and the run with that and an audit feed from the same DB.  A JSON
streaming generator and parser that ignored duplicate names would work
just fine because schema is enforced on the *write* side and so there
can be no duplicate names, and *nothing* but the write side need ever
concern itself with duplicate names.  There's quite a few moving
pieces and layers in this one app, but only one piece that ensures
properly-formed data -- outside that piece there is no relevance to
duplicate name handling for there can't be duplicate names.

I don't think it'd be critical to wordsmith the RFC so that this app
can work with streaming generators/parsers that are oblivious to
duplicate names, but it'd be nice to.  One way to do it is to use the
passive voice.  Otherwise there might have to be a [what do we call
this?] consideration for application deverlopers using streaming
encoders/parsers that are duplicate name oblivious.  There's a
trade-off between writing very generic text (but in a passive voice)
and having to cover a number [possibly lots] of specific cases.

> I would be happy with "SHOULD" at parser/generator level, and even "MUST"
> for serializer/deserializer level, since those are cases that are easy to
> support efficiently.

That's not really enough for my use case.

> At the same time, given such separation of processing layers, nothing
> prevents applications from doing custom serialization/deserialization, and
> by-passing strict checks. I don't personally mind that -- as long as
> ramifications are made clear, it's their responsibility -- but I don't think
> is universally agreed view.

Right, "strict checks" somewhere.  Just not necessarily in the
generator nor parser.

Nico
--