Subject: [apps-discuss] Fwd: New Version Notification for draft-ietf-appsawg-json-patch-04.txt

From: Mark Nottingham <[email-masked]>
Date: Mon, 17 Sep 2012 18:24:02 +1200

This draft incorporated some minor feedback from James and made a few error conditions explicit.

With it -- assuming that the decision to keep "test" in as-is -- I *think* we're ready for WGLC for both json-pointer and json-patch.

Cheers,

Begin forwarded message:

> From: [email-masked]
> Subject: New Version Notification for draft-ietf-appsawg-json-patch-04.txt
> Date: 17 September 2012 6:22:25 PM NZST
> To: [email-masked]
> Cc: [email-masked]
> 
> 
> A new version of I-D, draft-ietf-appsawg-json-patch-04.txt
> has been successfully submitted by Mark Nottingham and posted to the
> IETF repository.
> 
> Filename:	 draft-ietf-appsawg-json-patch
> Revision:	 04
> Title:		 JSON Patch
> Creation date:	 2012-09-17
> WG ID:		 appsawg
> Number of pages: 15
> URL:             http://www.ietf.org/internet-drafts/draft-ietf-appsawg-json-patch-04.txt
> Status:          http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-patch
> Htmlized:        http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-04
> Diff:            http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-json-patch-04
> 
> Abstract:
>   JSON Patch defines the media type "application/json-patch", a JSON
>   document structure for expressing a sequence of operations to apply
>   to a JSON document.
> 
> 
> 
> 
> The IETF Secretariat
> 

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

---

From: "Paul C. Bryan" <[email-masked]>
Date: Mon, 17 Sep 2012 12:15:23 -0700

By recommending we go with -03's test semantics, I was not endorsing
testing for presence. For my edification, could I know the case for
testing presence is? In other words, since most operations fail if a
value is not present, in what case would it be necessary to test for
presence before applying such operations?

Paul

On Mon, 2012-09-17 at 18:24 +1200, Mark Nottingham wrote:

> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 17 Sep 2012 13:17:22 -0700

Ah, sorry - I looked at the diffs before I released, but that slipped by (will teach me to submit in an airport). 

I'll re-release without it.

Regards,

On 17/09/2012, at 12:15 PM, Paul C. Bryan <[email-masked]> wrote:

> By recommending we go with -03's test semantics, I was not endorsing testing for presence. For my edification, could I know the case for testing presence is? In other words, since most operations fail if a value is not present, in what case would it be necessary to test for presence before applying such operations?
> 
> Paul
> 
>> > To: 
>> [email-masked]
>> > Cc: 
>> [email-masked]
>> > URL:             
>> http://www.ietf.org/internet-drafts/draft-ietf-appsawg-json-patch-04.txt
>> 
>> > Status:          
>> http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-patch
>> 
>> > Htmlized:        
>> http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-04
>> 
>> > Diff:            
>> http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-json-patch-04
>> 
>> > 
>> > Abstract:

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

---

From: James M Snell <[email-masked]>
Date: Mon, 17 Sep 2012 13:30:03 -0700

Edge case question... the current description for "add" is not 100% clear
for this case:

Assume we have the following existing document...

  {"a":{}}

And we provide...

  {"add":"/a/b/c", value:"foo"}

Is this an error or will the operation create the entire path?

Likewise with "move".. given {"a":{"b":{"c":"foo"}}}

If I provide...

  {"move":"/a/b/c", to:"/x/y/z"}

What happens if neither x or y currently exist?

- James

On Mon, Sep 17, 2012 at 1:17 PM, Mark Nottingham <[email-masked]> wrote:

> testing for presence. For my edification, could I know the case for testing
> presence is? In other words, since most operations fail if a value is not
> present, in what case would it be necessary to test for presence before
> applying such operations?
> >
> > Paul
> >
> >> With it -- assuming that the decision to keep "test" in as-is -- I
> *think* we're ready for WGLC for both json-pointer and json-patch.
> >>
> >> Cheers,
> >>
> >>
> >> Begin forwarded message:
> >>
> >> > From:
> >> [email-masked]
> >>

