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] Key Issues

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.


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