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: RE: [office-collab] Arbitrary order rejection (was Notes on Conference call to discuss use case solutions UC4-UC8)


Agreed that producers often consolidate changes that can be viewed as single ones into a single change.

However, when different users do it, that is generally not allowable, including when the original user does more that involves change by the intermediate author.

I don't know how to make that statement about ECT.  It might be true, but I am not confident about it.  There is probably something that can be done with a graph-theoretic depiction of the cases that might demonstrate closure on this question.  I haven't undertaken anything like that.

I was only commenting about interdependent attributes and what happens when they are changed (by inheritance even) and then changed more.  This is not about the broader problem you raise in your reply.  I think that is an interesting problem.  I wasn't going there.  Just pointing out that semantics and interdependence are inescapable in ODF, even at the attribute level. 

 - Dennis

PS: Since ODF 1.2 does not track moves, there is no experience with that in current implementations of ODF.  I believe those are very interesting cases, and they impinge on cut-and-paste rules too, perhaps.  It is interesting to see how clip-board involvement is handled now, although there is no clue in the ODF 1.2 specification of tracked changes.

-----Original Message-----
From: Robin LaFontaine [mailto:robin.lafontaine@deltaxml.com] 
Sent: Monday, September 12, 2011 01:38
To: office-collab@lists.oasis-open.org
Subject: Re: [office-collab] Arbitrary order rejection (was Notes on Conference call to discuss use case solutions UC4-UC8)

In general the independence of the changes is established by the actions of the user, i.e. whether he/she made the changes as a single action or several actions perhaps with other actions in between. Such independence is recorded in the tracked changes because each change is a separate change (CT). 

The example was intended to illustrate the problem in the simplest possible way, but the problem itself is more widespread. UC6 is a larger example - a text frame is moved, text is edited, then it is resized, then moved again. The changes are independent, from the user's perspective and are recorded as such because they are different CTs. 

So I believe this remains true: "for ECT any two changes that affect one 'bucket' can only be rejected correctly in the reverse order, i.e. if the last change is rejected first. Of course a user does not know anything about buckets so this may lead to confusing behaviour." 

Robin

