At 01:12 AM 5/17/02 +1000, Martin Sevior wrote: >I've been thinking about how to do these and I think that they could be >implemented with a simple meta-property "author" that is attached to all >piecetable changes during an editting session. ie Every piecetable frag >has an additional attribute - "author:........". Then layouts can be >built with different authors showing up as different colors.
Martin, I'm really glad to see you thinking about this feature. As you say, it's must-have for corporate use. Three things to think about as you head down this path: 1. Before littering the document with frag-level author props (a cool idea, BTW), we should really add the "pruning" logic we've discussed in the past to not emit explicit properties that match the defaults. We already have this problem with cut & paste, where a side effect of the RTF impexp process generates a full set of redundant PROPS for each change. Or for a more comparable example, consider the current lang prop, which gets explicitly added to each block, rather than inheriting from the doc-level PROPS that Tomas suggested we add. 2. More importantly, how would you handle the "deletion" screw case? Say we have two successive modifications to a given draft: - RMS adds "GNU/" to all occurrences of "Linux", and - ESR goes back through and deletes them. At edit time, all of the deleted content exists inside the piece table, but by design none of it gets exported to the file format. Off the cuff, I don't see a trivial robust change to the file format which will handle this gracefully. 3. Finally, as a UI issue, I suspect that change tracking should be off by default. But we can cross that bridge when we come to it. bottom line ----------- For revision marks to work well, we need to handle all three of the following style of changes: insert, change, and delete. The first is easy, the last is hard, and the second can be expressed as a combination of the other two. Paul
