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-3448) ODF 1.2CD05 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:comment-tabpanel&focusedCommentId=21644#action_21644 ] 

Dennis Hamilton edited comment on OFFICE-3448 at 9/27/10 2:12 PM:
------------------------------------------------------------------

There is a slight matter of figuring out how White Space rules work when there are <text:change-start> and <text:change-end> markers with white space around them.  Presumably the final normalization of white space in how the rendered text is determined happens as if the markers are not there.  I don't think there is a problem in this case, but we might need to be concerned about edge cases depending on how rejection of the insertion would work.  It seems that the producer of the insertion can control rejection not having a surprising consequence and we don't have to be concerned here.

[Added: Oh, I remember now.  This can impact how the tracked-change is shown in presentation of the document. That's a consumer matter, I expect, and it depends on the consumer implementation that users not be surprised what happens with regard to spaces on rejection or acceptance of the insertion.  I assume that there is nothing that needs to be said about this with regard to how the markup works and how rejection is cured.  We should be certain of that, however.]

      was (Author: orcmid):
    There is a slight matter of figuring out how White Space rules work when there are <text:change-start> and <text:change-end> markers with white space around them.  Presumably the final normalization of white space in how the rendered text is determined happens as if the markers are not there.  I don't think there is a problem in this case, but we might need to be concerned about edge cases depending on how rejection of the insertion would work.  It seems that the producer of the insertion can control rejection not having a surprising consequence and we don't have to be concerned here.
  
> 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]