OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-collab message

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


Subject: RE: [office-collab] Comparison generic-ct-proposal and extended-ct-proposal


I think there are complications around ODF <text:section> that may not make it amenable to simple trackable changes, and it is definitely more serious than a style change, because it may be an insertion point for content derived elsewhere.  

When there are manipulations of <text:section> elements by users, the question becomes which one(s) is/are being edited when there is section linking involved.  Also, to remove a derived <text:section> it may in effect be a replacement of the <text:section> by whatever the source provides, but breaking the connection.  (Note: the source need not be in the content.xml part or it can be conveniently placed there but marked as not shown.)  

Removing a source <text:section> leads to questions about what happens to the ones that are derived from it by linking, etc.  So there are edits of a <text:section> with derived content that are more like editing a field.  There's other editing that may really be of the source (and how does that reflect in the derived copy?) and so on.  (Side note: replications of section content can't be identical because of constraints on xml:id and, along with that, prospects for current/extended change marks existing in the source of the replication when the source is obtained by linking to another <text:section>.)

See ODF 1.2 CS01 Part 1 section 5.4.  Also, see the schema.  Note that the content that is present is a possibly-empty run of text-content elements.  In places where the <text:section> appears as text-content, it might be possible to just drop the <text:section> tags.   This doesn't work for all places where <text:section> is allowed, depending on what the text-content run is within the <text:section>.  Also, some <text:section> occurrences (such as in header-footer-content) are not as text-content.

There are probably more variations to deal with than the ones I found in a cursory inspection of the schema (and recollection of my struggling to understand <text:section> in the work on ODF 1.2).  Handling of nested <test:section> elements is left as an exercise for the student.

 - Dennis

-----Original Message-----
From: Frank Meies [mailto:frank.meies@oracle.com] 
Sent: Tuesday, March 29, 2011 00:17
To: office-collab@lists.oasis-open.org
Subject: Re: [office-collab] Comparison generic-ct-proposal and extended-ct-proposal

Hi John,

thank you for your input, I'll change the document accordingly, see attachment. The most common use case for "delete an element but not its content" is removing a styled span, so you are right, this can be expressed using text:format-change. Another use case for remove-leaving-content is removing a text:section without removing its content. Do we want to handle this as a text:format-change as well?

[ ... ]



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