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] Multiple changes


Hi,

some insight to Apache OpenOffice (incubating)/OpenOffice.org change
tracking:
- Yes, AOO tries to be "intelligent" regarding changes made by a certain
author to her/his own changes.
- making a change to change in a certain time frame - I think these are
minutes - are "combined"; even if the document has been save-close-reopened
in between. Thus, we you delete a character that you have inserted before
you end up with no change.
- just start with an empty document and activate change tracking. Then type
some characters, but wait at least a minute between each character. You
will end up with several tracked changes - one for each character.
- I hope that a "session" ends at least when another author has touched the
document.

Mit freundlichen Grüßen / Best regards
Oliver-Rainer Wittmann

--
Advisory Software Engineer
-------------------------------------------------------------------------------------------------------------------------------------------

IBM Deutschland
Beim Strohhause 17
20097 Hamburg
Phone: +49-40-6389-1415
E-Mail: orwitt@de.ibm.com
-------------------------------------------------------------------------------------------------------------------------------------------

IBM Deutschland Research & Development GmbH / Vorsitzende des
Aufsichtsrats: Martina Koederitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart,
HRB 243294



From:	Patrick Durusau <patrick@durusau.net>
To:	office-collab@lists.oasis-open.org
Date:	20.09.2012 22:41
Subject:	Re: [office-collab] Multiple changes
Sent by:	<office-collab@lists.oasis-open.org>



Svante,

OK, trying again:

When you say:

      Not being saved. I can rewrite a sentence a dozen times , in the end
      it is only saved the delta from the start and the end of the session.
      In other words the operations are being compressed to express the
      information set representing the session delta.

What is a session?

If I save my document with tracking on and change a change (deleting the
"b" character) that was tracked, without accepting the changes:

<text:change-start text:change-id="ct139634698526728"/>a<text:change-end
text:change-id="ct139634698526728"/>

Previously, before the save, this read:

<text:change-start text:change-id="ct139634698526728"/>ab<text:change-end
text:change-id="ct139634698526728"/>

Now I save and *close* the file, is that a session?

<text:change-start text:change-id="ct139634712754456"/>a<text:change-end
text:change-id="ct139634712754456"/>

IDs get changed on reload, but changing a change, is still not captured,
after save and close of file.

So far, at least in the OpenOffice implementation:

1) save does not end a session

2) save and closing document does not end a session

3) ending change tracking does not end a session

Of course, OpenOffice does not implement "to be specified operations based
CT" but that means we have to define what is meant by "session."

I remain convinced this is possible or I would not be pushing so hard on
it.

Hope you are having a great day!

Patrick

