Re: [Json] JSON Patch and null arrays

Hi Ron,

I agree that it would be friendly for this to be the case, but that's not how we wrote the spec:

~~~
   Because this operation is designed to add to existing objects and
   arrays, its target location will often not exist.  Although the
   pointer's error handling algorithm will thus be invoked, this
   specification defines the error handling behavior for "add" pointers
   to ignore that error and add the value as specified.

   However, the object itself or an array containing it does need to
   exist, and it remains an error for that not to be the case.  For
   example, an "add" with a target location of "/a/b" starting with this
   document:

   { "a": { "foo": 1 } }

   is not an error, because "a" exists, and "b" will be added to its
   value.  It is an error in this document:

   { "q": { "bar": 2 } }

   because "a" does not exist.
~~~

-- https://tools.ietf.org/html/rfc6902#section-4.1

Changing this now would hurt interoperability, so the right thing to do IMO is to continue to require separate operations.

Cheers,

> On 6 Dec 2019, at 10:22 am, Ron Alleva <ronallevatech@gmail.com> wrote:
> 
> Hi all,
> 
> I’ve been trying to find a good answer around the internet, but I’ve come up short. To describe the question in a JSON patch test, I’m wondering if this should be a valid test: 
> 
> { "comment": "Add array element to null",
> "doc": {"foo": 1},
> "patch": [{"op": "add", "path": “/bar/-", "value": 1}],
> "expected": {"foo": 1, "bar": [1]} } 
> 
> What should “expected” be in this case? Some libraries seem to implement what is above, but I’ve seen other libraries that insist you must create the array first, and only then you can add to it, so the above would result in an error. 
> 
> The most “user friendly” approach I believe would be the above test case. In this case, the client does not have to retrieve and interpret the object to determine if it has to create the array first, it can just add elements.
> 
> Is there any opinion on what is a valid interpretation on the spec with regards to this? Is it just “undefined” because we can’t know that bar is intended to be an array?
> 
> Thanks in advanced,
> 
> Ron
> 
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json

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