Requirement

[ronnie thebonnie <ronniethebonnie@gmail.com>]

+NAME
Ronnie The Bonnie

+CONTACT
ronniethebonnie@gmail.com

+CATEGORY (select one or more from below)
other

+SCOPE (select one or more from below)


general/

+USE CASE
Any case where objects are saved that don't have change tracking elements such as text has. 

+DESCRIPTION
Proposal: change tracking of objects on a per object basis. 
Robustness by generalization and consistency with foundations in my previous proposal about enhancing tracked changes. 


I have build upon an earlier proposal, short description of that proposal: 
Adding Infrastructure and general approach in ODF for the purpose advanced change tracking in ODF files. 

Preserving backwards compatibility, 

presenting two different mechanisms one simpler one more advanced. 




Intro: 
Currently odf has a mechanism for tracking changing text, now in odf v1.2 drafts with text formatting included. 
However there are area's where odf hasn't got such detailed change tracking support, such as tables and formulas. 
These could get rules for change tracking but this can only go so far. 
What to do with OLE-objects, images and other inserted content? 
It's going to be a bit difficult to describe rules because we're talking about things we don't know the properties of. 

proposal:
What we need to have is a general system to describe the following of an object: addition/changes/deletion. 
In an earlier proposal I have suggested a mechanism of sub-documents that can store a document for each version. 

Very simple, general system and robust. But it isn't really efficient. This proposal is meant to improve the efficiency a little by doing things on a per object base instead of a per document base. 


I propose for change tracking objects as a whole, a new generalized element. 

<object:change-tracking>
</object:change-tracking>
That can contain the following elements: 
one addition, no to several changes and one deletion. 
(note: after a deletion, there could be an addition but it's sometimes tricky to find out if the object is the same) 

The elements are going to need an attribute to say to what version they belong. 

Two different situations/cases: 

a) All of the objects properties are described in one place in the document. 
Short: the whole object is present. 

In this case, the change tracking just goes around the object:
<object:change-tracking>
    <object:addition addition attributes>
        description of object, e.g. table, formulae, other things,... 

    </object:addition>
</object:change-tracking>

b) The object itself is actually stored somewhere else. 
Short: there is a reference to the object. 
NOT the same as an url
Because the url is the object, not the website. 

An example would be a picture(bitmap image). 
Here the reference in the document would get the change tracking things around it. 
But the object itself should be stored in a folder in a central change tracking folder. 

ExampleSomething.odt/changeTracking/subDocumentOrVersionName/
(Whatever the standard is to name the sub-document: version or version-documentName or something else...)

Here the folder subDocumentOrVersionName would be a folder with only some objects of that version of the document.

It would actually be a rather empty sub-document. It would in our example contain a picture folder with our picture in it. 
Thus the picture can keep having the same name but is stored in a different location. 
The relevant information about the subDocumentOrVersionName (what it is) would be stored in a change tracking meta data file stored in the appropriate place. See also my previous proposal about change tracking mentioned in the beginning. 



Compatibility:
About backwards-compatibility: xml is supposed to be extensible. 
That means that applications just skip things they don't understand. 
New functionality thus there is not much problems about backwards compatibility. 

Documents could be troublesome. If the new elements and their content are being skipped by applications that don't understand them, objects that are changed tracked as in case b) would not show up in the document.