Suggestion: Focus initially on a small number of use cases

[robert_weir@us.ibm.com]

I'm hearing general agreement that we will want to specify the 
application-level semantics semantics for change tracking.  Obviously this 
is sizable task in itself.  But I don't think we should let that get in 
the way of making progress on the editing question.

The way I see it, there are three things we need to consider from the 
specification standpoint:

0) Scope -- what are the end-user or real-world "facts" that may be 
tracked?  We might initially think this is "all state stored in the 
document", but that begs the question of what the relevant state is. 
Certainly not the lexical state of the XML's text.  Differences in 
ignorable whitespace, attribute ordering, etc., are not significant.  And 
we probably don't mean the entire abstract document model either, since 
changes in some areas are not significant, e.g, the value of ID/IDREF, so 
long as they express the same graph.  We need to define, or at least 
enumerate, what kinds of things may be change tracked.  This could be 
open-ended, e.g., all changes except A, B and C.  Or it could be a closed 
set of items. I think the former is more flexible, while they latter is 
easier to implement a user-interface for.

1) What are the required properties of a document with respect to change 
tracking, e.g., the syntax and other static properties of a document?

2) What are the required properties of an application, either a producer 
or a consumer of documents, when working with tracked changes?

I'm hoping we can make progress on questions 1) and 2) without getting too 
caught up in trying to boil the ocean with question 0).  We could, for 
example, make progress on these questions by simply agreeing on one or two 
specific specific use cases and drill down into them, until we're all 
satisfied that we understand the implementation ramifications of them.  I 
think we'll benefit from diving deep on 1 or 2 specific examples. 

Perhaps pick one simple or average example, a mainstream workhorse use 
case, like inserting text into a paragraph, where the inserted text has 
been copied from another document with a different style.  So you're 
pasting in text with a new style definition.  For sake of argument, let's 
suppose this was an automatic style.

And then, maybe we can pick the most hardest edge case that we agree must 
be supported.  Maybe even be forward looking and pick the hardest one that 
we think must be supported within the next 5 years.   The one that, if 
adequately solved in a way that is reasonably implementable, would 
demonstrate that a given proposal can handle almost anything we can throw 
at it.  I'd be interested in know what you think might be a suitable acid 
test for change tracking.

We could then discuss how the two proposals handle these two use cases, 
and look at them from all angles:

a) existing implementations
b) new implementations
c) implementations that are "close to the XML"
d) implementations where runtime models differ from the XML
e) processing by applications that do not support change tracking
f) backwards compatibility, i.e., how an ODF 1.2 consumer would handle 
such a document
g) interactions with allowable ODF extensions
h) other perspectives?

In other words, I think we'll make better progress if we focus on a small 
number of uses cases, including an acid test one.  Then, if we agree on a 
proposal we can confirm that it works for the other use cases and circle 
around to drill down into the "scope" question.

Regards,

-Rob