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

[Thorsten Behrens <tbehrens@novell.com>]

monkeyiq wrote:
> > 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.
> 
Hi Ben,

well, Ganesh mentions in his implementer's notes that 

 * Paragraph or Header merge with list-items
 * List-item merges with paragraphs or headers
 * List-item splits
 * List-item merges
 * List merge with another list
 * Table cell splits
 * Table cell merges

are challenging, and suggests extra mechanisms to handle those -
which, to me, seems to support my argument that implementations have
a hard time to cope with genericity.

I agree that the simple cases, like insertions and deletions of text
or paragraphs don't pose problems - but that is not surprising. At
any rate, we need to make the hard cases work, and interoperate -
otherwise, what's the point in having ct revamped.

Cheers,

-- Thorsten

PGP signature