ietf
[Top] [All Lists]

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

2013-01-05 19:48:57
Robert,

I neither represent the WG (except in as far as I attempt to do so as document 
editor), nor do I judge consensus in the WG (the Chairs do, although at this 
late date, the IESG are making the decisions).

That said, if we were starting this from scratch, I *personally* could see 
adding some syntax to distinguish intent, as I don't see it causing any huge 
amount of harm (besides leading some to believe that JSON Pointer is a 
proto-schema language). 

However, at this point, doing so really a judgement call; we have multiple 
implementations, and we shouldn't force them to change arbitrarily. 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). 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.

Soon, the IESG will make its determination, so you'd likely be much more 
productive by laying out your argument cogently to them, rather than focusing 
on me.

If we were to open up to further changes, I'd like to see us discuss things 
like allowing header modifications in the format, and specifying the target's 
intended media type (which was already discussed and rejected in the WG). 

However, I'm even more interested in getting this format published, in the 
knowledge that HTTP PATCH has been defined for some time, but is effectively 
useless (at least against JSON) without any defined, stable patch format. If we 
find serious deficiencies, nothing stops us, or you, or anyone else from 
defining a new patch format (as James is already doing).

Cheers,


On 06/01/2013, at 11:19 AM, Robert Sayre <sayrer(_at_)gmail(_dot_)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 <mnot(_at_)mnot(_dot_)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 <sayrer(_at_)gmail(_dot_)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 <matt(_at_)mpcm(_dot_)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 
<jasnell(_at_)gmail(_dot_)com> wrote:




On Sat, Dec 15, 2012 at 8:36 PM, Robert Sayre 
<sayrer(_at_)gmail(_dot_)com> wrote:

On Fri, Dec 14, 2012 at 9:17 AM, Markus Lanthaler
<markus(_dot_)lanthaler(_at_)gmx(_dot_)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:jasnell(_at_)gmail(_dot_)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(_dot_)lanthaler(_at_)gmx(_dot_)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-bounces(_at_)ietf(_dot_)org [mailto:apps-discuss-
bounces(_at_)ietf(_dot_)org] On Behalf Of The IESG
Sent: Tuesday, December 11, 2012 4:01 PM
To: IETF-Announce
Cc: apps-discuss(_at_)ietf(_dot_)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(_at_)ietf(_dot_)org mailing lists by 2012-12-25. Exceptionally, 
comments
may
be
sent to iesg(_at_)ietf(_dot_)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-discuss(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/apps-discuss

_______________________________________________
apps-discuss mailing list
apps-discuss(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/apps-discuss




_______________________________________________
apps-discuss mailing list
apps-discuss(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/apps-discuss




_______________________________________________
apps-discuss mailing list
apps-discuss(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/apps-discuss




--
Matthew P. C. Morley
_______________________________________________
apps-discuss mailing list
apps-discuss(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/apps-discuss

--
Mark Nottingham   http://www.mnot.net/




--
Mark Nottingham   http://www.mnot.net/




<Prev in Thread] Current Thread [Next in Thread>