[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Commented: (OFFICE-2796) 5.5.4 text:deletion- second item in list: "If the change mark is inside a heading, proceed asabove, except adapt the end tags to match their new counterparts." ?
[ http://tools.oasis-open.org/issues/browse/OFFICE-2796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20339#action_20339 ]
Dennis Hamilton commented on OFFICE-2796:
-----------------------------------------
It's more complicated than this.
If you look at all of the places that a change-mark for a deletion can occur, we need a rule for rejecting the deletion that makes sense.
Any time a deletion cuts an element between its start tag and end tag (so there are end tags with no starts and/or start tags with no ends in the removed fragment), there must be a systematic way those are given matching starts on the front and ends on the back of the changed-region deletion element.
A consumer must know how to reinsert the well-formed deletion element content back at the point of the change-mark by removing start- and/or end-tags such that the original structure is restored. (There may be cases where there is nothing to strip, and that has to be clear as well or else there is always one start and one end to strip, which would also make sense.)
A producer, then, can only do deletions that a consumer can restore by this means.
It would be valuable to specify this descriptively rather than procedurally. Note that the deletion-rejection rule is also the same rule needed to figure out how to show the deletion in the presentation, but shown as a change-tracked deletion.
[Side notes: Finally, I note that implementations must treat replacements as deletions followed by insertions (in time, not necessarily in text order). Some implementations allow one or the other to be accepted/rejected in any combination, I haven't checked to see if this is a natural possibility with whatever the tag-matching rule is and how insertions are figured out. I assume that an insertion can also have the effect of slicing elements, but that is handled by the change-begin and change-end markers. This means that deletions (certainly by different reviewers) can slice through insertions, and it is not clear what happens when a deletion scoops up a change-begin or change-end without its mate, which seems to be permissible. There are related questions with regard to other spans that do not have to fit the hierarchical structure of the XML Bookmark spans and index spans seem to be the cases of interest, though there may be more markers that I haven't noticed yet. Attempting to reverse-engineer what is not said here, and the analysis to establish its sufficiency hurts my brain.]
> 5.5.4 text:deletion - second item in list: "If the change mark is inside a heading, proceed as above, except adapt the end tags to match their new counterparts." ?
> -------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: OFFICE-2796
> URL: http://tools.oasis-open.org/issues/browse/OFFICE-2796
> Project: OASIS Open Document Format for Office Applications (OpenDocument) TC
> Issue Type: Bug
> Components: Text
> Affects Versions: ODF 1.2 CD 05
> Reporter: Patrick Durusau
> Fix For: ODF 1.2 CD 06
>
>
> 5.5.4 text:deletion - second item in list: "If the change mark is inside a heading, proceed as above, except adapt the end tags to match their new counterparts." ?
> The preceding paragraph says:
> "If the change mark is inside a paragraph, insert the text content of the <text:deletion> element as if the beginning <text:p> and final </text:p> tags were missing."
> Does this mean:
> "If the change mark is inside a heading, insert the text content of the <text:deletion> element as if the beginning <text:p> and final </text:p> tags were missing."
> ? Since deleted text is save in <text:p></text:p>, shouldn't it simply be placed back in the <text:h></text:h> element?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]