- From: Dennis E. Hamilton <dennis.hamilton@acm.org>
- Date: Sun, 21 Sep 2014 08:43:51 -0700
- To: <public-change@w3.org>
- Message-ID: <002b01cfd5b2$d83264f0$88972ed0$@acm.org>
No, I am not going where you are pointing me. (I prefer to be asked questions rather than told where I am going.)
My question was about one sentence you wrote. I still don’t understand it. What does
“I can see for example that we could provide the "external" list of modification the same ZIP content for OOXML, ODF, EPUB, etc.”
mean?
- Dennis
ABOUT WHAT I SEE
I am talking about what works among interoperable implementation, and in that case, it is more appropriate to extend existing change-tracking provisions in existing standards rather than add an independent one the deployment of which will raise conflicts and confusion for *users* of personal-/office-productivity software.
I certainly do not object to extension of standards, or addition of supplementary arrangements. XML Schema and Relax NG are alternatives to the DTD and are completely successful. However, DTD was not obsoleted, although it is often not used and also often forbidden in certain applications of XML. After all, there is a DTD for XML Schema [;<). But the schema-language situation has led to XML-based standards having to provide both schema forms (as done for OOXML), mainly because the Japanese National Body is insistent about RNG.
I am definitely not talking about this level of specification variation. I am talking about the complexities of the situation with these complex higher-level formats and the difficulty of having implementers invest in multiple change-tracking schemes.
The multiple XML schema approaches used in the standards do not intrude on the users, only the implementers, who use the schema language that works for them (although ODF only has the RNG XML flavor except when including some standards by reference).
My considered opinion is that having to support two or more change-tracking mechanisms is a very high-friction, high-maintenance situation and I am not so sanguine about it.
In particular, whatever Microsoft decides to support, if anything, will be decisive in respect to ODF change-tracking interoperability. It is inconceivable to me that Microsoft would support two schemes for OOXML documents, and any third-party support will always be marginal and suitable for niche applications only. With the race to presence on all devices (where Linux means Android) and the cloud, I can’t imagine any participant in that challenge being distracted by such a development.
On the other hand, I can imagine ODF dying the death of many small cuts because the major implementations fail to collaborate on stable interoperability and the standard does not get much better in that respect. I am working at not being discouraged by that prospect. Some days I do better than others, particularly when I avoid talking or thinking about it.
- Dennis
From: innovimax@gmail.com [mailto:innovimax@gmail.com] On Behalf Of Innovimax W3C
Sent: Sunday, September 21, 2014 03:18
To: Dennis Hamilton
Cc: public-change@w3.org
Subject: Re: External vs Internal situation of Changes (was RE: Change tracking processing instructions and deletion)
Dennis,
I see where you're going. You imply that providing extension is bad for standards because the standards has built-in support for change tracking
I don't buy this argument since this is the one that XML people gave to the XML Schema and Relax NG community telling them that DTD is already built-in so you can't add another schema language
Hope this example is clear to enough to you
Regards,
Mohamed
On Sat, Sep 20, 2014 at 8:25 PM, Dennis E. Hamilton <dennis.hamilton@acm.org <mailto:dennis.hamilton@acm.org> > wrote:
I am not clear how you mean “the same ZIP content” in
“I can see for example that we could provide the "external" list of modification the same ZIP content for OOXML, ODF, EPUB, etc.”
One might be able to insert external changes into an OOXML, ODF, or EPUB container, but those formats and their processors have constraints on the nature of material in those containers and how it is to be retained if the document is edited (assuming EPUB provides for editing). Also, even though the underlying packaging is based on *separate* profiles of how Zip is to be used and multiple parts of the document-file are to be organized.
This came up at DChanges 2014 where folks were having trouble annexing version-control information into OOXML and ODF containers. I pointed those investigators to the standards for guidance. Even with the standards, different processors find edge cases to object to. In almost all of them, any change to the recognized part of the document leads to a document file in which the annexed material has been removed. There is a collision with document security issues otherwise, and that is particularly pertinent if the document file is digitally signed.
- Dennis
From: innovimax@gmail.com <mailto:innovimax@gmail.com> [mailto:innovimax@gmail.com <mailto:innovimax@gmail.com> ] On Behalf Of Innovimax W3C
Sent: Saturday, September 20, 2014 06:22
To: Dennis Hamilton
Cc: public-change@w3.org <mailto:public-change@w3.org>
Subject: 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 <mailto: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> [mailto: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 <mailto: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 €
--
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 €
--
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 €
Received on Sunday, 21 September 2014 15:44:22 UTC