---

From: "Paul C. Bryan" <[email-masked]>
Date: Mon, 17 Sep 2012 14:56:08 -0700

On Mon, 2012-09-17 at 13:30 -0700, James M Snell wrote:

> Edge case question... the current description for "add" is not 100%
> clear for this case:
> 
> 
> 

My original intent was for this to be an error condition, though I agree
the current language makes it unclear.

> What happens if neither x or y currently exist?

Likewise, was intended to be an error condition.

Paul

---

From: Martin Thomson <[email-masked]>
Date: Mon, 17 Sep 2012 15:15:33 -0700

Reading the description of "move", I can infer that the intent is to
specify the name of the node such that, olddoc#{move} == newdoc#{to}

This is unlike other "move" or "mv" commands where you are able to
identify a container as the target of a move.

old:
  { "a": { "b": "foo" } }
patch:
  { "move": "/a/b", "to": "/" }
new:
  { "a": {}, "b":"foo" }

I assume that it is entirely intentional that this is not supported,
but it would be nice to clarify that this is not a feature that is
provided.

--Martin

---

From: "Paul C. Bryan" <[email-masked]>
Date: Mon, 17 Sep 2012 15:21:15 -0700

>   { "move": "/a/b", "to": "/" }

This attempt at the "move" operation above will fail because there is
already a value at "/", namely an object containing a sole "a" member.

> but it would be nice to clarify that this is not a feature that is

Not only is it entirely intentional that it's not supported, it's
actually documented as such. To wit in §4.4:

"If the location in the 'to' member references a member of an existing
object in the target document, it is an error condition if a value at
the specified location already exists..." Hence, it will fail as
indicated above.

Paul

---

From: "Paul C. Bryan" <[email-masked]>
Date: Mon, 17 Sep 2012 15:50:22 -0700

Okay, I take it back; I was referring to an object, which root cannot be
inferred to be. So we have a hole where the root value of the document
is neither an array nor an object; it's merely a value. Perhaps language
stating that the root is an invalid "to" target, because it always
exists.

Paul

---

From: James M Snell <[email-masked]>
Date: Mon, 17 Sep 2012 16:35:26 -0700

+1... root never makes sense as a move to target. If the intent is to alter
the root element, use "replace" instead.

On Mon, Sep 17, 2012 at 3:50 PM, Paul C. Bryan <[email-masked]> wrote:

> **
> inferred to be. So we have a hole where the root value of the document is
> neither an array nor an object; it's merely a value. Perhaps language
> stating that the root is an invalid "to" target, because it always exists.
>
> Paul
>
> Not only is it entirely intentional that it's not supported, it's actually
> documented as such. To wit in §4.4:
>
> object in the target document, it is an error condition if a value at the
> specified location already exists..." Hence, it will fail as indicated
> above.
>
> Paul
>
>  --Martin
>
> apps-discuss mailing [email-masked]://www.ietf.org/mailman/listinfo/apps-discuss
>
>
> apps-discuss mailing [email-masked]://www.ietf.org/mailman/listinfo/apps-discuss
>
>
>

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 18 Sep 2012 12:33:42 +1000

"/" is not the root. It is an item in the root object with an empty string as its name.
Hence, Martin’s example “old” and “patch” values are valid, but they don’t produce his “new” value, nor Paul’s error. They produce { "a": {}, "":"foo" }.

old:
  { "a": { "b": "foo" } }
patch:
  { "a": {}, "":"foo" }

P.S. The empty string "" is the JSON-Pointer to the root, which will often be an object, or an array, but could also be a string, or number etc. I guess {"remove":""} is valid. It leaves an empty document (eg a resource with 0 bytes), though that isn’t a valid JSON value.

--
James Manger

From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul C. Bryan
Sent: Tuesday, 18 September 2012 8:50 AM
To: Martin Thomson
Cc: Apps Discuss; Mark Nottingham
Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-ietf-appsawg-json-patch-04.txt

