Re: [office-collab] Generic CT proposal - an implementer's look atit

[Robin LaFontaine <robin.lafontaine@deltaxml.com>]

Thorsten,

I think that the point that you make is very interesting, and I think that it is true that implementation of the generic CT proposal would require a different approach within an application.

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.

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.

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. In this case, it will need to be able to ignore that change in an intelligent way. But this seems to be a fundamental problem, which is present in either approach. This problem may be fundamental, but it can certainly be solved.

Regards,
Robin


On 01/04/2011 02:37, Thorsten Behrens wrote:

Hi,

prompted by the recent activity around the two alternative change
tracking proposals, let me add the perspective of another
implementer (LibreOffice) to this discussion.

First off, I'd like to say that I find the generic proposal for
conditional modifications of xml elegant and concise - but I'm
afraid I cannot see a way to implement it, in a way that ensures
sufficient interoperability between different producers and
consumers.

Here's the crux: because the proposal relies solely on generic
modifications of the xml info set (both structurally, by changing
the tree, and by modifying attributes), and all those operations are
considered valid (section 3, items 6 and 7 of the
generic-ct-proposal), the set of semantically distinct editing
operations *is unbounded*.

Which is a fundamental problem, for all applications that need to
map the change tracking markup into their internal,
optimized-for-editing document models - because what you have here,
is a limited set of editing operations, that are closely related to
concrete user actions ("insert" an object, "delete" an object,
"merge" two objects - with a very application-specific meaning, that
may not map 1:1 to the xml representation).

Because of its genericity and expressive power, the generic ct
approach would be a very leaky abstraction over a producer's
internal representation - i.e. it would be very likely that
different applications produce different ct markup, for an otherwise
semantically identical user action - then in turn putting the onus
of interpreting that action correctly on the consuming application.

Cheers,

-- Thorsten

-- 
-- -----------------------------------------------------------------
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