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


Hi Daniel


delete-last-para flag was to differentiate the following two cases.

If the current text looks like this...

	<text:p>abc<text:change>xyz</text:p>

and the change looks like this...

	<deletion>
      	<text:p>DELETE</text:p>
		<text:p>DELETE DELETE DELETE</text:p>
		<text:p>DELETE</text:p>
      </deletion>

then did the original look like this...

	<text:p>abc</text:p>
     	<text:p>DELETE</text:p>
	<text:p>DELETE DELETE DELETE</text:p>
	<text:p>DELETE</text:p>	
	<text:p>xyz</text:p>

or this...

	<text:p>abcDELETE</text:p>
	<text:p>DELETE DELETE DELETE</text:p>
	<text:p>DELETExyz</text:p>


Based on you feedback a Solution C presents itself.

Solution C
---------

We could simply define that the open <text:p> at the beginning of a
deletion and the close </text:p> at the end of the deletion are always
ignored. In this case...

	<deletion>
      	<text:p>DELETE</text:p>
		<text:p>DELETE DELETE DELETE</text:p>
		<text:p>DELETE</text:p>
      </deletion>

would always map to this...

	<text:p>abcDELETE</text:p>
	<text:p>DELETE DELETE DELETE</text:p>
	<text:p>DELETExyz</text:p>

If you wanted this...

	<text:p>abc</text:p>
     	<text:p>DELETE</text:p>
	<text:p>DELETE DELETE DELETE</text:p>
	<text:p>DELETE</text:p>	
	<text:p>xyz</text:p>

then your deletion would look like this....

	<deletion>
		<test:p></text:p>
      	<text:p>DELETE</text:p>
		<text:p>DELETE DELETE DELETE</text:p>
		<text:p>DELETE</text:p>
		<test:p></text:p>
      </deletion>


The only problem I see with this is that it is not obvious to someone
looking at an instance or at the schema that this is the way it works.
They would have to read the docs. Both Solution A and Solution B are
more obvious to someone just looking at an instance document. 

I suggest we hold off on a decision until I have had a chance to look at
the table/text change merging issue. One of these solutions may present
itself as best when looked at from the perspective of table changes.

-Phil



-----Original Message-----
From: Daniel Vogelheim [mailto:Daniel.Vogelheim@sun.com] 
Sent: Monday, May 05, 2003 12:46 PM
To: office@lists.oasis-open.org
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

   <deletion>
    <text:p>bla<text:change-begin/>DELETE</text:p>
    <text:p><text:change-end/>bla</text:p>
   </deletion>

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...


Comments?

Sincerely,
Daniel










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