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

     <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:
       <text:p>DELETE DELETE DELETE</text:p>
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. 



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