Re: [office-collab] GCT Issues Wiki page

["Andreas J. Guelzow" <andreas.guelzow@concordia.ab.ca>]

On Wed, 2011-08-24 at 07:19 -0600, Robin LaFontaine wrote:
> Please do raise anything that needs discussion on this email list
> referencing the issue

GCT-Issue-1:

I fail to see how the suggestion described in
http://www.oasis-open.org/apps/org/workgroup/office-collab/email/archives/201104/msg00024.html would solve this issue. 

From a user perspective there is no obvious distinction between
conforming ODF documents and extended-conforming ODF documents, nor are
there any obvious markers inside the file other than that a consumer
will suddenly encounter an element or attribute it does not expect.

Typically extended-conforming documents can be sensibly read by ignoring
the extension. One cannot sensibly read change tracking information by
ignoring some of the change tracking info.

GCT-Issue-2:
IMHO, amending the proposal to include information on which editing
operation is represented essentially changes the character of GCT to
something more like ECT. So isn't this response really a statement that
ECT in principle cannot work?

In the related message 
http://www.oasis-open.org/apps/org/workgroup/office-collab/email/archives/201104/msg00049.html
asks the question
"2) Do we need to differentiate between two actions that have the same
effect on the document?"
I would like to answer this with a clear yes. Refering to the example
that lead to that question, if a user deletes column K, the user may be
quite disturbed if the change tracking lists a deletion of column B.
 

GCT-Issue-4:

I fail to see why "The notion that an edit operation would be a short
form seems attractive but it also needs to be reversible to undo and
then a small operation becomes big because of the cacheing needed."
would be correct. Referring to the example, the undo of "insert row" is
simply a "delete row", so how does it suddenly become big? To undo a
delete row one of course need to store the content of that row and a
list of changes caused elsewhere.  

With respect to Rob's comment on this issue, while using R1C1 cell
addressing would indeed leave more _relative_ cell addresses unchanged
(it has no effect on absolute addresses), recording the editing
operations rather than the result on the xml representation of the
document would be much shorter.

Andreas

-- 
Andreas J. Guelzow, PhD, FTICA
Concordia University College of Alberta