Subject: [apps-discuss] JSON Patch question about the remove operation

From: Francis Galiegue <[email-masked]>
Date: Fri, 8 Mar 2013 16:31:57 +0100

Hello,

I am writing an implementation of JSON Patch. Reference document:

http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-10

The question is about the remove operation (section 4.2).

The text says that the target location must exist for the operation to
succeed, which is pretty normal.

But what if the target location is the document itself? Ie,

{ "op": "remove", "path": "" }

It really means that the resulting document is, well, nothing, not
even a JSON null. Or am I missing something? Shouldn't the empty JSON
Pointer be forbidden?

--
Francis Galiegue, [email-masked]
JSON Schema in Java: http://json-schema-validator.herokuapp.com

---

From: Francis Galiegue <[email-masked]>
Date: Fri, 8 Mar 2013 17:34:44 +0100

> The question is about the remove operation (section 4.2).

Well, I have another question about, this time, the move operation.

Say we have this data:

[ "victim", {}, {} ]

and this patch:

{ "op": "move", "from": "/0", "to": "/1/x" }

The text says:

   This operation is functionally identical to a "remove" operation on
   the "from" location, followed immediately by an "add" operation at
   the target location with the value that was just removed.

So, does this mean that the result of the above should be:

[ {}, { "x": "victim" } ]

or is it:

[ { "x": "victim" }, {} ]

?

If it is the first one, then it means that

{ "op": "move", "from": "/0", "to": "/2/x" }

will fail. But on the other hand, this:

{ "op": "move", "from": "/0", "to": "/0/x" }

while forbidden, would theoretically work...

---

From: Francis Galiegue <[email-masked]>
Date: Fri, 8 Mar 2013 17:39:08 +0100

> Well, I have another question about, this time, the move operation.
[snip]

Sorry for the mishaps. "to" should read "path" in all examples, of course.

---

From: "Paul C. Bryan" <[email-masked]>
Date: Fri, 08 Mar 2013 09:56:09 -0800

I consider it to have no value, not even null, i.e. not exist. The
intent was to make it possible to subsequently insert a value at the
root level successfully, as well as to support the semantics of the
"replace" operation.

Paul

On Fri, 2013-03-08 at 16:31 +0100, Francis Galiegue wrote:

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

---

From: Francis Galiegue <[email-masked]>
Date: Fri, 8 Mar 2013 18:58:20 +0100

On Fri, Mar 8, 2013 at 6:56 PM, Paul C. Bryan <[email-masked]> wrote:
> I consider it to have no value, not even null, i.e. not exist. The intent
> was to make it possible to subsequently insert a value at the root level
> successfully, as well as to support the semantics of the "replace"
> operation.
>
> Paul
>

OK, but then I suppose this is an error if this is the only operation
in a JSON Patch?

---

From: "Paul C. Bryan" <[email-masked]>
Date: Fri, 08 Mar 2013 09:58:44 -0800

> while forbidden, would theoretically work...

The way it's written, if you wanted to move "victim" to the adjacent
object in the array (element 1 before the move), then the last operation
above would be the way to do it.

Paul

---

From: "Paul C. Bryan" <[email-masked]>
Date: Fri, 08 Mar 2013 10:01:17 -0800

> OK, but then I suppose this is an error if this is the only operation

I suppose it depends on the implementation. JavaScript has an undefined
type, which seems like a valid way to represent the absence of a value.
Other languages though don't have a similar capability (e.g. Java).

Paul

---

From: Francis Galiegue <[email-masked]>
Date: Fri, 8 Mar 2013 19:19:43 +0100

On Fri, Mar 8, 2013 at 6:58 PM, Paul C. Bryan <[email-masked]> wrote:

The "from" location MUST NOT be a proper prefix of the "path"

   location; i.e., a location cannot be moved into one of its children.[...]
>
> The way it's written, if you wanted to move "victim" to the adjacent object
> in the array (element 1 before the move), then the last operation above
> would be the way to do it.
>
> Paul

Do you mean this one?

Because according to the spec, it is not legal:

   The "from" location MUST NOT be a proper prefix of the "path"
   location; i.e., a location cannot be moved into one of its children.

Or is it meant to be that the prefix relationship must be evaluated
_after_ the move (since in this case /0 will have changed)?

---

From: "Paul C. Bryan" <[email-masked]>
Date: Fri, 08 Mar 2013 10:45:34 -0800

Unfortunately, these cases you're presenting are proving that the text
could still stand to be improved. Prefix relationship must be evaluated
after the move.

Paul

---

From: Francis Galiegue <[email-masked]>
Date: Fri, 8 Mar 2013 20:44:19 +0100

On Fri, Mar 8, 2013 at 7:45 PM, Paul C. Bryan <[email-masked]> wrote:
> Unfortunately, these cases you're presenting are proving that the text could
> still stand to be improved. Prefix relationship must be evaluated after the
> move.
>

What about:

* for the removing of "":

Note that it is possible to remove the empty path ""; in effect, this
means removing the entire document. The representation of such a
missing document is left up to implementations.

* for moving to a child:

If the "from" location resolves to an object member, then it MUST NOT
be a proper prefix of the "path" location; ie, an object member cannot
be moved to one of its children.

The latter is because if you choose to move an array index, given that
this is functionally equivalent to a remove then an add, then the
structure of the array will have changed before the add. Whereas if
you choose to move an object member to a child of itself, the target
location will not exist anymore.

Comments?

---

From: "Paul C. Bryan" <[email-masked]>
Date: Fri, 08 Mar 2013 11:51:47 -0800

