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

[Ganesh Paramasivam <ganesh@crystalfab.com>]

Hi,

Just wanted to give my opinion from an implementation view-point of
the generic-ct-proposal.

I agree that for some use-cases there may be multiple ways of
representing the same change. Some use-cases that I can think of that
come under this category are

- Paragraph splits
- Paragraph with Paragraph merges
- Paragraph with Header merges
- Header with Paragraph merges

However, I have found that all the different ways to represent changes
for the above use-cases capture the actual change accurately and
precisely. i.e It is possible for an implementation to determine the
change unambiguously and thereby to represent that change in it's
internal model. It would great to remove the redundancy if possible
though.

Do you have any specific use-cases other than the above mentioned ones
that you had in mind to illustrate this problem ?

Thanks,
Ganesh

On Fri, Apr 1, 2011 at 7:07 AM, Thorsten Behrens <tbehrens@novell.com> 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
>