[{"op":"type","path":"","value":"array"},{"op":"remove","path":"/1"}]
Problem solved. Still no bug, and still nothing I can see that needs fixing.
I've said my piece on it to. Afaic, this spec is done and ready to go.
- James
On Jan 5, 2013 9:25 PM, "Robert Sayre" <sayrer@xxxxxxxxx> wrote:
On Sat, Jan 5, 2013 at 8:55 PM, James M Snell <jasnell@xxxxxxxxx> wrote:
>
> On Jan 5, 2013 8:20 PM, "Robert Sayre" <sayrer@xxxxxxxxx> wrote:
>>
>> On Sat, Jan 5, 2013 at 6:59 PM, Mark Nottingham <mnot@xxxxxxxx> wrote:
>> >
>> > Yes, you've brought that to our attention several times. If you wanted
>> > this spec to align with your software, it would have been much easier
>> > if you'd got involved before Last Call.
>>
>> Well, there shouldn't be any big adjustments to my software at all,
>> and the document generally looks good. This is just a bug: two parties
>> can apply the same patch and get different results, without
>> encountering an error.
>>
>
> Not seeing the bug... applying the same patch to different resources that
> have different states ought to have different results.
This argument is fallacious. Consider this JSON patch:
{ "op": "remove", "path": "/1" }
This patch can be generated by removing a key from a hashtable by the
sender, and then applied to an array by the recipient (which may
result in array shifts etc). A good quality patch format would not
permit such an obvious ambiguity, because applying that patch can fail
all parties. The resulting document does not reflect the intent of any
author.
I have obviously said my piece. And, fwiw, I don't think the IESG
should contradict the WG.
- Rob