OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

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


Subject: Re: [office] Formula Sub Committee Draft Charter


Here are a few comments on the draft charter.  Generally these
are comments agreeing with them.


> OpenDocument Spreadsheet Formula Sub Committee (FSC) Draft Charter
> ==================================================================
> 
> Statement of purpose
> --------------------
> To create a specification for a formula language which can be used in 
> OpenDocument v1.0 spreadsheet documents as value of the table:formula 
> attribute specified in section 8.1.3 in addition to the application 
> dependent formula languages that are supported by OpenDocument v1.0.

This is fine as written.  I hope that the resulting spec
could actually be used in MORE areas than table:formula.  But clearly,
it should be useful AT LEAST in table:formula.

...
> 2. It must specify a well defined processing model. The description of the
>    processing model  should be oriented on the description of processing
>    models of programming languages.

Agree, though we'll need to be careful about what we
mean by "well-defined", or we can spend all day fighting about
differences that users don't care about.
I don't think anyone is worrying about the
15th significant digit returned by ATAN().  And there are some
constructs (like "3"+3) that different applications disagree on.
I believe we should define semantics for even such cases, if
possible, but if we cannot achieve an agreement, it's better to
document where we cannot get agreement than to abandon the
effort altogether.


> 3. It must specify a basic function set. The basic function set must be
>    extendible in future versions of the specification.
>    [Note: Functions sets correspond to function or class libraries of
>    programming languages. The basic function set corresponds to the 
> build-in
>    function or class libraries of programming languages.]

Agree. I think you'd be better off defining a basic function set
and standard levels BEYOND that basic set.  That way, implementers
can have some notion of prioritization, and users can have an idea of
whether or not their data will port.

> 5. It must permit application specific extensions to the processing model.
>    [Note: Ideally, application specific formula languages can be 
> (re-)defined
>    as extensions to the formula language specified by this SC. This may
>    require extensions to the processing model, for instance implicit type
>    conversions.]

I'm not sure I understand this at all.
Is this "you can add new data types?"  Or "you can
make some required parameters optional?"
If you could explain what you mean here, I'd VERY much appreciate it.

> 6. It must be friendly to conversions from and to existing office 
> application
>    spreadsheet formula languages.

Yes.  I'd even add "... with existing spreadsheet data", just to
clarify that we are trying to make sure that people don't
lose their data!

> Deliverables
> ------------
> 1. A written specifications for spreadsheet formulas in plain English that
>    can be used with the OpenDocument v1.0 specification, and also can be
>    included into a future version of OpenDocument.

add "(at least by reference)".  Today's spreadsheets have a lot of
functions, and defining them all will make the OpenDocument spec weigh
even more :-(.  Also, I'd like to hold out the olive branch for a while.
Thus, I suggest starting off by making it a separate volume... it can be
incorporated into OpenDocument by volume number or by reference, without
making everyone print it.

> This specification shall
>    be delivered in two phases:
>    1. A specification for of the formula grammar (syntax).
>    2. A specification for the processing model and the basic function set
>      (semantic).

Change "the basic" to "a basic"; if the group agrees to
a levelled approach, then it's more obviously worded that way.


> 
> Scope of work
> -------------
> The subcommittee's work is to create a base specification for a 
> spreadsheet formula language to be used with OpenDocument. The 
> specification shall permit the creation of OpenDocument spreadsheet 
> documents whose formulas are exchangeable between applications.
> 
> Manner and schedule of work
> ---------------------------
> The work of the subcommittee will be primarily through conference calls 
> and a mail list set up by OASIS for subcommittee work. Access by the 
> public will be through an openly available mail list archive.

Add: "The group may decide to use other mechanisms, such as a Wiki."
[This doesn't presuppose WHERE that is, or IF it'll be used, but
let's at least allow the option.  OASIS rules will of course
take precedence.]

--- David A. Wheeler


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