Hi, One of the issues raised about the GCT has been the difficulty in pinning down which attributes can and can't have ac:change applied. And that trying to come up with a specification of which XML elements need to be change tracked for various levels of compliance with GCT is too hard. I was again thinking about this during the last conference call, though couldn't serialize my thoughts coherently enough in real time. Looking at page 17 of the extended proposal one can see that for image, shape and chart tracking in the ECT the whole draw:frame is replaced with an updated XML tree each time any part of that tree is changed in a revision. An exact equivalence in GCT would be to mandate that remove-with-content be used on the old draw:frame to remove and track it, and insert-with-content be used right after the remove-with-content in insert a new entire draw:frame XML tree for the updated image, shape, or chart. In a large way this makes the ECT actually give hints as to what might be desired XML trees to track en masse with the GCT. This has been since expressed by Robin as the V1/V2 viewpoints. Looking at the transcript for the conference call, the finding of such use cases is the very thing that orcmid mentioned doubts about being feasible on page 1. It seems bottom up proposals like the GCT are frowned on because folks don't think "conformance profile"s can be made for it, but the ECT provides those very profiles, be it with absolutely huge granularity "buckets" which might not be desired at times. IMHO the GCT still offers some advantages even at such large granularity because there are bound to be specific XML attributes which are far, far more interesting to a document user than others. For example, the URL for an image in a draw:frame is likely 1000 times more interesting than if a border is applied to the image. On the other hand, changes to certain other rarer attributes might indicate something nefarious has occurred, such as trying to hide content somehow. Surely something that an application would like to direct the user to. So with a GCT like solution one might specify a conformance level which is able to track that specific attributes like the image url, and fallback to bulk insert/remove-with-content handling if other attributes need updating. This allows tools to be less sophisticated because they do not need to handle ac:change for all attributes inside a draw:frame while reducing document bloat because common and "interesting to user and more subject to change" attributes are given a more blessed status by being stipulated as needing to have ac:change for an application which wants to claim a given ODF+GCT compliance level. One the other hand, considering abiword, the code that creates and reads ac:change attributes is also generic enough to do so for any abiword internal model <-> ODF attribute. Thus supporting a wider range of attributes with this mechanism is fairly mechanical. Although I've been chastised in the past for over mentioning abiword, it is an implementation which I am familiar with and which perhaps has an object model for CT which other applications have or will have as well. One logical follow on from the above and the V1/V2 that Robin put forward is: If conformance profiles are not able to be made for the GCT, then also the ECT will fail to be able to capture use cases which are interesting to document computing. This is an inevitable outcome of having the ECT rely on such use cases for its markup; how to add/remove a column, how to track a change to any XML element/attribute inside a draw:frame (eg, the current prop: by en masse update of that tree). In other words, if the ECT lacks a use case, then the ECT also lacks the ability to track something of importance. If the ECT has a use case then the GCT can express the same thing in its own markup. The advantage with the GCT of allowing more sophisticated conformance levels such as tracking the image URL using ac:change is of course available and straight forward to specify, the hard part being deciding the lists of attributes or sub XML elements which are of interest for finer grained tracking. One interesting scenario when considering ECT buckets vs GCT with specific attributes using ac:change is what happens if an application wants to show the user the differences between two versions. I would have thought this to be a very important scenario, if not an absolutely critical one to consider. One major drawback I see with the bucket approach is that the application has to do XML diffs at runtime. To show that the URL of an image has changed, or that text in the caption has become bold, the application must compare the old and new buckets and work out the list of changes. Conversely, the GCT can store attribute changes in ac:change attributes and as such they are trivial to find and display. I could imagine the bucket approach bogging down in applications like abiword which are not ODF natively and which will need to examine bucket differences for all revisions at load time. On the other hand, reading a collection of ac:change records is quick.