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

Then you are providing a use case here

I can see for example that we could provide the "external" list of
modification the same ZIP content for OOXML, ODF, EPUB, etc.

Could this be a use case you want us to consider ?

Mohamed

On Sat, Sep 20, 2014 at 2:57 PM, Dennis E. Hamilton <dennis.hamilton@acm.org
> wrote:

> 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> 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 €
>



-- 
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 €