Re: [office-collab] Change tracking uses cases

[Robin LaFontaine <robin.lafontaine@deltaxml.com>]

Rob,

Comments inline below.

robert_weir@us.ibm.com wrote:
> 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.
>   
Yes I agree, and these are covered in the use cases for Lists, D.1 to D.7
> 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.
>   
Yes I agree, and these are covered in the use cases for Tables, C.5 to C.10
> 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.
>   
Some of these are covered in the attributes use cases, B.1 to B.3. In 
terms of a change to an image file, then I think the best we can hope 
for is to include the old and new image files and possibly references to 
them. But I think this needs further discussion.
> 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.
>   
 There is clearly no point in tracking changes to cached values which 
can be recalculated. Applications will often ignore these when they read 
a document in, and regenerate them to ensure that they are correct. 
Therefore I think at best we would include the latest cached value and 
not any previous values. But I think this is mainly an application 
issue. Do you think we need any facility within the track change format 
to handle this?
> 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.
>   
 These are cases where a small change to the data file may have a big 
impact on the appearance of the document. But I don't think there are 
any implications for the track change format, provided we are able to 
record these changes.
> 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. 
>   
 XML IDs in ODF could be used as references into a document from outside 
- is this within the scope of the spec? In this case they should not be 
volatile and an application should preserve them. But there are other 
IDs used purely for internal references, for example references to 
automatic styles. These are a bit more of a problem, and I think this 
needs further discussion.
> 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
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>
>   


-- 
-- -----------------------------------------------------------------
Robin La Fontaine, Director, DeltaXML Ltd  "Change control for XML"
T: +44 1684 592 144  E: robin.lafontaine@deltaxml.com      
http://www.deltaxml.com      
Registered in England 02528681 Reg. Office: Monsell House, WR8 0QN, UK