OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-collab message

[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


Hi Frank,

you wrote:
> You mean delta:removed-content:
> 
> <office:body>
> <office:text>
> <delta:removed-content ...>
> <text:p>...</text:p>
>         ....
> </delta:removed-content ...>
> </office:text>
> </office:body>
> 
No, the thing I had in mind was more like

<office:body>
<office:text>
<delta:remove-leaving-content-start ...>
<...>
 <...>
  <...>
    ....
  </...>
 </...>
 <...>
    .... 
 </...>
 .
 .
 .
</delta:remove-leaving-content-start ...>
 <...>
   ....
 </...>
<delta:remove-leaving-content-end .../>
</office:text>
</office:body>

For making ct transactions individually acceptable and rejectable,
of course also the inverse, modulo nested added / removed content
inside the delta:remove-leaving-content-start block, action needs to
be possible inside the application core - i.e. you *will* need to
transform that xml into actionable editing instructions on the
internal document model, i.e. be able to glean the semantics of that
markup on your doc ...

So I maintain that, for being implementable with reasonable effort,
via a non-xml-based representation, the generic ct is heavily
under-constrained. :)

Cheers,

-- Thorsten

PGP signature



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]