Multiple spec and test requests

I have a few other issues for the spec itself, so as per issue #22 , I thought I would report them here. If this issue tracker is in fact a good place, I can then split these into separate issues if you wish and as you deem appropriate (or use the RFC tracker as appropriate).

Distinguishing whole doc/root and empty string property

Spec clarification: Although I already see tests which suggest that path "" functions as the whole document/root doc and "/" targets an empty string property (and the JSON Pointer spec supports this), I think this ought to be briefly documented in this spec.

Whole document removal treatment

Spec clarification and test addition: I think special behavior (and a test) ought to be defined for the following:

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

I believe all other operations will lead to a well-formed JSON document except for this one. I would think it should be optionally allowed by the spec (especially since it can be handled by a subsequent "add" at path "").

"New" operation

Spec feature request: One fundamental type of operation which I see is missing is having a way to indicate one wishes to add a new object member but throw an error if it already exists (or a way to add at root (i.e., path "") but throw if a root already exists).

Currently the "add" operation behavior will auto-create or replace as long as the parent object exists and "replace" will only replace, but there is no way to indicate one only wishes to create.

Likewise if one wishes to add to an array at an index and throw an error if that index already exists.

"new" might be a suitable operation name for such a behavior.

Splicing

Spec feature request: Other other fairly fundamental type of operation which could be adding would be options for splicing beyond just adding or removing a single item, or replacing a single item with another single item. I think a "splice" operation would not only be useful for convenience but also semantically express to applications that the additions/removals are related. This feature would also encompass multiple sequential additions or removals from an array without both needing to occur together. I would think that add could allow parameters for the contents of an array of values to be added at the designated index (i.e., not to add the array itself), remove could allow parameters for multiple array item removal starting at a given index while replace, move, and copy would be suitable for combined arbitrary add/remove splicing.

JSON Collection Patch (allowing JSON References)

Spec feature request or new spec: While the following proposal might not be suitable for HTTP PATCH (since it is indicating multiple files at once), I think it would have a role for being standardized, possibly as a superset of JSON Patch. This "JSON Collection Patch" would overload all existing JSON Patch operations to support JSON References (of potentially different file sources) in addition to JSON Pointers. A new operation object member or new path indicator like "#". would, I think, need to be allowed in those cases which needed to distinguish between the adding/removing/moving/copying of a whole file itself or just all of its contents (e.g., {"op": "add", "path": "http://example.com/file.json#", "value": {}} might add an empty object to an already-existing empty file while {"op": "add", "path": "http://example.com/file.json", "value": {}} might also create the file and then add the value (if a value was even supplied)).

The benefit of such a spec would be in allowing for atomic operations across documents and for preserving relationships between documents (e.g., allowing for version control to trace a "blame" of a document's contents as containing a move from another document to the current one).

json-patch / json-patch-tests