Re: [office] Formula Sub Committee Draft Charter

[robert_weir@us.ibm.com]

Michael Brauer - Sun Germany - ham02 - Hamburg <Michael.Brauer@Sun.COM>
wrote on 01/17/2006 10:36:32 AM:


> 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. The formula
> language specified by this SC shall be usable in cases where none
of the 
> application dependent aspects of existing formula languages are required.
> 

I'd prefer something a bit stronger here.  In
some standards there is a distinction between these three things:

1) implementation-defined (implementation must choose
a behavior and document it) 
2) unspecified (implementation should choose a behavior
but is not required to document it)
3) undefined (anything can happen)

For example, ANSI/ISO C made this distinction.  The
size of an integer is implementation-defined, the value of the  __LINE__
preprocessor constant is unspecified, and deferencing a null pointer is
undefined.

Although we don't explicitly use this language, the
state of formulas in the ODF 1.0 specification is, in my opinion, unspecified.
 There is nothing in the specification which indicates that this is
something that which is or was intended to be implementation-defined.  So,
I'd be a little hesitant to even mention "the application dependent
formula languages that are supported by OpenDocument v1.0".  As
far as the specification is concerned, they does not even exist.  

So, I'd suggest wording this more simply like, "To
create a specification for a formula language to be used in OpenDocument
spreadsheet documents as value of the table:formula attribute specified
in section 8.1.3."


> The resulting specification must meet the following requirements.
> 
> 1. It must specify a grammar for formulas.

Suggest the grammar is done in ABNF form according
to IETF RFC 2234.


> 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.
>     [Note: Since office applications are implemented using
programming
>     languages, formula languages have the same platform
dependence regarding
>     the precision of float calculations as programming languages;
for this
>     reason, it seems to be reasonable to orient the the
processing model
>     specification on programming language specifications.]
> 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.]
> 4. It must permit application specific extension functions.
>     [Note: These correspond to additional function or class
libraries that are
>     deployed for interpreted programming languages.]


I'd go further -- "it must define a method to
reference application-defined extension functions".  In other
words, let the functions be application-defined, but be sure that the extension
mechanism (at the markup level) is specified. 

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

This one scares me.  I don't think we want to
encourage processing model extensions, do we?  Perhaps we can express
this as, "The specification will provide a list of implementation-defined,
unspecified and undefined behaviors in the processing model".  

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

I think this will occur naturally, with the give and
take of development of an open standard through a community process.  So
don't know if we need to make this an explicit requirement. 

> 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. 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).
> 
> 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.
> 
> Conference calls will be scheduled on a regular basis as agreed by
the sub 
> committee after its formation.
> 
>    Proposed chair: [TBD]
>    Proposed secretary: [TBD]
>    Proposed editor: [TBD]
> 

I believe David makes most sense as Chair.  
I can volunteer as Editor. 

-Rob