On 09/20/2012 03:57 PM, Svante Schubert wrote:
      On 20.09.2012 15:26, Patrick Durusau wrote:
            Svante,

            On 09/20/2012 08:35 AM, Svante Schubert wrote:
                  Hi Patrick,

            <snip>

                        When forward progress of the text stops? When I
                        stop deleting the inserted text? When the cursor
                        has moved off the inserted text (after
                        deletions/additions)? Or the cursor has left the
                        inserted text for more than 5 seconds? After a
                        save?
                  Why shall we care? This is absolutely an implementation
                  detail of the application, all we have to care about is
                  that similar changes are able to be reflected by
                  different set(s) of operations, which all have in common
                  that they have the same information set, resulting in the
                  end into an equal change.
                  For instance, instead of three operations:
                     1.	insert "a" in paragraph 1 at position 1
                     2.	insert "b" in paragraph 1 at position 2
                     3.	insert "c" in paragraph 1 at position 3


                  The application might as well sent one operation:
                     1.	insert "abc" in paragraph 1 at position 1


                  AFAIK Google Docs is pushing every change right away to
                  the server, like editing in a field using AJAX.



            We should care because we are *not* writing a protocol for
            interchange of change tracking information.

      I suggest we do not invest too much energies to focus on what we
      should *not* do, who has a benefit from that attitude?
      Focus on what we are able to archive for our goal of change-racking.
      To allow an ODF application to undo changes made by another ODF
      application has much to do of of the interchange of change
      information. But perhaps we are just again at cross-purposes..
            We are writing a format to track changes in a file format for
            reading and presentation to a user (same or another user), post
            change. On the same or a different application.

            What is meant by: "..resulting in the end of an equal change?"
      That the state of the document is the same.

            I perform the following operations:

               1.	insert "a" in paragraph 1 at position 1
               2.	insert "b" in paragraph 1 at position 2
               3.	insert "c" in paragraph 1 at position 3


            I move off that changed text and perform changes elsewhere.


            I return to the abc text, which shows "change" in my interface
            and:


            4. delete "c" in paragraph 1 at position 3


            Question: Is that reflected in the *markup syntax* that is
            saved as part of the document?


      Not being saved. I can rewrite a sentence a dozen times , in the end
      it is only saved the delta from the start and the end of the session.
      In other words the operations are being compressed to express the
      information set representing the session delta.


            Here is what I get with the latest version of OpenOffice:


            <text:change-start text:change-id="ct139634698526728"/>
            ab<text:change-end text:change-id="ct139634698526728"/>


            The rest of the changes tracking:


            def in paragraph 2 at positions 1, 2, 3


            ghi in paragraph 3 at positions 1, 2, 3


            I conclude that changes to changes are not tracked in
            OpenOffice.


      Sure.


            That could be a *serious* failing if we are tracking changes by
            authors and a subsequent author can change my change and it
            still shows up as my change, albeit not as I changed it.


      No problem as far as I see...


            Hope you are having a great day!


      Same to you,
      Svante


            Patrick













                        Changing the position pointer (start or end) may be
                        part of a definition of change but it is a fairly
                        crude one.

                  Only if the position pointer is part of the document
                  state to be changes, AFAIK OOo is saving it into the
                  settings.xml properties.
                  Otherwise I refer to the beginning of this mail, a change
                  is reflected by an operation call upon the document.
                        Hope you are having a great day!

                        Patrick
                  Hope you are having a great day as well!
                  Svante


                        On 09/20/2012 05:49 AM, Svante Schubert wrote:
                              Hi Patrick,

                              On 19.09.2012 17:04, Patrick Durusau wrote:
                                    Svante,


                                    On 09/19/2012 08:35 AM, Svante Schubert
                                    wrote:
                                          Hi Patrick,
                                    <snip>
                                          That is at what time does the
                                          state of the text become "fixed"
                                          so that
                                          change tracking is engaged again?

                                          With "fixed" you might as well
                                          think about a
                                          compression/condensation of
                                          operations. For example, if
                                          someone inserts a word and
                                          deletes it again,
                                          it will not occur in the CT,
                                          although there had been two
                                          operations.
                                    That was my question.

                                    You are presuming a model that does not
                                    track changes to changes.
                              Might be philosophical, as every operation
                              creates a new independent
                              document state. Therefore two (or more)
                              sequential operations changing
                              the same data, could be interpreted either as
                              two (or more) independent
                              changes of the document state or as a change
                              of a change.

                              After realizing both views are equivalent it
                              is much easier to work
                              solely with the prior model, where each
                              change is independent and
                              movable along the sequence of operations
                              (presuming to do the required
                              OT adaption during movement, i.e. whenever
                              passing a create/delete
                              operation that influence the position of the
                              moving operation
                              de/increase the position integer).
                                    Which is one presumption but perhaps
                                    not the one that the TC desires
                                    to make.
                              The TC is likely to favor the easiest and
                              efficient model being offered.
                                    Can think of compression/condensation
                                    of operations but that means the
                                    CT syntax has to record multiple
                                    changes, say make bold and italic
                                    instead of separate operations of bold,
                                    then italic (on the same text).
                               From a abstract high level view, changing
                              the style on text is nothing
                              more than an change of properties on a
                              sequence of the document. Someone
                              might change a single property or multiple
                              properties. Latter might be
                              done via operations by either passing all
                              properties along or defining a
                              set beforehand. Someone might even have the
                              vision that some style sets
                              are being defined before the operations
                              occurs (to follow our convention
                              over configuration approach), either within
                              the document (as a given
                              style set) or preferable within the ODF
                              specification, by "style blends"
                              from the application vendors. For instance,
                              the "heading 1" style set
                              might be defined before hand, instead of
                              passing the styles for every
                              document being opened.

                              Various compressions are thinkable, all they
                              have to have in common is
                              to keep the information set equivalent.
                                    And, it means we have to define when
                                    compression/condensation occurs
                                    and how it is recorded in syntax.
                              Uncertain yet, if we have to be necessarily
                              such strict. We definitely
                              have to define what operations are
                              equivalent. We could even come up
                              with a normalized form of operations (the
                              most efficient form of
                              operations to be exchanged).
                                    Not objecting to your answer but it
                                    leaves out a lot of detail. ;-)

                              Sure, just wanted to keep the mail short ;)
                                    Hope you are having a great day!

                                    Patrick

                              Hope you are having a great day as well!
                              Svante

                              ---------------------------------------------------------------------

                              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


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