Okay, I take it back; I was referring to an object, which root cannot be inferred to be. So we have a hole where the root value of the document is neither an array nor an object; it's merely a value. Perhaps language stating that the root is an invalid "to" target, because it always exists.

Paul

old:

  { "a": { "b": "foo" } }

patch:

new:

  { "a": {}, "b":"foo" }

This attempt at the "move" operation above will fail because there is already a value at "/", namely an object containing a sole "a" member.

provided.

Not only is it entirely intentional that it's not supported, it's actually documented as such. To wit in §4.4:

"If the location in the 'to' member references a member of an existing object in the target document, it is an error condition if a value at the specified location already exists..." Hence, it will fail as indicated above.

Paul

--Martin

>> From: [email-masked]<mailto:[email-masked]>

>> To: [email-masked]<mailto:[email-masked]>

>> Cc: [email-masked]<mailto:[email-masked]>

> [email-masked]<mailto:[email-masked]>

[email-masked]<mailto:[email-masked]>

[email-masked]<mailto:[email-masked]>

---

From: James M Snell <[email-masked]>
Date: Mon, 17 Sep 2012 19:36:05 -0700

Ah! Good catch. My brain had completely misfiled that little detail.

On Mon, Sep 17, 2012 at 7:33 PM, Manger, James H <
[email-masked]> wrote:

> "/" is not the root. It is an item in the root object with an empty string
> as its name.****
>
> Hence, Martin’s example “old” and “patch” values are valid, but they don’t
> produce his “new” value, nor Paul’s error. They produce { "a": {}, "":"foo"
> }.****
>
> ** **
>
> old:****
>
>   { "a": { "b": "foo" } }****
>
> patch:****
>
>   { "move": "/a/b", "to": "/" }****
>
> new:****
>
>   { "a": {}, "":"foo" }****
>
> ** **
>
> ** **
>
> P.S. The empty string "" is the JSON-Pointer to the root, which will often
> be an object, or an array, but could also be a string, or number etc. I
> guess {"remove":""} is valid. It leaves an empty document (eg a resource
> with 0 bytes), though that isn’t a valid JSON value.****
>
> ** **
>
> --****
>
> James Manger****
>
> ** **
>
> *From:* [email-masked] [mailto:
> [email-masked]] *On Behalf Of *Paul C. Bryan
> *Sent:* Tuesday, 18 September 2012 8:50 AM
> *To:* Martin Thomson
> *Cc:* Apps Discuss; Mark Nottingham
> *Subject:* Re: [apps-discuss] Fwd: New Version Notification for
> draft-ietf-appsawg-json-patch-04.txt****
>
> ** **
>
> ****
> On Mon, 2012-09-17 at 15:15 -0700, Martin Thomson wrote: ****
>
> ** **
>
>
> Reading the description of "move", I can infer that the intent is to****
>
> specify the name of the node such that, olddoc#{move} == newdoc#{to}****
>
> ** **
>
>
> This is unlike other "move" or "mv" commands where you are able to****
>
> identify a container as the target of a move.****
>
> ** **
>
> old:****
>
>   { "a": { "b": "foo" } }****
>
> patch:****
>
>   { "move": "/a/b", "to": "/" }****
>
> new:****
>
>   { "a": {}, "b":"foo" }****
>
>
> ****
> ** **
> I assume that it is entirely intentional that this is not supported,****
>
> but it would be nice to clarify that this is not a feature that is****
>
> provided.****
>
>
> ****
> ** **
> ** **
> --Martin****
> ** **
> On 16 September 2012 23:24, Mark Nottingham <[email-masked]> wrote:****
>
> > This draft incorporated some minor feedback from James and made a few error conditions explicit.****
>
> >** **
>
> > With it -- assuming that the decision to keep "test" in as-is -- I *think* we're ready for WGLC for both json-pointer and json-patch.****
>
> >** **
>
> > Cheers,****
>
> >** **
>
> >** **
>
> > Begin forwarded message:****
>
> >** **
>
> >> From: [email-masked]****
>
> >> Subject: New Version Notification for draft-ietf-appsawg-json-patch-04.txt****
>
> >> Date: 17 September 2012 6:22:25 PM NZST****
>
> >> To: [email-masked]****
>
> >> Cc: [email-masked]****
>
> >>** **
>
> >>** **
>
> >> A new version of I-D, draft-ietf-appsawg-json-patch-04.txt****
>
> >> has been successfully submitted by Mark Nottingham and posted to the****
>
> >> IETF repository.****
>
> >>** **
>
> >> Filename:      draft-ietf-appsawg-json-patch****
>
> >> Revision:      04****
>
> >> Title:                 JSON Patch****
>
> >> Creation date:         2012-09-17****
>
> >> WG ID:                 appsawg****
>
> >> Number of pages: 15****
>
> >> URL:             http://www.ietf.org/internet-drafts/draft-ietf-appsawg-json-patch-04.txt****
>
> >> Status:          http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-patch****
>
> >> Htmlized:        http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-04****
>
> >> Diff:            http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-json-patch-04****
>
> >>** **
>
> >> Abstract:****
>
> >>   JSON Patch defines the media type "application/json-patch", a JSON****
>
> >>   document structure for expressing a sequence of operations to apply****
>
> >>   to a JSON document.****
>
> >>** **
>
> >>** **
>
> >>** **
>
> >>** **
>
> >> The IETF Secretariat****
>
> >>** **
>
> >** **
>
> > --****
>
> > Mark Nottingham****
>
> > http://www.mnot.net/****
>
> >** **
>
> >** **
>
> >** **
>
> >** **
>
> > _______________________________________________****
>
> > apps-discuss mailing list****
>
> > [email-masked]****
>
> > https://www.ietf.org/mailman/listinfo/apps-discuss****
>
> _______________________________________________****
>
> apps-discuss mailing list****
>
> [email-masked]****
>
> https://www.ietf.org/mailman/listinfo/apps-discuss****
>
> ** **
>
> ** **
>
> _______________________________________________****
>
> apps-discuss mailing list****
>
> [email-masked]****
>
> https://www.ietf.org/mailman/listinfo/apps-discuss****
>
> ** **
>

