Repaired Change-Tracking (RCT) is an approach to change-tracking for ODF 1.2 documents that corrects and extends the existing provisions of ODF 1.2 change-tracking for document text.
The specification of RCT is accomplished by an extension profile that includes foreign extensions to ODF 1.2 documents. These extensions are designed so that (1) they are safely ignored by strict ODF 1.2 document consumers and (2) they can be adopted by OASIS, with appropriate namespace reservations, in a manner that is safe for early adopters of the extension.
Promulgation of the extensions beyond the scope of the RCT specification. It is recognized that there needs to be two kinds of adoption for the RCT repairs to be effective:
- Incorporation of support for the extensions in a processor having native ODF support. The preferable case is Apache OpenOffice, since Apache License 2.0 updates and the related issue/feature tracking is adaptable to all products with the same code-base ancestry.
- Incorporation of support for the extensions in converters between ODF and Microsoft Office Word formats, the benchmarks for text document change-tracking.
The RCT activity does contribute test documents for the handling of repaired change-tracking.
-- Dennis E. Hamilton
RCT extensions are repairs to existing ODF 1.2 change-tracking provisions. Development starts from the the explicit provisions of ODF 1.2. It is presumed that conforming ODF 1.2 producers only produce tracked-change information that can be presented, accepted, and rejected by ODF 1.2 consumers that rely exclusively on the ODF 1.2 provisions.
It is known that prominent implementations employ tacit arrangements that are undocumented implementation-dependent deviations. It is not possible to address that. Instead, RCT provides explicit approaches to what has been tacit before, allowing RCT-aware consumers to interpret the information in a reliable, interoperable manner. This allows deviating producers to now convey RCT information on the correct interpretation of their tracked changes. The supporting analysis and principled basis for RCT may also lead to tracked-change forms that are dealt with more reliably even by RCT-unaware ODF 1.2 consumers. The approach is made understandable by construction of exemplary cases using a fictitious office-productivity software system, Blue Sky Office.
This approach is very different than the hypothetical SCT scheme, which is entirely incompatible with ODF 1.2 change-tracking. SCT for ODF is a mechanism that preserves digital signatures of documents with the modifications kept separate, the combination permitting a digital signature that is also preserved in the making of further changes. That level of document integrity changes the manner in which all kinds of changes are captured and presented, including use of form fields, spreadsheet cell entries, etc. Even were SCT the objective, the analysis and approach undertaken by RCT is an important contribution. SCT handles more changes, and in a different way, but the changes that RCT accommodates must also be supported in SCT.
It is fundamental to RCT that all extension is by introduction of attributes that can be safely ignored as foreign attributes by RCT-unaware ODF consumers. And, just as for all ODF 1.2 provisions, consumers that are RCT-aware can have implementation-defined limitations on interpretation of cases.
RCT provides information for representing individual changes as compositions of simpler changes. Even when an ODF 1.2 consumer does not treat the combinations as atomic, the component changes tend to be more accurate for interoperable interchange.
RCT is also intended to be more resilient in the face of change overlapping and change collisions, where the order of acceptance/rejection of changes is important for accuracy of change provenance.
It is characteristic of ODF 1.2 change-tracking and similar approaches that changes that are accepted and rejected are no longer tracked. This loses provenance information about the change history of a document. It is legitimate for tracked-change entries to become orphaned and ignored in various ways. RCT includes an extension for signaling retention of orphaned tracked-change information in order to preserve document history.
Suites of test cases are important for the achievement of RCT, confirming the benign handling of RCT-based tracked changes by down-level implementations. The test cases are also important in their support for making heretofore tacit practices explicit and mitigating interchange failures that happen even among the same implementations.
The latest details of RCT development are tracked on the Roadmap page. The organization of materials into hypertext of the RCT specification is envisioned and developed in the RCT Organization folder.
- n140501b: RCT: ODF 1.2 Change-Tracking Repair Roadmap [latest]
- n140501c: Roadmap Initial Sketch
- n140501-cache: Resources captured for RCT development
- n140501a: Diary & Job Jar
- DChanges 2014 Program, available at <https://sites.google.com/site/dchanges14/program>.
- RCT: Repaired Change-Tracking ODF 1.2 Extension Profile (hypertext)
- BSO: Blue Sky Office FTW Edition
- d140605: RCT Profile Organization
- d140501: Provisional Namespace ns/odf/1.2/rct#
- d140604: RCT Interoperability Assessment
- d140603: RCT Application Assessment
- d140602: RCT Extension Down-Level Resiliency
- n140502: ODF 1.2 Change-Tracking Complexity
- n140503: ODF 1.2 Text-Document Schema Analysis
- n140602: Conformant ODF 1.2 Documents
- n130301: SCT: Savage Change-Tracking
- Hamilton, Dennis E.
- RCT: ODF 1.2 Change-Tracking Repair. nfoWorks nfoNote folio n140501 0.07, November 6, 2014. Accessed at <http://nfoWorks.org/notes/2014/05/n140501.htm>.
created 2014-05-05-15:47 -0700 (pdt) by