OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-collab message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [office-collab] Counting issues, etc


I HAVE A CONCERN.  I think a failure to appreciate what is currently supported, and why it is supported the way it is (whatever difficulties there are with its proper specification and implementation) risks a folly of the kind said about those who refuse to study history.  This is especially a concern when it is claimed that the successor to ODF 1.0/1.1/1.2 change tracking will be able to accept or upgrade from (and downgrade to, where upgradeable from) the "legacy."  This needs to be moved from a matter of belief to a matter of demonstrated fact.

I use ODF CT here because there are implementations and behaviors that are known to be supported and working in more-or-less reliable ways.  It is easy to construct simple but interesting cases and examine the resulting XML and see what works when it works.  

I gave a simple case of a commonly-supported deletion that crosses from the end of one paragraph into the beginning of another.  

Here's more explanation of what it is that GCT has to stack up against in that simple example.

RESPONDING TO JUST THE FIRST PART ONLY:

I meant "something like" to avoid getting into the details of how deleted material is made well-formed.  I omitted the use of change marks and the way the material might be carried apart from showing how a deleted content fragment that severs elements can be adjusted to be content in a well-formed XML element.  I also did not get into how such a well-formed XML element can be restored to the proper fragment if the deletion is rejected by a subsequent consumer.

In particular, I was not saying what MCT is proposed to do, I was saying what must be accomplished in some manner if the example I gave is handled as a single deletion and expressed in XML.

In fact, the current <text:tracked-changes> <text:changed-region> <text:deletion> holds a run of text-content patterns and the run of two <text:p> elements I provide below qualifies. 

If I had gotten specific about how this works in ODF 1.2, I would have shown the post-deletion paragraph this way:

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

The <text:change> element can appear anywhere (runs of) paragraph-content can appear.  It has a text:change-id attribute (of type IDREF) that identifies the <text:changed-region> element (by its xml:id) that has the <text:deletion> element carrying the deleted material.  (Note that when these linkages are broken in either direction, a consumer can simply remove the appropriate widows and orphans, so broken connections can be cleaned up by CT-aware consumers, and damage left by CT-unaware consumers is to that extent self-healing.)

Note that, no matter what else happens in the resulting paragraph in places separate from or even spanning the <text:change> marker, there is nothing that has to be recomputed.  Text in the paragraph before the <text:change> marker can grow or shrink and it doesn't matter.  Likewise, if there is a subsequent deletion via a different session/author that includes the <text:change> mark, that is also no problem.  There is nothing that has to be figured out or adjusted to preserve the tracking of this particular deletion, even if it ends up inside tracked-deletion material.  

The user presentation and the acceptance/rejection process takes some care, but that's apparently the proper time to do it since something has to be done at that point regardless.  It is a rocket- (i.e., computer-) science problem to specify it in a sound way though.  I grant that ODF 1.2 CT is awesomely underspecified. 

 - 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

[ ... ]
> 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.

[ ... ]



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]