[{"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" <say...@gmail.com> wrote:
> On Sat, Jan 5, 2013 at 8:55 PM, James M Snell <jasn...@gmail.com> wrote:
> >
> > On Jan 5, 2013 8:20 PM, "Robert Sayre" <say...@gmail.com> wrote:
> >>
> >> On Sat, Jan 5, 2013 at 6:59 PM, Mark Nottingham <m...@mnot.net> 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
>
