RE: External vs Internal situation of Changes (was RE: Change tracking processing instructions and deletion)

In response to Mohamed’s request for use cases and requirements, I have this.
 
It is not clear to me that there are use cases or requirements that differentiate between external and internal situation of change information.  I think it is other conditions and possibly non-functional requirements that will drive choices.
 
In some cases, there is no choice but to have “external” change information, as when the document subject to change is immutable for important reasons.  Presumably, one can make a copy that can be modified.  But sometimes it is necessary to be able to demonstrate that the change-tracked derivative is in fact a derivative of the original and there are no other changes but those tracked.  And passing around full copies like that might be problematic.
 
I realize, from the question here, that one thing that might not be clear is *how* far is the external are we talking about.  If the material is so external that it is separable from the document files to which it applies, there are different kinds of risks with regard to ensuring the integrity of the combination.  
 
Internal cases have some of the same risks in the face of damage, but it might be easier to detect when some sort of disconnect has occurred and consequences of damage might be more localized.  I *hypothesize* that recovery from breakage in the internal case may be more successful and more localized (though not necessarily without loss), but I know of no objective testing of that hypothesis.
 
-   Dennis
 
From: innovimax@gmail.com [mailto:innovimax@gmail.com] On Behalf Of Innovimax W3C
Sent: Saturday, September 20, 2014 02:01
To: Dennis Hamilton
Cc: public-change@w3.org
Subject: Re: External vs Internal situation of Changes (was RE: Change tracking processing instructions and deletion)
 
Thanks Dennis,
Can you start providing Use cases and requirements in order to move this discussion forward ?

Thanks
Mohamed
 
On Thu, Sep 4, 2014 at 8:12 PM, Dennis E. Hamilton <dennis.hamilton@acm.org <mailto:dennis.hamilton@acm.org> > wrote:
My more limited experience is consistent with Robin’s observation, below.  Having change-tracking external to the document makes it very difficult because changes alter the position of and path to material in the XML-recorded document structure.  With embedded markers, the markers that have no collision with subsequent changes simply float around as the material containing them changes position, even if swept up in a subsequent change.  This is particularly important where the markers are embedded in text streams, but it applies when they arise between elements also.
 
Robin points out a design point of change-tracking in office documents that is extremely important.  In OOXML (i.e., Microsoft Office) and ODF (i.e., OpenOffice.org descendants) documents, changes can be accepted and rejected in any order so long as there are no collisions among them, and more changes can continue to be made atop other changes, overlapping other changes, etc.  This becomes extremely difficult to “point into” and raises issues about what an user is seeing when they make an overlapping/colliding change and what they are shown the result to be (and that it be reversible).
 
Note that we are talking about markers, not necessarily details about the changes.  For example, with ODF, if the markers are ignored in the XML elements that give rise to the text flow of the rendered document, the document that is presented is one with all changes accepted as if no change-tracking were employed.
 
There is an interesting use case where embedded markers don’t work, and that is when changes need to be kept separate to preserve the digital signature of a base document and of the subsequent intermediates that are passed around.  One could consider pre-positioning markers everywhere, but that is clearly infeasible (especially into text runs) as a general case.  However, there are restricted cases where pre-positioned markers – labels on specific elements -- are sufficient. (I think *these* would also work with XPath, but pre-situated labels are much easier and the restrictions to acceptable changes are simpler to verify by cross-referencing to labels.)  I found this intriguing enough to address it separately, as Protected Change-Tracking, in a submission to DChanges 2014: <https://sites.google.com/site/dchanges14/program>.
 
 
-- Dennis E. Hamilton
     <mailto:dennis.hamilton@acm.org> dennis.hamilton@acm.org    +1-206-779-9430 <tel:%2B1-206-779-9430> 
     <https://keybase.io/orcmid> https://keybase.io/orcmid  PGP F96E 89FF D456 628A
    X.509 certs used and requested for signed e-mail
 
 
From: Robin LaFontaine [mailto:robin.lafontaine@deltaxml.com <mailto:robin.lafontaine@deltaxml.com> ] 
Sent: Thursday, September 4, 2014 08:45
To: public-change@w3.org <mailto:public-change@w3.org> 
Subject: Re: Change tracking processing instructions and deletion
 
Hi Claudius,

I think one issue with XQuery Update for change tracking is that although it looks good for one transaction, it does not work well for multiple transactions because the XPaths will change as the document is changed. In theory you could undo the changes in order (though only if every change had been tracked), but it would be almost impossible to undo in any other order with predictable results.

Consider also a document with a series of XQuery Update changes, it would be quite hard to work out how to display these changes, but much easier if the changes are embedded in PIs within the document (or indeed in markup).

There is a design decision about where to keep the changes:
1. Within the document
2. Separate, e.g. in a series of transactions in XQuery Update

Most current systems I believe use choice 1, either as markup (e.g. Word, ODF, Arbortext) or PIs (e.g. oXygen, XMetaL, Xopus). I think there are good reasons for this choice.

Robin

-- 
Robin La Fontaine
Director
DeltaXML Ltd "Experts in information change"
 
T: +44 1684 592 144 <tel:%2B44%201684%20592%20144>  
E: robin.lafontaine@deltaxml.com <mailto:robin.lafontaine@deltaxml.com>  
W: http://www.deltaxml.com
Malvern Hills Science Park, Malvern, Worcs, WR14 3SZ, UK
Registered in England 02528681 Reg. Office: Monsell House, WR8 0QN, UK
 
On 28/08/2014 17:49, Claudius Teodorescu wrote:
Hi,
It is very nice to see PIs used to track changes. Last year, when I mention PIs as a method for track changes, on this list, I had no clue they were used.
As to syntax for effectively track changes, why not use XQuery Update?
[ … ]
 



-- 
Innovimax SARL
Consulting, Training & XML Development
9, impasse des Orteaux
75020 Paris
Tel : +33 9 52 475787 <tel:%2B33%209%2052%20475787> 
Fax : +33 1 4356 1746 <tel:%2B33%201%204356%201746> 
http://www.innovimax.fr
RCS Paris 488.018.631
SARL au capital de 10.000 €