office-collab — archive

[Robin LaFontaine]

Something tickled my mind when the question about arbitrary rejection order was raised Tuesday morning, but I was either not awake enough to remember the details or was already juggling too many windows with a laptop screen and touchpad to find prior discussion on this topic. Both GCT and ECT, using their different representations, store the previous state for each change that is made. Conceptually, each should be in the same position with regard to a specific change being rejected and what should be restored. Recall the e-mail thread from June ("Serialization and change tracking ") about this topic, using UC 1 as the example. Here's the first e-mail: http://www.oasis-open.org/apps/org/workgroup/office-collab/email/archives/201106/msg00015.html . That thread looked at arbitrary order rejection for both ECT and GCT, so I think it's fair to say both representations can handle it. If there are any specific problems with ECT, I'd love to have the details as both Doug and I noted early on that we think arbitrary order rejection is important to users. More fundamentally, it also uncovered that what results from various orders of rejection in cases when there are multiple changes to the same content depends on how the application chooses to structure the change-tracking markup when the changes are made and how it handles the remaining change markup. (e.g.: Tristan: I suppose it depends on how the change is made in the first place. John: Yes, I think that €™s the rub. Off the top of my head, I think it varies based on how the style change is effected in markup) It appears to me that a little runtime intelligence is required to determine what a particular rejection should yield (perhaps room for application choice / differentiation) and how to "clean up" the remaining change tracking markup. If I read Dennis' comment correctly, I think the above is in line with what he mentions about OpenOffice. John