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,

Daniel Vogelheim wrote:
> 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.

We've already agreed this change.

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

This attribute needs to be clarified further.

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

This proposal sound very reasonable to me as well.

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

I agree. We should move this in the next phase.

> 
> 
> Sincerely,
> Daniel
> 
> 

I suggest that we vote about Phil's proposal as soon as we have 
clarified what to do with the text:merge-last-paragraph attribute.

Best regards

Michael




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