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

[Tatu Saloranta <[e-mail]>]

On Wed, Jul 3, 2013 at 2:37 PM, Nico Williams <[e-mail]> wrote:

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

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.

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.

-+ Tatu +-