[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office-collab] Generic CT proposal - an implementer's look atit
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]