OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [OASIS Issue Tracker] Issue Comment Edited: (OFFICE-3312)NEEDS-DISCUSSION: Public Comment: Proposal to improve change tracking inODF



    [ http://tools.oasis-open.org/issues/browse/OFFICE-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20632#action_20632 ] 

Dennis Hamilton edited comment on OFFICE-3312 at 8/18/10 11:03 AM:
-------------------------------------------------------------------

GUIDING PRINCIPLE #3: SLICING, SPLICING, AND DICING

This is more about understandint that all slicing, splicing and dicing cases are identified and accounted for in existing and proposed approaches to tracked changes.  We might say these are guiding principles for review of provisions, with the idea that we need to know what principles are applied to these cases for a given approach to tracked changes:

Invariant Selection 3.1: In the case when a deletion precedes an insertion as part of a replacement operation, when the deletion slices elements to the extent permitted, is the result always well-formed and can an insertion splice the sliced elements nevertheless?  Or is an insertion always expressed as well-formed markup introduced into the well-formed markup left after the deletion?  [Note: in the latter case, the deletion and the insertion can be independently revoked and/or accepted without much concern.  Some implementations seem to exhibit such an invariant.]  [Note 2: An element is sliced when a start tag is separated from an end tag as the result of a deletion.  The removed material will have some unmatched end tags toward the beginning and some unmatched start tags beyond any unmatched end tags toward the end.][Note 3: It is assumed that, if any extraction of deleted material is "unbalanced" in this way, it will be packaged as well-formed XML in its retention as part of the tracked change history and there shall a determinant procedure for restoring the original material as if no deletion had occured both as part of revoking the deletion and also exactly enough for showing and identifying the deleted material in its original place for document review purposes.  ODF does not require implementations in this regard, but the change-tracking provisions must be demonstrably and reliably amenable to such operations.]
Subcase 3.2: Although there may be provision for properly slicing elements, what happens when a deletion slices an insertion span (signified by <text:change-start> and <text:change-end> markers) such that one or the other is removed from the remaining markup?  What about off-hiearchy paired markers of other kinds, including bookmark spans, reference-mark spans, TOC marks, index marks, etc.

Subcase 3.3 In addition to the slicing of non-hierarchical spans between various start and end markers, there is also the issue of separating elements having ID-valued attributes into places where it may not be clear that references to such elements are still intended or appropriate.  When the only references are included in the same deleted material as the start tag having the matching ID-valued attribute, there may be no ambiguity.  When there are references from non-deleted material or even references by URI fragment identifier from other parts of the package, the situation is far cloudier.  (This can apply when there is RDF targeted at such an ID from a separate RDF file or from RDFa elsewhere in the same or other non-RDF package file.

There may be more, but these seem to be enough to be concerned about when assessing current and proposed change tracking approaches.

I have ignored the special cases that apply to tracking transformations to tables other than to the text of individual table cells.

      was (Author: orcmid):
    GUIDING PRINCIPLE #3: SLICING, SPLICING, AND DICING

This is more about understandint that all slicing, splicing and dicing cases are identified and accounted for in existing and proposed approaches to tracked changes.  We might say these are guiding principles for review of provisions, with the idea that we need to know what principles are applied to these cases for a given approach to tracked changes:

Invariant Selection 3.1: In the case when a deletion precedes an insertion as part of a replacement operation, when the deletion slices elements to the extent permitted, is the result always well-formed and can an insertion splice the sliced elements nevertheless?  Or is an insertion always expressed as well-formed markup introduced into the well-formed markup left after the deletion?  [Note: in the latter case, the deletion and the insertion can be independently revoked and/or accepted without much concern.  Some implementations seem to exhibit such an invariant.]  [Note 2: An element is sliced when a start tag is separated from an end tag as the result of a deletion.  The removed material will have some unmatched end tags toward the beginning and some unmatched start tags beyond any unmatched end tags toward the end.]

Subcase 3.2: Although there may be provision for properly slicing elements, what happens when a deletion slices an insertion span (signified by <text:change-start> and <text:change-end> markers) such that one or the other is removed from the remaining markup?  What about off-hiearchy paired markers of other kinds, including bookmark spans, reference-mark spans, TOC marks, index marks, etc.

Subcase 3.3 In addition to the slicing of non-hierarchical spans between various start and end markers, there is also the issue of separating elements having ID-valued attributes into places where it may not be clear that references to such elements are still intended or appropriate.  When the only references are included in the same deleted material as the start tag having the matching ID-valued attribute, there may be no ambiguity.  When there are references from non-deleted material or even references by URI fragment identifier from other parts of the package, the situation is far cloudier.  (This can apply when there is RDF targeted at such an ID from a separate RDF file or from RDFa elsewhere in the same or other non-RDF package file.

There may be more, but these seem to be enough to be concerned about when assessing current and proposed change tracking approaches.

I have ignored the special cases that apply to tracking transformations to tables other than to the text of individual table cells.
  
> NEEDS-DISCUSSION: Public Comment: Proposal to improve change tracking in ODF
> ----------------------------------------------------------------------------
>
>                 Key: OFFICE-3312
>                 URL: http://tools.oasis-open.org/issues/browse/OFFICE-3312
>             Project: OASIS Open Document Format for Office Applications (OpenDocument) TC
>          Issue Type: Bug
>          Components: Lists, Part 1 (Schema), Schema and Datatypes, Styles, Table, Text
>    Affects Versions: ODF 1.2 CD 05
>         Environment: This proposal addresses issues around change-tracking as it has existed since ODF 1.0.  It is evidently offered in the context of ODF 1.2.
>            Reporter: Dennis Hamilton
>            Priority: Blocker
>             Fix For: ODF 1.2 CD 06
>
>
> Copied from office-comment list
> Original author: Robin LaFontaine <robin.lafontaine@deltaxml.com>
> Original dates: 2010-07-30-09:33Z to 2010-07-31-09:52Z
> Original URLs: 
>    http://lists.oasis-open.org/archives/office-comment/201007/msg00009.html
>    http://lists.oasis-open.org/archives/office-comment/201007/msg00010.html   
>    http://lists.oasis-open.org/archives/office-comment/201007/msg00011.html
> [Note: the office-comment issue scraper may have run but these came through at a time when the JIRA engine may have been blocked in some way.  I have created this issue as a placeholder until such time as the automated forwarder catches up.]

-- 
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]