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] SUMIF, COUNTIF, COUNTBLANK, DCOUNT, DSUM, ... withempty cells and "" and ="" e

What was the argument against 1B -- self-consistency?

I'm not in favor of departing from Excel's behavior for capricious reasons, but if we can get greater consistency and simplicity at the same time by make small deviations, then I'd certainly consider it, even if it requires more work for existing implementations to consume & translate Excel files.


"David A. Wheeler" <dwheeler@dwheeler.com> wrote on 12/15/2006 01:03:04 PM:

> Eike Rathke said:
> > There is some inconsistency in how applications handle empty cells in
> > various conditional functions, and also Excel in itself isn't
> > consistent. This is somewhat a big mess, but I also have no concrete
> > idea whether we should do better or for interoperability's sake mimic
> > the Excel behavior, which might be preferred, and also Gnumeric does.
> > Please see also http://www.openoffice.org/issues/show_bug.cgi?id=65221
> > where a testcase document with some explanations is attached.
> As I see it, we have at least two basic options:
> 1. Mandate a very specific behavior.
>   A. Make it consistent with Gnumeric & Excel, even though it's completely
>       self-inconsistent.  If we could identify a consistency, that'd be good!
>   B. Make a self-consistent behavior, but not consistent with
> current practice.
>       I think this is a bad idea.
> 2. Allow more variance (e.g., don't mandate a particular approach).
>    In this case, I think we should document the differences as "Note:"s,
>    so we can discuss them (and convert them into requirements later
> if desired).
> My inclination is to start with #2, so that at least it's all
> documented somewhere
> accessible.  It'll then be easier then to switch to 1A, if it's desired.
> The risk of #1 is that if we mandate too much, we may require a lot of
> self-inconsistency that we'll regret.  The risk of #2 is that users
> can't depend on
> certain odd behavior in all apps, but it's not clear that users
> actually depend on
> this one.
> I can easily be talked into something different.  Anyone have any more
> thoughts on this?
> --- David A. Wheeler

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