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
- From: robert_weir@us.ibm.com
- To: office-formula@lists.oasis-open.org
- Date: Wed, 1 Mar 2006 18:46:50 -0500
"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.
-Rob
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]