Re: [Json] RFC 4627bis vs RFC 6902 (JSON Patch)

[Nico Williams <[e-mail]>]

On Thu, Feb 20, 2014 at 11:35 AM, Francis Galiegue <[e-mail]> wrote:
> On Thu, Feb 20, 2014 at 6:31 PM, Barry Leiba <[e-mail]> wrote:
>>> The latter makes sense on the _producer_ of a patch operation;
>>> however, on the parser side, should a parser receive a "malformed"
>>> (f.e duplicated "op") operation, it seems to me that RFC 6902 expects
>>> the parser to raise an error -- which RFC 4627bis does not mandate.
>>
>> What do you see as a conflict?
>>
>> The JSON spec gives general parameters for JSON, and allows duplicates.
>>
>> The JSON Patch spec gives specific parameters for a specific use of
>> JSON.  For that use, duplicates are not allowed.
>>
>> That all looks just fine to me, and absolutely consistent.
>>
>
> Not to me. As I see it, 75+% of JSON parsers on the "market" just
> cannot parse JSON Patch correctly because of the restrictions imposed
> by RFC 6902. Note: parse, not emit (or "consume, not produce" -- or
> whatever metaphor suits you).

JSON Patch predates the discussions as to RFC4627bis, so a bit of
mismatch is to be expected.  JSON Patch says "objects MUST have
exactly one ..." but parser behavior is not specified, so it's unclear
if that's a requirement for encoders or parsers.  Even if you
interpret that as a requirement for parsers, the requirement may be
met by the application rather than the parser (e.g., when the
application uses an online JSON parser).

We had very many very lengthy threads on subjects like this in the
JSON WG, and I'm pretty sure that we discussed JSON Patch in
particular as well.  You might want to look at the archives.

> IOW: I don't see "MUST have a unique member named 'foo'" and
> "behaviour is unpredictable" as being consistent with one another.

The former is insufficiently prescriptive, therefore ill-defined,
therefore consistent with the latter.

FWIW, the JSON WG had proposals to improve this and other aspects of
JSON, but it was heavily constrained by _actual_ practice in the wild.

Nico
--