Robin LaFontaine wrote:
> Although the set of semantically distinct editing operations is unbounded as
> you say, the generic proposal unambiguously represents the state of a document
> before and after an edit operation. Therefore it supports all types of editing
> operation.
>
Hi Robin,
yeah, I'm not disputing that. :)
> If you take the approach that you are suggesting, whereby the change tracking
> format supports specific known editing operations such as insert an object or
> delete an object, then it will be necessary to get agreement amongst all the
> applications as to what these editing operations are. They will certainly not
> be the same in all editors, and indeed as each editor is enhanced it may well
> add editing operations. There is a danger therefore that this approach will
> always be trying to hit a moving target.
>
True, that would be a drawback - but potentially we could come up
with a set of _basic_ ops, that apps could then use to compose more
complex changes of - quite similar to the generic ct's atomic
changes, but with a (much) lower impedance towards app's editing
semantics?
> With either approach, it will always be the case that a particular application
> needs to read in a change that it is not able to recognise or is not supported.
>
Hm. With the generic proposal, apps would never be provably able to
handle all cases (unless processing is very close, or on, the xml
info set). Whereas for a bounded set of ops, one would at least be
able to state "we don't support X, Y, Z yet" - and eventually get
there.
Cheers,
-- Thorsten
