OpenDocument - Adv Document Collab SC

Hi, Looking at the generic change tracking proposal, example 6.13.2 uses delta:remove-leaving-content-start to handle the case when a text:p is toggled to a text:h in revisions. Example 6.9.2 uses ac:changeXXX to track an attribute's values during a document's lifetime, in the example the text:style-name is tracked. How do these two interact? If I set a style to a heading then the document will need to move to using a text:h and thus will use a delta:remove-leaving-content-start to include and strip the original text:p before outputting the text:h for the current heading style. Should ac:change attributes be used for inclusive groups which do not require mutation between text:p and text:h elements and the delta:remove-leaving-content-start method used when such an element change has been forced?

Hi Ben, Example 6.13.2 as you say shows a change from a text:p to a text:h. It also involves an effective change in style name from Text_20_Body to Heading_20_1. However, as the element name is being changed, the attribute change does not need to be marked as a separate change, the original value is removed with the text:p and the new one is inserted with the text:h. The remove-leaving-content and insert-around-content constructs, although not affecting the content in their subtrees, do include the addition/insertion of the attributes on the element. So when removing the text:p, the text:style-name attribute is also removed and the corresponding attribute is inserted again with the insertion of the text:h. Hope that clears it up. Regards, Tristan On 29 Mar 2011, at 06:13, monkeyiq wrote: > Hi, > Looking at the generic change tracking proposal, example 6.13.2 uses > delta:remove-leaving-content-start to handle the case when a text:p is > toggled to a text:h in revisions. Example 6.9.2 uses ac:changeXXX to > track an attribute's values during a document's lifetime, in the example > the text:style-name is tracked. > > How do these two interact? If I set a style to a heading then the > document will need to move to using a text:h and thus will use a > delta:remove-leaving-content-start to include and strip the original > text:p before outputting the text:h for the current heading style. > > Should ac:change attributes be used for inclusive groups which do not > require mutation between text:p and text:h elements and the > delta:remove-leaving-content-start method used when such an element > change has been forced? > > > > --------------------------------------------------------------------- > 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 > -- Tristan Mitchell, DeltaXML Ltd "Change control for XML" T: +44 1684 869 035 E: tristan.mitchell@deltaxml.com http://www.deltaxml.com Registered in England 02528681 Reg. Office: Monsell House, WR8 0QN, UK

On Tue, 2011-03-29 at 10:58 +0100, Tristan Mitchell wrote: > Hi Ben, > > Example 6.13.2 as you say shows a change from a text:p to a text:h. It > also involves an effective change in style name from Text_20_Body to > Heading_20_1. However, as the element name is being changed, the > attribute change does not need to be marked as a separate change, the > original value is removed with the text:p and the new one is inserted > with the text:h. The remove-leaving-content and insert-around-content > constructs, although not affecting the content in their subtrees, do > include the addition/insertion of the attributes on the element. So > when removing the text:p, the text:style-name attribute is also > removed and the corresponding attribute is inserted again with the > insertion of the text:h. > > Hope that clears it up. > > Regards, > > Tristan So assuming the below three phase edit, where a text:h is changed to a text:p and then the style is modified to remain text:p but obviously the style-name needs ac:changeXXX tracking things should look like the below? Starting with <text:h text:style-name="Heading_20_1" text:outline-level="1"> What are the ground rules? </text:h> is changed to <text:p text:style-name="Normal_1"> What are the ground rules? </text:p> is changed to <text:p text:style-name="foo"> What are the ground rules? </text:p> Then in ODT generic CT you get something like the below..? I'm still working out here the idref values for the ac:change001 and delta:insertion-change-idref. But at least the markup of ac:change for style changes not effecting an element change seems logical... As far as idefs go, In my current implementation this would likely turn out to have the contents of the text:p inserted as pcdata with ct1234 and the text:p itself having an idref of ct1235 assuming the style-name change from normal_1 to foo happened in ct1235. But that can be clarified in another email once I get the code creating things like the below. <delta:remove-leaving-content-start delta:removal-change-idref='ct1234' delta:end-element-idref='ee888'> <text:h text:style-name="Heading_20_1" text:outline-level="1" /> </delta:remove-leaving-content-start> <text:p text:style-name="foo" ac:change001="ct1234,insert,text:style-name,Normal_1" delta:insertion-type='insert-around-content' delta:insertion-change-idref='ct1234'> What are the ground rules? </text:h> <delta:remove-leaving-content-end delta:end-element-id='ee888'/>

