For JSON, the issue of handling curly braces (for objects) and square brackets (for arrays) is similar to the issue of handling XML start and end tags. Again, some representation of connected change is needed to maintain syntactic correctness.
Object members and array members are comma separated, and this syntax is tricky to get right in some situations. The syntax is shown below.
object = begin-object [ member *( value-separator member ) ]
end-object
array = begin-array [ value *( value-separator value ) ] end-array
These are the six structural characters:
begin-array = ws %x5B ws ; [ left square bracket
begin-object = ws %x7B ws ; { left curly bracket
end-array = ws %x5D ws ; ] right square bracket
end-object = ws %x7D ws ; } right curly bracket
name-separator = ws %x3A ws ; : colon
value-separator = ws %x2C ws ; , comma
Insignificant whitespace is allowed before or after any of the six
structural characters.
ws = *(
%x20 / ; Space
%x09 / ; Horizontal tab
%x0A / ; Line feed or New line
%x0D ) ; Carriage return
Here is an example of a change to an array of strings.
Table 4. JSON structural change
| A.txt | O.txt | B.txt |
|---|---|---|
[[12,13,14],20,21,22] |
[12,13,14,20,21,22] |
[[12,13,14,20,21,22]] |
This could be represented as shown below.
[ <<<<<<<42< A.txt [ ||||||| O.txt ======= >>>>>>> B.txt <<<<<<<61< A.txt ||||||| O.txt ======= [ >>>>>>> B.txt 12,13,14 <<<<<<<42< A.txt ] ||||||| O.txt ======= >>>>>>> B.txt ,20,21,22 <<<<<<<61< A.txt ||||||| O.txt ======= ] >>>>>>> B.txt ]
The above will produce syntactically correct results, though it is not intuitive and requires careful allocation of id values for the conflicts to ensure correct behaviour. Note that the '[' in A has to be a separate conflict from the '[' in B, although they are at the same position in the array. Note that it could be argued that these changes are not conflicts, but this does not matter here; the point is that if we do want to represent them as choices for a user to select, then we are able to do so.