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] Goals/levels/packaging/complex numbers

"David A. Wheeler" <dwheeler@dwheeler.com> wrote on 03/01/2006 10:08:20 AM:

> I think a great value of standardization is revealing everyone's
> requirements, and then working to try to achieve them (presuming "not
> excessively complex" is a requirement too).  So far, the union of
> requirements looks like this:

> * Don't require EVERY ODF app to support formulas


> * Don't require EVERY formula-supporting app to support a massive number
> of functions; some may only want to support + - * / SUM and a
> specialized set


> * Have a large set of defined functions, so that if two apps DO support
> the same function, it means the "same" thing


> * Have a shorthand way of describing sets of functions (and maybe
> semantics) so that you can describe what a particular application supports

I'm not sure if we're all thinking the same thing here.  For example, simply having a section header in the specification called "database functions" is sufficient to accomplish this, and becomes a shorthand notation for implementations to state their compliance level as a checklist item;  "SuperDuper Spreadsheet 1.0 supports ODF database, financial and advanced math functions".

Or we could have markup-level declaration features to define which libraries a particular document requires, akin to #include or import statements, or even with unique namespaces for different function packages.  But I'm not sure much is added.  Doesn't it work today to have a simple regex over all formula attribute values to determine the set of all functions which are referenced?  Of course, all we need then is for someone to add an Eval(string) functions which allows a user to pass in a formula as a string, perhaps retrieved from a web service, or as user input, and all bets are off.  At that point, you cannot have a static determination of what functions a spreadsheet uses.

> * Have some predefined sets of functions so that users can easily say "I
> need set X".

The above certainly enables this.  I'm just not a big fan of us elevating a certain subset with the loaded term "level 1" or "level 2".  To me this is too desktop-centric.  I'm wearing two hats here.  As a spreadsheet vendor I'm happy to have a core set of functions and capabilities chosen for desktop interchange, but I would expect this to involve a larger ODF modularization and profile activity and be issued separately from the ODF specification.

Think of XHTML and their modularization effort.  A good summary of their goals is here:  


I think this is exactly what we want, you can replace "XHTML" with "ODF" in this statement and I would find it 100% correct and essential for us:

"Modularizing XHTML provides a means for product designers to specify which elements are supported by a device using standard building blocks and standard methods for specifying which building blocks are used. These modules serve as "points of conformance" for the content community. The content community can now target the installed base that supports a certain collection of modules, rather than worry about the installed base that supports this or that permutation of XHTML elements. The use of standards is critical for modularized XHTML to be successful on a large scale. It is not economically feasible for content developers to tailor content to each and every permutation of XHTML elements. By specifying a standard, either software processes can autonomously tailor content to a device, or the device can automatically load the software required to process a module."

But I emphasize that this is a larger effort, involving far more than formula.  We should do this work, but do it right, and do it in a unified, coordinate way across ODF capabilities, not just formulas.  This might be something we can help with from the newly-formed ODF Adoption TC.


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