[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Updated: (OFFICE-3448) ODF 1.2 CD05 Part 1 -5.5.4 Text Deletion Interoperable Definition Required
[ http://tools.oasis-open.org/issues/browse/OFFICE-3448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Oliver-Rainer Wittmann updated OFFICE-3448:
-------------------------------------------
Proposal:
[Dennis' proposal:]
The stakeholders in this provision need to offer what works here from their knowledge of existing implementations of ODF 1.0/1.1.
1. Define what constitutes a single selection that shall be supported by a confirming implementation of tracked-change deletions and that a consumer that supports the feature shall be able to present (if that is a consumer capability) and to reject the change (if that is a claimed consumer capability). [Note, this is not what makes a single selection at the UI, but what is turned into a single-deletion selection and may well be part of a larger selection that a producer allows to be made as part of processing a document.]
2. The question is basically, what is the original case of a span of markup that can be replaced by a single <text:change> element:
2.1 If it is admissable to cut off start tags before the deletion selection from their end tags within the selection, and start tags within the selection from their end tags that are beyond the end of the selection, what are the conditions that must be satisfied between those respective elements that will be torn at the front of the selection and those torn at the rear of the selection?
2.2 What is the rule for healing the scar left by the removal of the selected markup and replacement by the <text:change> element.
3. The next question is how, for such a deletion, is the deleted markup repaired so that those end tags in the selection that have no longer have start tags are made well-formed elements. Likewise, how is the deleted markup repairs so that those start tags in the selection that have no longer have end tags are made well-formed elements, such that the entire deletion material in the <text:deletion> is well-formed.
4. Finally, what additional must be done to the <text:deletion> material, no matter what adjustments were made, to ensure that it is unambiguously restorable in the event that the deletion is rejected. [This should also be sufficient that a consumer that is implemented to show tracked deletions can do so reliably.]
5. Edge cases: Describe whether deletions selections can occur in deleted material that is being shown as tracked but not rejected. Can the selection cross out of the deletion material or must it be entirely within or entirely without?
If some of these cases or extending beyond them is implementation-defined or implementation-dependent, that strikes me as eminently reasonable. However, I believe a well-defined interoperably-implementable case must remain, such that a consumer can also determine whether it can handle whatever else shows up in a tracked deletion.
[Oliver's proposal:]
Use the information given at Dennis' proposal for an improved or new ODF change tracking for the next version of ODF
was:
The stakeholders in this provision need to offer what works here from their knowledge of existing implementations of ODF 1.0/1.1.
1. Define what constitutes a single selection that shall be supported by a confirming implementation of tracked-change deletions and that a consumer that supports the feature shall be able to present (if that is a consumer capability) and to reject the change (if that is a claimed consumer capability). [Note, this is not what makes a single selection at the UI, but what is turned into a single-deletion selection and may well be part of a larger selection that a producer allows to be made as part of processing a document.]
2. The question is basically, what is the original case of a span of markup that can be replaced by a single <text:change> element:
2.1 If it is admissable to cut off start tags before the deletion selection from their end tags within the selection, and start tags within the selection from their end tags that are beyond the end of the selection, what are the conditions that must be satisfied between those respective elements that will be torn at the front of the selection and those torn at the rear of the selection?
2.2 What is the rule for healing the scar left by the removal of the selected markup and replacement by the <text:change> element.
3. The next question is how, for such a deletion, is the deleted markup repaired so that those end tags in the selection that have no longer have start tags are made well-formed elements. Likewise, how is the deleted markup repairs so that those start tags in the selection that have no longer have end tags are made well-formed elements, such that the entire deletion material in the <text:deletion> is well-formed.
4. Finally, what additional must be done to the <text:deletion> material, no matter what adjustments were made, to ensure that it is unambiguously restorable in the event that the deletion is rejected. [This should also be sufficient that a consumer that is implemented to show tracked deletions can do so reliably.]
5. Edge cases: Describe whether deletions selections can occur in deleted material that is being shown as tracked but not rejected. Can the selection cross out of the deletion material or must it be entirely within or entirely without?
If some of these cases or extending beyond them is implementation-defined or implementation-dependent, that strikes me as eminently reasonable. However, I believe a well-defined interoperably-implementable case must remain, such that a consumer can also determine whether it can handle whatever else shows up in a tracked deletion.
My proposal for this issue and also for issue OFFICE-3449 is that we take it as additional input/feedback for an improved or new ODF change tracking for the next version of ODF.
> ODF 1.2 CD05 Part 1 - 5.5.4 Text Deletion Interoperable Definition Required
> ---------------------------------------------------------------------------
>
> Key: OFFICE-3448
> URL: http://tools.oasis-open.org/issues/browse/OFFICE-3448
> Project: OASIS Open Document Format for Office Applications (OpenDocument) TC
> Issue Type: Bug
> Components: Needs Discussion, Part 1 (Schema), Text
> Affects Versions: ODF 1.2 CD 05
> Reporter: Dennis Hamilton
> Priority: Blocker
> Fix For: ODF 1.2 CD 06
>
>
> This is related to ODF-2796 and other tracked changed discussions.
> We have evidence, based on difficulties that have been experienced, and in difficulties explaining section 5.5.4 and connected material t ourselves, that we lack enough information for independent interoperable implementation.
> We need a minimum sufficient description that need not go beyond what is known to be implemented, nor attempt to comprehend every particular nuance of what is known to be implemented, especially if it cannot be described without appealing to the implementtion.
--
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]