The problem with separators is that they cannot consistently be associated with either the start or the end of each item (member for object and value for array) because if there is only one item then no separator is needed. Therefore, maintaining correct syntax when items are added or deleted is not trivial. As mentioned above, the diff3 format does not allow consecutive choices without 'anchor' data between, so it is necessary to group consecutive items that may be added or deleted into one choice. This apparent restriction does lead to a greater likelihood of the syntax of each choice being consistent.
Here is an example of a change to an array of strings.
Table 5. JSON array value change
| A.txt | O.txt | B.txt |
|---|---|---|
["one", "two"] |
["one"] |
["three", "four"] |
This could be represented as shown below. Note here that we are not showing
the result of running 'diff3 -m' but rather we have run an JSON aware comparison
yielding results that we want to express in the diff3 format.
[ <<<<<<< A.txt "one", "two" ||||||| O.txt "one" ======= "three", "four" >>>>>>> B.txt ]
The above will produce syntactically correct results, though it is not ideal because it would be more natural to choose the values separately rather than as a complete list. This separation can be achieved by inserting additional white space so that we get two choices as shown below.
[ <<<<<<< A.txt "one" ||||||| O.txt "one" ======= >>>>>>> B.txt <<<<<<< A.txt , "two" ||||||| O.txt ======= >>>>>>> B.txt <<<<<<< A.txt ||||||| O.txt ======= , "three", "four" >>>>>>> B.txt ]
However, this representation can lead to syntax errors because if the "one" is rejected by accepting the B.txt choice in the first conflict, then we do not need a comma before the next item. Unfortunately, we cannot get round that using a connected choice. The problem here has to do with a combination of choices rather than one choice. We can just be pleased that XML attributes are not comma separated!