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

[Svante Schubert <svante.schubert@gmail.com>]

Hello Dennis,

On 16.10.2012 02:18, Dennis E. Hamilton wrote:

I'm still confused.

MCT will use only operations, specified in the specification what ODF XML will change, to express a change in the document.
Operations are similar to labels to reference to a change described in the spec. To be able to only refer to those changes from the document and not explicitly describe the changes by before-after XML in each document (as GCT & ECT would do), the specific ODF XML change of an operations need of course be defined in a specification.
This is in additional helpful as only the minority of ODF applications have an XML based model and would need to some forensic work on the XML to figure out this parametrized label anyway.
This description of the XML change of your challenge is what I am trying to draft now to fulfill your challenge, Dennis.
After defining the XML change of your action (merge paragraph), we will define the XML change to undo your action (split paragraph), which will be capable to be parameterized in a way that the original state of the document can be restored.


Let us focus on the first three components of your challenge test document "CT-2012-10-04-1554-Challenge-01.odt":

<text:h text:style-name="P1" text:outline-level="1">Change-Tracking Challenge #1</text:h>
<text:p text:style-name="P2">This is a simple demonstration of cross-structure change-tracked deletion.</text:p>
<text:p text:style-name="P3">The deletion is a single operation striking the end of one paragraph and the beginning of the next, resulting in a single post-deletion paragraph.<text:s text:c="2"/>Subsequent challenges will involve compounding of deletions to reflect how they are tracked. <text:s/>It is also important to understand how deletion deals with the indentation of this paragraph.</text:p>

The heading is the first component, you start delete text from the second to the third component, which serialized MCT operations for the change of your challenge might be:
<del s="/2/10" e="/3/18" />
<merge s="/2" e="/3" />
The above are NOT the undo operations, but the operations that describe your change. The undo will follow as soon we agree on what is being changed in the XML and we (or I) need to think over how to handle styles in general (I will be on the ODF plugfest tomorrow and LibreOffice conference after, so I might have to pause this thread till next week).

I even would omit the second parameter for the merge as only sibling paragraphs can be merged. 
You challenge is by the way quite similar to the exampe of slide 14 of the MCT presentation (see MCT presentation), although that neglects styles completely, but even your challenge does not fully cover the style problematic, so I would like to extent this challenge.

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.

Shouldn't it? Paragraph styles after merging are like highlanders, there can only be one. Imagine both of your paragraphs of your challenge would have an indent, how do you merge it, which should be overtaken in the end?
No, everything is overtaken from the first paragraph, only the hard formatted text styles are being reused from both.

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:

Before change:
<h>start delete</h>
<p>delete end</p>

After change:
<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.

What I meant with this ODF XML draft example was, the starting mark-up of having a heading containing the text "start delete" in bold and a paragraph with the text "delete end" in italic both as hard formatted text styles.
And the ending markup of deleting the text "delete" in the heading and "delete " in the paragraph and finally merging these two.

In general the style change can be described as: "Hard formatted text styles of the components are moved to spans, all other format properties are kept from the first paragraph (or heading)."

Does this makes sense to you?
Svante

 - 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