office-collab — archive

Groups - Conference call to discuss use case solutions UC4-UC8 added

From: Robin LaFontaine <[email protected]>
To: [email protected]
Date: Sat, 10 Sep 2011 11:27:00 -0000

On 09/09/2011 20:29, John Haug wrote: 91C4760493E4094B9871E5A496374DA23B1EDBE0@DF-M14-02.exchange.corp.microsoft.com type= cite > 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. 91C4760493E4094B9871E5A496374DA23B1EDBE0@DF-M14-02.exchange.corp.microsoft.com type= cite > 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 b ol d ) (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 b ol d ) 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:[email protected] ] Sent: Friday, September 09, 2011 9:36 AM To: [email protected] 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: [email protected] 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: [email protected] http://www.deltaxml.com Registered in England 02528681 Reg. Office: Monsell House, WR8 0QN, UK