[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. 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]