Re: [office] Formula Sub Committee Draft Charter

[Michael Brauer - Sun Germany - ham02 - Hamburg <Michael.Brauer@Sun.COM>]

Robert,

robert_weir@us.ibm.com wrote On 01/30/06 22:13,:
> 
> 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
>  > ==================================================================
>  >

[...]

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

The table:formula attribute's value starts with a namespace prefix which 
determines the formula language that is used for the formula. Currently the 
OpenDocument specification does not specify a formula language itself, but 
applications may and have to use whatever formula language is apropriate for 
them. The namespace prefix indicates which formula language is used. So, I 
think formulas are implementation defined actually.

Anyway, what I wanted to say is that an application may still use an 
implementation defined formula language if the OpenDocument formula language 
is not sufficient, or if it is reasonable to use an implementation defined 
formula language for legacy or interoperability reasons.

I think we should provide this option, because otherwise the risk is very 
high that we define a formula language that is the superset of all or many 
existing languages, and that is very difficult to implement in the end.

We in my opinion also have to provide this option, because we would declare 
existing documents non-conformat otherwise.


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

I agree that we probably do not need the references to application defined 
formulas, but the above proposal means that one has to use the formula 
language we specify. That's something we in my opinion should not ask for, 
for the reasons I stated above.

My suggestion would be

"To create a specification for a formula language that may be used in 
OpenDocument spreadsheet documents as value of the table:formula attribute 
specified in section 8.1.3."

Or if we want that people use our formula language if ever possible:

"To create a specification for a formula language that should be used in 
OpenDocument spreadsheet documents as value of the table:formula attribute 
specified in section 8.1.3 where apropriate."

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

It's probably a good suggestion. Do you think we should add this to the charter?

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

Sounds good. Maybe we should replace "application" with "implementation"?

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

I think your suggestion sounds good as well. What I think we have to permit 
is for instance that our standard specifies the result of a function for 
integer parameters only, but that an implementation may provide determinstic 
results also for let's say string values by applying an implicit type 
conversion. If we declare the result of the function to be implementation 
specific if non-integer values are used as parameters, then this is possible. 
So, yes, your suggestion sounds good.

[...]
>  >
>  >    Proposed chair: [TBD]
>  >    Proposed secretary: [TBD]
>  >    Proposed editor: [TBD]
>  >
> 
> I believe David makes most sense as Chair.   I can volunteer as Editor.

We actually have two volunteers for the chair position, David and Eike. My 
proposal would be that we run the TC with two co-chairs, or a chair and a 
co-chair.


> 
> -Rob
> 

Best regards

Michael