[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [office-collab] Notes on Conference call to discuss use casesolutions UC4-UC8
Something tickled my mind when the question about arbitrary rejection order was raised Tuesday morning, but I was either not awake enough to remember the details or was already juggling too many windows with a laptop screen and touchpad to find prior discussion on this topic.
Both GCT and ECT, using their different representations, store the previous state for each change that is made. Conceptually, each should be in the same position with regard to a specific change being rejected and what should be restored.
Recall the e-mail thread from June ("Serialization and change tracking ") about this topic, using UC 1 as the example. Here's the first e-mail: http://www.oasis-open.org/apps/org/workgroup/office-collab/email/archives/201106/msg00015.html.
That thread looked at arbitrary order rejection for both ECT and GCT, so I think it's fair to say both representations can handle it. If there are any specific problems with ECT, I'd love to have the details as both Doug and I noted early on that we think arbitrary order rejection is important to users. More fundamentally, it also uncovered that what results from various orders of rejection in cases when there are multiple changes to the same content depends on how the application chooses to structure the change-tracking markup when the changes are made and how it handles the remaining change markup. (e.g.: Tristan: I suppose it depends on how the change is made in the first place. John: Yes, I think that’s the rub. Off the top of my head, I think it varies based on how the style change is effected in markup)
It appears to me that a little runtime intelligence is required to determine what a particular rejection should yield (perhaps room for application choice / differentiation) and how to "clean up" the remaining change tracking markup.
If I read Dennis' comment correctly, I think the above is in line with what he mentions about OpenOffice.
John
-----Original Message-----
From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org]
Sent: Thursday, September 08, 2011 1:53 PM
To: 'Robin LaFontaine'; office-collab@lists.oasis-open.org
Subject: RE: [office-collab] Notes on Conference call to discuss use case solutions UC4-UC8
I have regularly rejected/accepted changes out of order in OpenOffice.org. In fact, you can reject a deletion and accept the insertion that was made in its place. (Obviously, "in its place" is not remembered in the current implementation nor the specification.) The two chunks of material then remain side-by-side in the way they were presented as a tracked deletion and tracked insertion.
The cases of one change being imbedded in another is odd except for moves (which are not explicitly provided for in ODF 1.2 change tracking) where one does need to be more clever. But not very much more clever.
I am guessing but it might only be movement that has this property of being reversible with later changes *that don't cross the boundary between moved-in and pre-existing* kept intact. If there can be a cross-over that edit breaks hierarchy in this manner, something trickier needs to happen. In other cases, the right thing happens because it has to.
- Dennis
-----Original Message-----
From: Robin LaFontaine [mailto:robin.lafontaine@deltaxml.com]
Sent: Thursday, September 08, 2011 09:39
To: office-collab@lists.oasis-open.org
Subject: [office-collab] Notes on Conference call to discuss use case solutions UC4-UC8
Notes on ADC SC Call - 6th Sept 2011
Present
-----------
Andreas
Robin (Chair)
John
Patrick
Rob
Svante
Thorsten B
Tristan
(Robin's office was suffering a power outage so he apologised that he could not access notes made for the call.)
UC4
------
Robin - with ECT buckets it seems that it is not possible to reject changes in any order, only reverse order gives the correct result.
Patrick - asked for clarification on why we need to reject out of order. Robin gave the example of moving a text frame and then editing the text. You may wish to only reject the move.
UC5
------
The main issues with this use case is the deletion and re-addition of the text content. It also has the same problems as UC4 but this was already covered in previous call.
UC6
------
ECT is very verbose. Again, cannot reject in any order.
Patrick - is the verbosity worse than the current change tracking format?
There is not really a comparable example in the current change tracking John - the main concern is how an application matches together the fine-grained GCT changes with a viewable edit operation.
Robin responded to say that they are modifying the spec to add editing operation information. Understood that this is an issue for an editing application reading in tracked changes, and needs to be addressed.
UC7 + 8
------------
No significant comments on these use cases.
Consensus report
-------------------------
Robin will work on a first draft of this, should be complete by month end. Report to contain an introduction to the different approaches, report on work done in the SC and a SWOT analysis for each approach. Comments from SC members would be useful - Rob queried the wisdom of including member's names with quotes. If the document is to be sent out for public review, it can be an issue in that quotes would then need to be approved by companies. Decision was made to include quotes without names. Noted that there will be a revised version of GCT addressing some of the issues raised. There is no revision to ECT expected.
AOB
------
Svante asked if we could define what would be in the first milestone.
Robin commented that this could only be done once we had decided on which approach to move forward with.
Date of next call will need to be re-scheduled as John's dates away have changed, date to be confirmed early in October.
--
-- -----------------------------------------------------------------
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
--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]