Mark, The WG's reasoning, as stated in your message below, seems flawed. Messages since your last communication on this matter have shown:
1) The ambiguity around arrays makes the patch format unsuitable for common concurrent editing algorithms. 2) The ambiguity is likely to occur in the real world, for a couple of different reasons. 3) It's not possible to tell whether a JSON Pointer document is syntactically correct in isolation. Additionally, you raised this point in your message below: > > the patch author already has to understand the semantics of the document > they're patching That claim does not seem to be well-justified, and it could be meaningless to the person implementing patch software (for example: https://github.com/sayrer/json-sync). This issue is a problem in practice, and it's a problem in theory as well. JSON-Patch messages aren't sufficiently self-descriptive, so they aren't appropriate for use in a RESTful system. A response containing technical reasoning seems in order, since the points raised by myself and others on this issue are unrelated to the WG's previous thinking. - Rob On Sun, Dec 16, 2012 at 9:41 PM, Mark Nottingham <m...@mnot.net> wrote: > Robert, > > This was discussed extensively in the Working Group. > > The root of the issue was that some people reflexively felt that this was > necessary, but upon reflection, we decided it wasn't; although it seems > "natural" to some, especially those coming from a static language background, > it didn't provide any utility. > > You might argue that someone who (for example) adds to "/foo/1" in the > mistaken belief that it's an array, when in fact it's an object, will get > surprising results. That's true, but if we were to solve this problem, that > person would still need to understand the underlying semantics of "foo" to do > anything useful to it -- and I'm not hearing anyone complain about that (I > hope). > > Put another way -- do you really think that people PATCHing something as if > it's an array (when in fact it's an object) is a significant, real-world > problem, given that the patch author already has to understand the semantics > of the document they're patching? I don't, and the WG didn't either. > > Regards, > > > On 17/12/2012, at 3:36 PM, Robert Sayre <say...@gmail.com> wrote: > >> The cost of fixing it seems low, either by changing the path syntax of >> JSON pointer or changing the names of operations applied to arrays. >> Array-like objects are common enough in JavaScript to make this a >> worry. The other suggestions either assume a particular policy for >> concurrent edits or require more machinery (test operation etc). >> Wouldn't it be simpler to make the patch format more precise? >> >> - Rob >> >> On Sun, Dec 16, 2012 at 4:33 PM, Matthew Morley <m...@mpcm.com> wrote: >>> I am usually lurking and struggling to keep up with these posts. But, I >>> concur with James, this really is a non-issue in practice. >>> >>> The JSON Pointer expresses a path down a JSON object to a specific context. >>> The Patch expresses a change within or to that context. >>> Everything about the both standards is about that end context. >>> >>> If you want to confirm the type of the context before applying a patch, this >>> should probably be part of a test operation. I'm not sure if this is >>> possible at this point (?), but that is where the logic should exist. >>> >>> >>> >>> On Sun, Dec 16, 2012 at 12:22 AM, James M Snell <jasn...@gmail.com> wrote: >>>> >>>> >>>> >>>> >>>> On Sat, Dec 15, 2012 at 8:36 PM, Robert Sayre <say...@gmail.com> wrote: >>>>> >>>>> On Fri, Dec 14, 2012 at 9:17 AM, Markus Lanthaler >>>>> <markus.lantha...@gmx.net> wrote: >>>>>> >>>>>> Hmm.. I think that’s quite problematic. Especially considering how JSON >>>>>> Pointer is used in JSON Patch. >>>>> >>>>> I agree--I provided the same feedback privately. It seems >>>>> straightforwardly unsound. >>>>> >>>> >>>> In practice it doesn't seem to be much of an issue. >>>> >>>> Specifically, if I GET an existing document and get an etag with the JSON, >>>> then make some changes and send a PATCH with If-Match, the fact that any >>>> given pointer could point to an array or object member doesn't really >>>> matter >>>> much. >>>> >>>> For example: >>>> >>>>> GET /the/doc HTTP/1.1 >>>> >>>> < HTTP/1.1 200 OK >>>> ETag: "my-document-tag" >>>> Content-Type: application/json >>>> >>>> {"1":"foo"} >>>> >>>>> PATCH /the/doc HTTP/1.1 >>>> If-Match: "my-document-etag" >>>> Content-Type: application/json-patch >>>> >>>> [{"op":"add","path":"/2","value":"bar"}] >>>> >>>> Generally speaking, someone should not be using PATCH to perform a partial >>>> modification if they don't already have some knowledge in advance what they >>>> are modifying. The only time the apparent ambiguity becomes an issue is >>>> when >>>> a client is blindly sending a patch to an unknown endpoint... in which >>>> case, >>>> you get whatever you end up with. >>>> >>>> - James >>>> >>>> >>>>> >>>>> - Rob >>>>> >>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Markus Lanthaler >>>>>> >>>>>> @markuslanthaler >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> From: James M Snell [mailto:jasn...@gmail.com] >>>>>> Sent: Friday, December 14, 2012 5:41 PM >>>>>> To: Markus Lanthaler >>>>>> Cc: IETF Discussion; IETF Apps Discuss >>>>>> Subject: Re: [apps-discuss] Last Call: >>>>>> <draft-ietf-appsawg-json-pointer-07.txt> (JSON Pointer) to Proposed >>>>>> Standard >>>>>> >>>>>> >>>>>> >>>>>> JSON Pointer does not distinguish between objects and arrays. That is >>>>>> not determined until the pointer is applied to an actual object >>>>>> instance... >>>>>> the pointer "/1" is valid against {"1":"a"} or ["a","b"] >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Dec 14, 2012 at 2:51 AM, Markus Lanthaler >>>>>> <markus.lantha...@gmx.net> wrote: >>>>>> >>>>>> I've asked that before but didn't get an answer. So let me ask again >>>>>> (even >>>>>> though I'm quite sure it has already been asked by somebody else). >>>>>> >>>>>> How does JSON Pointer distinguish between objects and arrays? E.g. >>>>>> consider >>>>>> the following JSON document: >>>>>> >>>>>> { >>>>>> "foo": "bar", >>>>>> "1": "baz" >>>>>> } >>>>>> >>>>>> As I read the draft, the JSON Pointer "/1" would evaluate to "baz" even >>>>>> though that's probably not what the author intended. Is there a way to >>>>>> avoid >>>>>> that? >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Markus >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Markus Lanthaler >>>>>> @markuslanthaler >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: apps-discuss-boun...@ietf.org [mailto:apps-discuss- >>>>>>> boun...@ietf.org] On Behalf Of The IESG >>>>>>> Sent: Tuesday, December 11, 2012 4:01 PM >>>>>>> To: IETF-Announce >>>>>>> Cc: apps-disc...@ietf.org >>>>>>> Subject: [apps-discuss] Last Call: <draft-ietf-appsawg-json-pointer- >>>>>>> 07.txt> (JSON Pointer) to Proposed Standard >>>>>>> >>>>>>> >>>>>>> The IESG has received a request from the Applications Area Working >>>>>>> Group >>>>>>> WG (appsawg) to consider the following document: >>>>>>> - 'JSON Pointer' >>>>>>> <draft-ietf-appsawg-json-pointer-07.txt> as Proposed Standard >>>>>>> >>>>>>> The IESG plans to make a decision in the next few weeks, and solicits >>>>>>> final comments on this action. Please send substantive comments to >>>>>>> the >>>>>>> ietf@ietf.org mailing lists by 2012-12-25. Exceptionally, comments >>>>>>> may >>>>>>> be >>>>>>> sent to i...@ietf.org instead. In either case, please retain the >>>>>>> beginning of the Subject line to allow automated sorting. >>>>>>> >>>>>>> Abstract >>>>>>> >>>>>>> >>>>>>> JSON Pointer defines a string syntax for identifying a specific >>>>>>> value >>>>>>> within a JSON document. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> The file can be obtained via >>>>>>> http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-pointer/ >>>>>>> >>>>>>> IESG discussion can be tracked via >>>>>>> >>>>>>> http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-pointer/ballot/ >>>>>>> >>>>>>> >>>>>>> No IPR declarations have been submitted directly on this I-D. >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> apps-discuss mailing list >>>>>>> apps-disc...@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/apps-discuss >>>>>> >>>>>> _______________________________________________ >>>>>> apps-discuss mailing list >>>>>> apps-disc...@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/apps-discuss >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> apps-discuss mailing list >>>>>> apps-disc...@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/apps-discuss >>>>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> apps-discuss mailing list >>>> apps-disc...@ietf.org >>>> https://www.ietf.org/mailman/listinfo/apps-discuss >>>> >>> >>> >>> >>> -- >>> Matthew P. C. Morley >> _______________________________________________ >> apps-discuss mailing list >> apps-disc...@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss > > -- > Mark Nottingham http://www.mnot.net/ > > >
