Copy values and move after removal
04copy retains the source. move removes it first, then interprets its destination on the resulting document.
Separate invalid move from /a to /a/b: a is an ancestor of the proposed destination, so this move is forbidden.
Source for this drawing: RFC 6902 · Read RFC section 4.4 ↗
New to this? Start hereA quick picture + helpful background
First, agree how to read the message.
An encoding tells a reader how to interpret bytes. A format tells it how values fit together. Correctly reading a value does not make that value trustworthy.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
A move’s destination uses the post-removal positions.
- move and copy MUST contain a from pointer whose source exists. copy is equivalent to adding the source value at path; the source remains. The destination follows add rules, including the need for an existing parent.
- move is equivalent to removing from, then immediately adding that removed value at path. In the same-array example, moving index1 to index3 removes grass first, then inserts it at index3 of the shortened array.
- The from location MUST NOT be a proper prefix of path: an object cannot be moved into its own child. Compare pointer locations/tokens, not just raw string starts; /a and /ab are different member names. Missing sources and invalid destinations are errors.
The first state is a separate object-copy example. The next three reproduce the RFC A.7 array move; the final state is a separate invalid self-descendant move. These are not one continuous patch. Root-remove ambiguities are deliberately outside these examples.
Read the RFC section ↗