We should not be distracted by the change-tracking case. The paper provides a general case with regard to the identified anti-pattern.
Although it was the problem of having reliable change-tracking work that inspired the Anti-Pattern paper, the finding of the paper is that reliable interchange is a *prerequisite* to any effort to have dependable change-tracking in a collaborative activity involving WYSIWYG software document files. The prerequisite problem is inherent in securing interoperability using editable forms such as ODF, OOXML, and (probably) EPUB. It matters for all interoperability cases involving heterogeneous products and platforms and a standard document-file format. It is obviously a prerequisite in the interoperable use of a Corinthia-style editor of ODF/OOXML documents that must interchange with Desktop applications for the same formats. That's the reason I am recommending the paper to the attention of this project and others. Although this is about an RCT envelope, one could have an equivalent envelope that does not extend to change-tracking features. For example, there is a connection with the "Assurance Helix" I introduce at <https://cwiki.apache.org/confluence/display/Corinthia/ODF>. - Dennis SUGGESTIONS For those who want to delve into this, I recommend reading the paper this way: a. Read from the beginning through the end of Section 2 to understand what the anti-pattern case is. It is a general condition. It is about the difference between how documents are manifest to users versus what is conveyed in file formats. b. Skip section 3 on Change Tracking in ODF. c. Read Section 4 through section 4.5. These do not involve change-tracking at all. d. A counterpart of the RCT Extension technique (section 4.8) would be useful for any other kind of profile in which the document files are legitimate extended ODF documents that are handled correctly when the extensions are ignored in accordance with the ODF rules for them. It would not be worded around change-tracking in the way section 4.8 is. e. Continue through Section 5, discounting the emphasis on tracked changes. Don't be too distracted by the notation introduced in 4.3. It is mainly about the point that it is the equivalence of manifestations that matter, and that there need to be some means for agreement on an envelope of document-file features and *their* *processors* that provides for interoperable use in an application domain of concern. This matters with respect to Corinthia-based processors when interoperated with desktop fixtures such as Microsoft Office, LibreOffice, Apache OpenOffice, etc. -----Original Message----- From: Peter Kelly [mailto:pmke...@apache.org] Sent: Saturday, June 13, 2015 22:47 To: dev@corinthia.incubator.apache.org Subject: Re: "Navigating the Document-Format Anti-Pattern" This is one of the main reasons why I believe that change tracking information has no place in a document format, but is better dealt with by a version control system. — Dr Peter M. Kelly pmke...@apache.org PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key> (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966) > On 14 Jun 2015, at 3:38 am, Dennis E. Hamilton <dennis.hamil...@acm.org> > wrote: > > The PDF of the paper about RCT (Repaired Change-Tracking), "Tracked Changes: > Navigating the Document-Format Anti-Pattern," provides a pattern-like model > for the interoperability assurance for WYSIWYG document using standard > document-file formats. The author's final submission version is available > for download in the bibliographic entry at > <http://nfoworks.org/notes/2015/06/n150601.htm>. > > A key finding in this paper is that in the absence of a profiled envelope in > which there is interoperability assurance when interchanging documents using > a format such as ODF, there is no prospect for such interchange working > properly with change-tracking in the files. > > Conditions on which such an envelope can be established and change-tracking > accomplished in a dependable way are sketched. > > This is important to Corinthia with regard to profiling the interoperability > among processors of standard formats and also determining how to profile the > handling of those formats in an interoperable way, whether or not > change-tracking (the original stimulus for the work) is every accomplished > with Corinthia. > [ ... ]
