RE: Before-Looks or After-Looks

Case 1.b is exactly how ODF works and how it is implemented in LibreOffice and Apache OpenOffice, to name two.  It means that when the change-tracking data is completely ignored, what is presented is the document that would be seen when tracked changes are not shown.  
 
This is by design.  That is, the default presentation is as if all of the changes had been accepted. That is the after-look case. 
 
So, for 1.b, when a change is accepted, it just means the change-tracking entry is removed.  When a change is rejected, the separate-but-linked change-tracking entry is used to revert the default text to its earlier form.
 
The 1.a scenario is as you describe.  Only on acceptance of changes is the before-look updated (virtually if not literally).  Rejection of the changes does not have to touch the before-look, because the rejected changes are simply ignored.
Version control systems have employed all of these techniques.  For convenience, Visual Source Safe always keeps an after-look and then, to economize on storage, has deltas that change it to successive earlier versions when one is needed.  Other source-code controls have done the reverse, where there is a before-look (the initial version) and deltas for the successive successors.  Git, of course, solves this issue by keeping full looks of every version, presenting diffs when folks want to see them.
 
-   Dennis
 
 
 
From: innovimax@gmail.com [mailto:innovimax@gmail.com] On Behalf Of Innovimax W3C
Sent: Tuesday, September 30, 2014 09:20
To: Dennis Hamilton
Cc: public-change@w3.org
Subject: Re: Before-Looks or After-Looks
 
Dennis,
Let me try to rephrase
I have a document D1 at t0
Modifications are made on D1 at a later time t1 ( t1 > t0 )
My understanding is if I REJECT ALL the modifications done on D1, I get back to D1
Is this "1.a" scenario ?
If such, I don't get how 1.b could make sense unless we are in a ACCEPT ALL scenario 
Mohamed
 
On Tue, Sep 23, 2014 at 11:56 PM, Dennis E. Hamilton <dennis.hamilton@acm.org <mailto:dennis.hamilton@acm.org> > wrote:
I think there is a fundamental difference to be considered.  It has to do with answering the following question:

1. When the change-tracking information is all ignored, what remains,
        a. The original unchanged XML document (the before-look), or
        b. The fully-changed XML document (the after-look)?

There may be a requirement here.

At one point, I thought that it didn’t matter, in the sense that one form could be transformed to the other (before removing the change-tracking).  Now, I am not so sure.

The ODF representation for tracked changes has (1.b) as its default result when change-tracking information is ignored.  In an interoperability setting, that seems to be the safest approach.

There is one case where the before-look is needed and that is when the document file is digitally signed and can’t be modified without that counting as tampering.  So however change is represented, it can’t touch the original.  One could still provide an after-look style of tracked changes using a copy.  That’s messier.  Or one could use some sort of supplemental information that accounts for changes to the original without touching the original, a case that I touched on in my DChanges paper on Protected Change-Tracking.  This can be made a specialized problem, with general change-tracking still handled with case (1.b).

How does the choice between before-looks and after-looks come down in the usage scenarios others are considering?


 -- Dennis E. Hamilton
    dennis.hamilton@acm.org <mailto:dennis.hamilton@acm.org>     +1-206-779-9430 <tel:%2B1-206-779-9430> 
    https://keybase.io/orcmid  PGP F96E 89FF D456 628A
    X.509 certs used and requested for signed e-mail






-- 
Innovimax SARL
Consulting, Training & XML Development
9, impasse des Orteaux
75020 Paris
Tel : +33 9 52 475787
Fax : +33 1 4356 1746
http://www.innovimax.fr
RCS Paris 488.018.631
SARL au capital de 10.000 €