55
addressing scheme enables the notion of the location of data within a sequence to be almost
completely decoupled from the state of the sequence at an application instance. With invari-
ant addresses, the representation of operations themselves can also be invariant. This leads
to a more flexible and modular architecture that can treat data transmission and conflict
detection and resolution completely independently. It also allows the semantics of opera-
tional conflicts to be resolved separately from the issues of data transmission, notification,
relative timing of user operations and synchronization.
The more obvious problem is the problem of conflicting changes. Changes mayconflict
when their scopes coincide in some way and the semantics of the operation make the in-
tended result unclear. A simple motivating example (to be examined fully in context in Sec-
tion 3.3) is the overlapping of the source regions of two separate move changes. The ques-
tion is where to put the region overlapped by both changes. There are several possibilities: If
one change is given priority, the effect is like a temporal ordering, in which the higher pri-
ority operation “got there first.” If neither operation were to be given priority, the common
text would appear at the destination of each change (effectively duplicated), or at neither
(effectively deleting it). Whether overlapping scopes create a conflict, the kinds of resolu-
tions that are possible depend critically on the semantics of the operations involved, and the
specific relationships of the changes’ zones of effect.
Table 3.1 structurally classifies types of potential conflict. There are essentially two kinds
of region of effect for a change: a point between two elements of the sequence (at which
data might be inserted), or a range covering some number of elements of the sequence
(whose data might be read by the operation, or within which the contents might be
changed). These structural conditions may cause conflicts for any set of operations. The fol-
lowing table lists possibilities for permutationaloperations, according to the taxonomy of
addressing scheme enables the notion of the location of data within a sequence to be almost
completely decoupled from the state of the sequence at an application instance. With invari-
ant addresses, the representation of operations themselves can also be invariant. This leads
to a more flexible and modular architecture that can treat data transmission and conflict
detection and resolution completely independently. It also allows the semantics of opera-
tional conflicts to be resolved separately from the issues of data transmission, notification,
relative timing of user operations and synchronization.
The more obvious problem is the problem of conflicting changes. Changes mayconflict
when their scopes coincide in some way and the semantics of the operation make the in-
tended result unclear. A simple motivating example (to be examined fully in context in Sec-
tion 3.3) is the overlapping of the source regions of two separate move changes. The ques-
tion is where to put the region overlapped by both changes. There are several possibilities: If
one change is given priority, the effect is like a temporal ordering, in which the higher pri-
ority operation “got there first.” If neither operation were to be given priority, the common
text would appear at the destination of each change (effectively duplicated), or at neither
(effectively deleting it). Whether overlapping scopes create a conflict, the kinds of resolu-
tions that are possible depend critically on the semantics of the operations involved, and the
specific relationships of the changes’ zones of effect.
Table 3.1 structurally classifies types of potential conflict. There are essentially two kinds
of region of effect for a change: a point between two elements of the sequence (at which
data might be inserted), or a range covering some number of elements of the sequence
(whose data might be read by the operation, or within which the contents might be
changed). These structural conditions may cause conflicts for any set of operations. The fol-
lowing table lists possibilities for permutationaloperations, according to the taxonomy of
