35
tent of including tables and pictures). Authoring systems should be capable of sup-
porting changes to document parts of all data types.
7. It should allow the application to control the parameters for data consistency.Rather
than enforcing a single model that cannot be correct for all applications, it should
enable applications to determine how much consistency is appropriate, and when. By
postponing policy decisions to the greatest extent possible, a greater variety of ap-
plications can be accommodated.
8. It should provide a definitive semantics for interpreting and modeling asynchrony and
inconsistency.A chief difficulty in implementing systems that have to deal with dis-
tributed editing (synchronous or asynchronous) is understanding what is going on
with respect to times of updates and the movement of data between the parties to
an editing session. One thing that a framework and its underlying model can provide
is a simple model of temporal and causal interaction.
9. It should provide application implementers with an easy default option.Conflict and
version management are complex, thorny problems for implementers and for users as
well. It is useful to have a (potentially less safe) “see no evil” policy available if it
can reduce a system’s demands on a user for the enforcement of safety and consis-
tency. A framework should help application writers to offer users a convenient way
to ignore potential problems, or defer them—perhaps indefinitely. The exact for of
default is worth careful consideration as it is likely to be used. It is also desirable
that a system be able to support a choice between a small number of default policies.
The discussion in section 1.8 supports the following additional requirements for a merge
function, listed in order of priority:
1. Reasonability of change model.While complexity may be involved when changes
combine (since editing histories aretricky), the basic operations provided must be
intelligible and unsurprising to users and application designers.
tent of including tables and pictures). Authoring systems should be capable of sup-
porting changes to document parts of all data types.
7. It should allow the application to control the parameters for data consistency.Rather
than enforcing a single model that cannot be correct for all applications, it should
enable applications to determine how much consistency is appropriate, and when. By
postponing policy decisions to the greatest extent possible, a greater variety of ap-
plications can be accommodated.
8. It should provide a definitive semantics for interpreting and modeling asynchrony and
inconsistency.A chief difficulty in implementing systems that have to deal with dis-
tributed editing (synchronous or asynchronous) is understanding what is going on
with respect to times of updates and the movement of data between the parties to
an editing session. One thing that a framework and its underlying model can provide
is a simple model of temporal and causal interaction.
9. It should provide application implementers with an easy default option.Conflict and
version management are complex, thorny problems for implementers and for users as
well. It is useful to have a (potentially less safe) “see no evil” policy available if it
can reduce a system’s demands on a user for the enforcement of safety and consis-
tency. A framework should help application writers to offer users a convenient way
to ignore potential problems, or defer them—perhaps indefinitely. The exact for of
default is worth careful consideration as it is likely to be used. It is also desirable
that a system be able to support a choice between a small number of default policies.
The discussion in section 1.8 supports the following additional requirements for a merge
function, listed in order of priority:
1. Reasonability of change model.While complexity may be involved when changes
combine (since editing histories aretricky), the basic operations provided must be
intelligible and unsurprising to users and application designers.
