RE: [office] Tracked changes proposal

["Philip Boutros" <Philip.Boutros@stellent.com>]

Hi Daniel

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.

-Phil



-----Original Message-----
From: Daniel Vogelheim [mailto:Daniel.Vogelheim@sun.com] 
Sent: Wednesday, April 23, 2003 10:55 AM
To: office@lists.oasis-open.org
Subject: Re: [office] Tracked changes proposal


Hello Phil,

Philip Boutros wrote:
> 1.
> Remove the Open Office specific text:protection-key attribute from the

> text:tracked-changes element. Open Office would presumably move this 
> information to an application specific area.

Makes sense. The protection key would likely go into the document
settings.

> 2.
> Remove the text:merge-last-paragraph attribute from the 
> text:changed-region element. The behavior modified by this attribute 
> seems to be very specific to Open Office application.

I'm afraid this attribute is indeed version specific. Additionally, the 
description of it is bad... :-P

The idea is how to handle 'partial' paragraphs: In general, changes will

not start and end on paragraph boundaries. Basically, a change will 
contain parts of a paragraph at the beginning or end. Problem: How do we

encode this? Since XML only allows complete elements, and since we 
wanted to have all text inside of paragraph elements, we decided to also

include all changed text in complete paragraphs.

Example:
     <text:p>bla bla bla DELETE</text:p>
     <text:p>DELETE DELETE DELETE</text:p>
     <text:p>DELETE bla bla bla</text:p>

If someone deletes the 'DELETE' part of this text, the result will be:

In the changed region:
     <deletion>
       <text:p>DELETE</text:p>
       <text:p>DELETE DELETE DELETE</text:p>
       <text:p>DELETE</text:p>
     </deletion>
In the text body:
     <text:p>bla bla bla <text:change/> bla bla bla</text:p>

Note that there are now four paragraphs (three in deletion, one in text)

where there were only three before. So if you want to know how the text 
looked like before the change, you need to copy the deleted text to the 
change-mark position, and you need to merge the beginning and end 
paragraphs into the surrounding paragraph.

Problem is: How do you handle cases where there is no surrounding 
paragraphs? E.g. at the beginning or end of document, before/after 
tables, sections, ...

The flag was introduced to handle these kinds of corner cases. The 
problem is, it is basically defined by OOo application behaviour. I 
guess just copying this doesn't make sense to any non-OOo applications.

I wonder how to define this behavior properly in the spec, and whether 
any similar flags would be needed...


> 3.
> I suggest we modify the office:change-info element as follows.
> 
> A. Remove chg-author, chg-date & chg-time attributes
> B. Remove its text content
> C. Allow office:change-info to contain any combination of the 
> following metadata elements: meta:generator, meta:creator, dc:date, 
> dc:description and meta:user-defined.

Yes, makes sense. Would generator, create, date and description occur
only once, and meta:user-defined any number of times?

> 4.
> After considering how to implement the text:format-change element it 
> is not clear to me how changes to styles, automatic-style and 
> style-properties would interact. Given the amount of work still 
> remaining on the specification it seems prudent to drop it or leave it

> as is for this version of the specification.

OK.


Sincerely,
Daniel