W3C home > Mailing lists > Public > public-change@w3.org > September 2014

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

From: Dennis E. Hamilton <dennis.hamilton@acm.org>
Date: Thu, 4 Sep 2014 11:12:07 -0700
To: <public-change@w3.org>
Message-ID: <00ab01cfc86b$be6a09f0$3b3e1dd0$@acm.org>
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
     <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] 
Sent: Thursday, September 4, 2014 08:45
To: 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 
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?
[ … ]
 
Received on Thursday, 4 September 2014 18:37:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:11:23 UTC