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