That's along the right lines. The remove-leaving-content and insert-around-content would have the same change transaction id as they happen at exactly the same time. The subsequent attribute change (change of para style) would be in a new change transaction as it is a separate change. I expect it's just a typo but the closing tag in the example after What are the ground rules? would be a text:p The final result would be something like this (my changes highlighted in bold): <delta:remove-leaving-content-start        delta:removal-change-idref='ct1234'        delta:end-element-idref='ee888'>   <text:h text:style-name= Heading_20_1  text:outline-level= 1 /> </delta:remove-leaving-content-start> <text:p   text:style-name= foo    ac:change001= ct1235 , modify ,text:style-name,Normal_1  delta:insertion-type='insert-around-content'   delta:insertion-change-idref='ct1234'> What are the ground rules? </t ext:p > <delta:remove-leaving-content-end delta:end-element-id='ee888'/> On 29 Mar 2011, at 11:49, monkeyiq wrote: On Tue, 2011-03-29 at 10:58 +0100, Tristan Mitchell wrote: Hi Ben, Example 6.13.2 as you say shows a change from a text:p to a text:h. It also involves an effective change in style name from Text_20_Body to Heading_20_1. However, as the element name is being changed, the attribute change does not need to be marked as a separate change, the original value is removed with the text:p and the new one is inserted with the text:h. The remove-leaving-content and insert-around-content constructs, although not affecting the content in their subtrees, do include the addition/insertion of the attributes on the element. So when removing the text:p, the text:style-name attribute is also removed and the corresponding attribute is inserted again with the insertion of the text:h. Hope that clears it up. Regards, Tristan So assuming the below three phase edit, where a text:h is changed to a text:p and then the style is modified to remain text:p but obviously the style-name needs ac:changeXXX tracking things should look like the below? Starting with <text:h text:style-name= Heading_20_1 text:outline-level= 1 >  What are the ground rules? </text:h> is changed to <text:p text:style-name= Normal_1 >  What are the ground rules? </text:p> is changed to <text:p text:style-name= foo >  What are the ground rules? </text:p> Then in ODT generic CT you get something like the below..? I'm still working out here the idref values for the ac:change001 and delta:insertion-change-idref. But at least the markup of ac:change for style changes not effecting an element change seems logical... As far as idefs go, In my current implementation this would likely turn out to have the contents of the text:p inserted as pcdata with ct1234 and the text:p itself having an idref of ct1235 assuming the style-name change from normal_1 to foo happened in ct1235. But that can be clarified in another email once I get the code creating things like the below. <delta:remove-leaving-content-start       delta:removal-change-idref='ct1234'       delta:end-element-idref='ee888'>   <text:h text:style-name= Heading_20_1  text:outline-level= 1 /> </delta:remove-leaving-content-start> <text:p  text:style-name= foo  ac:change001= ct1234,insert,text:style-name,Normal_1  delta:insertion-type='insert-around-content'  delta:insertion-change-idref='ct1234'> What are the ground rules? </text:h> <delta:remove-leaving-content-end delta:end-element-id='ee888'/> -- Tristan Mitchell, DeltaXML Ltd Change control for XML T: +44 1684 869 035 E: tristan.mitchell@deltaxml.com http://www.deltaxml.com Registered in England 02528681 Reg. Office: Monsell House, WR8 0QN, UK

On Tue, 2011-03-29 at 11:59 +0100, Tristan Mitchell wrote: > That's along the right lines. The remove-leaving-content and > insert-around-content would have the same change transaction id as > they happen at exactly the same time. The subsequent attribute change > (change of para style) would be in a new change transaction as it is a > separate change. Excellent, so we are on the same page here for how things should look :)) > > > I expect it's just a typo but the closing tag in the example after > "What are the ground rules?" would be a text:p yep. A little over zealous cut and paste from the original text:p -> text:h from the generic proposal document. > > > The final result would be something like this (my changes highlighted > in bold): An interesting observation, applications might track when a change takes effect. For example, records like ct1234 text:style-name Normal_1 ct1235 text:style-name foo record that in given revisions then attributes are set to a given value. and as the ODF+CT proposal says, the ac:change records the revision where something is changed and the value *before* that change was effective. Thus the above immediate changes generate: ct1235,modify,text:style-name,Normal_1 and the "foo" value is stored inline in the text:style-name attribute. And the following four changes in immediate, ie, user sets style to foo in ct12 while using the application: ct12 text:style-name foo ct13 text:style-name bar ct14 text:style-name baz ct15 text:style-name bob gives on ODF+CT: <text:p text:style-name="bob" ac:change001="ct12,insert,text:style-name" ac:change002="ct13,modify,text:style-name,foo" ac:change003="ct14,modify,text:style-name,bar" ac:change004="ct15,modify,text:style-name,baz" ...</text:p> At ct12 you know style-name is inserted, and the value foo would be used inline in text:style-name="foo". Just a little aside for those who are wishing to implement this in other tools. > > <delta:remove-leaving-content-start > delta:removal-change-idref='ct1234' > delta:end-element-idref='ee888'> > > <text:h text:style-name="Heading_20_1" text:outline-level="1" /> > > </delta:remove-leaving-content-start> > <text:p > text:style-name="foo" > ac:change001="ct1235,modify,text:style-name,Normal_1" > delta:insertion-type='insert-around-content' > delta:insertion-change-idref='ct1234'> > What are the ground rules? > </text:p> > <delta:remove-leaving-content-end delta:end-element-id='ee888'/>