[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=20897#action_20897 ]
Dennis Hamilton commented on OFFICE-2796:
-----------------------------------------
I am attempting to confirm my understanding of what happens here. I don't believe that the business of renaming an end tag that is following a restored deletion is anywhere close to the necessary behavior, although it is important. It seems to deal with the fact that you can sever from the within a <text:p> to within a subsequent <text:h> and vice versa, but that need not be all of the cases, and it needs to be explained better.
Here is what I am talking myself through to understand what the model might be. I am using text-content and paragraph-content to refer to those particular schema patterns:
1. <text:deletion> elements carry the deleted text that is tracked as a succession of one or more text-content instances. The sequence can contain any arrangements of any numbers of change-marks, <text:p>, <text:h>, <text:list>, <text:numbered-paragraph>, <text:section>, <text:soft-page-break> and shape instances along with <table:table>, <text:table-of-content>, <text:bibliography> and the variety of <terxt:*-index> element instances.
1.1 It is noteworthy that there is no <text/> allowed in the succession of text-content instances . Also, we must deal with cases where a permissible deletion severs elements such that there are unmatched end tags toward the beginning of the deletion markup and/or unmatched start tags toward the end of the deletion markup.
1.2 For all unmatched end tags in the extraction, matching start tags must be added at the front of the extraction to make the severed elements whole in the <text:deletion> text-content sequence. The start tags are added to the front in the reverse order of the unmatched end tags in the deleted markup. The result will be that the element with the first unmatched end is nested within the one with the next unmatched end tag, etc.., reflecting the nesting that applied before the deletion. For all unmatched start tags, the elements are made whole by adding corresponding end tags at the end of the deleted material, starting with the right-most unmatched start tag. The addition of end tags is in reverse order to the order of the unmatched start tags in the extracted material. For added start tags, appropriate attributes from the original start tag are also carried over, but there must not be any duplication of ID values that are required to be unique in the XML document. Producers shall not produce <text:deletion> elements where the unambigous determination of severed elements cannot be restored. Producers shall not sever elements where addition of start tags cannot be performed in a way that results in a valid element or where the severed element cannot be joined with the remainder of a severed element on the other side of the deleted markup.
1.3 Furthermore, an added start tag and the corresponding added end tag must be of the same or compatible element types, ones that can have exactly the same pattern of trailiing content, such as <text:> and <text:p>. and the first-added start tag must be for an element that permits a <text:change> element at the point where it is severed. Whenever an added end tag is of a different element type that the compatible added start tag, the undeleted end tag that the added end tag was added to stand in for is changed to be an end tag for the same element type that the added start tag is. This creates a well-formed element where an element beginning is spliced to an element ending in order to heal elements across the gap left by severing of elements as part of the deletion. For every severed element whose start tag is to the left of the deletion, there must be a severed element whose end tag is compatible and to the right of the deletion, after suitable renaming of end tags. There can be no severed elements whose end tags are to the right of the deletion for which there is not a corresponding and compatible start tag of a severed element to the left. [Note: These conditions constrain the extent to which a producer can sever elements in creating a tracked deletion. Producers might manipulate elements to make an achievable tracked deletion. Producers are also likely to limit the extent of deletions that can be produced as a single change.]
1.4 In addition, after any adjustment for severed elements, if there are any <text/> element children directly in the deleted material, the entire, adjusted sequence must be transformed to a single element that has any text <text/> instances appear to be part of paragraph-content instances, e.g., in <text:a>, <text:h>, <text:p>, <text:meta>, <text:meta-field>, or <text:span> instances.
1.5 an unambiguous way to address (1.4) is to always add start and end tags around the adjusted deletion material when the adjusted deletion is immediately and completely internal to an element that has <text/> element children. The start and end tags would be for the same element type as the element which has the still-exposed <text/> as its element children. [Note that the result must always be a valid element if the adjustments were also valid and the element having <text/> element children also allows <text:change> in its mixed content.]
2. However (1) is accomplished, it must be such that to the extent that something like (1.2-1.5) is accomplished in combination with where the corresponding <text:change> marker appears, there is an unambigous way to revoke the change and restore the deleted material to the document as if it was never removed (correcting as necessary for the prospect of an adjacent insertion). Producers shall not produce <text:deletion> elements where this is not true for where the <text:change>-marked deletion was made.
3. A <text:change> mark where a deletion has been made can occur anywhere that an element-content or paragraph-content instance is allowed (and perhaps other places). Since we desired that only unambiguous cases are valid in produced dcouments, the procedure sketch above can be applied in reverse to restore the text as it was before the deletion.
3.1 The trick seems to be to know when it is necessary to remove tags from the beginning and end of the <text:deletion> sequence of text-content elements, and how to sever elements and resplice their beginnings and ends with the original ends and beginnings in the deleted markup.
3.2 Since a <text:change> element will appear in the deepest element that was (possibly) severed by the deletion, we need to be able to determine whether the <text:deletion>'s text-content sequence goes directly in place of the <text:change> element or whether the element having the <text:change> element child needs to be split and re-spliced to the beginning and end of the deletion, and so on until there is no more splitting and re-splicing to be done.
3.3 It appears that we know there is something special to do with the deletion we are restoring depending on whether its first (and possibly only) element is acceptable directly as an element child the element where the <text:change> is found.
3.4 The other thing we need to understand is that the <text:change> is in the interior of a nest that needs to be severed and have the deletion respliced so that the remaining text-/paragraph content is at the right level. We need to know how to unravel enough start tags (and end tags) from the <text:change> text-content sequence to be at the right place for resplicing up to the right level. (If we had a marker for this, it would be easy, but we don't.)
4. It looks like a basic procedure for identifying where the deletion restores is as follows:
4.1 Assume that we are working our way down through a document model when we find the <text:change> element. At this point, we know what elements we have seen the start tags for and which are still "open" (with their end tags somewhere beyond the <text:change> element in the markup.
4.2 If there is no element-content in the corresponding <text:deletion> we're done. Ignore the <text:change> and move along..
4.3 At this point, there is a sequence of consecutive start tags at the beginning of the <text:deletion> markup for its text-content sequence. That sequence ends when the next token is an end tag or a <text/> child element. (The sequence can be empty.)
4.4 The initial sequence of those start tags that exactly match the start tag names of the stack we are in, ending with the element we are in, represent the nest in which the deletion shall be spliced. [It would be nice if that were unique. It will be if there is some limitation on recursion through the same elements in a deletion nest.]
5. Having established an initial sequence match, we know how high up above where the <text:change> element occurs the deleted material extends, and we know which elements need to be severed and respliced to the front of the originally-deleted markup and to the rear of the originally-deleted markup. We also know how to rename the end tags of the split off tails that are respliced to the originally-deleted markup.
6. The current specification may apply to a restricted case of this. Nevertheless, it must be clear that the <text:change> element can be buried underneath splices that heal over the scar of the deletion and that the restoration has to work up from the <text:change> location into those superior elements. If there is <text/> outside of any element in the sequence of deleted material (which is likely in most cases), then the <text:deletion> text-content sequence will consist of a single element of the type of the element parent and, because it is a single element, no element splicing is required at that level, the unwrapped element content will just fit in once any splicing at deeper levels down to the <text:change> location is handled. (If that is the <text-change> location, we are done.)
> 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
> Assignee: 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]