[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Suggestion: Focus initially on a small number of use cases
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]