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 05:40:44 PM:

> robert_weir@us.ibm.com wrote:

> > 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.
> But they would immediately turn back to us and ask "can you write the
> formula spec so that we CAN profile it", and "what is a good initial
> set?"  We _ARE_ the people for formulas; there's no one to pass the buck
> to :-).  So let's give them the tools they need to profile formulas,
> should that effort ever come to pass, and include enough material so
> people don't HAVE to wait for a group that doesn't currently exist.
> > Think of XHTML and their modularization effort.
> Yes, that's what I'm thinking of.  But in order to have modules, the
> spec itself has to be written so that you CAN think in terms of
> modules.  If a later group wants to create OTHER profiles, GREAT.  But
> let's give them the tools so that they CAN define such profiles, and in
> case they never show, let's define a few starting profiles so that
> people can have useful profiles NOW.

We're converging here.  This is good.  I agree we need to provide the tools needed to define profiles.  But does this really require that we propose concrete profiles in the spec?  I'm really concerned that coming out with profiles here, before there has been an attempt at a more comprehensive modularization and compliance statement, will only tie our hands.  Modularization is not the type of thing that lends itself to a bottom-up approach.  If formulas defines 4 profiles, then metadata defines 3 profiles, and accessibility then defines 6 profiles, we don't end up with just 72 profiles.  We end up with chaos.  This needs to be solved top-down.

Also, I'm not sure we have the right people on this subcommittee for that effort.  For example, there may be parties who have no interest at all in defining a formula language, but would have high interest in defining a desktop profile (or other profile)for spreadsheet functionality.  These are really two different tasks.  The first is specifying a syntax and semantics for expressions.  The other is a determination of which functions logically belong together for a particular purpose (desktop use) and this is more a marketing than a technical question.  We have not been advertising this subcommittee as one which would be defining functional profiles for particular uses.

That said, we can certainly propose a basic set, or even multiple sets.  In fact we should do this.  But I believe this should be a communication to a modularization/conformance subcommittee or the ODF Adoption TC.  Again, the concern is prematurely tying our hands before we've fully thought through the ODF-wide ramifications and achieved consensus on a common approach to this common issue.


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