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
