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


Dennis,

It is clear that you disagree but I remain at a loss as to the source of the disagreement.

If your point is ODF 1.2 does not track change tracking as proposed by MCT, right in one.

If your point is that ODF 1.2 inserts elements in the markup to perform change tracking (MCT doesn't), again, right in one.

If your point is that ODF 1.2 change tracking, despite being underspecified, does in fact work in some cases, once again, right in one.

None of which are relevant to discussions of the basis for MCT.

That is unless and until we can establish a common vocabulary and ground for discussion of MCT, we are going to talk past each other. Whether discussing the merits of MCT or other aspects of change tracking.

There has been widespread agreement in the TC that the current ODF change tracking is inadequate. Robin Fontaine spent more than a year of meetings carefully documenting two complete proposals to replace ODF change tracking. Another proposal has arisen from scattered posts and presentations, which has been recommended to the TC. And we are now working on fleshing that out.

Perhaps this will help (and your posts helped to provoke this comment):

The difference in ODF 1.2, ECT and GCT change tracking and MCT is your starting point of view.

For ODF 1.2, ECT and GCT (warning, just my opinion, others may correct), change tracking *looks forward* from the document instance as read into the application and when the file is saved, changes are recorded against the original document markup.

For MCT (again, just my opinion), change tracking *looks backward* from the document instance that is being saved and records changes as operations against the document that is being saved.

The results should be equivalent but how you specify them and advantages/disadvantages are quite different.

Does that help?

Hope you are having a great day!

Patrick





On 10/02/2012 04:06 PM, Dennis E. Hamilton wrote:
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?

[ ... ]


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



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