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>
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
>
>     dennis.hamilton@acm.org    +1-206-779-9430
>     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
>
> *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
Fax : +33 1 4356 1746
http://www.innovimax.fr
RCS Paris 488.018.631
SARL au capital de 10.000 €