Ganesh Paramasivan

Took a quick look at the document. Looks great. Some of the things
that I like are

- The mechanism to have dependencies between changes is essential for
implementing delete-change tracking in tables. So this spec would make
that possible.


Pierre Stirnweiss:
- the dependency syntax of subsequent changes still lacks so i can''t
comment too much about this. One remark however: the whole thing gives me
the feeling that change tracking here has been drafted with "versioning"
use case in mind. Change tracking can also be used as a
who-made-what-change in a multi-user workflow. The two are not
incompatible, but the second should be kept in mind when further designing
the interrelation syntax between changes.


Robin La Fontaine:
This is a fair point. There is an implicit understanding that there are different versions of the document represented by the various edits, and that there is some order to these versions, and the ordering is needed in the case of potentially conflicting changes. This would work in a reasonable fashion for the use case of who-made-what-change, but there is no representation of alternative changes which are mutually exclusive. Such a representation might be needed for this use case, although we did not have that in the requirements.  At the moment that is the only difference in the two use cases that I can think of, but there may be others.

Perhaps it would be sufficient in our dependency syntax to be able to indicate that two changes are alternatives, and one or the other must be chosen and not both. I guess this could extend to any number of changes, i.e. only one of several could be chosen. An application that did not understand alternatives would have to reject all but one of the potential changes. I would welcome your view on this.