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] Commented: (OFFICE-2565) 8.3.2 E2.5 isinsufficiently clear



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

Dennis Hamilton commented on OFFICE-2565:
-----------------------------------------

This seems to be a carryover of old language that has not been reviewed recently.

In the discussion, there is an interesting question about honoring settings and whether this is needed.

Eric raised an interesting problem in the specific case of the null date setting and what happens if someone sets a value (where the setting is specifiable) that an implementation of an evaluator can't handle.  This strikes Dennis as an integration issue, not a specification issue.  Maybe the problem is we think of evaluators as free-standing and having to be pluggable.  I don't think that is it.

> 8.3.2 E2.5 is insufficiently clear
> ----------------------------------
>
>                 Key: OFFICE-2565
>                 URL: http://tools.oasis-open.org/issues/browse/OFFICE-2565
>             Project: OASIS Open Document Format for Office Applications (OpenDocument) TC
>          Issue Type: Bug
>          Components: OpenFormula
>    Affects Versions: ODF 1.2 Part 2 CD 1
>            Reporter: Andreas Guelzow 
>            Assignee: Robert Weir 
>             Fix For: ODF 1.2 Part 2 CD 2
>
>
> 8.3.2 E2.5 states that  a conforming small group evaluator "shall evaluate the following calculation settings".
> I doubt that we really only mean that it should evaluate it (in that case there would be no point of mentioning it) but it is probably intended that it should take some action as the result of the evaluation. 
> As one extreme we may want it to warn the user if it cannot handle that specification (e.g the given null-date).
> At the other extreme we might expect it to handle every conceivable value. In this case we automatically imply that it can handle negative date serial numbers since if the null-date is in teh future, TODAY will need to return negative date serials....
> We should clarify our expectation.

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