Oh, good - someone wrote an RFC for it - thanks for the link! It looks a lot like a post on partial updates in REST [1] where I recommended using null in the context of relational databases like mysql. Now I kinda feel undefined might be a better way to explicitly delete properties, especially if using a NoSQL database.
Thanks, you're right. "null" is what I do use - I forgot undefined won't work with JSON.parse. It would be nice to have a way to explicitly define a property as null, versus non-extant.
If you start with original.json, then client 1 applies add-middle-name.json, and then moments later client 2 applies change-name.json not knowing that the other patch had been applied, you'll end up with a possibly unintentional merging of the two. I'm assuming change-name here wanted to clobber the whole name object, and did not intend to merge and keep the middle name.
There's a couple ways around this. One is to code defensively and always pass the middle:null when clobbering the name, since you know other clients could set a middle name. The other is to do some sort of versioning check to ensure no one else has changed the document since you last fetched it. That could be implemented outside the json patch, using if-not-modified headers or something, though it is tempting to do it with the "test" actions provided in the main spec discussed here.
I prefer it, and think it's much easier to understand.