office-formula message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [office-formula] Key Issues
- From: robert_weir@us.ibm.com
- To: Daniel Carrera <daniel.carrera@zmsl.com>
- Date: Mon, 27 Feb 2006 16:57:16 -0500
Daniel Carrera <daniel.carrera@zmsl.com> wrote
on 02/27/2006 04:47:44 PM:
> robert_weir@us.ibm.com wrote:
> > If we want, is sufficient for us to define ODF formulas period,
> > and leave it to a future specification to define subset and superset
> > profiles for various other uses. This could even be done
by vendors or
> > on an industry basis,
>
> Well, spreadsheets are a mature industry. In a sense, vendors have
> already decided best practices. So, we could follow your approach
> without waiting a few years. For example, take the intersection of
most
> interesting spread sheets and call that "basic". Take a
spreadsheet that
> focuses on the scientific field (Gnumeric? - not sure) and use that
to
> get the "science" package. You get the idea.
>
Spreadsheets are mature, but a spreadsheet format
with multiple levels of support is not. It is the slicing and dicing
and then standardizing predefined levels that concerns me. The best-practice
(only-practice?) in spreadsheets today is to offer everything. We
all pay for that terms of load time and memory use whether we need it all
or not. So, I'm not sure the answer lies in current implementations.
Another way to look at it is to take the common intersection
(as you say) of current implementations and standardize that set of functions.
We can leave it at that. If vendors then want to define subsets
or supersets of that for special uses, then let them. And if something
really interesting happens with a particular profile/level/package set,
then we (or someone else) can standardize that in the future.
-Rob
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]