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 02/28/2006 12:51:51 PM:

> More importantly, there seems to be general agreement that the
> resulting formula spec MUST support BOTH constrained environments
> (like PDAs).  I think Dan Bricklin wants an even SMALLER base set.
> Yet if the "base" is tiny, or there's NO defined grouping, then
> either everyone has to implement EVERYTHING (no PDAs for you!)
> or the base is tiny (no interoperability for you!).

I don't agree with that logic.  Imagine you have a PDA spreadsheet.  Then you are given a valid ODF document which matches your subset of functionality.  You can read it and process it with no problems.  Any document you create on that implementation, is by default valid ODF and can be read by any ODF-compliant implementation.  Further if someone sends you a spreadsheet which you cannot handle, then you need to handle that as an error condition and degrade gracefully, notify the user, etc.  The task is the same whether you have levels or not.  It is the same today when exchanging documents between Excel and 1-2-3.  Any implementation which is less than a full implementation needs to check if the document it reads uses functions it does not support.  This applies to formulas, charts, styles, whatever.  This can not be avoided in a world of multiple implementations.  

I think the meta-requirement is that the functionality required to understand a document be easily discoverable by reading the document.  With that capability (which I believe we already have) then we support the reality that there are an infinite number of levels.  Everyone who downloads the OO source code and adds or removes a function can create their own "level".  The person who wants scientific computing on PDA has a different level than someone who wants financial functions on their cell phone.  Also, every implementation which allows custom, user-defined functions via script or binding to external code, allows a custom level.  

So, the question is do we want to elevate some sets of functions to official "levels" which we specify and carve in stone for an enduring standard?  Or do we want to encourage a more flexible approach, and allow vendors and users to discover "what works"?  Is the choice we make in levels a good choice for today, tomorrow and the day after?  Is this subcommittee the best place to determine what bundles of functionality are best used in a PDA spreadsheet? Or a Wiki? Or for a vertical application?  

Presumably an implementor knows their users/customers best and will give them the functions they want, regardless of what levels we define.  The real purpose of the spec is not to tell implementors what features they need to write, but to give them a common way to express the features they do decide to implement.  So, I think of the function specification as a cookbook.  You are not required to make every dish in the cookbook in order to be compliant, but if you use these function names in this namespace, then you must follow the syntax/semantics of that function definition.

The metadata discussions we've been having on the main TC list show the range of special-use ODF-editors which are being imagined.  We really need to think beyond the general-purpose monolithic desktop editors we have today.  There will be more than just a handful of implementations that will want to claim ODF compliance.  I'd rather not have us make problem domain level decisions for users and implementors about which functions are "basic" and which ones are "advanced" and define compliance based on those labels.  


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