Change tracking uses cases

[robert_weir@us.ibm.com]

Some quick thoughts on change tracking on what makes this a hard problem.  
I'm looking at this problem from the user perspective, not the markup 
perspective, just trying to suggest a scope.

I think we all have an intuitive sense that actions that the user takes to 
change the document should be reflected in change tracking.

1) Some types of changes are simple at the markup level, but lead to 
complex changes in the user's view of the document.  For example, 
inserting or deleting items into a numbered list will change the numbering 
of all following list items.

2) Conversely, some changes at the user level are very simpe, but at the 
markup level are complex, such as inserting or deleting a column in a 
table.  A single simple user-level change causes many changes at the 
markup level, because of the row-oriented encoding of tables.

3) There are many possible "links" in an ODF document, such as an image 
frame pointing to an image file, or a paragraph pointing to a style 
definition.  This gives you a triad of: linking object, link, and linked 
object.  Changes can occur to any of them.  For example, I can add/remove 
an image, change which image file I am pointing to, or keep the image name 
constant but change the underlying bytes of the image.  Change tracking 
should be able to represent changes at all of these levels.

4) Perhaps a variation on referential integrity  -- we have part of ODF 
that represent a cached value of other content in the document.  For 
example, tables can store both a formula as well as the last cached value 
of the formula.  A slide can have a cached thumbnail image.  When the 
underlying data changes, the cached value should be invalidated.

5) In most cases changes occur to a specific part of a document, something 
that you can point to.  But in some cases the change is more global, such 
as changing document metadata, or changing the definition of a named 
style.

6) Some changes to a document are of no consequence, in terms of 
information value to the user.  For example, changes to XML ID's, so long 
as they represent the same graph, should be freely changeable.    There 
are other examples of similar "volatile" data in a document.  For example, 
if I have a spreadsheet that has a cell using the RAND() function or the 
NOW() function, I probably don't want to generate a tracked change every 
time the spreadsheet recalculates. 

Are there any other similar "edge cases" to worry about?  I think tracking 
content changes is the easy part.  But what else do we need to avoid 
missing?

-Rob