> To maintain strict backward compatibility (of the format, not the applications) would mean that the change tracking as represented in ODF 1.2 is valid change tracking in ODF-Next. Having reviewed all the
comments that I can find on this issue (see below) I do not think anyone is arguing for this position
Nobody has argued for it but we haven’t really discussed it until now. This is the key question. Are we making an explicit decision to make a breaking file
format change such that ODF 1.3/2.0/whatever documents are not readable by users of existing implementations without some sort of backport update (or forcing those users to upgrade)?
I think the answer can legitimately fall either way. My main reason for bringing up backward compatibility was that it impacts users and we ought to be clear
with ourselves what impact the next ODF will have on them. This affects users primarily in their ability to share files with one another across older and newer versions of applications. We might agree to say this is an implementation issue and implementers
must decide how their app will address the transition from 1.2 to 1.3/2.0 for their own user base – e.g., do nothing and let users figure it out, handle reading/saving both formats so users can choose, releasing backports for older versions, etc. We might
also decide that the next ODF is more 1.3-ish than 2.0-ish and breaking changes should only occur in major version changes. I’m not aware of any guiding principles from the main TC on what the next ODF is all about, so we may not yet know whether it’s more
minor or major version oriented.
> there seems to be evidence (and probably consensus) that some of the patterns are not worth building on (see last comment in 5 and also 6 and 7 below)
> and "There is almost no interoperability among the various non-Microsoft implementations of ODF when it comes to tracked changes."
I wouldn’t conclude that particular flaws in the specification of the current change tracking invalidate the patterns it defines. I believe most of the complaints
below are in regard to the insufficient definition of how to handle certain types of deletions. The ECT proposal recommended improving this, as did a couple people during a conference call discussion, as I recall. Of course, we haven’t yet looked at how
to make it more explicit since we don’t yet have a decision on whether it’s to be fixed or thrown out.
> 6. Andreas G email 2011-05-06
Andreas makes some good comments about spreadsheet CT. I’d studied that part of the standard (§9.9
in ODF 1.2) and couldn’t figure out a few parts of it that were underspecified as I couldn’t get various applications to produce the markup. Similar to the above notion about better specifying text deletion, that same principle could be applied to parts of
spreadsheet CT to make it more clear, implementable and interoperable. I think Andreas’ expertise (as well as other longtime ODF people who may understand that section better than I) could effect changes here that I suspect will be both relatively small and
yield significant improvement.
John
From: Robin LaFontaine [mailto:robin.lafontaine@deltaxml.com]
Sent: Wednesday, May 11, 2011 6:24 AM
To: office-collab@lists.oasis-open.org
Subject: [office-collab] 1. Backward compatibility: what are requirements?
Should ODF-Next CT be Backward Compatible with ODF 1.2?
The issue of backward compatibility has been raised in a number of emails. It is an important issue because if we are trying to maintain backward compatibility with existing change tracking within ODF 1.2, then this would seem to be an important constraint
on the ECT and to rule out the GCT solution.
Backward compatibility was not one of our initial requirements, though there was agreement that we need to be able to convert from the existing change tracking mechanism to any new one.
To maintain strict backward compatibility (of the format, not the applications) would mean that the change tracking as represented in ODF 1.2 is valid change tracking in ODF-Next. Having reviewed all the comments that I can find on this issue (see below) I
do not think anyone is arguing for this position, although a principle of the ECT is that this would be possible. The consensus seems to be that CT does not work the way it is currently specified.
If that is the case, then what are the aspects of CT in ODF 1.2 that are important and good and that we are trying to keep? This was a specific question raised in our initial call. See
http://wiki.oasis-open.org/office/Change%20Tracking%20Requirements
for the list from this initial conference call.
The ECT objective is to build on existing patterns and code, but there seems to be evidence (and probably consensus) that some of the patterns are not worth building on (see last comment in 5 and also 6 and 7 below).
There is also the point that we might be throwing out any existing CT interoperability, but as Microsoft did not implement CT at all in their ODF and "There is almost no interoperability among the various non-Microsoft implementations of ODF when it comes to
tracked changes." (comment 8 below) this also seems to be of limited value.
From the comments, it is difficult to discern what is of real value in the existing CT, apart from some general features that have been identified. If there is more specific real value here, then we need to identify it.
COMMENTS MADE IN PREVIOUS DISCUSSIONS/EMAILS
These are not in a particular order, and I have tried not to quote anything out of context (my apologies if I have done so), but rather to save others going back through the stack of emails etc.
1. In our initial conference call this point was made:
1.5 Can convert from existing change tracking mechanism to new one
- all changes recorded in current format can be converted, i.e. a defined way to move to the new format
2. extended-ct-proposal
http://www.oasis-open.org/apps/org/workgroup/office-collab/download.php/41699/extended-ct-proposal.odt
"The basic idea behind this proposal is to preserve the existing ODF change tracking and extend it to support missing use cases. We believe this best preserves backward compatibility with existing implementations and makes best use of existing patterns and
code. It also maintains the current model of ignoring changes for applications that do not support change tracking."
3. John H email 2011-04-21
http://www.oasis-open.org/apps/org/workgroup/office-collab/email/archives/201104/msg00070.html
"I mentioned on this week’s call we have not discussed high-level guiding tenets such as how we want to handle backward compatibility, ..."
"I think there is another large CT-specific question we haven’t addressed – a decision on whether we want to discard and replace the existing ODF 1.0 - 1.2 CT model. This has significant impact on existing implementations and the state of interoperability
they have built up to at this point*. As Rob noted in the call, the TC’s rough, overall tenets have been that backward compatibility is important, it’s open to large breaking changes though more for new major versions of ODF rather than minor versions and
to not tie ODF too much to any one implementation in the future."
* but see 8 below
4. Doug M email 2011-01-21
http://www.oasis-open.org/apps/org/workgroup/office-collab/email/archives/201101/msg00009.html
"One thing that struck me was the combination of “1.5 Can convert from existing change tracking mechanism to new one” and “2.2 Interoperability with other formats.” These two requirements may be at odds with one another: is it actually possible to define change
tracking in a way that maps to the existing approach as well as the approach used in OXML, for example? I think that we should take into consideration the magnitude of existing usage of ODF and OXML change tracking, and prioritize accordingly, in the interest
of maximizing the opportunities for use of the new approach we’re designing. I’m sure there are other perspectives on this, but it’s probably a conversation worth having."
Tristan M comments:
"As far as requirement 1.5 goes, I think this would only be a one-way conversion i.e. converting from the existing change-tracking mechanism to the new one. The resultant document would of course have the same limitations as the existing change-tracking format
in that it would only represent those changes that can currently be tracked. Converting back the other way is not necessary and indeed need not be possible. The conversion would either be performed via an application's internal model in a load-save cycle and/or
could be written as an XSLT script to generate the new format. If we limit conversion to this direction only, I see no reason why interoperability with other formats would need to be compromised."
5. Ganesh P email 2011-04-01
http://www.oasis-open.org/apps/org/workgroup/office-collab/email/archives/201104/msg00000.html
"1. The supplement seems to introduce a new way to handle delete
changes ( it is called as the Insert/Delete style and is conceptually
different from the ODF 1.2 delete change handling mechanism ). So, the
new mechanism should be applied to the <p> to <p> and <p> to <h>
merges too ( The two use-cases that are explicitly handled in the
current ODF 1.2 specification ) . Right ?
John H comments: "The reference to Insert/Delete style is the same pattern from the first document. I gave it a name here to differentiate it from the “paragraph style” approach I wanted to at least bring up in case it was worth discussion."
"2. Doesn't the introduction of the new mechanism break backward
compatibility to the old ODF 1.2 change tracking format."
John H comments: "The general question of backward compatibility needs to be looked at in detail across the board for both proposals, particularly with input from implementers who have existing change tracking support. I think both proposals may have back-compat
issues. Depending on various choices the SC would need to make about the specific changes it would introduce, I think the extended one could be designed to be additive only – introduce only new mechanisms."
Relevant to this point is also this earlier blog from Doug M:
http://blogs.msdn.com/b/dmahugh/archive/2009/05/13/tracked-changes.aspx
"I put paragraphs in quotes there for a reason: in the simple example we’re looking at here, I did not delete a paragraph, I deleted a word from inside a paragraph. So why is the deleted text wrapped inside a paragraph element?
"The answer is that the ODF spec requires deleted content (as contained in a text:deletion element) to be schema-compliant, regardless of whether the deleted region was a well-formed element or (as in this case) merely a fragment within some other structure,
such as a word within a paragraph.
"This is the source of the problem I alluded to above, for implementers who choose to support ODF tracked changes. Each implementer must decide how to synthesize markup to make each piece of deleted content into well-formed XML, and then later – when it comes
time to accept or reject the change – each implementer must make decisions about how to distinguish between the synthesized packaging and the deleted content itself.
"Unfortunately, the ODF specification doesn’t provide much guidance on this complex topic."
6. Andreas G email 2011-05-06
http://www.oasis-open.org/apps/org/workgroup/office-collab/email/archives/201105/msg00001.html
"ODF1.2 simply reiterates the ODF1.0/1.1 description of change tracking
for spreadsheets. Neither of them I find understandable, for example
the distinction between deletions and cutoffs raises the question (at
least in my mind) whether the table:position value refers to the current
col/row numbering or the col/row numbering at the time of the change.
The Standard appears mute on this. Moreover in the current discussion
there is concern about "buckets". The current spreadsheet change
tracking model appears to considers each table cell as a bucket which
seems quite coarse to me.
"Based on the current state of the description and specification this
does not appear implementable to me."
7. Dennis H in document ODF 1.0-1.2 CURRENT DELETION-TRACKING FORENSICS
http://www.oasis-open.org/committees/document.php?document_id=41714
"Deletion tracking is underspecified in the current ODF 1.0-1.2 specifications. However, it is quite successfully implemented, suggesting that the problem is in the specification failing to capture the necessary information from which to make independent interoperable
implementations.
"This note demonstrates the “ground truth” for current deletion tracking. It is offered to indicate that there is much that needs to be comprehended in the current ODF 1.x practice so that it can be preserved in any improvement of the specification and the
cases that are covered."
8. Doug H blog
http://blogs.msdn.com/b/dmahugh/archive/2009/05/13/tracked-changes.aspx
"There is almost no interoperability among the various non-Microsoft implementations of ODF when it comes to tracked changes."
--
-- -----------------------------------------------------------------
Robin La Fontaine, Director, DeltaXML Ltd "Change control for XML"
T: +44 1684 592 144 E: robin.lafontaine@deltaxml.com
http://www.deltaxml.com
Registered in England 02528681 Reg. Office: Monsell House, WR8 0QN, UK
--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php