RE: [office-collab] Counting issues, etc

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

ADDITIONAL RESPONSE

To be clear, my illustrations are of a portion of a document read by a CT-implementing consumer, and the persistent form produced by that consumer.

When I speak of the user action and how that producer responds, it is only meant to illustrate what is essential for the producer to arrive at the produced form of the change.  In the case of the simple example, it is a deletion that crosses from the end of one paragraph-content element into the beginning of the following paragraph-content element and is implemented as a single deletion.

This is a genuine use case, even though what happens at the ODF format level is simply that there is an expression of it in the persistent XML that is produced.

So when I speak of what is captured somewhere, I mean in the persistent form and was not intending to imply anything about what happens internally or even what is acted upon internally.

With regard to the persisted XML after the deletion in my example, there is nothing unusual in the resulting paragraph text apart from the fact that, for ODF 1.2, there will be a marker element at the point where the deletion happened.  This little scar tissue contributes no content and is ignored by non-CT-aware applications.  

If there are no markers in the case of MCT, that makes it interesting to find when that portion of the input has a history of tracked changes and where the scar is.

To answer the question about what determines the form and content of the spliced (post-deletion) result: In current practice it is the leading element that determines the resulting element.  That is, the start tag is that of the original leading element and the end tag of the decapitated and spliced element is changed to provide a well-formed match.  

That appears to be a consistent practice.  It is quite visible that it happens that way.  It is simply how things seem to work now and in interoperability with other formats.  I showed an example that would also be legal that does preserve the attributes on opposite sides of the splice, but it doesn't do anything about the elements being different.

 - Dennis

-----Original Message-----
From: office-collab@lists.oasis-open.org [mailto:office-collab@lists.oasis-open.org] On Behalf Of Patrick Durusau
Sent: Tuesday, October 02, 2012 01:31
To: office-collab@lists.oasis-open.org
Subject: Re: [office-collab] Counting issues, etc

[ ... ]

That is *not* what is captured elsewhere. How an application "captures" 
the change isn't nor should it be any of our business.

 
> THE PUZZLE
>
> How is this case handled in the MCT proposal?  I know what the ODF 1.2 "solution" is, and I can imagine simple attribute additions to that specification that would assist in (1) correct presentation with changes shown and (2) correctly restoring the original markup if the deletion is rejected.

The text as saved by the application:

<text:p text-attributes1>Consider that once upon a time there were three little pigs.</text:p>


That is the text *against which* operations are expressed to record 
changes for acceptance/rejection by others.

[ ... ]

> BONUS POINTS
>
> In the original text, but with the same deletion, consider what happens when one or the other of the two <text:p> elements is a <text:h>.

<text:h text-attributes1>Consider that: </text:h>
<text:p text-attributes2>ACKXXX once upon a time there were three little pigs.</text:p>


To anticipate interoperability questions, I think we need to define a 
default when deletions cross element boundaries, which typically mean a 
change in styles.

So the question back to Dennis is:

Do I have:

<text:h text-attributes1>Consider that once upon a time there were three little pigs.</text:h>


Or,

<text:p text-attributes2>Consider that once upon a time there were three little pigs.</text:p>

As the final text?

[ ... ]