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

[Pete Resnick <[e-mail]>]

Speaking strictly as a participant, and just to give guidance, not 
insist on an outcome.

On 7/3/13 1:35 AM, Eliot Lear wrote:
> Nico,
>    
>> 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.
>    

Let's remember the meaning of these capitalized words in IETF parlance. 
We use them "where it is actually required for interoperation or to 
limit behavior which has potential for causing harm." So a MUST would 
mean that not doing so would prevent interoperation or cause harm. 
RECOMMENDED (like SHOULD) would also mean that not doing so would 
prevent interoperation or cause harm, but "that there may exist valid 
reasons in particular circumstances to ignore a particular item, but the 
full implications must be understood and carefully weighed before 
choosing a different course."

In this instance, saying that generators SHOULD not produce duplicates 
is to say that if you do produce them, you might not interoperate or you 
might cause harm to some parsers, but there might be valid reasons 
(i.e., because your storage or compute footprint is too small to retain 
state) to produce duplicates. And documenting that there may be reasons 
that generators will produce duplicates (and explicitly stating those 
reasons) certainly puts parsers on notice that they will need to deal 
with it. Giving parsers some guidance on what to do in that case is all 
the better.

So I don't think saying RECOMMENDED or SHOULD regarding not producing 
duplicates should be seen as a non-starter. That's a defensible position 
for the WG to take.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - [phone]