---

From: "Paul C. Bryan" <[email-masked]>
Date: Mon, 17 Sep 2012 19:53:13 -0700

You're right, thanks! So, "/" would be a valid move-to location. ""
would yield an error condition.

Paul

On Tue, 2012-09-18 at 12:33 +1000, Manger, James H wrote:
> Hence, Martin’s example “old” and “patch” values are valid, but they
> don’t produce his “new” value, nor Paul’s error. They produce { "a":
> {}, "":"foo" }.
> 
>  
> 
> old:
> 
>   { "a": { "b": "foo" } }
> 
> patch:
> 
> P.S. The empty string "" is the JSON-Pointer to the root, which will
> often be an object, or an array, but could also be a string, or number
> etc. I guess {"remove":""} is valid. It leaves an empty document (eg a
> resource with 0 bytes), though that isn’t a valid JSON value.
> 
>  
> 
> 
> --
> 
> James Manger
> 
> 
> 
>  
> 
> 
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Paul C. Bryan
> Okay, I take it back; I was referring to an object, which root cannot
> be inferred to be. So we have a hole where the root value of the
> document is neither an array nor an object; it's merely a value.
> Perhaps language stating that the root is an invalid "to" target,
> because it always exists.
> 
> Paul 
>

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 18 Sep 2012 16:56:55 -0700

So, do we need any spec changes / clarifications here? More examples? Nothing?

On 17/09/2012, at 7:53 PM, Paul C. Bryan <[email-masked]> wrote:

> You're right, thanks! So, "/" would be a valid move-to location. "" would yield an error condition.
> 
> Paul
> 
>> On 16 September 2012 23:24, Mark Nottingham <
>> [email-masked]
>> > wrote:

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