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

[Nico Williams <[e-mail]>]

On Wed, Jul 3, 2013 at 3:29 PM, Eliot Lear <[e-mail]> wrote:
> On 7/3/13 9:48 PM, Pete Resnick wrote:
>> 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."
>
> I have to say that ambiguity of a language implies an introduction to
> interoperability problems.  But MUST we use MUST in those cases?   I
> would prefer the catch the problem when we have the opportunity.  If the
> WG feels differently, Meh.  As Nico said, deal with it at a higher layer.

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.

I'd be very happy either way.

In the case of the application I mentioned object well-formedness is a
feature of the underlying DB so there's never a way to end up with
duplicate names, so using non-conformant generators/parsers is not a
problem: the result would be conformant.  As long as that's OK I'll be
happy.

Nico
--