ietf
[Top] [All Lists]

Re: [apps-discuss] Last Call: <draft-ietf-appsawg-json-pointer-07.txt> (JSON Pointer) to Proposed Standard

2013-01-05 23:59:27
[{"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(_at_)gmail(_dot_)com> wrote:

On Sat, Jan 5, 2013 at 8:55 PM, James M Snell <jasnell(_at_)gmail(_dot_)com> 
wrote:

On Jan 5, 2013 8:20 PM, "Robert Sayre" <sayrer(_at_)gmail(_dot_)com> wrote:

On Sat, Jan 5, 2013 at 6:59 PM, Mark Nottingham <mnot(_at_)mnot(_dot_)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

<Prev in Thread] Current Thread [Next in Thread>