RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 6 records.

Status: Held for Document Update (1)

RFC 6902, "JavaScript Object Notation (JSON) Patch", April 2013

Source of RFC: appsawg (app)

Errata ID: 4787
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: Daniel Frey
Date Reported: 2016-08-25
Held for Document Update by: Alexey Melnikov
Date Held: 2017-02-23

Section 4.2 says:

The "remove" operation removes the value at the target location.

The target location MUST exist for the operation to be successful.

For example:

{ "op": "remove", "path": "/a/b/c" }

If removing an element from an array, any elements above the
specified index are shifted one position to the left.

It should say:

The "remove" operation removes the value at the target location.

The target location MUST exist for the operation to be successful.

For example:

{ "op": "remove", "path": "/a/b/c" }

If removing an element from an array, any elements above the
specified index are shifted one position to the left.

The target location MUST NOT be a reference to the root. It is an
error in this document:

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

Notes:

The semantics of { "op": "remove", "path": "" } are never specified. If we allow to remove the root element, what would the result be? It would no longer be a valid JSON document, hence I propose to explicitly require the path of the "remove" operation to not reference the root.

Mark Nottingham: This isn't an errata; it would require gaining consensus and updating the document. See also: https://github.com/json-patch/json-patch2

Status: Rejected (5)

RFC 6902, "JavaScript Object Notation (JSON) Patch", April 2013

Source of RFC: appsawg (app)

Errata ID: 4596
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: Missing 'Append' operation
Date Reported: 2016-01-21
Rejected by: Barry Leiba
Date Rejected: 2016-01-21

Throughout the document, when it says:

Its value MUST be one of "add", "remove", "replace", 
"move", "copy", or "test"; other values are errors. 

It should say:

Its value MUST be one of "add", "append", "remove", 
"replace", "move", "copy", or "test"; other values are errors. 

... and more text to add the 'append' op description.

Notes:

There is a key missing piece to this RFC. You can do { "op": "add", "path": "/attr", "value": "val"}, which will add or modify the 'attr' attribute, if it exists or not. However, you cannot add an item to a potentially non-existing array. Updating an array that may or may not exists, forces the client to always call GET on the resource. See this API spec: https://orchestrate.io/docs/apiref#keyvalue-patch which implements the op 'append', which would solve this problem.
--VERIFIER NOTES--
This is an enhancement suggestion, not an errata report; the errata system is not for that.

Errata ID: 5239
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: Grzegorz Olszewski
Date Reported: 2018-01-19
Rejected by: Barry Leiba
Date Rejected: 2020-12-09

Section A.16 says:

An example target JSON document:

   { "foo": ["bar"] }

   A JSON Patch document:

   [
     { "op": "add", "path": "/foo/-", "value": ["abc", "def"] }
   ]

   The resulting JSON document:

   { "foo": ["bar", ["abc", "def"]] }

It should say:

An example target JSON document:

   { "foo": ["bar"] }

   A JSON Patch document:

   [
     { "op": "add", "path": "/foo/-", "value": ["abc", "def"] }
   ]

   The resulting JSON document:

   { "foo": ["bar", "abc", "def"] }

Notes:

surplus square brackets in resulting JSON document
--VERIFIER NOTES--
The example is correct as written: the value to be added to the array is itself an array, so the new element is ["abc", "def"].

Errata ID: 6351
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: Palle Cogburn
Date Reported: 2020-12-09
Rejected by: Barry Leiba
Date Rejected: 2020-12-09

Throughout the document, when it says:


Notes:

If the patch elements included a property "previous" that contained the original value in case of an operation such as "remove" for instance, it would be easy to create the reverse operation - "add". In that way the path elements can be used as audit records and it is easy to revert a path or even a part of a patch, so the document is back to a previous version. All you have to do is apply the reverse patch and also add those elements to the audit trail.
Is this something to consider adding to this document or is it an implementation detail?
--VERIFIER NOTES--
This is a feature request, not an errata report, so it is rejected as an errata report. The suggested feature should be discussed on an appropriate mailing list to see if there is interest in adding this feature.

Errata ID: 4419
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT

Reported By: Brett Zamir
Date Reported: 2015-07-17
Rejected by: Barry Leiba
Date Rejected: 2016-01-21

Section A.14 says:

An example target JSON document:

   {
     "/": 9,
     "~1": 10
   }

   A JSON Patch document:

   [
     {"op": "test", "path": "/~01", "value": 10}
   ]

   The resulting JSON document:

   {
     "/": 9,
     "~1": 10
   }

It should say:

Proper JSON Pointer escaping should occur when resolving
paths for application to the target document.

An example target JSON document:

   {
     "/": 9,
     "~1": 10
   }

   A JSON Patch document:

   [
     {"op": "add", "path": "/~01", "value": 11}
   ]

   The resulting JSON document:

   {
     "/": 9,
     "~1": 11
   }

Notes:

At http://tools.ietf.org/html/rfc6902#appendix-A.14 , I have a few issues:

1. Even though JSON Pointer is referenced elsewhere, I think reference ought to be made here to JSON Pointer in order to clarify what meaning "escape ordering" has here.
2. The operation indicated in this section is "test" which is not documented in its respective sections as returning any kind of document at all. I believe "add" or "replace" must have been the intended operation instead. And to make clear that the value of key "~1" would have actually been affected by such a modifying operation, the value in the result ought to differ from that in the original document.
--VERIFIER NOTES--
The example is correct, but could use clarification. The authors have noted this and put it in their JSON Patch issues list here: https://github.com/json-patch/json-patch-tests/issues/22

Errata ID: 4460
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT

Reported By: Lucas Bickel
Date Reported: 2015-08-29
Rejected by: Barry Leiba
Date Rejected: 2015-08-29

Section 4.1 says:

   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.

It should say:

   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. Considering a target location of "/a/1"
   it should be not be an error in this document:

    { "a": [ "foo" ] }

    while the same "add" into this document will be an error:

    { "a": [ ] }

    because "/a/0" does not exist.



Notes:

Adding to an object has such a nice example that explains the error cases. I think adding to a sequential array should have one as well.

To my understanding this is already pretty clear from RFC6901, I feel it will make the spec easier to implement if we have an example right here.
--VERIFIER NOTES--
Thanks for the comment, Lucas. This is, though, not a report of an error, so as an errata report it is rejected. It is a reasonable suggestion that we should consider if a new version of the document is done. The comment is recorded in the JSON mailing list archive.

Report New Errata



Advanced Search