Re: [office-collab] Counting issues, etc

[Patrick Durusau <patrick@durusau.net>]

Dennis,

On 10/01/2012 12:05 PM, Dennis E. Hamilton wrote:
> In the spirit of starting with simple examples, here's one similar to what Patrick introduced.  I am not assuming which approach to change-tracking is used beyond assuming that the persistent form of the document can be read as if the changes are all applied when change-tracking is ignored.
>
> ORIGINAL SPECIMEN
>
>     <text:p text-attributes1>Consider that: </text:p>
>     <text:p text-attributes2>ACKXXX once upon a time there were three little pigs.</text:p>
>
> The user deletes, as a single operation, the text from the ":" to the text ending "ACKXX".
>
> If this is allowed as a single deletion (it is in current ODF 1.2 implementations of change-tracking) at least two things will happen:
>
> The resulting text will often be persisted as
>
>      <text:p text-attributes1>Consider that once upon a time there were three little pigs.</text:p>
>
> And something like the following will be captured elsewhere to reflect the deleted content:
>
>         <text:p text-attributes1>: </text:p>
>         <text:p text-attributes2>ACKXX</text:p>

This is our first point of departure.

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

> There is additional markup to know where the deletion point is and information sufficient for (1) revoking the change, (2) accepting the change (trivial), and also (3) being able to display the text with change tracking in-line with distinctive markup.  (The ODF specification doesn't address these, but it is required to afford these activities in a practical implementation.)
>
> Note that the formatting differences of the second paragraph are lost.  This is typical of what happens if the user takes no further action to remedy that.
>
> Another way to handle that would be with something like this in the persisted post-deletion markup:
>
>   <text:p><text:span text-attributes1>Consider
>    that</text:span><!-- deletion point --><text:span text-attributes2>
>     once upon a time there were three little pigs.</text:span></text:p>
>
> although this requires an implementation that makes it easy for users to recognized and control <text:span> effects.
>
>   
> 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.

So that if I simply print the "text," I get it as if all changes have 
been accepted.

I was expecting a fuller list of "components" but in their absence, 
consider if we use text-offsets (no attempt to formulate the change syntax):

insert ":" at 14.

create <text:p attributes2> at 19. (by well-formedness rule, now open 
elements must close)

insert "ACKXXX " at 19. (note the text point is now inside the new 
paragraph. But also note that the operations are defined against the 
text *as known to the application* so shifting text locations are 
trivial to calculate.)

> 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?

Perhaps a better way to say the difference in MCT and proposals to date:

Other proposals are capturing changes as they occur in markup syntax (or 
at least purport to). (A changing text.)

MCT expresses changes against the final text to revert it to some 
earlier state. (A final text or at least one where I can reliably 
calculate character off-sets for example.)

Yes?

Hope you are having a great day!

Patrick

>   - Dennis
>
> PS: Knuth has said as much to me, although when I saw him in June, change-tracking was not part of the conversation [;<).
> The problem is not with simple examples, it is with solutions that are simple only for the wrong problem.

Too bad. ;-)

True, but simple examples cut away hidden assumptions, like applications 
caching their change tracking operations in markup for later 
serialization. I find that difficult to believe. Not that it could not 
happen.

PS: I used character off-sets but you could just as easily, if not more 
so, use XPath expressions. Or a subset of XPath actually. Would be one 
less new thing to have to learn.


> -----Original Message-----
> From: office-collab@lists.oasis-open.org [mailto:office-collab@lists.oasis-open.org] On Behalf Of Patrick Durusau
> Sent: Sunday, September 30, 2012 03:12
> To: office-collab@lists.oasis-open.org
> Subject: Re: [office-collab] Counting issues, etc
>
> [ ... ]
>
> Now, assume that staying with an all <text:p> example (apologies to
> Dennis but Knuth says it is easier to start with simple examples and
> work your way up), we have:
>
> <text:p>A paragraph</text:p>
> <text:p>Paragraph that will be deleted - no change tracking</text:p>
> <text:p>Another paragraph</text:p>
> <text:p>Paragraph to be inserted - with change tracking</text:p>
> <text:p>Yet another paragraph</text:p>
>
> [ ... ]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: office-collab-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: office-collab-help@lists.oasis-open.org

--
Patrick Durusau
patrick@durusau.net
Former Chair, V1 - US TAG to JTC 1/SC 34
Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)

Another Word For It (blog): http://tm.durusau.net
Homepage: http://www.durusau.net
Twitter: patrickDurusau