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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 <jasnell@xxxxxxxxx> wrote:



On Sat, Dec 15, 2012 at 8:36 PM, Robert Sayre <sayrer@xxxxxxxxx> wrote:
On Fri, Dec 14, 2012 at 9:17 AM, Markus Lanthaler
<markus.lanthaler@xxxxxxx> 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:jasnell@xxxxxxxxx]
> 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.lanthaler@xxxxxxx> 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-bounces@xxxxxxxx [mailto:apps-discuss-
> > bounces@xxxxxxxx] On Behalf Of The IESG
> > Sent: Tuesday, December 11, 2012 4:01 PM
> > To: IETF-Announce
> > Cc: apps-discuss@xxxxxxxx
> > 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@xxxxxxxx mailing lists by 2012-12-25. Exceptionally, comments may
> > be
> > sent to iesg@xxxxxxxx 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-discuss@xxxxxxxx
> > https://www.ietf.org/mailman/listinfo/apps-discuss
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>
>
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/apps-discuss
>


_______________________________________________
apps-discuss mailing list
apps-discuss@xxxxxxxx
https://www.ietf.org/mailman/listinfo/apps-discuss




--
Matthew P. C. Morley

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]