[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
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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]