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


David A. Wheeler wrote On 02/03/06 04:54,:
> Here are a few comments on the draft charter.  Generally these
> are comments agreeing with them.
>> OpenDocument Spreadsheet Formula Sub Committee (FSC) Draft Charter
>> ==================================================================
>> 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.

If "to document" means to declare this implementation dependent, I agree to 
this. Actually, the reason I added that the reference to the processing 
models of programming languages is that these descriptions usually also do 
not guarentee that the result of the calculation is always exactly the same.

>> 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.

One may add levels at a later phase, but what I think is essential is that we 
get the basic function set, and that we don't delay our first specification 
by having discussions for functions that go beyond a basic function set. If 
turns out to be apropriate to divide even the basic function set into levels 
or classes, then it is of course okay to define something like this.

>> 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.

I've explained that in my previous mail.

>> 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!

I think that's naturally.
>> 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.

The term "including" here is related to the OpenDocument specification or 
standard itself. Whether this specification consists of one or more documents 
does not matter. The term "reference" in contrast to this may suggest that 
the formula specification is not part of OpenDocument itself. That's actually 
not want we want.

>> 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.

I have to admit that I don't see a difference between using "the" and "a" here:-)

>> 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.]

You are right. What about:

"The work of the subcommittee will be primarily through conference
calls and a mail list set up by OASIS for subcommittee work, or other IT 
tools provided by OASIS for TC work. Access by the public will be through an 
openly available mail list archive."


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