MHonArc v2.5.0b2 -->
office message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [office] Formula Sub Committee Draft Charter
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]