Final call has already been reached; it's in the RFC submission queue.
So, the train has left the station, so to speak.

An errata that clarifies some of these edge cases would seem to be in
order though.

Paul

---

From: Barry Leiba <[email-masked]>
Date: Fri, 8 Mar 2013 14:55:07 -0500

> Final call has already been reached; it's in the RFC submission queue. So,
> the train has left the station, so to speak.
>
> An errata that clarifies some of these edge cases would seem to be in order
> though.

If the changes are minor and clarifying, we can make them in AUTH48,
before the RFC is published.  If it's more significant, we can pull it
back from the RFC Editor queue for fixes.

Barry, Applications AD

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 8 Mar 2013 13:18:43 -0800

> back from the RFC Editor queue for fixes.

The current discussion seems to be more than clarifying, because no one seems to have thought of them before Francis did. But it is far from clear that what Francis has found is the last of where the document will need to be clarified.

Proposal: do this as an errata *and* start a bis document. Let the latter bake for about six months.

--Paul Hoffman

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 8 Mar 2013 13:22:13 -0800

I'd rather hold off on starting the bis document right away, but otherwise
this plan seems fine to me.

On Fri, Mar 8, 2013 at 1:18 PM, Paul Hoffman <[email-masked]> wrote:

> So,
> order
> The current discussion seems to be more than clarifying, because no one
> seems to have thought of them before Francis did. But it is far from clear
> that what Francis has found is the last of where the document will need to
> be clarified.
>

---

From: Francis Galiegue <[email-masked]>
Date: Fri, 8 Mar 2013 22:32:48 +0100

On Fri, Mar 8, 2013 at 10:18 PM, Paul Hoffman <[email-masked]> wrote:
[...]
> The current discussion seems to be more than clarifying, because no one seems to have thought of them before Francis did. But it is far from clear that what Francis has found is the last of where t…

Sorry for that... And all the more sorry that I have just found
another one. This time with replace. It is said that:

   This operation is functionally identical to a "remove" operation for
   a value, followed immediately by an "add" operation at the same
   location with the replacement value.

But this is not quite true. Consider:

{ "op": "replace", "path": "/0", "value": 1 }

against:

[ true ]

The remove leads to:

[]

and add will fail, since /0 does not exist anymore. It would have to
be an add to "/-" to work...

Rather than sending mail after mail, what is the correct way to report
this kind of findings?

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 8 Mar 2013 13:57:27 -0800

Others may disagree, but I think it's fine to send an email first to get a
couple of people to agree that the issue is real, and then open an erratum
if so.

---

From: "Paul C. Bryan" <[email-masked]>
Date: Fri, 08 Mar 2013 14:23:45 -0800

I agree the issue is real.

Paul

On Fri, 2013-03-08 at 13:57 -0800, Murray S. Kucherawy wrote:
> Others may disagree, but I think it's fine to send an email first to
> get a couple of people to agree that the issue is real, and then open
> an erratum if so.
> 
> 
> 
> 
>         > The current discussion seems to be more than clarifying,
>         because no one seems to have thought of them before Francis
>         did. But it is far from clear that what Francis has found is
>         the last of where the document will need to be clarified.
>         >
>         
>         
>         
>         JSON Schema in Java:
>         http://json-schema-validator.herokuapp.com
>

---

From: t.petch <[email-masked]>
Date: Tue, 12 Mar 2013 14:49:26 +0000

----- Original Message -----
From: "Murray S. Kucherawy" <[email-masked]>
To: "Francis Galiegue" <[email-masked]>
Cc: "Barry Leiba" <[email-masked]>; "Paul Hoffman"
<[email-masked]>; <[email-masked]>
Sent: Friday, March 08, 2013 9:57 PM
Subject: Re: [apps-discuss] JSON Patch question about the remove
operation

> Others may disagree, but I think it's fine to send an email first to
get a
> couple of people to agree that the issue is real, and then open an
erratum

I would go further and say it is categorically not fine to post the
erratum without sounding it out on e-mail first.  e-mail is lightweight,
costs very little to explore, to get feedback on while an erratum is
heavier, costs more even when it is not accepted.  Of course, if
everyone agreed on what is and is not a suitable topic for an erratum,
there would be no difference but I think that, increasingly, errata are
being used to report things that do not warrant reporting, such as
missing commas, and once the erratum is posted, there is a cost to
squashing it, whereas with an e-mail, you can gently suggest -
off-list - that this not really what the process is intended to be used
for.

The technical topics on this thread seem an excellent use of the
facilities, the only regret being that they did not surface at an
earlier time.

Tom Petch

> > On Fri, Mar 8, 2013 at 10:18 PM, Paul Hoffman
<[email-masked]>
> > wrote:

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 12 Mar 2013 10:56:06 -0400

Test cases are still more than welcome:
  https://github.com/json-patch/json-patch-tests

Cheers,

On 08/03/2013, at 1:45 PM, Paul C. Bryan <[email-masked]> wrote:

> Unfortunately, these cases you're presenting are proving that the text could still stand to be improved. Prefix relationship must be evaluated after the move.
> 
> Paul
> 
>> On Fri, Mar 8, 2013 at 6:58 PM, Paul C. Bryan <[email-masked]
>> > wrote:
>> 

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

---

From: Francis Galiegue <[email-masked]>
Date: Tue, 12 Mar 2013 16:44:16 +0100

>   https://github.com/json-patch/json-patch-tests

Interesting!

I have written a set of test cases for my own implementation (in
Java), I'll try and adapt these -- and why not send more tests from
the ones I have written.