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. > 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. > 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. > However, I'm even more interested in getting this format published, Well, I guess someone has something they want to ship... - 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/ > > >
