On 06/01/2013, at 1:29 PM, Robert Sayre <[email protected]> wrote: > On Sat, Jan 5, 2013 at 5:48 PM, Mark Nottingham <[email protected]> wrote: >> >> However, at this point, doing so really a judgement call; we have multiple >> implementations, and we shouldn't >> force them to change arbitrarily. > > The word "arbitrarily" seems inappropriate here. I raised at least > four technical issues and your message addresses none of them.
... and I explained why. >> As far as I can see, you haven't convinced anyone that this is a serious >> enough problem to do so (and I don't >> appear to be the only one to hold that opinion, by any means). > > Did you read this thread? Markus Lanthaler and Conal Tuohy raised > similar points. Yes. >> Furthermore, it's not clear that the use cases you have in mind (since you >> have brought up JSON Sync) >> are in-scope for these specifications. > > That assertion is both unsubstantiated and incorrect. json-sync has > identical primitive operations to JSON Patch (create/edit/remove vs > add/replace/remove). The JSON Patch document defines Copy and Move in > terms of the add/replace, so those are mostly syntactic sugar. The > only meaningful delta is the "test" operation, and I do plan to add > that to json-sync, since it's a good way to make application-specific > assertions. 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. >> However, I'm even more interested in getting this format published, > > Well, I guess someone has something they want to ship... Right. I'll let that statement stand on its own; I think anyone who's been participating or watching the WG can assess how justified it is. Always a pleasure, Rob. > > - Rob > >> Cheers, >> >> >> On 06/01/2013, at 11:19 AM, Robert Sayre <[email protected]> wrote: >> >>> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Sat, Dec 15, 2012 at 8:36 PM, Robert Sayre <[email protected]> wrote: >>>>>>>> >>>>>>>> On Fri, Dec 14, 2012 at 9:17 AM, Markus Lanthaler >>>>>>>> <[email protected]> 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:[email protected]] >>>>>>>>> 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 >>>>>>>>> <[email protected]> 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: [email protected] [mailto:apps-discuss- >>>>>>>>>> [email protected]] On Behalf Of The IESG >>>>>>>>>> Sent: Tuesday, December 11, 2012 4:01 PM >>>>>>>>>> To: IETF-Announce >>>>>>>>>> Cc: [email protected] >>>>>>>>>> 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 >>>>>>>>>> [email protected] mailing lists by 2012-12-25. Exceptionally, comments >>>>>>>>>> may >>>>>>>>>> be >>>>>>>>>> sent to [email protected] 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 >>>>>>>>>> [email protected] >>>>>>>>>> https://www.ietf.org/mailman/listinfo/apps-discuss >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> apps-discuss mailing list >>>>>>>>> [email protected] >>>>>>>>> https://www.ietf.org/mailman/listinfo/apps-discuss >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> apps-discuss mailing list >>>>>>>>> [email protected] >>>>>>>>> https://www.ietf.org/mailman/listinfo/apps-discuss >>>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> apps-discuss mailing list >>>>>>> [email protected] >>>>>>> https://www.ietf.org/mailman/listinfo/apps-discuss >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Matthew P. C. Morley >>>>> _______________________________________________ >>>>> apps-discuss mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/apps-discuss >>>> >>>> -- >>>> Mark Nottingham http://www.mnot.net/ >>>> >>>> >>>> >> >> -- >> Mark Nottingham http://www.mnot.net/ >> >> >> -- Mark Nottingham http://www.mnot.net/
