Re: [office-formula] Grouping functions and capabilities

[robert_weir@us.ibm.com]

I guess I'm not convinced that classifying
the functions, by whatever means, changes anything.  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().  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.  We can gracefully degrade in the absence of
3D charts, or if we lack a certain cell border style, or advanced format.
 But there is no way to degrade if you don't have FOO().  I think
this naturally leads to most large spreadsheets having all the functions
people every use, and users tread carefully when they use anything less
than that.  

Analogies to other technologies which
are subsetted will only take you so far.  JDBC levels, embeddable
C, etc., are all used by techies who are expected to be intimate with the
various profiles and capabilities of their tools.  But the end user
using the spreadsheet is blissfully unaware of all of this.  They've
used FOO() since 1990 in Excel, and they want to use FOO() now.

That said, perhaps there is something
useful that can be done to help the editors better detect and notify users
when they receive a document which uses a function they do not know about.
 Especially since there are not really options for degrading gracefully.


In any case, I'd recommend that we work
on getting out a draft of the full specification and take care of profiles
later.  I'm more worried about diverging implementations of the same
spreadsheet functions than how we handle interoperability among partial
implementations.  Let's get something out now that at least handles
interop for the full implementations.  We can always add profiles
later.  I wouldn't hold up the stuff we agree on for lack of consensus
in this area.  We can do this incrementally.

-Rob

"David A. Wheeler" <dwheeler@dwheeler.com>
wrote on 07/11/2006 01:17:58 PM:

.
.
.
> 
> Rob Weir said:
> > I'm not following.  Can you give a couple of examples?
> 
> Okay, how's this:
> * Function "AND" is a function, and most of its requirements
>    are assigned to the "AND_1" group.  For
an implementation
>    to meet the "AND_1" group requirements, it
has to implement
>    all of its requirements (including all the test cases
identified for it).
> * A "_LOGICAL_1" group is defined as the group (of groups):
>    AND_1 + OR_1 + NOT_1 + ...
>    To meet the _LOGICAL_1 requirements, you have to meet
all of them.
> * A _LEVEL_1 group is defined as the group:
>    _LOGICAL_1 + _FINANCIAL_1 + ...
>    So if you want to acquire a spreadsheet that meets "_LEVEL_1"
>    requirements, you can easily state that requirement.
 If you
>    really only need the _LOGICAL_1 functions, you can state
that too.
>    A _LEVEL_2, etc., could be defined the same way.
> 
> This is more flexible that the old "single number" system,
at the cost
> of more complexity in the spec.  All the tables saying "Level"
would
> need to be changed to say "Group", and all the level numbers
would
> need to be changed to text values.
>