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


Help: OASIS Mailing Lists Help | MarkMail Help

office message

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

Subject: Re: [office] Tracked changes proposal

Hello Phil,

Philip Boutros wrote:
> Two possible solutions come to mind to resolve your issue with #2. Both
> attempt to avoid the text:merge-last-paragraph attribute by encoding the
> information in the deletion element.
> Note: I don't have the spec with me (I'm on the road) so please excuse
> any incorrect element names.
> Solution A
> ----------
> Change the allowable content inside to deletion element to include
> standalone span (or other appropriate) elements. Your example could then
> be unambiguously stated as follows:
>      <deletion>
>        <text:span>DELETE</text:span>
>        <text:p>DELETE DELETE DELETE</text:p>
>        <text:span>DELETE</text:span>
>      </deletion>
> Solution B
> ----------
> Allow/require change-begin and change-end tags within the deletion
> element to mark the part that was actually deleted. Again your example
> would turn into:
>      <deletion>
>        <text:p><text:change-being/>DELETE</text:p>
>        <text:p>DELETE DELETE DELETE</text:p>
>        <text:p>DELETE<text:change-end/></text:p>
>      </deletion>
> I think either one of these work. I'm partial to Solution B because it
> seems more flexible, the deletion element would not need a special
> content model and in Solution A some "auto magic" creation of </p> tags
> would be required which seems bad.

Yes, both of these would work. I tend more towards Solution A, though. 
:-)  Solution B would indeed be more flexible, but it also allows some 
non-sensical definitions, such as


What would anyone do with the bla part of this deletion?

The only issue I have with A is that it violates the 
all-text-content-is-in-paragraph-elements rule. But one could easily 
change that by puttint the partial paragraphs not into a <text:span>, 
but rather into some <text:partial-paragraph> element. Essentially, a 
rename from your suggestion...

The final thing I wonder about is... what if one was to define that all 
deletion redlines would have to start/end with such 
span/partial-paragraphs? If necessary, one could just add empty ones, 
right? But if we always start/end with 'special' paragraphs, the only 
special thing about them is them being start or end, so we could just as 
well use normal properties. In other words, couldn't we just drop the 
delte-last-para flag completely?  Somehow, I can't wrap my head around 
this problem: I'm sure I'm missing something obvious here. Or maybe we 
did miss something when specifying that flag in the first place, and 
this is just a much better solution...



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