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


Help: OASIS Mailing Lists Help | MarkMail Help

office-formula message

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

Subject: Re: [office-formula] A-functions

On 9/8/06, David A. Wheeler <dwheeler@dwheeler.com> wrote:
> I think it would be DISASTROUS to spec something we KNOW
> is not true, and will NEVER become true.  Better to make it
> implementation-defined... which is in fact what we do.

Hmm. Basically, you are suggesting to write in the spec something
like: "Implement this function how you want" ? I'm not sure if we'll
manage total compatibility that way, but ah well, seems like there
isn't any better option.

Bot A and non-A treat numbers as numbers.
If the implementation doesn't have distinct logicals, then logicals
always get treated the same as numbers.
If the implementation supports logicals, A version treats them as 1
and 0, non-A is implementation specific.
As for strings, the behaviour is implementation-specific. A-version is
never allowed to ignore it, it must somehow convert the string to a
number - either parse the number, or just use 0. Non-A version can
either convert the string to a number, or ignore the string entirely.

All these functions must behave in the same way for one implementation
- ie., if SUM treats logical/strings in some way, COUNT, AVERAGE, ...,
all must treat them the same.

Are the rules regarding these functions good enough now ? :)
Also, where to write them ? I think it'd be bst to write these in some
section somewhere, and in each related function, point the reader to
that section, so that we don't have to copy-paste these rules 20

/ Tomas

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