RE: [office-collab] Paragraph merge in ODF (earlier - Re: [office-collab] FW: [office] Groups - MCT Challenge #1 Documents (Zip) uploaded)

["Dennis E. Hamilton" <dennis.hamilton@acm.org>]

I'm still confused.

Let's back up.  Is it agreed that the selection and deletion illustrated in MCT Challenge #1 is legitimate?  Is it agreed that the rejection of the deletion in a subsequent CT-aware consumer should restore the original text and all of its formatting, as if the deletion never happened?

 - Dennis

FURTHER OBSERVATIONS

The "Normal" style is a descendant of the default paragraph style in styles.xml.  That happens to be how it is done in the document I started from.

Furthermore, the movement of text styles from the paragraph styles and introduction in <text:span> styles is certainly within an application's discretion.  However, the <style:paragraph-properties> of style P3 got lost in the process.  That should not have happened.

There is nothing in ODF that requires that particular refactoring of styles in order to correctly track the changes.  (I'm not saying refactoring should be prevented, I'm saying this particular one doesn't work.)  In this particular case, important information needed to properly reject the deletion was lost in the process.  I don't doubt that there are implementations that do that, and perhaps all current OpenOffice-heritage code has the same deficiency.  It is not necessary to adopt a different change-tracking model to correct that.

Also, I don't know what this markup is:

<h>start delete</h>
<p>delete end</p>
<h>
    <span>start </span>
    <span>end</span>
</h>

It has nothing to do with the challenge example.  Is it a hint about what MCT does?  I find it inexplicable.

 - Dennis

-----Original Message-----
From: Svante Schubert [mailto:svante.schubert@gmail.com] 
Sent: Monday, October 15, 2012 16:03
To: dennis.hamilton@acm.org
Cc: office-collab@lists.oasis-open.org
Subject: Re: [office-collab] Paragraph merge in ODF (earlier - Re: [office-collab] FW: [office] Groups - MCT Challenge #1 Documents (Zip) uploaded)

On 16.10.2012 00:35, Dennis E. Hamilton wrote:


	I don't believe that is an adequate explanation.  I don't understand either the scope nor the necessity of " All paragraph properties (hard formatted and named style) are lost, similar the text properties of a named style of the second paragraph."

Before we discuss what you believe is adequate, let us discuss what changes may occur during a paragraph merge. The text content change is pretty obvious and can be ignored or explained later. Interesting is what happens to the styles.

A paragraph can have hard formatted text and paragraph style properties. Let us take a look into your document "CT-2012-10-04-1554-Challenge-01.odt":

<style:style style:name="P3" style:parent-style-name="Normal" style:family="paragraph">
    <style:paragraph-properties fo:margin-left="0.5in">
        <style:tab-stops/>
    </style:paragraph-properties>
    <style:text-properties fo:font-style="italic" style:font-style-asian="italic"/>
</style:style>

Now the "Normal" parent named style could have again paragraph and text properties (in the styles.xml), unfortunately it does not have any.
Anyway what someone might observe by testing several ODF applications: Hard formatted styles of the components are moved to spans, all other format properties are kept from the first paragraph (or heading).

<h>start delete</h>
<p>delete end</p>

<h>
    <span>start </span>
    <span>end</span>
</h>



	
	
	For one thing, there is no necessity of implementing it that way in ODF 1.2.  

I can not follow your reasoning here. ODF is the specification and I do very much see the necessity that ODF 1.2++ implementations are able to know what operations will be tracked by the standard and what ODF XML change these operations trigger to achieve interoperability and minimal change-tracking file-size, flexibility and upcoming features (as merge, versioning and real-time collaboration).


	
	
	But, mainly, this is not a response to the challenge.  The challenge is to show what is a correct representation of the equivalent change-tracking in MCT.  That is, what are the structures/markup employed in the document persisted with MCT that provides tracking in a way that it can be presented and accepted or rejected in another consumer?

That is the first part of the response, Dennis.
First we specify an operation and afterwards we will use it.

Therefore again, would you agree on the observation, Dennis?
Svante


	
	 - Dennis 
	
	-----Original Message-----
	From: Svante Schubert [mailto:svante.schubert@gmail.com] 
	Sent: Monday, October 15, 2012 15:10
	To: dennis.hamilton@acm.org; office-collab@lists.oasis-open.org
	Subject: Re: [office-collab] Paragraph merge in ODF (earlier - Re: [office-collab] FW: [office] Groups - MCT Challenge #1 Documents (Zip) uploaded)
	
	On 15.10.2012 23:49, Svante Schubert wrote:

		The first paragraph (or heading) will keep its named style properties
		(both text and paragraph), while the character (or text) format
		properties are being moved from each paragraph to spans within the
		merged paragraph.

	
	Reading it over, I realized I could have made the above more explicit:
	
	"The first paragraph (or heading) will keep its named style properties (both text and paragraph). In addition the hard formatted paragraph properties of the first component are being kept.
	The hard formatted text (or character) properties of each component are moved from each style to new hard formatted text styles referenced by new created spans embracing the remaining text of each previous component within the
	new merged paragraph. All paragraph properties (hard formatted and named style) are lost, similar the text properties of a named style of the second paragraph."
	
	Svante