[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Updated: (OFFICE-3449) ODF 1.2 CD05 Part 15.5.3 Text Insertion Interoperable Definition Required
[ 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]