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. >>> 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. Ah. I meant that the WG seems to be favoring "running code" a little too heavily in the presence of a bug. It's an old argument, and it's boring: "We can't change it now, there are already twelve users!" > > Always a pleasure, Rob. That tone leaves something to be desired, but no matter. This is a bug and the WG should fix it. I don't think more process emails are necessary. - Rob On Sat, Jan 5, 2013 at 6:59 PM, Mark Nottingham <m...@mnot.net> wrote: > On 06/01/2013, at 1:29 PM, Robert Sayre <say...@gmail.com> wrote: > >> On Sat, Jan 5, 2013 at 5:48 PM, Mark Nottingham <m...@mnot.net> 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 <say...@gmail.com> 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 <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/ >>>>> >>>>> >>>>> >>> >>> -- >>> Mark Nottingham http://www.mnot.net/ >>> >>> >>> > > -- > Mark Nottingham http://www.mnot.net/ > > >
