OASIS Open

This is a copy of SC34/N1630, ballot results and comments on the ISO/IEC 26300:2006 DCOR2 ballot. This is the ISO/IEC equivalent of our ODF 1.0 Approved Errata 02. Note that we received comments from Germany and Japan. The TC should review and decide how they want to handle this. Fix in Errata 03? Synch up with Approved Errata for ODF 1.1 (which itself would synch up with AMD 1 for ISO/IEC 26300)? Are any of these errors also in ODF 1.2? Please, record any needed changes in JIRA, according to the correct target.

I was curious to determine whether the treatment of insertion and deletion in ODF change-tracking had more symmetry than is evident from the treatment of the two cases in the specification. This exploration reveals that, while there are similar conditions that arise, the two are quite different. I also discovered that insertion is even more subject to peculiar cases than is the case for deletion. This is most evident in cut and paste examples where the result of the insertion is quite inexplicable.

This document was prepared based on the RNG Schema of ODF 1.2 CSD05. It is a preliminary effort to arrive at the heirarchical dependencies of elements related to change-tracking and all the places where change-marks can occur in ODF 1.2. There is little explanation of this v0.25 (alpha or pre-alpha) and it also needs to be double-checked and updated with respect to ODF 1.2 CS01 and its RNG Schema. Basically, the columns identify the consituents of particular elements or patterns of elements in the RNG Schema. The rows identify what elements a pattern appears in as a constituent directly or at some level of descendency. 0 means directly (and applies to patterns within other elements), 0? means optionally directly, and 0* means none-or-more times. The number indicates the least depth within the hierarchy of the column pattern/element at which the row item occurs. The transitive extension beyond depths 0 and 1 can be carried out mechanically but I have not done that except for a few feeble cases (to understand how I would do it generally). Note that some rows are part of related groups and the group may also be a named pattern. I also differentiate between leaf elements (typically fields and elements like <text:s>) that are always empty XML elements or are pure text elements according to the RNG Schema. Also, some columns are the same for several elements or for the children of an element. In those cases I have consolidated as many of those together as I can.

Extracted from JIRA, this spreadsheet contains the resolutions from the member and public comments received during the public review of CSD06 that occured December 17th, 2010 - January 1st, 2011.

This document presents analysis of a change-tracked deletion example based on the current tracked-changes provisions of ODF 1.2. It also turns up an unexpected implementation edge case that I assume applies generally to releases based on the OO.o 3.3 code base. The demonstration of the failure, which can lead to corrupted deletions that restore incorrectly when rejected, is serious enough. I include that portion of the analysis, albeit implementation dependent, because it demonstrates the subtleties that must be understood (and should be documented in the ODF specification) in order to properly implement the deletion approach that has been appealed to since ODF 1.0.