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

[monkeyiq <monkeyiq@gmail.com>]

On Fri, 2011-04-01 at 12:52 +0530, Ganesh Paramasivam wrote:
> 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.

I also don't find that the generic proposal being "generic" precludes it
from being implemented. It would be nice in some cases to have a
canonical, or "preferred" way to express the XML when two or more things
are interacting in the generic proposal.

> 
> 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
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>