[ http://tools.oasis-open.org/issues/browse/OFFICE-3449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Oliver-Rainer Wittmann updated OFFICE-3449:
-------------------------------------------
Proposal:
[Dennis' proposal:]
Again ,the stakeholders of this provision must assist in arriving at an interoperably-implementable description of what current implementations manage for ODF 1.0/1.1.
1. Define what constitutes a legitimate single insertion selection and how it relates to other occurrences of insertion selections. Must they be non-overlapping? May they be nested? We want a case for allowed insertion selections that are implemented and that shall be supported by a conforming implementation that supports tracked changes shall be able to present the insertion (if that is a consumer capability) and to reject the insertion (if rejection is a consumer capability). [Note: there is no concern, here, for what a producer might turn into multiple insertions to accomodate an operation provided for processing of a document, only what one must be prepared to recognize as a single selection in the document.
2. How much of healing across a tracked deletion is involved when healing across the deletion that rejection of an insertion is?
3-4 omitted because they seem to be irrelevant in this case.
5. Edge cases: Whether deletions can occur that remove part of an insertion selection, and if so, what is done about the curing the broken connection between <text:change-start> and its matching <text:change-end>?
I have the same sense of what works as implementation-defined and implementation-dependent requiring that there be some useful remainder that can be interoperably implemented and that a consumer can detect whether it can deal with whatever else shows up in regard to tracked insertions.
[Note: I have stayed away from use cases, although there is obviously an interest among implementers in seeing how what is provided works with interesting cases, such as a cut and paste operation that leaves deletions and results in insertions. Also pasting over a selection leads to deletions and insertions at the destination. I don't think we can speak to that, although there is some concern that what is well-defined in the format can be usable in such manipulations. Undo, which does not leave residue in conforming markup of the produced document, is also a consideration for implementers nonetheless.]
This is simpler than tracked deletion alt
[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:
Again ,the stakeholders of this provision must assist in arriving at an interoperably-implementable description of what current implementations manage for ODF 1.0/1.1.
1. Define what constitutes a legitimate single insertion selection and how it relates to other occurrences of insertion selections. Must they be non-overlapping? May they be nested? We want a case for allowed insertion selections that are implemented and that shall be supported by a conforming implementation that supports tracked changes shall be able to present the insertion (if that is a consumer capability) and to reject the insertion (if rejection is a consumer capability). [Note: there is no concern, here, for what a producer might turn into multiple insertions to accomodate an operation provided for processing of a document, only what one must be prepared to recognize as a single selection in the document.
2. How much of healing across a tracked deletion is involved when healing across the deletion that rejection of an insertion is?
3-4 omitted because they seem to be irrelevant in this case.
5. Edge cases: Whether deletions can occur that remove part of an insertion selection, and if so, what is done about the curing the broken connection between <text:change-start> and its matching <text:change-end>?
I have the same sense of what works as implementation-defined and implementation-dependent requiring that there be some useful remainder that can be interoperably implemented and that a consumer can detect whether it can deal with whatever else shows up in regard to tracked insertions.
[Note: I have stayed away from use cases, although there is obviously an interest among implementers in seeing how what is provided works with interesting cases, such as a cut and paste operation that leaves deletions and results in insertions. Also pasting over a selection leads to deletions and insertions at the destination. I don't think we can speak to that, although there is some concern that what is well-defined in the format can be usable in such manipulations. Undo, which does not leave residue in conforming markup of the produced document, is also a consideration for implementers nonetheless.]
This is simpler than tracked deletion alt
Please see my comment on issue OFFICE-3448
My proposal for this issue - as for issue OFFICE-3448 - 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.3 Text Insertion Interoperable Definition Required
> --------------------------------------------------------------------------
>
> Key: OFFICE-3449
> URL: http://tools.oasis-open.org/issues/browse/OFFICE-3449
> 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-3448 and related issues around tracked changes.
> There is actually no description of what constitutes an insertion and what it takes to reject one. (Acceptance is easy).
> All we have said is that <text:change-start> and a matching <text:change-end> element bound the insertion and associate it with a <text:insertion> element.
> But the span of markup betweem a <text:change-start> to its corresponding <text:change-end> has all the characteristics of a selection. And rejecting the insertion is an act of deletion. Although that deletion is presumably not tracked, a consumer that supports insertion rejection, must know how to heal the removel of the inserted markup similar to ways that markup is healed around the scar of a tracked deletion.
--
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
