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] Grouping functions and capabilities

Robert Weir said:
> > I guess I'm not convinced that classifying the functions, by whatever means,
> > changes anything.

I agree that profiling doesn't solve the universe's problems, but I
still think it's useful.  I propose that we give it a try, and go from there.
If it's worthless, that'll become obvious.

> >  As a user, if I want to use a FOO() in my spreadsheet and
> > it isn't there, then the fact that the spreadsheet was rated "Level 1" is
> > little comfort.
> >  I don't have my FOO() and I want FOO().  

Ah, but "level 1" didn't include FOO().  If you wanted FOO(), you would've
picked an application that supported "level 3" (which let's say has FOO)
or at least "level 1 + FOO".  This should make it easier for you to
choose an application that supports what you need, which is the
point of a profile.  In practice, nobody wants to test an app for every function;
they want a convenient shorthand like "meets level 2" or "meets level 2 +
financial_4" so they'll pick the right application.

This can apply to an individual, or to a company/government/organziation...
if they want a full-function spreadsheet application, it'll be easy to winnow
out the 5-function applications.

> > Ditto for if I do
> > save my spreadsheet from an editor that has this function but then it is
> > loaded my someone who doesn't have it.

Ah, but it works the other way too.  Often there are several ways to
do something.... one may be widely portable (using only level 1 functions),
while the other may not be.  If I have a way to KNOW that, then I can
stay in the straight-and-narrow and use the more portable approach.

For example, Excel lacks the ARABIC() function, a function widely supported
elsewhere... knowing that this function is NOT supported everywhere might convince
you to do something else instead.

There are other reasons for US to do profiling:
1. By identifying what's "most important/common" first, we force ourselves to work
    on the most important and most common functions first, wringing out their
    exact semantics.  Yes, ARABIC() is a nice function, but let's talk about SUM()
    first, shall we?
2. By identifying what's "most important/common" first, we help implementors
    determine what's more important... and make sure that they get that implemented
    first.  We have ALREADY had a significant impact on existing implementations,
    particularly KOffice and wikiCalc.  The KOffice folks have been using our draft
    test spreadsheet to find and fix problems... not because there's a mandate to do so,
    but because it helps them to focus on the most important issues
    for real users, using small test cases that are easier to work with.
    Similarly, though wikiCalc is not trying to implement ALL functions, it's implemented
    all of the old level 1 functions... because it wasn't as hard to do that smaller set,
    AND because it results in MOST data files being portable.

Tomas Mecir said:
> Well, the thing is, the only solution to this would be requiring all
> spreadsheets to implement all possible functions, and at the same
> time, prohibiting them from implementing anything more. Which,
> obviously, is not a good idea.
> I personally like this LOGICAL_1, ... approach, it makes it relatively
> easy to check for level of compatibility, and allows incremental
> updating to be more and more compatible with the spec - for example, I
> can have all Level 1 functions fully complaint, and most higher ups
> present, but occasionaly giving different results for whatever reason.
> And, yeah, if agreeing on levels/groups is a problem (although I don't
> see why), let's just move on to defining each function and worry about
> groups later on.

Probably the biggest risk is spending too much time on "what level is this in",
as opposed to defining it.  But we're all grown-ups here, and I think a
rough consensus on grouping/leveling will be sufficient for the purpose.
I have used a very simple metric - "how many different implementations support it",
with each implementation having a "vote" on importance.   I think this
metric is justifiable - if more apps implement a given function, then clearly
it's more important.

--- David A. Wheeler

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