OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-collab message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: 6. Order of accept/reject in GCT


6. Order of accept/reject in GCT
 - I'll write an email to clarify this one (I am not sure who raised this and I cannot locate it right now )
I have found it now:
ThisDoug H
http://www.oasis-open.org/apps/org/workgroup/office-collab/email/archives/201101/msg00011.html
"Forcing the user to accept/reject changes in a particular order (which is essentially random, determined by the order in which collaborators happened to edit the document) seems to make change tracking more akin to a revision history, with fixed versions of the document available from specific points in time."

Note that the order of changes can be of critical importance in some use cases, for example tracking the changes to a legal document. Therefore this requirement should not be dismissed. I think you have made an important distinction here, which is reflected in the two viewpoints 'Editor Feature Viewpoint' and 'Document Version Viewpoint' in the email discussion "Suggestions for moving forward to resolve issues".
 
There is no intention in the GCT to force users to accept or reject changes in a particular order. The facility of ordering is provided so that an application can indicate to another application that there is a sequential dependency, e.g. a word edit to a paragaph cannot be undone if the paragraph has been added and this paragraph adding has already been rejected. Equally, an application can communicate in the format that there is no sequential dependency by using a CT Set.

GCT document states:
10. CTs can be grouped either in a specific order (CT Stack) or as a set (CT Set). These groupings are for convenience, for example to allow a global edit (change all), or an editing session, to be undone in one operation. A CT group shall only reference previously-defined CTs or CT groups.

In section 5 the document says, "The ordering of the change transactions is important. If a user wishes to undo the changes one by one, then this can be achieved by undoing the change transaction at the end of the list and then moving up the list." This is not very clear, I agree. It it the truth but not the whole truth!

The objectives for CT ordering and grouping are:

1.  To provide a default ordering such that a receiving application can undo the changes in the reverse order and guarantee that the document is correct.

2. To provide the ability for an application to communicate that a group of CTs is order independent, or that it is order dependent. For example, if all the CTs were put into a single CT set, then each one could be undone in any order.

3. To provide the ability for a single CT to be in more than one group, for example an edit might be part of a 'global edit' group and also part of a group that represents all the changes made in a particular editing session.

We need to clarify this in the document, so thank you for pointing out the issue.
 
Best regards,
Robin

-- 
-- -----------------------------------------------------------------
Robin La Fontaine, Director, DeltaXML Ltd  "Change control for XML"
T: +44 1684 592 144  E: robin.lafontaine@deltaxml.com      
http://www.deltaxml.com      
Registered in England 02528681 Reg. Office: Monsell House, WR8 0QN, UK


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]