corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <>
Subject RE: "Navigating the Document-Format Anti-Pattern"
Date Sun, 14 Jun 2015 16:15:19 GMT
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 

 - Dennis


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 [] 
Sent: Saturday, June 13, 2015 22:47
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

PGP key: <>
(fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)

> On 14 Jun 2015, at 3:38 am, Dennis E. Hamilton <> 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 <>.
> 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.
[ ... ]

View raw message