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] Add FFT() to formula spec?



"David A. Wheeler" <dwheeler@dwheeler.com> wrote on 02/16/2008 09:44:19 PM:

> Andreas J Guelzow:
> > I had the impression that in the past we never even entertained
> > suggestions for functions (or extension to functions) that weren't
> > implemented by at least one program that supported ODF.
>
> Our general rule has been that it had to be at least one spreadsheet,
> whether not it supported ODF.  (We've made a few exceptions, primarily on
> the grounds of portability/internationalization.)  In this case, we have an
> example - Excel. It doesn't support it the same way but we do have an example.
>


And this certainly makes sense for the initial release of OpenFormula, which is trying to capture the existing range of spreadsheet functions and specify their behaviors.   But once that phase of work is complete, I think we can add additional ones, even if not already implemented by a vendor.  Remember, we have most of the ODF vendors already represented on the ODF TC, so they can and will speak up for their interests and concerns.

The challenge I think is how we partition the spreadsheet functions into interoperable libraries of related functions.  Think of C or C++ standard libraries.  What we have today is like having all functions in one big header file "library.h".  Or maybe "small.h", "medium.h", and "large.h".  You can make an argument for a partition like that for a general purpose word processor for general purpose use.  But it doesn't always lead to a useful breakdown of functionality once you get into the advanced stuff.  For example, FFT would presumably go into the "large.h" library.  But this would encompass everything from advanced financial, to advanced engineering, to advanced string manipulation functions.  Not something that matches any real-world task.

An alternative, or supplementary way to look at this is to have specialized libraries, akin to 'signal-processing.h' or 'bonds.h' that would bring in specialized functions.  So, if we wanted, we could define these advanced functions in such libraries.  You could even require the ODF file to declare or "import" them in the manifest file or in metadata so an application will quickly know whether they can support them.

-Rob

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