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

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.


"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.

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