From: Tomas Frydrych (tomas@frydrych.uklinux.net)
Date: Sat May 18 2002 - 16:26:55 EDT
Hi David,
> <r -5,+6><r -4,+6><r -2,+6>Abi</><r -1>w</><r +1>W</>ord</><r
> +4,-6>OpenOffice</> rocks<r +9> like a penguin</><r -8> on <r
> -3,+6,-7>toast</><r+3,-6,+7>toads</></>.</>
>
> Is that the idea? That looks like it contains all the information we
> could need.
Basically yes, except the revision attributes would not be nested,
i.e., if you have
<r -2>Abi</><r -1>w</><r +1>W</>ord.
and editor 3 wants to remove all changes it would look like
<r -2,+3>Abi</><r -1,+3>w</><r +1,-3>W</>ord.
This is simply because the r attribute would really be part of the c
token, i.e., <c revision="-2;+3">, and the c tokens cannot be
nested -- that's XML limitation; it makes no functional difference
(you can capture just the same states) but it makes the parsing
simpler.
> I assume this includes some fancy conflict handling. Go back to my
> example, and suppose you are faced with
>
> OpenOffice rocks on toads. (revision 4)
>
> Now, if you only accept 4's revisions, should the result be:
>
> OpenOffice rocks on toads.
>
> or
>
> OpenOffice rocks on toast.
without the nesting the text after the 4th editor's changes would
look
<r -2,-4>Abi</><r -1,-4>w</><r +1,-4>W</>
<r -4>ord</><r+4>OpenOffice</> rocks on
<r -3>toast</><r+3>toads</>.
by accepting the 4 revision _alone_ you would get
OpenOffice rocks on <r -3>toast</><r+3>toads</>.
That is, to take as an example the fragment <r +1,-4>W</>, it
would completely disappear, since by accepting #4's view on it,
you are implicitely rejecting #1's view on. You get neither 'toast' nor
'toad', since #4 did not comment on these, so you still get both
versions. I see only limited use for accepting revisions this
particular way, perhaps if you have a boss whose changes you do
not dare to modify :-).
However, by accepting the way the _whole_document_ looks as a
result of the cumulative revisions 1-4, you would get
OpenOffice rocks on toads.
since in absence of changes by editor 4 you would be accepting
the changes by the highest editor prior to him, in this case 3.
> Even worse, how do you accept only 5's revisions? 5 has over-written
> lots of changes made by earlier revisers. You aren't either accepting
> or rejecting those revisions, so they should still be available in the
> document.
Not really, in case where several different views on a single piece of
text are expressed by several editor by accepting on of them you
are automatically rejecting the rest.
> Also, we will need a good UI distinction between rejecting a revision,
> and stetting a revision. Stetting a revision is itself a (new)
> revision, while rejecting a revision removes that revision from the
> document.
The main difference would be that you can only accept/reject an
individual revision when "mark revisions while editing" is turned off,
and by doing so, you turn it into ordinary text. On the other hand
you can only stet a revision while "mark revisions while editing" is
turned on.
Tomas
This archive was generated by hypermail 2.1.4 : Sat May 18 2002 - 16:35:48 EDT