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

[James M Snell <[e-mail]>]

On Jan 5, 2013 8:20 PM, "Robert Sayre" <[e-mail]> wrote:
>
> On Sat, Jan 5, 2013 at 6:59 PM, Mark Nottingham <[e-mail]> 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. #worksasintended
#wontfix #moveonthereisnothingmoretoseehere

- james

> >>> 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 <[e-mail]> wrote:
> > On 06/01/2013, at 1:29 PM, Robert Sayre <[e-mail]> wrote:
> >
> >> On Sat, Jan 5, 2013 at 5:48 PM, Mark Nottingham <[e-mail]> 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 <[e-mail]> 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 <[e-mail]>
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 <[e-mail]> 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 <[e-mail]>
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 <[e-mail]>
wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Sat, Dec 15, 2012 at 8:36 PM, Robert Sayre <[e-mail]>
wrote:
> >>>>>>>>>
> >>>>>>>>> On Fri, Dec 14, 2012 at 9:17 AM, Markus Lanthaler
> >>>>>>>>> <[e-mail]> 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:[e-mail]]
> >>>>>>>>>> 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
> >>>>>>>>>> <[e-mail]> 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: [e-mail] [mailto:apps-discuss-
> >>>>>>>>>>> [e-mail]] On Behalf Of The IESG
> >>>>>>>>>>> Sent: Tuesday, December 11, 2012 4:01 PM
> >>>>>>>>>>> To: IETF-Announce
> >>>>>>>>>>> Cc: [e-mail]
> >>>>>>>>>>> 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
> >>>>>>>>>>> [e-mail] mailing lists by 2012-12-25. Exceptionally,
comments
> >>>>>>>>>>> may
> >>>>>>>>>>> be
> >>>>>>>>>>> sent to [e-mail] 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
> >>>>>>>>>>> [e-mail]
> >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/apps-discuss
> >>>>>>>>>>
> >>>>>>>>>> _______________________________________________
> >>>>>>>>>> apps-discuss mailing list
> >>>>>>>>>> [e-mail]
> >>>>>>>>>> https://www.ietf.org/mailman/listinfo/apps-discuss
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> _______________________________________________
> >>>>>>>>>> apps-discuss mailing list
> >>>>>>>>>> [e-mail]
> >>>>>>>>>> https://www.ietf.org/mailman/listinfo/apps-discuss
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> _______________________________________________
> >>>>>>>> apps-discuss mailing list
> >>>>>>>> [e-mail]
> >>>>>>>> https://www.ietf.org/mailman/listinfo/apps-discuss
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> Matthew P. C. Morley
> >>>>>> _______________________________________________
> >>>>>> apps-discuss mailing list
> >>>>>> [e-mail]
> >>>>>> 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/
> >
> >
> >
> _______________________________________________
> apps-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/apps-discuss