Hi, Firstly, apologies for missing the last conference call. Since we are gathering wiki pages for issues with GCT and ECT I thought I would reiterate some of my thoughts FWIW. I think most of the points in this email have been discussed before. I am bringing them together to help make it easier for them to be included and referenced in any document such as consensus reports etc. Note that I'm just an implementer, so any thoughts I express below are more or less how I imagine change tracking might be desired by certain consumers. My first line of thought boils down to what the motivation is for performing change tracking in the first place. At a very abstract level, one could store the content.xml et al files in a git repository and perform rather complex XML or semantic diffs on the revision history to obtain change tracking without any application support. Some of the issues raised on the list recently come up here for semantic diffs. For example, treating styles with equivalent semantics but different names as equal and thus "not a change". See for example:
http://markmail.org/message/65dsnvrzmbdmjxka However, one might like the document editor itself, be that LibreOffice, Calligra, abiword, or AJAX code, to help you see changes and offer to negate them, track new changes, or perform other actions. It then becomes interesting for ODF itself to allow a representation of changes to be captured in the document file itself. This is as opposed to storing just the latest state on ODF and performing a diff with an older complete ODF document. This is where I find the ECT bucket concept extremely troublesome. In order for an application to tell you what changed it must perform a complex semantic diff between inline content in content.xml (r10) and the latest bucket (r9). To find what changed in (r9) then another complex semantic diff is needed between r9 and r8 and so forth. I find this an extremely critical issue has it means that users of change tracking are relying on various applications to imply changes rather than being told directly and explicitly what has changed. For government use cases this might be an unacceptable distinction and as such the use of ODF for change tracking of documents might be rejected due to uncertainty. This is without considering the computational complexity of performing these diffs over chains of buckets to look back 20 revisions. Another way ECT buckets are, IMHO, deceptive is that they are proposed as a means to make things simple. Contrary to this, in abiword loading and saving an ECT bucket would require a different code path for buckets to mainstream content. It seems the OOo code would also require such attention:
http://markmail.org/message/ox5ft4g57tgtyepz At least for abiword, changes to an attribute are stored in the data model inline. Thus it actually becomes harder to implement writing to an ECT bucket than to just use GCT ac:change attributes during a save. This is because to write a bucket the code needs to consider a whole rage of an in memory model and the revision and state attached to everything in that bucket to figure out what the bucket content will be. I reiterate my concern for matched pair XML elements in ECT buckets (UC7 and UC8). Having the start XML element move to a bucket will cause problems with matching pair end XML elements. One could at times insert a new matching end tag, thus splitting two matching elements into four. This also cascades in future changes, and the operation may very well need to change the names associated either with the new pair or the old pair of elements to maintain uniqueness. Such a name change itself needs to be change tracked or at least be able to explicitly and deterministically imply the link between the two pairs (the renamed one(s) and the original one) so that GUI elements can offer both to users wishing to review revisions. As I expressed early on, I think it might also be useful for the GCT to have some conformance levels which list elements, attributes etc which must be tracked in order for an application to be claim a given level of conformance. This has been discussed over a few threads on the list. For longer life documents, some form of change tracking epochs might be useful:
http://markmail.org/message/64xcxoagwyxy4sn4 And in any case, I think change tracking on the RDF of the document should definitely not be a forgotten item:
http://markmail.org/message/4t6zlmiieno2g7on