ECT Buckets and GCT

[monkeyiq <monkeyiq@gmail.com>]

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.