On 10/09/2011 16:07, Dennis E. Hamilton wrote: 

	But of course it must be known that changed attributes are independent in a given situation, yes?  In some cases, the interdependence is not known from the schema alone, and so "some intelligence" is required.  (It is potentially even more fun if foreign-attributes or attributes with foreign-values are present in the document produced with change tracking.)
	
	I am not sure if there is any guidance in the current implementations or not.  Experiments with style changes would have to be made to see if it is even apparent to users that there were multiple, separate style changes in exactly the same span.
	
	 - Dennis
	
	-----Original Message-----
	From: Robin LaFontaine [mailto:robin.lafontaine@deltaxml.com] 
	Sent: Saturday, September 10, 2011 04:26
	To: office-collab@lists.oasis-open.org
	Subject: Re: [office-collab] Arbitrary order rejection (was Notes on Conference call to discuss use case solutions UC4-UC8)
	
	On 09/09/2011 20:29, John Haug wrote: 
	
		I still have the same two questions/comments:
	
		1.       The application needs a little intelligence about what to provide the user after future actions.
	
		2.       Leaving aside #1, how is “any two changes that affect one 'bucket' can only be rejected correctly in the reverse order” any different between ECT and GCT?
	
	I hope that the example provided shows that for ECT this is true, but please let me know if you are not convinced. UC8 also provides a good example of this issue.
	
	So, how is GCT different? For the example below we would have for GCT this representation:
	
	<style:style style:name="Style1" style:family="paragraph">
	  <style:text-properties fo:font-weight="bold" ac:a3_d22e5="ct2,modify,fo:font-weight,normal" 
	   fo:font-style="italic" ac:a3_d22e10="ct1,insert,fo:font-style"  />
	</style:style>
	
	(I used the sandbox here to get this: http://www.deltaxml.com/samples/track-changes/sandbox.html )
	
	You can reject either ct1 or ct2 here in either order to get back to the initial version. Reject ct1 and the font-style attribute goes. Reject ct2 and the font-weight reverts to normal. There is no collateral damage.
	
	This is how GCT can handle this situation correctly and differs from ECT in this respect. This is a small example, UC8 is a larger one.
	
	Regarding your example in 2 below, yes you are correct that GCT cannot handle this any better than ECT because we are at the lowest level of granularity. Consider an attribute color="red" (and I respectfully use US spelling!), then this changes to "green" then to "black". What happens if we undo the change of red to green, then undo the change of green to black? Well, it is not really possible or sensible to do that at that level of granularity. But when we change the font-weight we do not expect collateral damage in the change to another attribute, which happens with ECT in my example - that is where ECT and GCT differ.
	
	
		
	
		 
	
		1. Runtime behavior
	
		I think runtime behavior may be conflated with storage format.  The storage format needs to provide the means for applications to store the information necessary to preserve the state of the document, which may also include information about how it got where it is.  The application may manipulate the stored data as needed to achieve this – the data itself does not need to be seen as rigidly unchanging.
	
		 
	
		..snip 
	
		 
	
		2. GCT & ECT
	
		First, let me make clear that I ask this to better understand this claimed difference, because I don’t see it.  My intent is not to turn around a question about ECT and cut down GCT.  Taking the “Proposal 2” markup from GCT-style-change-response.odt, if change ct1 is rejected, depending on what the application does with the remaining ct2 markup, wouldn’t that result in either (A) dropping ct2 also or (B) keeping the text:span around the “ol” in “bold” with an out-of-sync ct2 cached state?  It looks to me like the same situation where a little runtime intelligence is required to handle this in a particular way.  (A) might be clear and may be desirable, but it implicitly rejects all other changes after ct1, so the user can’t keep the underlined “ol”.  (B) leaves an unexpected format state (NormalStyle) waiting when the user rejects ct2.  Assuming I have the GCT behavior correct:
	
		 
	
		Starting markup
	
		<text:p text:style-name="BoldStyle">Remove
	
		<text:span text:style-name="NormalStyle" ac:change001="ct1,add,text:style-name">b</text:span>
	
		<text:span text:style-name="UlNormalStyle" ac:change001="ct1,add,text:style-name" ac:change002="ct2,modify,text:style-name,NormalStyle">ol</text:span>
	
		<text:span text:style-name="NormalStyle" ac:change001="ct1,add,text:style-name">d</text:span>
	
		</text:p>
	
		 
	
		(A) Rejecting ct1 reverts the “add” and removes the middle text:span
	
		<text:p text:style-name="BoldStyle">Remove bold</text:p>
	
		--> Remove bold (not: Remove bold)
	
		 
	
		(B) Rejecting ct1 without implicitly dropping ct2 leaves a text:span which, if ct2 is later rejected, will revert the “ol” to NormalStyle
	
		<text:p text:style-name="BoldStyle">Remove b
	
		<text:span ac:change002="ct2,modify,text:style-name,NormalStyle">ol</text:span>
	
		d
	
		</text:p>
	
		--> Remove bold (but after rejecting ct2: Remove bold)
	
		 
	
		 
	
		 
	
		Does that make sense or did I leave something insufficiently described?  I apologize for the length of the above, but I wanted to make my thinking as clear as I could.  If it’s not, everyone will have a wait a while for me catch up on e-mail after I get back from vacation. J
	
		 
	
		John
	
		 
	
		From: Robin LaFontaine [mailto:robin.lafontaine@deltaxml.com] 
		Sent: Friday, September 09, 2011 9:36 AM
		To: office-collab@lists.oasis-open.org
		Subject: [office-collab] Arbitrary order rejection (was Notes on Conference call to discuss use case solutions UC4-UC8)
	
		 
	
		On 09/09/2011 01:38, John Haug wrote: 
	
		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.
	
		I believe the issue can be illustrated in the example below.  
		
		Doc-v0:
		<style:style style:name="Style1" style:family="paragraph">
		    <style:text-properties fo:font-weight="normal"/>
		</style:style>
		
		Doc-v1:
		<style:style style:name="Style1" style:family="paragraph">
		    <style:text-properties fo:font-weight="normal" fo:font-style="italic"/>
		</style:style>
		
		Doc-v2:
		<style:style style:name="Style1" style:family="paragraph">    
		    <style:text-properties fo:font-weight="bold" fo:font-style="italic"/>
		</style:style>
		
		Change 1 (doc-v0 to doc-v1) adds fo:font-style="italic" and so caches
		<style:style style:name="Style1" style:family="paragraph">
		    <style:text-properties fo:font-weight="normal"/>
		</style:style>
		and has:
		<ct:format-change-start ct:id="1"/>
		<style:style style:name="Style1" style:family="paragraph">
		    <style:text-properties fo:font-weight="normal" fo:font-style="italic"/>
		</style:style>
		<ct:format-change-end ct:id="1"/>
		
		Change 2 (doc-v1 to doc-v2) changes fo:font-weight="normal" to fo:font-weight="bold" and so caches
		<style:style style:name="Style1" style:family="paragraph">
		    <style:text-properties fo:font-weight="normal" fo:font-style="italic"/>
		</style:style>
		and has:
		<ct:format-change-start ct:id="2"/>
		<style:style style:name="Style1" style:family="paragraph">    
		    <style:text-properties fo:font-weight="bold" fo:font-style="italic"/>
		</style:style>
		<ct:format-change-end ct:id="2"/>
		
		Then if you reject 2 then reject 1 it works OK, but reject 1 then reject 2 would result in:
		<style:style style:name="Style1" style:family="paragraph">
		    <style:text-properties fo:font-weight="normal" fo:font-style="italic"/>
		</style:style>
		which is incorrect because fo:font-style="italic" remains there although change 1 has been rejected.
		
		I believe the situation is that for ECT any two changes that affect one 'bucket' can only be rejected correctly in the reverse order, i.e. if the last change is rejected first. Of course a user does not know anything about buckets so this may lead to confusing behaviour. This is one reason for my opinion that recording changes to attributes is important.
		
		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
	
		--------------------------------------------------------------------- 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 
	
	


-- 
-- -----------------------------------------------------------------
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 



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