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-3760) Spelling issue in part 2 2.4

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

Andre Rebentisch commented on OFFICE-3760:

From the editor revision 1.2 CD02 REV08:
"Note: We keep maximum flexibility by simply asserting that there are Error values without saying what they are other than NA. In practice, users generally don't care which errors are which (other than an NA) in most cases, and implementations do different things in different cases.
Note: Excel 2003 has the following Error values (with ERROR.TYPE values), according to Walkenbach 2003, page 49 and Simon's "Excel 2000 in a Nutshell" page 527:
#DIV/0! (2) - Attempt to divide by zero, including division by an empty cell.
#NAME? (5) - Unrecognized/deleted name.
#N/A (7) - NA. Lookup functions which failed and NA() return this value.
#NULL! (1) - Intersection of ranges produced zero cells.
#NUM! (6) - Failed to meet domain constraints (e.g., input was too large or too small)
#REF! (4) - Reference to invalid cell.
#VALUE! (3) - Parameter is wrong type."

Generally I don't see why these indicative Error types should not get mentioned in the 1.3 specification.

> Spelling issue in part 2 2.4 
> -----------------------------
>                 Key: OFFICE-3760
>                 URL: http://tools.oasis-open.org/issues/browse/OFFICE-3760
>             Project: OASIS Open Document Format for Office Applications (OpenDocument) TC
>          Issue Type: Bug
>          Components: OpenFormula
>    Affects Versions: ODF 1.2
>            Reporter: Andre Rebentisch
>            Assignee: Robert Weir 
>            Priority: Minor
> part 2 (OpenFormula)- 2.4 item "Applications vary on the set of Errors they support. In this specification. The only distinguished Error is #N/A; all other errors are simply errors, allowing applications to choose the Error set that best meets their needs. "
> 1. "In this specification. The"
> 2. As the whole argument for underspecification of Error values sounds like a joke, rewording may be necessary. It does not appear necessary to defend the reasons for an underspecification. Also the uppercase/lowercase of "errors" needs to be reviewed. I understand that Error is used for the type, destinct from the (deviation etc.) error in certain formulas in OpenFormula, e.g. cmp. 6.1.27

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]