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: office-formula@lists.oasis-open.org
- Date: Mon, 27 Feb 2006 15:07:47 -0500
As you can see, there are combinatorial
large number of useful subsets of functions which an implementation could
choose to implement based on resource/function tradeoffs.
Note that we are not required to answer
this question in the general case. 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, e.g., the financial
analysis formula profile, or the Cambridge Center for Adult Education Accounting
Class profile, or the electrical engineering formula profile which would
contain a particular subset of functions, including specific extension
functions that we're not even going to touch in our specification. I'm
not convinced of our ability to cut this diamond right the first time.
I'd much rather see a single, unambiguous standard emerge and then
see what people do with it, and come back in a year and standardize on
whatever emerged as best practices.
So maybe we can start by standardizing
a way for implementations to define profiles, but we don't standardize
on any profiles ourselves?
Think of C/C++. When C was standardized,
it had a single set of required libraries. But eventually there emerged
subsets for embedded uses and supersets for more specific uses. Ditto
for HTML.
I'm not saying levels are bad, I'm just
wary of thinking we can get it right the first time.
-Rob
"Tomas Mecir" <mecirt@gmail.com> wrote
on 02/27/2006 11:11:02 AM:
> On 2/27/06, robert_weir@us.ibm.com <robert_weir@us.ibm.com>
wrote:
> > For example, advanced financial function and advanced
> > math functions are not going to be used by the same user. But
I could
> > imagine a PDF-based implementation used by an optical engineer
which needs
> > that Bessel function but would waste a lot of memory if they
had to fully
> > implement Level 4.
>
> Nobody is saying that they HAVE to implement everything ... They can
> implement just what they need, saying they have support for, say,
> Level 1, plus bessel functions from Level 4. Hmm, thinking of which,
> we could break each level into parts - I think this would be a good
> compromise between the level-based approach and the package-based
one.
> Each level except the first one(s) could have packages, so that
> partial implementations are possible, but all packages need to be
in
> for "full support of Level X to be claimable"
>
> / Tomas
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]